On Thu, Sep 09, 1999 at 05:42:47PM -0400, Brian Paul wrote:
> Michael I Gold wrote:
> > Technically, the same ptr should work for any compatible context, where I'd
> > define compatible as sharing the same Visual.
>
> I'm still not sure I see the reason for all this.
>
> If the address of an extension function depends on the context then that
> implies, for example, that
> &glPolygonOffsetEXT != glGetProcAddressEXT("glPolygonOffsetEXT")
> for some context(s).
>
> I think that's pretty weird. I've worked on an OpenGL application which
> deals with several simultaneous GL contexts. Extension handling is
> complicated enough without having to worry about context-dependant
> extension function pointers.
>
> It seems to me that just as glClear() is able to jump into the proper
> context-dependant subroutine, so should glPolygonOffsetEXT() or any
> other extension function.
Here's a scenario for analysis:
1. libGL ships supporting some set of extensions.
2. At a later time, vendor "A" updates their loadable driver module
with an "A"-specific extension. libGL knows nothing about this.
3. Application calls glGetProcAddress() for an direct "A" context
and it returns a pointer into libVendorA.so. Fine.
4. Vendor "B" decides this is a good extension and includes it in an
even later rev of their driver, libVendorB.so. libGL still hasn't
been updated.
5a. [FAILURE CASE] Application calls extension when a direct "B" context
is current, but using context-specific pointer for context "A".
libVendorA.so does not know anything about libVendorB.so. Incorrect
behavior necessarily results.
5b. Application obtains context-specific pointers for both "A" and
"B" and calls the "A" or "B" functions when "A" or "B" contexts
are current, respectively. Extension works properly.
One alternative would be to *require* all vendor extensions to
implement whatever libGL *would have* implemented were it updated to
directly support that extension, so that calling into the "A" pointer
gets redirected into the "B" driver. This seems technically challenging
and open to abuse.
Another alternative is for glGetProcAddress to dynamically extend
the libGL dispatch tables, dynamically synthesize entry points which
dispatch through those tables, and return a pointer to the resulting
hunk of code (Brett suggested this a few posts ago). This seems
hideously complex, and I don't know if it's even necessarily possible on
all architectures supporting Linux (does everyone have writeable code
space these days?). Of course the GLX dispatch table needs to be
extended on the server side as well, but that's a tractable task -
unrecognized GLX opcodes could be handed off to some standard entry
point in each driver.
A third alternative is to somehow convince all suppliers of libGL to
keep up with every possible extension shipped with every hardware
driver, and make sure that whenever the end user installs a new driver,
she also installs an updated libGL which knows about all extensions in
that driver. This presents few technical difficulties but I don't think
it's practical *in the general case* (it might be with reference to some
specific libGL).
Finally, ISVs could just restrict themselves to whatever entry
points happen to be in the libGL they're running under. This is a
copout, but might often happen - it imposes no additional burdens on
ISV, libGL supplier, or driver supplier.
Jon Leech
SGI
