On Thu, Sep 09, 1999 at 01:59:49PM -0600, Thomas Roell wrote:
> I would strongly opt for having the few entry points that the OpenGL
> 1.1 SI added there, as well as the texturing extensions to OpenGL
> 1.0. Our experiance with customers who are proting down from other
> platforms has been that those are considered very core.
Works for me. I don't see glPolygonOffsetEXT in your list, though?
It's an interesting case because the semantic behavior actually changed
between the extension and the 1.1 feature. Another area to be very
careful of in implementation is GLX protocol generation, since
extensions and core features use different protocol.
> Also I would love to see the ARB_multitexture API entry points see to
> be available as directly callable functions, as those are VERY widely
> used.
Agreed.
> I would also love to have a stetement added that if GetProcAccessEXT()
> returns a non-NULL pointer to an extension function, that this does
> not imply that the extension is usable. The presence of an extension
> should be determinded by
> glGetString()/glXQueryExtensionsString(). Rationale is that a GLX
> based libGL.so has to have the encoding/decoding part for the
> extension, while the X-Server side 3D pipeline might not support the
> extension.
Yes, this is really important. Another way the assumption fails is
if the function is present in the base client library, but the driver
for a particular card does not support it.
> > Also, an emerging use of wglGetProcAddress() is to return pointers
> > to OpenGL 1.2 core functions. While this exact scenario is unlikely to
> > arise on Linux, we should still be very clear up front about whether
> > non-EXT functions can be queried.
>
> Please let's avoid this. It would be intresting to know as to why
> people are using this approach.
Until an updated OPENGL32.DLL is shipped with Windows, apps cannot
directly access the 1.2 entry points even if an ICD has them.
> > Also note that the returned pointer is only valid when the current
> > context is the same as the context to which the GL was connected when
> > the pointer was obtained.
>
> What is the rationale for this constraint ?
>
> Would this imply what for every context that is created a seperate
> pointer had to be queried ?
Mostly the rationale is support for heterogeneous multihead.
Extensions not in libGL will give back function pointers into the client
driver. It's unlikely that an implementation of an extension in one
card's driver would work for a different card. If there's an easy way
for the app to determine that two contexts both referred to the same
head, we could relax the constraint to that extent.
Jon Leech
SGI
