On Tue, 29 Jul 2003 13:58:58 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote: > > > Hi, > > > > as I'm going to clean up vsync related stuff on the config-0-0-1-branch > > I read the code for dynamic glx extension registration in > > xc/lib/GL/dri/dri_glx.c and xc/lib/GL/glx/glxextensions.[ch]. I stumbled > > over this comment in front of __glXRegisterExtensions: > > > > ** In older versions of libGL (prior to October 2002) we _always_ > > ** called this function during libGL start-up. Now, we only call > > ** it from glXGetProcAddress() as a last resort. > > > > However, __glXRegisterExtensions is still called in driCreateDisplay. > > Hmm, on the other hand I found this comment in radeon_screen.c in front > > of __driRegisterExtensions: > > > > /* This function is called by libGL.so as soon as libGL.so is loaded. > > * This is where we'd register new extension functions with the dispatcher. > > > > Do the __driRegisterExtensions functions in the drivers rely on being > > called during initialisation? > > > > In fact I believe it could be dangerous if __driRegisterExtensions was > > called later as it may override extensions disabled in e.g. > > CreateContext due to lacking hardware support. Fortunately > > __glXRegisterExtensions returns immediately if it is called the second > > or later time. Maybe it's just a matter of updating a few comments after > > all. > > I'm inclined to believe that the comments in dri_glx.c are just wrong. > __glXRegisterExtensions has to be called before a call to > glXGetProcAddress. The app can query that string via > glXQueryExtensionsString long before calling glXGetProcAddress. In > fact, it may never call glXGetProcAddress. I'm sure glxinfo doesn't. :) So this does influence which extensions are listed in the extension string, contradicting what Keith wrote? In that case I have one more question. How can this work with multi-head configurations where you can have multiple different cards (different screens) on one display. Then each driver will add or readd extensions. But they should never disable any extensions, right? You don't want drivers to disable each others extensions, do you? 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? Just my thoughts. I hope I'm wrong ;-) 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
