Re: [Dri-devel] Observations about dynamic extension registration

[Felix <fx...@gm...>]

On Thu, 31 Jul 2003 10:12:47 -0600
Brian Paul <br...@tu...> 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
 fx...@gm...       \___/   \___/   U        at the same time.