Michael I Gold wrote:
>
> 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.
Huh? The ability to generate GLX protocol for a given extension, and being
able to return a function pointer for an extension are completely orthogonal
issues. I don't see any reason why a driver would have to update libGL.so
to support a new extension, unless we make a really brain-dead implementation
of glXGetProcAddress that depends on a static dispatch table.
> >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.
?? Again, I don't think anyone has suggested such a restriction. I certainly
haven't, and unless I've really misread what Allen posted, he hasn't either.
> >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.
Your original assumption is correct.
Cheers!
--
Brett Johnson <[EMAIL PROTECTED]>
Workstation Systems Lab
Hewlett-Packard Company
"Politicians, like diapers, should be changed regularly,
and for the same reason."
