>
> Further, I am interested in a scheme which can work cross-platform, and it
> has already been demonstrated that context independence cannot
(reasonably)
> be achieved on Windows.
Wouldn't it be perfectly valid for a driver to return the same context
independent proc in wglGetProc for each context?* (unless it's in the wgl
spec that calling the "wrong" proc should generate an error). Since we're in
agreement that there is no performance degradation to do so, why not?**
Windows already requires a two level jump table, why not take advantage of
this to implement the lower one in a linux compatible way? Also given that
the source for a reference implementation of the context independence
approach will be readily available, much of the engineer effort to do so is
reduced also. Certainly the even the hard core free software folks would
agree to not having this bit of code not copyleft infect drivers, if it
means that by sharing this code it becomes simpler for graphics cards
developers to port drivers to Linux, right?
* this is a nice stealthy way to resolve the Microsoft won't do this, and
thus we can't take it to the ARB problem. If enough of the drivers support
the context indepent scheme it'll be a lot easier to get folks to agree to
standardize upon it... and it doesn't break the extant win codebase to do
so.
** actually I can think of at least one reason. An app with a "uses wrong
proc" bug would run fine on a driver with this feature, but fail on a card
without one.
>
> On a related note, Allen pointed out yesterday that my sample
> application-level per-context data structure which contains such things as
> the per-context extension pointers is not accessible from a general
purpose
> rendering library.
this is not my only concern. I certainly do not tend to write applications
with large amount of context specific "shadow" state, nor do I tend to test
for capabilities anywhere near the inner loop as your example seemed to
show. I tend to write "renderers" that have built in assumptions about the
desired output and the capabilities of the hardware and then choose between
them at a higher level in the code. Thus, only a small portion of the code
(perhaps only the initialization validating each of the possible renderers)
needs the details of the extension exsistance for each context. The actual
renderers would then only have to know about extension procs globally (i.e.
separate from any context specific information), and only those not expected
to be found in the users dll itself.
> While this is true, I must point out that (and I think
> Steve Baker mentioned this first) the library itself needs to know whether
> or not an extension is supported before it can call a context-independent
> function pointer, and therefore is required to maintain similar
per-context
> state. I still don't see how context independent pointers solves this
> problem, and if we cannot solve the whole problem its fruitless, nay, even
> misleading, to solve half of it.
A rendering library could be written to have an "isValid" method for each
render type (context specific), which the application could test when
changing the rendering type (or store in a context specific struct) -- or
more simply could simply be documented to have certain prerequisites.
This means that the rendering library could once at initialization time
fetch the full set of context independent procs it needs and never worry
about exsistance at all -- except in the isValid method. If the procs were
instead context dependent, then the library must create a dispatch table for
each context in which the renderer is to be used, requiring either explicit
initialization of the library for each context, and essentially creating a
context-independence layer within the library itself.
>
> Perhaps, Allen, its time we go to lunch and work this out. Anyone else
for
> a cheesesteak? =)
I'd love it we're I local. Santa Barbara is famous for it's tri-tip... road
trip anybody?
john
