----- Original Message -----
From: Michael I. Gold <[EMAIL PROTECTED]>
>
> In my mind there are two unresolved issues:
>
> 1) Whether or not returned pointers are context independent
>
> 2) Whether this is a GL extension or a GLX extension
>
> and I see the two as being peripherally related.
>
> 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.
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.
In considering exposing driver/context specific functions, there are a
series of questions we haven't even begun to ask, really. How far down the
dispatch process do we want to go in exposing driver specific functions? Are
we looking only to skip the libGL dispatch table, or do we want to go
further. In skipping the dispatch table do we defeat the use of the dispatch
table for "fast-path" tricks? How "unsafe" a function can or should be
exposed? For example should one expose a glVertex3fv without "begin/end"
testing or checking for immediate vs. display list? Are there some common
sets of these "expose lower level" functions that one than one vendor would
like to expose? Within a driver it may be convenient to handle 1st, 2nd,
and Nth vertex slightly differently. Is it reasonable to expose this sort of
specialized call s.t. the application writer assumes all responiblity for
making sure they don't confuse the card or crash the driver? Can it be done
w/o fracturing the API space and breeding endless incompatible extensions?
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.
