On Wed, 30 Jul 2003 09:20:28 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
I see: C SPECIFICATION
const char * glXQueryExtensionsString( Display *dpy,
int screen )
I don't mean what the GLX specification says to do. I mean what our code actually implements. Internally there is a *single* *global* table & extension string. So it's not even tracking it per-display. It's worse than that. :(
Yeah, I was just pointing out how extension tracking is specified.
they are instead tracked per-display. This doesn't "matter" right now because we don't support the configuration that you describe (at least not as far as I know!). Each card would be it's own display.
Maybe these configs don't work for one reason or another, but the configuration framework was designed with this in mind and also the code in dri_glx.c handles the case of different drivers for different screens. I see two choices here, either glxextensions.c manages multiple screens itself or the four bitfields server/client_support/only are managed in __GLXscreenConfigsRec. In either case glXGetUsableExtensions would have to be told about the screen. A screen number in the first case or a __GLXscreenConfigsRec pointer in the second case.
Since glXGetUsableExtensions is only called from glXQueryExtensionsString (glxcmds.c, line 1416), that should be an easy change to make.
It gets more complicated with __glXEnableExtension. If it has to access per-screen extension information it would need some sort of a screen parameter too. As it's called by the driver, this is a binary compatibility problem. Furthermore it is called from __driRegisterExtensions which doesn't know the screen itself.
It is a binary compatabilty problem, but a minor one. Since no code with __glXEnableExtension has ever shipped with XFree86 (stable release or their CVS), our exposure is pretty low. Low enough that I wouldn't worry about it much. There is a pre-texmem code-path that was used by the R200 driver that needs to be maintained. I'm not sure how to keep that working.
The quick and dirty solution would be a global screen pointer that indicates the screen currently being configured.
A more invasive but more elegant solution is this:
I observed that glXQueryExtensionsString calls glXInitialize first which in turn loads and initializes the dri drivers (calls their createScreen functions). Thus, before an extension string is returned all drivers are initialized. So why not register extensions in the driver's createScreen function? The only reason I can see is the call to glXRegisterExtensions in glXGetProcAddress. Is there a good reason for not calling glXInitialize in glXGetProcAddress instead?
That's a really good idea. I think that solves most of the problems. Keith, do you have a problem with that change?
If not then this would kill two birds with one stone. We would know which screen we're dealing with when glXEnableExtension is called and we could enable extensions conditionally, depending on hardware support. We would have to add a new version of glXEnableExtension which takes a pointer to the GLXscreenConfigsRec or __DRIscreenRec (if we move the extension-related data structures there).
The bit-fields and next_bit would have to be copied to the __GLXscreenConfigsRec. We'd still want the global copies to track the initial state.
Isn't that just memset to 0?
No. It pulls some state from an internal table. Some extensions (like GLX_ARB_get_proc_address and GLX_EXT_visual_info) are enabled by default. Since this list of "on by default" extensions my change, the driver needs to pull in that initial state.
We'd also need to add an ext_list to the __GLXscreenConfigsRec to track extensions added by calling __glXAddExtension.
Ok.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
