The History of Linux3D.org

 This site is currently a history of my activities in Linux and 3D. It's really only serving as a place holder. It's autobiographical and therefore biased.It used to be the place where I stored some of my early work in supporting 3D for Linux, but it's value doing that has long since passed. It has some sentimental value to me, so I kept it and decided to put this site here instead. That leads me back to the question, why are you here?

3Dfx Voodoo Graphics

My work began with the 3Dfx Voodoo graphics card. That was the first consumer card that had reasonable 3D capabilities. It was a bit of an odd card. You would plug your standard 2D graphics card in to it, and then plug it in to your monitor. Normally it would pass through that 2D signal to your monitor, but when you fired up a 3D application, it would replce the 2D output with its own 3D output. That means it only ran in full screen 3D. In October of 1997, I did some research on 3Dfx and read up on their product and their manual. It mentioned that Linux support was TBD. That was enough of an opening for me to contact them. It turned out that they didn't have any Linux support, but they were open to the idea. 3Dfx used a library called Glide to access the hardware. I offered to port that Library to Linux, and after a period of negotiations, they agreed. It didn't take long to port the library, but it took months 3Dfx lawyers to approve releasing it anywhere. I wrote a device driver for the Linux kernel that allowed access to the Glide hardware and luckily 3Dfx had a fairly clean operating system layer that allowed me to hook Glide in t my device driver.

Once the library was ported it was possible to write full screen 3D applications, if you used Glide as your graphics interface. Although that's useful, it's far from being a standard. Luckily Brian Paul had written a library called Mesa which implemented the OpenGL API using a software renderer. But Brian was smart enough to write it in such a way that it was relatively easy to replace the software renderer with another implementation. A fellow in Italy, who's name I don't recall, did most of the work connecting the glide library to Mesa. Once that was complete, Glide itself because less relevant, because one could write software in OpenGL instead.

John Carmack, from Id Software, did just that with Quake. All of a sudden we had a 3D game (written in OpenGL) running on top of Mesa and using my port of the Glide library to get hardware acceleration.  In fact, our drivers were faster than the same libraries running under Windows, because of the lower overhead of the Linux kernel. Having a 3D game and OpenGL made Linux a viable platform for 3D graphics. In fact, Quantum3D which made simulators using 3Dfx hardware created a Linux version of their GEM system to Linux based on that work.

Titanic Render Farm

About the same time as the 3Dfx work, I was working for Digital Domain while they were working on the visual effects for Titanic. At that time we used a lot of computers without graphics displays in a configuration we called a render farm. Visual effects requires a lot fo computation to create computer graphics and to bring them together in to image. Those calculations used in making visual effects is collectively known as rendering. Creating a movie like Titanic requires a lot of rendering and therefore a lot of computers.

The typical workstation for doing this type of work was created by Silicon Graphics. They had a Unix operating system known as Irix. They used MIPS processors. They had high end graphics cards. Essentially all the digital artists used them for making the graphics for films. When Digital Domain looked to create the render farm for Titanic using SGI workstations/servers was an obvious choice, but those systems would be expensive. So I looked for alternatives.

Digital Domain had a Digital Equipment Corporation (DEC was later acquired by Compaq who was later acquired by HP) Alpha server. The software department had ported our major applications as had the vendors of some other software we needed. We had a chance to benchmark our applications on the Alpha and they ran great. The Alpha had extremely good floating point performance which was extremely important to our applications. We looked at using DEC workstations to make up our render farm. The cot of DEC Unix was high, but DEC was willing to make Digital Domain a good deal to lower the overall cost. That all looked really promising, until it turned out that we needed 160 workstations delivered in a period of two weeks. That means DEC needed to provide 20-30 workstation a day to Digital Domain. It turned out that DEC didn't have the production capability to do that.

At this point we started looking at another alternative to keep the costs down. Linux had been ported to the DEC Alpha processors, and in fact was able to run binaries compiled on for DEC Unix, if the appropriate libraries were available. So we took a few DEC workstations we had, installed Linux on them, and tried running our applications. We ran in to a bug with how the Linux kernel handed floating point emulation. I tracked down the bug and figured out which kernel instructions were causing the problem. Engineers working on Linux for Alpha provided a patch that fixed our problem and was  rolled in to the Linux kernel. Once that bug was fixed we found our applications ran great under Linux just as they did under DEC Unix. We ported all our applications to Linux and were up and running.

We eventually contacted a local white box vendor named DigitalScape to build the Alpha system for us. Bruce Faust from DigitalScape took great care of us, getting the systems put together for a great price and on the schedule we needed.  I built a master disk, DigitalScape installed on to each workstaiton when they were built. The system would then prompt the installer for a number, and that would be used to configure the system before it was delivered to Digital Domain. We had racks cabled up and ready as 10-20 machiens a day would arrive.We'd put them in a rack, attach the cables, and power them up. They'd be ready to use right away. The system spent months rendering 24 hours a day to make the movie Titanic.

Precision Insight and VA Linux Systems

A few years later I was contacted by a company called Precision Insight. They were a small consulting company that was creating a workstation quality version of OpenGL to run in the Linux X server, called the Direct Rendering Manager (DRM). The DRM would be open source and included in future versions of Linux. The early work for this was sponsored by SGI and Red Hat. Precision Insight had hired Brian Paul, the creator of Mesa, so they had an OpenGL implementation. They had also hired Kevin Martin, who was one of the team members of XFree.org who create the X server for Linux. Rik Faith was another quality software architect who was working on the project. They had seen the work I had done on the 3Dfx hardware and at Digital Domain, and thought I'd be a good addition. My first work for Precision Insight was to support 3Dfx hardware. PI was hired by 3Dfx. By this point 3Dfx had a card called the Banshee which did 2D and 3D, so it needed the support of the X server to be effective. 

Precision Insight was eventually bought by VA Linux Systems and became part of VA's professional services group. During that time the team grew, and ended up writing open source drivers for ATI, Intel, Matrox, 3Dfx, as well as several other X/OpenGL infrastructure projects for Lawrence Livermore National Labs. The team continued to improve Mesa's OpenGL implementation, the XFree86 X server, wrote the Linux AGP support, and a variety of other projects. Over this time I spent time as both an engineer and a manager. Eventually VA Linux decided to get out of the hardware business and shut down it's professional services devision. Most of that team went to Red Hat and Tungsten Graphics. 

Back to Hollywood

At this point I went back to Hollywood. I had done what I wanted by getting Linux used in the back end of Hollywood with my work on Titanic. I had built infrastructure that allowed Linux to be used as workstations by my work at Precision Insight. Now it was time for me to strike out on my own.I started Digital Ordnance. I took my experience at Digital Domain and earlier at Pacific Title and Art Studio and decided to make a Linux based product that would solve the film industries needs for real timeuncompressed 2k play back. My new product called the Frame Thrower does just that. We're still a small start up company. We've extended our Frame Thrower product to support digital cinema applications and now on set capture.

Looking Back and Looking Forward

When I look back at the work I did in late 1997, I think I must have been crazy. I was working a ton of hours on the 3Dfx product and on Titanic. I'm amazed that I managed, but I was driven.I was pashionate about moving the technology forward. I enjoyed being there at the very begining. It was important to consider my choices in my career and see if I could work on those goals. I found ways to combine my pashion with my career.

Now I sit back and look at what it's all become. I'm less directly involved, but I'm proud of what I've done. My company is working hard to push the technology forward and continue to make changes to Hollywood. Digital Ordnance has been around for five years now and I'm looking forward to looking back in another five and seeing what we've managed to do.