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.
