OpenGL OS Comparison

A Comparison of OpenGL Technology across Different Operating Systems

Introduction

This article presents a summary of the differences between Microsoft Windows 9x, Windows NT 4.0, and Windows 2000 with respect to OpenGL ICDs (Installable Client Drivers). While it is true that 99% of the code is common between an ICD built for any of these operating systems, understanding the background behind the other 1% is helpful. In fact, given the knowledge provided by this article, it is possible to create a single ICD binary that runs on Windows 9x, Windows NT 4.0, and Windows 2000.

Overview

Historically, OpenGL support was divided between two components known as the client and the server. OpenGL originated in an environment that typically had a centralized machine acting as a server and numerous remote machines that were clients of that server - an architecture proven to work well within that established environment. However, since the introduction of OpenGL onto Windows-based platforms, the notion of client and server has changed somewhat. On a Windows-based platform with hardware OpenGL acceleration, the client is the ICD and the server is generally the display driver for the graphics card. The client is responsible for fielding the OpenGL API calls and the server is responsible for communicating with the hardware (among other mundane tasks).

The Differences

There are a few very fundamental differences in the ICD architecture between Windows 9x and Windows NT 4.0. Most of these differences involve which component (the client or the server) handles three particular Windows API calls: DrvDescribePixelFormat, DrvSetPixelFormat, and DrvSwapBuffers. In Windows 9x, these calls are dispatched to the client, or ICD, but in Windows NT 4.0, these calls are fielded by the server, or display driver.

Consequently, a Windows 9x ICD must include these three entry points and perform the related functionality while a Windows NT 4.0 ICD does not have these calls. Instead, the calls are located in the display driver and registered with the operating system accordingly. In addition, the Windows NT 4.0 display driver must support the OPENGL_GETINFO escape command, which simply returns some basic information about the OpenGL ICD.

The "Swap Hack"

DrvDescribePixelFormat performs the simple task of filling in a pixel format descriptor structure with information about the requested pixel format. Developers should have no problem enabling this function in either the Windows 9x ICD or the Windows NT 4.0 display driver. Likewise, DrvSetPixelFormat, which sets the pixel format for the given window, should also be relatively simple for developers to implement on both the Windows 9x ICD and the Windows NT 4.0 display driver. However, DrvSwapBuffers presents a bit of a problem since the contents of the back buffer must be copied to the visible portions of the window on the desktop (or primary surface). Depending upon the implementation of the ICD and server, this operation may take place in either component (I have personally worked on projects where the swap takes place in the display driver, but in the ICD DDK the swap takes place in the ICD). Typically, either the ICD or the server is capable of performing the swap, but not both (for a variety of reasons - either one or the other doesn't "know about" the buffers, or doesn't have access to the blitter, etc.).

Assuming the ICD performs the swap, how do swaps ever occur if the ICD is not instructed to do so directly under the Windows NT 4.0 architecture? Well, the ICD DDK contains a clever "hack" which allows the ICD to perform the swap in Windows NT 4.0. This hack relies completely on the knowledge that Windows implicitly calls glFinish immediately before calling DrvSwapBuffers. The glFinish code cleverly climbs the call stack to identify the source from which it was originally called. If glFinish was called by the operating system, then it performs a swap (this works because the very next call by the OS will be DrvSwapBuffers). If it was called directly by the application, then glFinish does not perform a swap.

This clever trick allows the Windows NT 4.0 display driver to virtually ignore the DrvSwapBuffers call. The only thing that it must do is return TRUE, indicating success.

Windows 2000

The Windows 2000 architecture is unique because it can mimic either Windows 9x or Windows NT 4.0 based on the ICD registry entry. In Windows 9x and Windows NT 4.0, the ICD registry entry consists of a single string value associating the name of the ICD with the name of the display driver. In the case of a single string value, the Windows 2000 registry entry may follow this same format since the ICD architecture will be the same as in Windows NT 4.0.

However, the Windows 2000 registry entry may also be in an alternate format. Instead of a single string value, the ICD entry may itself be a separate key. In this case, there are several new values under the key including the name and version of the ICD, as well as a "flags" value (currently only the LSB of the flags value is significant - all other bits must be set to zero). If the flags value is set to zero, then the Windows NT 4.0 architecture is used (the display driver handles the three calls discussed above). If the flags value is set to one, then the Windows 9x architecture is used (the ICD fields the calls). The document entitled opengl-icd.doc, located in the docs directory of the ICD DDK, contains a thorough explanation of this registry format. Regardless of the format of the registry (and the value of "flags" if using the alternate format), the Windows 2000 display driver must still support the OPENGL_GETINFO command.

NOTE: When developing the Windows 2000 ICD, Intelligraphics' developers observed that the "swap hack" did not work in its original setting under Windows 2000. Instead of investigating this issue, the problem was solved by mimicking the Windows 9x architecture, thereby allowing the ICD to handle the DrvSwapBuffers call. However, it is highly probable that the swap hack could be made to work under Windows 2000 with minimal effort.

Summary

As basic as this information is many of us tend to forget some aspect of the various operating system differences. This fact is especially true when a new version of Windows is released that is different from all previous versions, as is apparent with Windows 2000.

The file opengl-icd.doc (mentioned above) contains plenty of good information. Although somewhat dated, it should be used as a reference for all aspects of ICD development, including the differences between the various operating systems.