Ian Romanick wrote:
On Fri, Nov 15, 2002 at 07:45:21AM -0700, Brian Paul wrote:Jens Owen wrote:Ian Romanick wrote:Can I get a quick run-down of the GLX code so that I can know where to begin?
Most of the server side support for GLX proper is in:
xc/programs/Xserver/GL/glx
This provides the main extension for indirect rendering and interfaces with the "../dri" and another glue piece "../mesa/src/X", I think, to complete the server side support.
The client side support is in:
xc/lib/GL/glx
That's basically it. If you've got detailed questions I can try to answer them. Adding new extensions which just add new enum values is pretty simple. Adding new GL/GLX functions is more work since you have to implement the GLX encode/decode functions and server-side dispatch.I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI) first because implementing it in any of the drivers that supports the vblank syncing would be trivial. That way 99% of the work in not device dependent. :) In the R200 driver, the behavior of SGI_swap_control can be added by changing r200WaitForVBlank to do something like: if ( rmesa->swap_interval != 0 ) { vbl.type = DRM_VBLANK_ABSOLUTE; vbl.sequence = rmesa->vbl_seq + rmesa->swap_interval; } else if ( getenv("LIBGL_SYNC_REFRESH") ) { ... The only catch is that I can find NO documentation of the GLX protocol for it. Given that, I'm going to implement it for direct rendering contexts only. I believe that this could be done by either adding a new entry point to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec and adding a DRIswapInterval function to dri_util.c. I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look either like glXSwapBuffers or glXUseXFont (for their gc->isDirect cases, anyway).
You have two choices:
1. A dynamically registered extension
In October I implemented a new mechanism in libGL to allow runtime
addition of new GLX extensions (not just GL extensions as it did before).
This will allow new DRI drivers to better work with older libGL libraries.
Basically, the driver calls __glXRegisterGLXFunction() and
__glXRegisterGLXExtensionString() to tell libGL about a new GLX extension.
If the user calls glXGetProcAddressARB("glXFoobarEXT") they'll get a
pointer to the new extension. And calls to glXQueryExtensionStrings()
will return the string registered with __glXRegisterGLXExtensionString().
To pull this off, libGL has a list of function name/address structs:
static struct name_address_pair *Dynamic_GLX_functions = NULL;
which keeps track of the functions registered with __glXRegisterGLXFunction().
glXGetProcAddressARB() just searches that list.
So, in principle you could and a server-side-only GLX extension to
libGL without ever touching the libGL code. But you should really
put a glXSwapInterval() function in libGL so that one can directly
call it without needing glXGetProcAddressARB().
The new glXAllocateMemoryNV() function would be good to follow as an
example of this.
Your implementation of glXSwapInterval() should also search this list.
You can cache the result of the search if you want.
In the r200 driver you'd have an r200SwapInterval() function that
got called via the glXGetProcAddressFunction(). This function would
just store the interval value in the rmesa context struct (assuming
that this value is per-context state - the spec doesn't say!).
2. As a hard-coded extension
This would involve implementing glXSwapInterval() as an ordinary
function in libGL. It would simply stuff the interval value into
the __GLXContextRec struct (assuming it's per-context). Then, it
would be up to the DRI driver(s) to check if libGL was new enough
before grabbing that value from the context rec.
One problem with this approach is that the extension would appear
to be present for all drivers, when it really isn't. We'd need
a new mechanism for DRI drivers to enable/disable GLX extensions
in a manner similar to Mesa's _mesa_enable/disable_extension().
The other problem is it would require the user to have the updated
libGL.so in addition to the new r200_dri.so driver.
What needs to be done in programs/Xserver/GL/glx/?
Nothing for a client-side-only GLX extension. > How do I get the
Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.cextension string exported? This also applies to the GLX_ARB_get_proc_address string. :)
-Brian
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
