Brian Hook, bwh@idsoftware.com, http://www.idsoftware.com

There seems to be some confusion about the difference between an OpenGL
ICD, a "minidriver" a.k.a. MiniGL, and a "standalone" driver. So in my
quest to make everyone in the world less confused about matters OpenGL,
I'll do my bit.

Snarfle gri moor landi ganillish.

Okay, I needed everyone to be confused first, thus the above. So anyone
who wasn't confused better be confused now, at least temporarily.

Okay, you can stop being confused.

Oh...uh, wait, I was saying something. Oh yeah.

OpenGL drivers.

So here's the deal. OpenGL is not tied directly to any particular windowing
system such as Win32 or X or anything like that. Each operating/window system
provides what are known as "window system bindings" that act as the system
dependent interface between an OpenGL application and the underlying window
system.

Under X, for example, the bindings are part of a library called GLX, developed
by SGI and/or the OpenGL ARB (I think). Under Win32, the bindings were
developed by Microsoft, and are called WGL (pronounced "wiggle") for obvious
reasons.

These bindings control things like tying an OpenGL application to a specific
window, swapping buffers, and finding "pixelformats". In an OpenGL code
the "core" OpenGL code is completely portable, but the window system code
(i.e. GLX/WGL stuff) is not. That small system specific kernel is what
gets ported between platforms (e.g. from Mac to Linux to PC).

Now, under each operating system you have various "driver interfaces" that
an OpenGL driver adheres to in order to communicate with the OS and 
window system efficiently. Under Win32 there have been two different
prevalent driver interfaces: the ICD (Installable Client Driver) and the
MCD (Mini Client Driver). The latter is dead, but the former still lives
on.

When an OpenGL driver for Windows is said to be "an ICD", that means it 
adheres to the Microsoft ICD interface mechanism. Which means that
an application that links directly to OPENGL32.LIB and uses OPENGL32.DLL
and WGL will magically work with that driver with no muss and no fuss.

A "full ICD" is just that -- a complete OpenGL driver implementation that
supports all of OpenGL and that works with the standard driver interface
mechanism. A "full ICD" is the best type of driver we can hope for from
a vendor.

But, there's a problem: WGL was designed LONG before 3D graphics accelerators
were prevalent, and WGL definitely was not designed to take into account
3D-only accelerators such as Voodoo 2. This means that 3Dfx can NOT write
an ICD (note: ICD meaning "an OpenGL driver that uses the Microsoft ICD
mechanism") for the Voodoo 2 since the WGL bindings only understand the
concept of a single graphics accelerator. This rears its head as a serious
problem with systems with, say, a RivaTNT and a V2. If both accelerators
had an ICD, which one will an application use?! Fortunately (or not),
this isn't a problem since only a single ICD can exist in a system (note:
Direct3D doesn't have this problem since Microsoft cared enough about D3D to
support device enumeration. WGL could easily be revved to support this
feature, however Microsoft, for obvious reasons, doesn't really care to
see that happen.)

3Dfx CAN write a FULL OpenGL driver for the V2, however it won't be an
offical ICD because they can't hose the system's primary display device's 
ICD. That would be poor manners.

This puts 3Dfx in the position of having a complete OpenGL driver for 
Voodoo Graphics and Voodoo2, but that driver is NOT an ICD. It is what
we call a "standalone driver". A standalone driver is simply a full
OpenGL implementation that does not use the Microsoft ICD driver
interface mechanism because of technical inadequacies within WGL.

Quake3 only supports one standalone driver -- the 3Dfx Voodoo(2/Rush)
full OpenGL standalone driver.

Finally, there is the issue of a "minidriver". A "minidriver" is a
_partial_ OpenGL implementation designed to support only those OpenGL
calls that are performed by a few key OpenGL games such as GLQuake
and Quake2.

To an application, a "minidriver" and a "standalone driver" look
the same, the difference being that a standalone driver is a FULL
OpenGL implementation (theoretically suitable for use in any
OpenGL game, applications, etc.) whereas a minidriver is a PARTIAL 
OpenGL implementation that is suitable for only a very few games and
that will likely explode gloriously if asked to do anything but the
limited subset of operations it is optimized for.

Quake3 does not knowingly or willingly support minidrivers, however
there is nothing preventing someone from writing one. But this is
a moot issue, since to my knowledge no minidrivers exist that can
support Quake3.

SUMMARY:

OpenGL drivers can be either partial implementations ("minidrivers")
or full implementations ("compliant" or "conformant").

Win32 OpenGL drivers can support the Microsoft ICD mechanism or may
be "standalone" drivers.

Quake3 supports "complete OpenGL ICD drivers" and "3Dfx's complete
standalone driver". 3Dfx's OpenGL driver for V2 is not an ICD,
however it IS a complete/full OpenGL implementation. It is a
standalone driver, NOT a minidriver.

I hope that clears things up. I have a creepy feeling that the above
makes sense if you already knew it all, but if you didn't already know
it, then you're still probably confused. Either way, I tried.

Later.