Skip navigation

Tag Archives: OpenGL

This is part three; part one is OpenGL, part two is Early 3D hardware.

As the team continued to work on improving OpenGL’s capabilities, another graphics technology effort – DirectX – had also been moving forward in parallel. In this earlier era at Microsoft, it was not uncommon to have overlapping product efforts, or even efforts the competed directly against each other. The prevailing attitude about such cases was to let the market decide. DirectX was focused on enabling games on Microsoft’s Windows 95 consumer operating system. DirectX got its start as a 2D-based technology providing game developers direct access to the graphics card’s frame buffer. This was very useful functionality up to a certain point, but games like Doom and Quake made it clear that 3D graphics would play a dominant role in the future of interactive games.

Microsoft purchased one of the few available software-based 3D APIs – Rendermorphics’ Reality Lab – early in 1995. The goal was to jumpstart the addition of 3D graphics capabilities to DirectX by incorporating the Reality Lab technology. I was asked to do the technical due diligence of the Reality Lab stack.

Unlike OpenGL, Reality Lab was a scene graph API. This meant that the full geometric representation of a 3D environment was fed to the API. Based on the viewer’s position and other variables, the scene graph engine would compute the necessary details for rendering the objects in the 3D environment all the way down to the individual primitives rendered at the end of the pipeline. As a scene graph API, I thought Reality Lab was pretty good, but it seemed to me an odd match for the intended game developer audience.

Games like Doom and Quake built their own engines for rendering 3D environments, and these engines were highly optimized and specialized for the game’s specific characteristics. What most game developers were looking for was a lower-level immediate-mode 3D API that allowed them to plug their game engines at the stage of processing where primitives were ready to be rendered.

directx_logoDirectX hoped to satisfy this need by providing a mechanism for developers to pre-construct lists of low-level graphics primitives that could then be handed to the graphics card driver to execute. In theory, this allowed direct hardware execution of 3D primitives. In practice, the interface was cumbersome and difficult to use, provided no performance benefit for all the extra trouble, and had limited functionality compared to OpenGL.

What game programmers like John Carmack were discovering was that OpenGL already provided a clean, efficient immediate-mode 3D API that could be used very effectively for game development as well as non-game applications. Whereas DirectX required adhering to overhead-inducing COM-based protocols, OpenGL was a clean, straightforward, well-documented C API.

The game developer community tends to be data-driven and immune to market-speak and spin; their bullshit detectors can be exceptionally good. They were being told to use DirectX for 3D games, but they wanted to use something proven that already existed and just worked. John Carmack’s observations on the topic is still a good read.

More and more developers were coming to Microsoft and demanding that it fully support OpenGL on both Windows NT and Windows 95. The technical work for Windows 95 had already been done, and hardware vendors work working with a pre-release version of the OpenGL MCD driver development kit anticipating final release. Developers wanted the OpenGL driver update for Windows 95 released as soon as possible.

An influential group of game developers even banded together and signed an open letter to Microsoft asking that OpenGL be fully supported on both Windows NT and Windows 95.

This was not how it was supposed to work out. DirectX was supposed to be Microsoft’s consumer graphics technology, and OpenGL was supposed to be “just” for high-end CAD for non-consumer markets. But the reality was that visualization technology didn’t care about somewhat arbitrary market segmentations: a good 3D API was a good 3D API. Many developers felt that OpenGL was the best 3D API at the time and wanted to use it for their games. This has been described as a religious issue, but game developers simply wanted tools that would help them get their work done.

Microsoft was in a tough spot. It now had two competing efforts on its hands, and it couldn’t simply kill either. OpenGL was necessary for continuing to compete in the workstation market, and DirectX was its high-profile brand and technology for enabling PC games. And while OpenGL was an external standard, Microsoft owned DirectX and was free to shape it on its own. Even though Direct3D had gotten off to a rough start, Microsoft couldn’t afford to retrench from DirectX.

The open letter had pushed things to a crisis point, and shortly after it went public I had a meeting with the senior manager in Windows whose task had recently become to clean up the OpenGL/Direct3D mess. I remember the central point of the conversation was that I was being asked to take responsibility for both OpenGL and DirectX graphics and to focus on ensuring that DirectX improved as quickly as possible while continuing to support OpenGL for non-game applications.

This would mean a number of things for me. I would have to leave programming as anything other than an occasional hobby since I would have my hands more than full with providing engineering leadership. I would never see my MCD driver work available in the much larger Windows 95/98 market. And I would also have to disappoint a large contingent of game developers who had hoped for a different outcome.

Of course I could have gone and worked on something else, but that would have served no constructive purpose. Microsoft was sticking with DirectX graphics, and the best thing for developers, users, graphics vendors, and Microsoft was to make DirectX as good as possible. Combining the OpenGL and DirectX graphics development efforts was probably the best way to achieve that; the OpenGL team had at this point a deep bench of 3D graphics talent.

So I said yes, and began the hard work of integrating and re-balancing the teams and getting people on board with a slightly awkward new mission and new priorities.

