The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Somebody explain to me how OpenGL ES implementations work

I'm a PC developer looking to get into development for OpenGL ES devices.

In the PC world, I used Direct3D. For Direct3D, there is a single SDK that you download from Microsoft and you develop your application against that SDK. Users can then take my Direct3D program and run it on any Direct3D-compliant hardware, and get hardware accelerated graphics - it doesn't matter whether their hardware is from ATI, Nvidia, Intel, etc. It "just works" on all hardware.

From what I have seen, this is not the case for OpenGL ES (I'm looking primarily at Windows Mobile, but I don't suppose it would be different for other platforms). That is, there doesn't seem to be a single, unified, OpenGL ES implementation anywhere. For example, PowerVR provides an implementation which only works on their hardware. Qualcomm provides another implementation which only works on their hardware. And so on. Considering the wide variety of hardware available which is OpenGL ES compliant, this seems like pure insanity.

Doesn't this mean that I will have to compile many, many different versions of my application? Or, at the very least, perform a runtime check to load the correct implementation depending on the hardware my program is running on?

On the PC, a Direct3D application can be hardware-agnostic. That is, it doesn't care what it's running on - Direct3D will forward your API calls to the driver and the driver deals with it (sends it to hardware for processing, or whatever). Why doesn't OpenGL ES work this way? Or am I misunderstanding the way OpenGL ES implementations work?

Re: Somebody explain to me how OpenGL ES implementations work

Direct3D uses the runtime model, i.e. the application talks to the Direct3D runtime provided by Microsoft, which talks to the graphics drivers provided by the GPU/graphics card/system manufacturer.

With OpenGL ES there is no common runtime, the application talks directly to the driver. This works fine as long as drivers from all vendors provide the same binary interface to the application. For Windows Mobile the drivers are provided as DLL and usually ship with the device. You just link your application against generic import libraries (e.g. libEGL.lib, libGLES_CM.lib, libGLESv2.lib), which perform the necessary steps to load the correct entry points from the DLL at runtime.

Re: Somebody explain to me how OpenGL ES implementations work

Thanks for the info.

So, if I use the standard Khronos headers, and link to the generic libraries as you mentioned, it will work on all hardware which ships with the necessary DLLs? If that's the case, then whose responsibility is it to provide these generic import libraries (eg. libGLESv2.lib)?

But instead of statically linked against libGLES*.lib, which can fail at runtime if the associated DLL is not here, I suggest you to have a look to the dynamic loader used in San Angeles Demo you can find in the OpenGL ES example section.