At 09:50 AM 11/10/99 -0700, Brett Johnson wrote:
>
>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.
I'm afraid you are a few days out of date on this one. Did you even read
my example which documents the failure case? The point is that there is no
way to determine if a returned function pointer would succeed for an
indirect renderer (i.e. is the GLX protocol support), even if it would
succeed for a direct renderer.
The solution, it turns out, is that the server side filters the
GL_EXTENSIONS string and removes and extensions which are not known to the
client side. While I agree that this solves the problem, it certainly was
not obvious to me that such filtering took place.
It makes little sense to go back and rehash this now, in light of this new
piece of information, but I assert that without it my concern was indeed
legitimate. Allen apparently agreed, hence his subsequent posts.
I still have concerns about the dispatch mechanism, btw. Who dictates the
dynamic order of the dispatch table? The client or the server? What
happens when one client talks to multiple servers, and multiple clients
talk to multiple servers? Who wins? I suspect I know the answer to this
one, but I'm still obviously uncomfortable with the can of worms we are
creating here, with IMO dubious benefit.
In any case, further discussion of the extension should now be moved to
opengl-arb-interest, for the next phase of the approval process.
-- Michael
