At 12:09 PM 10/21/99 -0700, you wrote:
>
>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?**
I have already stated that returned procs are likely driver-dependent and
context-independent within that driver. Unfortunately they are not driver
independent which is the real issue. If/when multimon OpenGL works on
Windows with two different cards in the system, the value returned from one
ICD will not work in the other ICD.
It is not required that contexts always return unique address, and most of
the time they do not. In fact I once proposed that the dependence be on
the Visual or PIXELFORMATDESCRIPTOR rather than on the context itself, so
all contexts created with the same Visual can generally share the pointer.
(pfd's in Windows are driver-specific)
>Windows already requires a two level jump table,
Unless I misunderstand, this is false. The ICD calls back into
opengl32.dll with the address of its dispatch table in an MS-dictated
format; opengl32.dll then copies the dispatch into its own table and there
is a one level jump. In an ideal world MS would simply use the ICD pointer
rather than copy the table, and dispatch table changes would be practically
free. But I guess they do an optimization to put some entry points
directly into TLS to speed up immediate mode calls.
Extensions are handled differently; the ICD maintains a one level jump
table which the application calls into, bypassing opengl32.dll completely.
Assuming the ICD's TLS lookup is efficient, the cost is comparable to the
core functions which are dispatched through opengl32.dll.
>why not take advantage of
>this to implement the lower one in a linux compatible way?
The problem is that opengl32.dll never handles extension dispatches, hence
there is no common higher level code which can own a driver-independent
dispatch.
>* 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.
Lets see, we could provide a standalone .lib which apps link against and
the mechanism could live there, but then wglMakeCurrent needs to go through
that library too, which then GetProcAddress the real wglMakeCurrent from
opengl32.dll. It may be possible to solve this but in kind of an icky way;
Windows developers need to link with a new .lib and the link order
matters... I can see a FAQ item in our future. We tried something similar
with SGI's OpenGL for Windows (overloading MS entry points) and it worked
but had a link order dependency which caused many people many lost hours
before they changed the FAQ or posted...I don't have fond memories of that
experience.
>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.
Ahh, I understand; with context dependent pointers you would have to go
through some level of pain to remain thread safe. Unfortunately if you
planned to support this code on Windows, you would already be required to
solve this problem. :(
>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.
It still seems like a good idea to notify the library when you change from
one context to the next, else it will have to re-validate all assumptions
on every call. Perhaps if the library is high-level enough you are
prepared to eat this cost.
>>
>> 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?
Hehe, tri-tip sounds good too! As long as we're going down this road, I
should mention that Costco has surprisingly good tri-tip. Maybe we can
stock up for the oglbase-discuss barbeque. :)
-- Michael
