Right, Jon's point, if I correctly parsed it, is valid. If extension
dispatching happens in libGL.so we unnecessarily introduce a second level
of indirection, which penalizes everyone. If we simply require the
application to track per-context function pointers, the extra indirection
is avoided. Note that a double indirection is still effectively required
for application which use multiple visuals (one in the app, one in the
drivers) but single visual apps (the common case, I believe) do not take
the hit. This matches the windows model, and I do not believe it can be
made any more efficient.
While on this topic, there is one annoying aspect of the windows model on
which we can improve - the location and format of the libGL.so dispatch
vector must be available to the driver so it can diddle the entries
directly. In fact I would propose that the driver itself supply the
dispatch vector through which libGL.so indirects. In the windows model the
driver calls a callback in the higher level code which copies the entire
dispatch state, even if only one entry point is changed! This has a
measurable impact on performance and encourages drivers to use runtime
conditionals instead of tweaking the dispatch. :-(
At 11:40 PM 9/15/99 -0700, you wrote:
>On Tue, Sep 14, 1999 at 09:42:38AM -0600, Brett Johnson wrote:
>[much elided]
>> Remember, the indirection has to happen in one form or another,
>> somewhere along the OpenGL pipeline. So I don't agree that doing the
>> indirection in the libGL is going to be a performance hit. In fact, I
>> think it can result in dramatic performance improvements if it's taken
>> advantage of by the driver writers.
>
> Not disagreeing with you, but using this as a jumping off point.
>
> There are two different indirections going on here. One is from the
>app to get to the proper per-context driver entry point (case addressed
>by gl?GetProcAddress), the second within a specific driver, to dispatch
>depending on the current GL state to routines which execute, compile
>into dlists, compile and execute, etc. (case addressed by your
>observations above). The second layer of dispatch can't be pulled up to
>application visibility and it's questionable how much exposure it could
>have to libGL in the case where libGL and the driver come from different
>sources.
>
> Here's my notional mental model of what dispatching must happen in
>two scenarios, leaving out the scenario where libGL.so synthesizes its
>own context-dependent indirection for dynamically obtained entry points,
>via something like the strawman code you proposed later in your mail:
>
> // Scenario for an entry point in libGL.so
> glFoo() // app makes call
> -> calls libGL.so:glFoo
> -> (*dispatch[context].glFoo)() // jump table based on context
> -> calls libDriver.so:__glFoo_driver_dispatch
> -> (*dispatch[state].glFoo)() // jump table based on GL state
> -> calls __glFoo_driver_MODE() // actually execute glFoo!
>
> // Scenario for an entry point not in libGL.so, in the case
> // where glGetProcAddress() returns context-dependent pointers
> glFooPtr = glGetProcAddress("glFoo")
> -> calls libDriver.so:glGetProcAddress("glFoo")
> -> returns pointer to libDriver.so:__glFoo_driver_dispatch
>
> (*glFooPtr)() // app makes call
> -> libDriver.so:__glFoo_driver_dispatch()
> -> (*dispatch[state].glFoo)() // jump table based on GL state
> -> calls __glFoo_driver_MODE() // actually execute glFoo!
>
> Jon Leech
> SGI
