PDA

View Full Version : Trying to understand where EGL fits in the stack



charlie mac
02-04-2010, 08:59 AM
hello, I have a few questions about EGL and how it fits into the OpenGL/Khronos stack overall. I've read the overview page but I'm still left with these questions:
Is EGL only for OpenGL ES or can a full OpenGL 2.x/3.x context be used? If EGL can be used on the desktop, is its window manager interface functionality intended to abstract the differences in GLX, WGL, and whatever the Mac OS equivalent is ? Or could it replace all 3 of those together?

Alfonse Reinheart
02-04-2010, 11:49 AM
Is EGL only for OpenGL ES or can a full OpenGL 2.x/3.x context be used?

Only for GL ES.

Jon Leech (oddhack)
02-04-2010, 06:43 PM
Is EGL only for OpenGL ES or can a full OpenGL 2.x/3.x context be used?


The EGL context creation API has functionality defined for both GL and ES contexts, but most implementations of EGL exist on mobile devices where only OpenGL ES is available. There is an EGL (1.1, I think) implementation available in the Gallium3D driver infrastructure the Mesa folks are developing as well.


If EGL can be used on the desktop, is its window manager interface functionality intended to abstract the differences in GLX, WGL, and whatever the Mac OS equivalent is ? Or could it replace all 3 of those together?

Yes, that is the intent. EGL started with the GLX API and then was genericized to replace X Windows-specific concepts with (hopefully) portable equivalents. EGL has also been evolving into a more significant role as the resource manager when using multiple Khronos APIs together, especially through the EGLImage family of extensions. OpenGL / ES, OpenVG, and OpenWF all can interact with or make use of EGL already, and there is work underway to extend that to more of our APIs.

There is an increasing amount of interest within Khronos in making EGL available on desktop platforms and I think you will be hearing more about this later in 2010 (don't treat this as a promise from Khronos, it's just my personal take on a direction we're heading in).

Of course there are already EGL wrappers that sit on top of desktop GLX and WGL, which can be useful for learning and porting older apps - but that sort of layering cannot support more recent EGL functionality. Stuff like EGLImage needs to be done via hooks deep into the graphics drivers to get good performance. Hopefully the Gallium3D EGL implementation will also grow to support this sort of functionality over time.