On Thu, 31 Jul 2003 10:12:47 -0600 Brian Paul <[EMAIL PROTECTED]> wrote:
> Keith Whitwell wrote: > > Ian Romanick wrote: > > > >> Felix Kühling wrote: > >> > >>> 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? > > > > > > Not off the top of my head. > > > > It's worth asking Brian about this, as he's had greater involvement in > > those paths than I. > > And Ian's made a lot of changes since I've worked in that code. I'm > not fully up to speed on it anymore. > > > You can't call __glXInitalize from in glXGetProcAddress because you > don't have a Display pointer. Right. glXRegisterExtensions doesn't need a display pointer. It loads the drivers for all displays and calls their __driRegisterExtensions methods. > Earlier, Felix wrote: > > > Do the __driRegisterExtensions functions in the drivers rely on > > being called during initialisation? > > Yes. > > The driver's __driRegisterExtensions() function can do two things: > > 1. Add new gl*() functions into the dispatch table. For example, if > libGL doesn't know anything about the GL_ARB_vertex_buffer_object > extension but the driver really does implement it, the driver can plug > in the glBindBufferARB(), etc functions into the dispatch table so the > app can use that extension. > > 2. The driver can register/enable new glX*() functions with libGL. > > In either case, this has to be done before the user gets the results > of glXGetProcAddressARB() or glXQueryExtensionsString(). Ok. So adding an extension basically involves two steps: 1. add some functions and tell glXGetProcAddress about them. 2. add the extension to the screen's extensions string. The new functions are globally visible and glXGetProcAddress returns the right pointer no matter if the extension is actually available as it can't know on which screen or display the function is going to be used. So we could split the process of adding an extension into the two steps above. __driRegisterExtension tells glXGetProcAddress about the new functions exported by the driver and __driCreateScreen (conditionally) adds something to the extension string of the correct screen. > > > Earlier, Felix wrote, and Ian followed up with: > > >> 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. > > I don't know the answer to this either. Then how am I supposed to know the answer ;-). But seriously, the safest thing is probably to call glXEnableExtension only in the driver's createScreen function so that the extensions string never changes while a GLX application is running (though I don't know if the spec requires this). Then there is probably no need to ever disable an extension later. > > -Brian > 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
