Jon Leech 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.
Hey, I think we're getting close to understanding one another! (I sure wish
I was better at communicating ideas ;o)
While it's true that some implementations currently have two indirections
(per context and driver-specific), I'm trying to point out that the
distinction between the two is artificial, and doesn't need to be there.
I.e. On x86, there only *needs* to be one indirection at call time (and
in fact, that's the case for HP's Windows drivers). IMHO, the biggest
reason that some implementations have two indirections is that there
currently isn't a simple way of managing the "context-specific"
indirection, so they just punt, and put up with the performance hit
inherent in adding another indirection (either that, or the underlying
graphics hardware is slow enough that an extra indirection doesn't affect
their performance).
So this problem is precisely what I'm proposing to solve. I suggest that
we make the dispatching API in libGL good enough that driver writers will
use it to manage their driver-specific indirection, and therefore do away
with the second layer of indirection you mentioned above. In the process,
we make it easy for gl*GetProcAddress to return a context-independant
function pointer.
Here's an example to illustrate what I have in mind:
Rather than just providing a spec that says where libGL.so should live, we
should provide the libGL.so itself, and turn libGL.so into nothing more than
a thin dispatch layer that "drivers" can plug into (this proposal would turn
Mesa into a "driver", for example). So imagine a simple libGL.so that
exported all of the OpenGL 1.2 entry points, and in addition, it exported
these entrypoints specifically for "driver" writers (Note: This is *NOT* an
API proposal. I think the actual API needs to be much more clever for
efficiency's sake. This is a rather simplified example, and it exists only
to help me communicate the idea I'm proposing. I'll be happy to propose an
actual API later, *after* I get folks to understand the general idea 8-):
DSPContext *glDSPCreateDispatchContext(void);
void glDSPDestroyDispatchContext(DSPContext *ctx);
void glDSPMakeDispatchContextCurrent(DSPContext *ctx);
void glDSPSetDispatchFunction(DSPContext *ctx, char *funcName, FuncPtr func);
/* Set up the dispatcher so that a call to "funcName" is dispatched to
"func". If "func" is NULL, dispatch to an empty function. */
So, rather than the driver maintaining its own internal dispatch tables, and
changing them on the fly depending on the current pipeline state, it could
use this (very efficient and elegant ;o) API to manage the dispatching,
and save an indirection at the same time. I think this is compelling enough
that it would encourage driver writers to actually use what we're doing here,
rather than just "rolling their own" libGL.so and dispatch mechanism.
> 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
So, given what I've proposed above, this would call "__glFoo_driver_MODE()"
directly, rather that indirectly through the "__glFoo_driver_dispatch"
function. Of course, driver writers would be free to add the extra indirection
if it was easier to do so and performance didn't matter...
> -> (*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
Instead, what I'm proposing is that "glGetProcAddress("glFoo")" would return
a pointer to "libGL.so:glFoo" (or given the strawman code I proposed earlier,
it would return "libGL.so:DSPJumpTable[glFoo_DSPoffset]").
> (*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
Cheers!
begin:vcard
n:Johnson;Brett
x-mozilla-html:FALSE
org:Hewlett-Packard;Worstation Systems Lab
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:WSL Turtle Master
fn:Brett Johnson
end:vcard
