| 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.
I suggested a long time ago (and yes, now I'm repeating myself) that
the protocol encode/decode functions be modularized in libGL.so so
that new protocol could be added without requiring a new libGL.so
(with driver implementations acting as providers). If you don't do
this, you have ensured that remote rendering with extensions will
always lag since a new libGL.so will be required for each extension
addition. It doesn't seem very difficult to accomplish and is
vaguely similar to jzulauf's suggestion.
| >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.
It seems like this is a solvable problem, just assign slots the
same way that other tokens are assigned. Again no need for a new libGL.so.
If I had my druthers, I would do the following:
1. context independent pointers
2. loadable glx protocol that can be packaged with individidual drivers.
3. Xserver queries drivers for their provisions at server initialize
(sure this doesn't handle hot-pluggable graphics, but I'm not
worried).
4. dispatch slots are fixed and assigned by some neutral party (perhaps
included in the extension spec)
5. if a pointer query fails for any reason, NULL is returned., or
change the query function to return a glx error as the function return
and the function pointer result as an out parameter.
6. No support for obtaining protocol support from a remote server, but
null drivers can be added to the system with additional protocol support.
If you don't like 3., change things so that the glx protocol modules are
packaged independently from the director renderer and the first glx
request loads all of the modules. Since all new extensions functions
include glx implementations, all functions should be available for query
without needing to load the direct renders.
-db
