At 12:35 AM 11/8/99 -0800, Jon Leech wrote:
> Here's a strawman mechanism to address the earlier objection about
>needing to query each driver DSO even if you don't use them: each DSO
>has a parallel flat-text file listing known extensions it exports.
>Server config mechanism identifies these along w/driver DSOs, or they
>use a consistent naming convention, or they get collapsed into a single
>registry by some external mechanism. GLX reads all of them on server
>startup and a priori knows all possible extensions supported by the
>client.
Have we decided that glXGetProcAddress takes a Display parameter? The
returned pointer may indeed be context independent but it is now also
server dependent. Consider the following scenario:
- Application wants to render to windows on two seperate displays, A and B.
- A is local to the app, B is remote
- Both servers support extension GL_EXT_foo
- App queries glFooEXT() from GLX client - succeeds
- App queries extension string from server B
- App calls glFooEXT() when trying to render to B
This will fail if the local client is unaware of the protocol for
glFooEXT(), and there is _no_ way for the app to predict this.
It comes down to this: unless we want display-specific proc addresses (in
which case we might as well go with context specific procs because the
"independence" has been lost), GetProcAddress must fail for any extension
pointer which is not known to the GLX, even when rendering locally.
Indeed, this simplifies the mechanism for maintaining the dispatch table as
well.
I am going to make one more appeal for context dependent pointers now. If
a local direct renderer supports an extension which is unknown to the GLX,
it can return a valid context-dependent pointer. If a remote server
supports an extension but the local GLX does not, a context-dependent query
will fail. This brings a bit of sanity to the picture and allows direct
renderers to expose new extensions without requiring an updated GLX, and
makes things no worse but more predictable for indirect rendering.
Even adding a dpy to glXGetProcAddress won't solve this, btw, because you
can mix direct and indirect rendering on the same display.
