Michael and I have been discussing this over the phone.
We agree (I think :-)) that the objections Michael raised are resolved
if the GLX protocol codec for glGetString() intersects the set of
extensions the client knows with the set of extensions the server
knows, and returns that intersection to the app.
My recollection was that GLX already did this intersection operation,
because a mismatch between GLX encoder, server, and local driver could
cause a problem even in the days before GetProcAddress. However,
Michael took a quick look at the code and didn't see anything
performing the operation, so I could be mistaken.
I've taken the liberty of copying Paula Womack, since I think she's
the one who told me about the need for the intersection operation
several years ago. Paula, does any of this ring a bell?
Allen
| At 01:23 PM 11/8/99 -0800, you wrote:
| >
| >The GLX extension-query mechanism returns the intersection of the
| >extensions supported by the server and the extensions supported by the
| >local GLX encoder. So there's no way for a client to be told that a
| >remote extension exists if the local GLX encoder is unable to generate
| >the protocol.
|
| You have now restricted the utility of glXGetProcAddress; it only supports
| extension which are known to the GLX implementation. If you load up a
| driver on your local system and it supports a new extension, you must also
| obtain a new libGL.so which knows about the extensions, assuming one is
| available. With context dependent pointers you would have no such
| restriction for direct rendering.
|
| >As for the function pointers, I wouldn't expect any substantial
| >difference between the local and remote cases. For a remote context,
| >the local GLX encoder just presents the same function dispatch table
| >that a local driver would present.
|
| Aye, and its easier to impement since you have just added the restriction
| that extension procs must be known to the GLX, which means that they must
| be registered and assigned a known dispatch table index. No more
| indirection in the driver, it always knows which dispatch slot gets the
| updated function pointer.
|
| Any vendor wishing to publish a new extension must update libgl.so with the
| new entries, and anyone wanting to use it must grab a new libgl.so. While
| this was always true for indirect rendering contexts, it now applies to
| direct renderers as well. I see this as a burden for the end user, as well
| as whoever maintains libGL.so, and that individual now becomes a bottleneck
| for all extensions for all vendors.
|
| >If the client app calls a function
| >that the GLX encoder doesn't support, then it gets the same behavior
| >that it would if it called a function that a local driver doesn't
| >support. (No-op or abort(), depending on the outcome of our
| >investigations into calling sequences.)
|
| >What have I missed?
|
| I guess I was operating under the assumption that glXGetProcAddress was
| supposed to be no less functional that wglGetProcAddress. The latter has
| an advantage that new extensions are available without requiring a new
| opengl32.dll.
|
|
|
|
