In your message of 9 September 1999 you write:
> 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.
Good analysis. Let's also add the fact that this is ONLY a problem
scenario if you are running a multihead scenario with different
adapters.
If it also ONLY a problem if the extension requires a new function to
be accessable, rather then only extending the semantics of a given
function by adding a few new tokens.
So far so good. But how many extensions are out there that add new
functions but do not require some very fundamental structural changes
in the underlying libGL ? What I'm trying to get at is, whether we are
dealing with a real problem, or just a theoretical one.
> 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.
Actually that is pretty easy to do. You simply build your libGL with a
bunch of "spare-entires", which simply consist of indirect jumps (no
calls) throu some free slots in the dispatch table. Having 100 such
entries doesn't cost much and should be sufficcient.
> 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).
*smile* This is pretty much how we will handle that issue. Actually,
this raises the issue of whether by default the drivers are supplied
with a matching libGL ?
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
