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?

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.

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)?

Using Khronos OpenGL ES API Registry and Khronos API Implementers Guide, you should be able to build your own custom OpenGL ES for Windows Mobile SDK-like.

I’ve did it and documented on this forum post here.

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.