----- Original Message -----
From: Bob Beretta <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 17, 1999 9:38 AM
Subject: Re: [oglbase-discuss] GL_EXT_get_proc_address: API considerations
only
> Hi All,
>
> Let's rein this back a little. It has been adequately proven (to me) that
both
> context-specific and context-independent specs *can* be implemented
> successfully and with equivalent run-time efficiency. If we can agree on
> that, we can drop the implementation discussion and concentrate on what
> is the right thing to do in terms of the OpenGL API.
>
> Shall we try to have a more concise discussion addressing just the API
> considerations?
>
>
this is of course the correct point of view. I think what is causing some of
the conflicting opinions is that the getProcAddress extension is being
overloaded in terms of it's desired functionality. Some see it as a "forward
compatibility" features, other see it as a fast path feature.
To some the purpose of the EXT is to allow a driver to supply a previously
unknow extension, and allow the application to access it as if it were one
of the known extensions. Thus the idea of having a layer of indirection for
the unknown extensions is acceptable, since that is already the case for the
known extension. That the entry point for a unknown extension to need to be
managed differently by the application than that of a known extension, would
seem to require fairly broad awareness within the application of which
extension were "known" and which were "unknown". If the known and unknown
extensions have the same semantics (they are both context independant) then
only the initialzation code need ever know this difference. For example one
might in their initialization code want to
if ( check_for_FOO_EXT_in_glGetString)
#ifdef SOME_SYMBOL_THAT_SAYS_FOO_EXT_IS_IN_THE_DOT_H
fooExtProc = glFooExt
#else
fooExtProc = glGetProcAddressEXT("FOO_EXT")
#endif
else
fooExtProc = safeNoopOrMaybeErrorProc
endif
And then the application can blithely use fooExtProc portably from on
platform to another, as if it were a known proc.
To others the purpose of the getProcAddress is to provide the "real" pointer
to the "real" function. With some history to back this up (e.g. the IM_
macros for IRIS GL on the 2000 and 3000 series SGI) one can correctly claim
that there is valid reason for wanting such "fast-path" procs. Assuming one
has hardware that directly implements the OpenGL pipeline. One could
imagine a driver supplied proc that simply shoved a vertex token-data pair
directly onto the card (or into the DMA buffer, etc.) with out testing for
begin/end, display list vs. immediate mode or ANYTHING. This is going to be
faster than going through libGL no matter how good the dispatch table is.
Exposing this functionality could result in higher application performance.
There is MUCH to be said for such avoidance of per-call overhead. The open
question is as to whether this has advantages over compiled display lists
which outweigh the risks and disadvantages
It is my opinion that it is the former "forward compatibility" feature
which is most urgently needed -- and the correct scope of the glGetProcEXT.
However, one could certainly entertain further getProc type extensions for
the performance critical applications (and risk tolerant) which returns a
"real function" is certainly a potentially useful -- e.g.
glGetContextProcEXT and glGetDriverContextIMProcEXT (or the additional of a
proc-type argument to glGetProcEXT) to return context specific general or
context specific immediate-mode procs.
I hope I have help clarify the potential source of the conflicting opinions
regarding glGetProcEXT and offered some means for resolution and consensus.
John M. Zulauf
