Discussion:
eglGetProcAddress
(too old to reply)
s***@gmail.com
2013-09-13 20:28:19 UTC
Permalink
The EGL specification (with the KHR_get_all_proc_addresses extension) says the following:

"Client API function pointers returned by eglGetProcAddress are independent of the display and the currently bound client API context, and may be used by any client API context which supports the function."

But how can this be? Suppose a system contains two physical displays, driven from two different video cards produced by different manufacturers with different drivers. The function pointers obtained for a context bound to screen A would point to the driver for video card A, whereas those for a context on screen B would point to the driver for video card B, violating the requirement. This would seem to imply that some sort of 'stub' code would have to be provided by EGL to perform a dispatch into the 'real' code based on the current context, defeating the whole point of the extensions to begin with.

Can anyone provide any clarifications?

-sb
Nobody
2013-09-14 08:58:54 UTC
Permalink
Post by s***@gmail.com
"Client API function pointers returned by eglGetProcAddress are
independent of the display and the currently bound client API context, and
may be used by any client API context which supports the function."
But how can this be? Suppose a system contains two physical displays,
driven from two different video cards produced by different manufacturers
with different drivers. The function pointers obtained for a context
bound to screen A would point to the driver for video card A, whereas
those for a context on screen B would point to the driver for video card
B, violating the requirement.
The pointers point to functions within EGL, not the driver, so
eglGetProcAddress() is closer to e.g. dlsym(), GetProcAddress() or
glXGetProcAddress() than wglGetProcAddress().
Post by s***@gmail.com
This would seem to imply that some sort of 'stub' code would have to be
provided by EGL to perform a dispatch into the 'real' code based on the
current context,
Indeed.
Post by s***@gmail.com
defeating the whole point of the extensions to begin with.
The KHR_get_all_proc_addresses extension removes the constraint that
queried functions must be extensions. This allows an application to use
OpenGL ES 2, OpenGL ES 3, or desktop OpenGL, with the actual
implementation determined at run time.
s***@gmail.com
2013-09-14 14:07:23 UTC
Permalink
Post by Nobody
The pointers point to functions within EGL, not the driver, so
eglGetProcAddress() is closer to e.g. dlsym(), GetProcAddress() or
glXGetProcAddress() than wglGetProcAddress().
But for something like OpenGL 3+, all functions must be loaded dynamically. So that means an EGL implementation supporting OpenGL 3+ must provide a stub for every single OpenGL core (and extension) function.

Apart from being a lot of work, the real concern would be that the client is inherently linked to the version of the client API that the EGL implementation supports. I.E. if some hypothetical EGL implementation supplies stub code for all the OpenGL 4.3 core functions and extensions, then that implementation can't be used for any new extensions or OpenGL 4.4 core functions until it's upgraded to provide the new stubs, despite the functionality being in the driver. That just seems unnecessarily limiting, since if that requirement wasn't there, any EGL implementation would be fully forward compatible. Off the top of my head, I can't even recall if there is a way to query which specific version of a client API an EGL implementation supports.

Thank you for your response.

-sb

Loading...