At 09:20 PM 9/19/99 -0700, you wrote:
>
>> If we are going to allow context-independent pointers, then this MUST be a
>> GLX extension. If its a GL extension, it doesn't make any sense
>> semantically to allow the same value to be used with other contexts.
>
>I'm a bit baffled by your view of a returned proc as a bit of ordinary
>OpenGL state. Noting that the returned proc is returned primarily for
>"forward compatibility" reasons, it seems far more sensible to treat the
>pointers returned for "unknown" extension procs as it is they were the same
>as the addresses of the known extensions (i.e. those in the .h / .so the
>application compiled and linked with) than to treat them as OpenGL state.
Consider an indirect rendering context - the returned pointer is by
necessity part of the client side GLX support, not specific to the context
being called. Thinking of the returned pointer as part of the window
system bindings rather than as context state has softened my position on
this whole issue, but crystalized the fact that we're talking about GLX
stuff not GL stuff. Remember that GL is a rendering API, and everything
that falls into the cracks has traditionally been part of the window system
bindings.
Furthermore, if we make this a GL extension, we have to accept up front
that context independence can never be achieved on Windows because of the
existing driver interface and the fact that MS won't be motivated to
implement such a complex dispatching scheme (problem is already solved there).
>I can see a valid, useful role for context/driver specific procs -- but more
>as a route to reduce the call overhead, by-pass error or state checking,
>and/or expose some of the functionality the display-lists are using
>internally (c.f. previous post's historical reference to IM_ macros for the
>IRIS 2000-3000 series) However, I believe this role isn't clearly defined or
>understood in such a way as to specified to the ARB in any multivendor sense
>at this point.
I'm not even thinking about these kinds of hacky shortcuts, just standard
calling conventions, error checking etc.
>I think until we've talked about these issues (and others) we shouldn't go
>down the road of the context specific procs (in terms of the OpenGL
>standard) -- and as such shouldn't slow the "forward compability" features
>of the glGetProc as currently discussed by adding this issue into the mix.
When you talk of context dependent function you are going off in an
entirely different direction than I was thinking about. To me it just
makes sense that a direct rendering context can return a pointer to an
internal function which wraps the dispatch entry in a standard way,
basically the same as the libGL entry points for core functions. It
simplifies the implementation considerably, IMO, and gives consistent
performance.
