On Thu, Sep 09, 1999 at 10:45:21AM +0100, Bernd Kreimeier wrote:
> > 3.2. The libraries should be located
>
> It's safe to assume that a lot of apps will ship with
> there own copies (Q1/Q2/Q3A style) and load.
Then they've taken themselves outside the scope of this proposal.
> > 3.4. Entry points supported by these libraries must include either of:
> > * All OpenGL 1.1, GLU 1.2, and GLX 1.2 entry points
> > * All OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture entry points
>
> (Dumb) question: does GLX physically belong into libGL?
That's the way it's typically provided on Unix implementations. In a
mixed direct/indirect rendering implementation, which is where we're
headed, the gl* entry points are likely to be implemented in a way
closely intertwined with GLX (e.g. glVertex3f makes use of GLX internals
to generate protocol for the X server or to dispatch the call to a
direct rendering clientside driver).
> Another dumb question: requiring *one* extension as
> standard entry point? I don't think EXTensions should
> be required at all.
*OpenGL* does not require this extension. The *proposed standard*
requires this extension. Without it, you can't cope with other
extensions in loadable drivers easily.
> > 3.5. void (*glGetProcAddressEXT(GLubyte *))(...);
>
> In the port I am currently working on, I keep the Win32
> mechanism of LoadLibrary/GetProcAddress (dlopen/dlsym)
> which is used for the entire API. I can switch between
> TNT and Voodoo on the same box easily.
>
> As we will load instead of link, we do this anyway. Is
> it a good idea to provide this inside GL? If the drivers
> are indeed separate DLL's, I can see the need. But this
> is not GL?
Nothing on Windows guarantees that you can load ICDs directly
without using the OPENGL32.DLL dispatcher, and this is even less likely
to work in the analogous case on Linux. OpenGL rendering will typically
be broken up among a kernel module, an X server module, and an X client
library. The client library is the only thing the app could load. The
kernel and server modules will be managed by XFree86 and DRI, or
possibly equivalents in other implementations.
> > extensions can always be added to hardware drivers after
> > the base link libraries are released. These drivers are
> > dynamically loaded by libGL,
>
> How does libGL map a (number of) unknown (at libGL compile
> time) extension function names to an equally unknown driver
> DLL name, and load that - on query? On glGetProcAddress?
Query GL_EXTENSIONS string to identify supported extensions, then
query entry points corresponding to extensions used by the app.
> I doubt that people will just link against libGL as present
> on the system already. I also see issues with running 2 or
> more different OpenGL's, e.g. one in software, one on a
> Voodoo2, and one on a TNT main display.
Once again: if they don't play by the rules of the ABI standard
we're creating, they can't make use of it. Maybe everyone doesn't want
to play and this whole effort is irrelevant, but I think it's pretty
clear that there are plenty of companies and OSS projects who want to
play.
Most ISVs are *not* going to go to extraordinary lengths like using
dlopen(), shipping their own 3D drivers, etc. The handful who are don't
need our help; our job is to make it as easy as possible for the rest. I
for one want to see a huge variety of open source and commercial
software that "just works" with whatever the underlying OpenGL is.
> > 4.4. glextGetProcAddress()
>
> See above.
> This is a simple wrapper around dlsym(). Is loading of
Not quite, although it might appear so at first glance. It must
figure out which driver module to obtain the entry point from and there
very well may be a translation step involved depending on how the driver
exports its entry points. It is not at all obvious that the driver
should export names such as 'glVertex3f', and the abstraction layer
introduced by glGetProcAddressEXT() makes this possible.
> drivers is implicit here? If people use this as a
> shortcut to circumvent query for extensions on glGetString
> level, it will be trouble.
Definitely true, and it will be documented as such.
Jon Leech
SGI
