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. 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? 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? > We'd also need to add an ext_list to the > __GLXscreenConfigsRec to track extensions added by calling > __glXAddExtension. Ok. > > >>>Consequently __glXDisableExtension should never be called (or better not > >>>even exist ;-). And the only way to disable an extension is to not > >>>enable it. Thus, if you don't want to enable the swap-interval > >>>extensions if the hardware can't support them (no IRQs) then you have to > >>>know whether IRQs work at the time __driRegisterExtensions is called. Is > >>>that possible? > >> > >>Now there's an interesting point. The bigger problem is that the driver > >>might not have a chance to call __glXDisableExtension until *after* the > >>app has called glXQueryExtensionsString. At that point the extension > >>string cannot be changed. I'm not sure what the right answer is here. > > > > Ok, so we have to know which extensions to enable before a driver is > > initialized in its createScreenFunc. Sounds tough :-/ > > Agreed. I think for the most part we can enable the extensions, but > just have them fail when used. That's a little better than nothing. Maybe we can do better than that. See above :) Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- 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
