Mike Houston (MH) : I started out with VRML, of all things, in high school. This was when VR was the next big thing and it was easy to understand and use starting out and the examples, books, and tutorials were great. The first APIs I used during my first real job as SDSC were OpenGL and Java3D on SGI Octanes, Reality Engines, Infinity Realities (big monster ones.. with some multi-screen quake playing from time to time). I lot of ideas in Java3D, good and bad, but some interesting lessons there. I did a little Glide work, more and more OpenGL, and then of course onto DirectX. Several home grown APIs during university work and of course more recently OpenCL and DirectCompute. Also a few scene graph based APIs along the way.

Andrew Lauritzen (AL) : I’m a fairly recent graphics geek compared to some, so while I used DirectDraw a bunch in the early years (direct framebuffer access before that), I didn’t really get into 3D APIs until around 2005 when I was in university. Being in the academic world, I started off with OpenGL 2.0. While this served me well for cross-platform work, I grew somewhat tired of the “legacy” situation in OpenGL. Thus I also used DirectX 9 a bit and the day that Vista was released I mostly switched to DirectX 10 due to the massively improved orthogonally and predictability of the API. Since then I do most of my work in DirectX 10+ with some occasional OpenGL when working on non-windows platforms.

2. In the past we had a throng of APIs, with each IHV trying to provide a low-level, optimal interface to its custom hardware – why do you think that particular approach failed and evolution took us along the path of the higher level APIs? What was the biggest issue which caused the end of the per-IHV API era?

MH : When you had as many players in the game when we were last looking at IHV specific APIs, it made it untenable for developers to build an application that could ship widely enough to make any money. Even though there are fewer players at the moment, although in the mobile space we are going to see an expansion, it's not realistic for a game developer to only build for one IHV or more specifically one generation of IHVs products. Higher level APIs provided more SW portability, which allowed developers to ship across a wider range of platforms with lower development costs. In the end it is really development costs that ended it.

AL : While there were many factors, I think most would agree that the game developers and ultimately their users drove the change. Compatibility was the primary concern: games only working on hardware from one vendor was bad for business. Licensing graphics engines was not as common as it is today and most developers had neither the time nor motivation to write a rendering backend for each hardware-specific API.

3. Should we look back to those times in order to attempt to predict the future? Are there any things that the “young” IHVs got absolutely right back then?

MH : Exposing "the metal" allows for rapid innovation to help figure out the various future HW and SW development paths to continue exploring down. Ironically, it's that drive and exploration that made many of the first standards work and have any longevity. Figure out all of the good ideas and put them together into a standard as best as possible.

AL : It is always useful to look at history, but I think several important things have changed since then that affect the situation. First, multiplatform games are now the norm, so most developers already have to deal with more than one graphics API and have developed infrastructure and expertise to that end. Furthermore it is common to license game engines today, due to their ever-increasing complexity.

4. If you'd have a call in designing a new API from scratch, which of the old APIs would you look at, if any? 3Dfx Glide, Rendition Redline, S3 MeTaL, IrisGL, Directx {n/n <= 4}, some other?

MH : For old APIs, remembering how OpenGL came to be and that it had a directed focus is an important lesson to remember. It tried to abstract the HW at the time but also attempt to map pretty direct onto what was being built at the time. So it provided an abstraction, but was close enough to how things worked in the real world that a developer had some expectation of why something worked well or didn’t. I think we have gotten into a place where we are adding things into some APIs that look good on paper or may expose some cool piece of hardware without really understanding the motivation and usage cases. But all APIs have lessons, good and bad, we should learn from. But no standard will ever be perfect for everyone.

AL : While some of the old graphics APIs are potentially interesting, I think the move to programmable shaders forced a rather major shift in design (for the better). Furthermore we’ve been moving to lower-level APIs in recent years and I see no reason to think that trend won’t continue.

5. There must be something you miss from the “early” days - what is it and why?

MH : I'm a bit of a hacker, so I do like low level access, however impractical it may be in general. I spent most of my university days making GPUs do unnatural things much to the dismay of some in industry. There are advantages of being able to get to everything in the hardware and differentiate from what others can do because you went through the effort and pain.

AL : There were brief stages during which specific things were more programmable or flexible in some useful ways, but overall I think we’ve made pretty solid forward progress. I’m not really too nostalgic for the old APIs.

6. Can you pick two favourite APIs, one old (e.g. IrisGL) and one “modern” (e.g. Directx8.1, Glide 3.0 or OpenGL 1.5) then tell us why you picked them?