Over the course of the next three years we steadily improved DirectX. I felt we had finally accomplished our goal of building a world-class 3D API when we released DirectX 8.

The experience was a formative one for me. I had to step outside the emotions surrounding the situation to find a way to make the greatest positive contribution possible. I had to earn the trust of a new team that had viewed my team and me as the enemy. And I had to take something that I felt was technologically inferior and make it great.

But great challenges can provide great opportunities…


A couple of years into my work on OpenGL I was given responsibility for running the OpenGL team as the dev lead. The team – like many of Microsoft’s development efforts back then – was small enough so that I could continue to have a hands-on role in coding while being the team’s manager. Although I knew that I would have less time to code, I was comforted knowing that I wouldn’t have to leave it behind completely. I was excited to have the opportunity to lead the OpenGL development effort but also apprehensive about managing people, especially people who had been my peers.

By this time, I had turned my focus to enabling graphics hardware to accelerate OpenGL performance. Although OpenGL on Windows already had an available hardware acceleration model – the Installable Client Driver, or ICD – it required the hardware vendor to license the OpenGL technology from SGI. In addition to that obstacle, developing an ICD was also complex; it required implementing the entire OpenGL API stack rather than just the parts that the hardware could accelerate. The specific method for accelerating the parts that made sense for some specific piece of hardware was entirely up to the vendor to design and implement from scratch. There was no common template or protocol or framework to follow. This approach provided maximum flexibility but at a very high implementation and maintenance cost. An ICD vendor wasn’t simply maintaining a device driver; they were maintaining an entirely separate implementation of all of OpenGL. OpenGL ICDs and the Windows OS kernel had a mechanism to exchange chunks of generic data which allowed the hardware portion of the ICD to communicate with the rest of the ICD implementation. Again, this was very flexible but also meant that every vendor had to come up with their own custom approach to structuring the communications between client mode (where regular programs ran) and kernel mode (the trusted execution environment where the OS and hardware-level drivers executed).

At the time, ICDs were fine for their intended target of high-end workstations. But my passion was to continue to push 3D graphics into the mainstream. A number of hardware vendors had become interested in providing dedicated 3D-acceleration hardware at lower cost, and given Moore’s Law and the volume-based economics of the PC business, hardware-accelerated 3D graphics was well positioned for mass adoption. To help move things forward, I wanted to make it much easier for hardware vendors who were new to 3D to bring their products to market. The difficulty and investment required to write an ICD driver was a significant obstacle to an emerging ecosystem of commodity 3D hardware.

Having done a bunch of driver work in the past, I set out to architect an OpenGL driver model that would provide a standardized interface to lower-cost hardware and remove as much of the software complexity of ICDs as possible. I focused on exposing only the functionality that lower-cost hardware could reasonably support, namely, the rasterizing of 3D primitives near the bottom of a complex 3D graphics pipeline. For example, 3D transformations and lighting operations would be done on behalf of the driver; the driver just had to render the computed 3D primitives on the screen. This division of labor could provide massive increases in overall graphics performance.

I called the driver model the Mini Client Driver, or “MCD” since it was similar in flow to an ICD, but the vendor only had to implement the rendering-specific part of the OpenGL stack.

S3 VirgeI wrote a corresponding sample driver (if I remember correctly, it used S3’s Virge hardware), and with the help of the OpenGL team, got the sample code and the corresponding MCD documentation into the next releases of Windows NT DDK (Driver Development Kit).

It’s worth making a few comments on driver development in general. Writing driver code can be one of the most satisfying and frustrating experiences possible as a developer. It’s incredibly exciting to have a new driver you’re building to actually do something useful with a piece of hardware for the first time (for example, rendering a test triangle on the screen). But drivers run as part of the operating system, so bugs and driver crashes can take down the whole OS. And with graphics drivers in particular, you always risk screwing up the thing you rely on the most to program and interact with the machine – the display. Add to this the fact that hardware doesn’t always work as documented, and that it’s very easy to miss setting the needed bit on some register or to have an off-by-one or some other error send the hardware into oblivion.

With enough persistence, lots of reboots, and the occasional debug print when all else fails, a robust driver will eventually emerge. And with any luck, you will never hear about your device driver because the only time that you do is when it’s NOT working. As with so many jobs in technology, writing drivers can be a thankless and invisible job despite being critical to making the technology we take for granted actually work.

Back to the main story: having released MCD for Windows NT, any graphics card vendor could now quickly and relatively easily implement OpenGL hardware acceleration using a standard driver model. Since the driver model itself was largely OS-agnostic, I then shifted our focus to providing a Windows 95 version of ICD to satisfy both growing developer and hardware vendor interest in OpenGL and 3D graphics. Windows NT had a growing but still relatively small share of the market compared to Windows 95, and I wanted to see OpenGL fully enabled on both operating systems. We engaged the hardware community around making OpenGL MCD drivers available on Windows 95, got the Windows 95 version of the code up and running quickly, and everyone was expecting the DDK update to be released very soon.

And then, I was asked to do something that would change everything.