glXGetProcAddress -- Useless In Practice?
rutski89
dlsym() to fetch a function would not get the job done, and where
glXGetProcAddress() would HAVE to be used instead.
And I'm not looking for an answer describing the general circumstances
under which function foo() or function bar() would have to be fetched
via glXGetProcAddress(), I'm looking for actual examples of real
functions.
Just very curious,
-Patrick
fungus
Why, exactly? What's the problem with glXGetProcAddress()?
fungus
OK, serious answer...
In *theory* it could break, as you suspect,
there's nothing to force driver writers
to expose the functions for dlsym().
In practice I wouldn't do it for a serious
program. The only people who have an excuse
for doing that sort of thing are the people
who write 4k intros.
My tip would to be have a single function
in your program which loads extensions.
That way you can easily change it if something
breaks.
Wolfgang.Draxinger
schrieb rutski89 <ruts...@gmail.com>:
That's a simple one: Say you have more than one GPU installed in your
system, and they're all of different kinds. And each GPU requires it's
very own driver. On windows opengl32.dll is just a dispatcher forwarding
the calls to the ICD responsible for the respective GPU. Similarily on
*nices. While libGL.so is still vendor dependent it may support
different GPU models from the same vendor in different code paths. So
each for each GL context glXGetProcAddress may give you different
pointers to identical names GL procedures.
TL:DR function pointers returned by glXProcAddress are tied to the
context, they may very well differ from symbol addresses obtained via
dlsym(), and in fact dlsym() may not return anything at all if
something is an extension.
Wolfgang
Nobody
> TL:DR function pointers returned by glXProcAddress are tied to the
> context,
This contradicts the GLX specification, which says:
GL function pointers returned by glXGetProcAddress are independent of the
currently bound context and may be used by any context which supports the
extension.
If a GL function is just a wrapper which dispatches to a driver-specific
function, glXGetProcAddress() should return a pointer to the wrapper, not
any underlying function.
Requiring the functions to be tied to a context would rule out using a
GLX extension to create the context in the first place.
OTOH, wglGetProcAddress() behaves as described, i.e. the functions are
tied to a specific context.
FWIW, the main reason for using glXGetProcAddress() is that it's part of
the GLX specification, while dlsym() is platform-specific (some platforms
have different functions for dynamic loading, while other platforms may
not even have dynamic libraries).
Also, an implementation isn't required to provide extensions via a
symbol with the appropriate name exported from libGL. It's free to make
extension functions "static" (or not exported, or exported under a
different name) and thus only accessible via a pointer returned from
glXGetProcAddress().