The Evolution of Direct3D

Posted on July 22, 2013 by TheSaint in DirectXFiles, GPU Programming, Graphics

*UPDATE:  Be sure to read the comment thread at the end of this blog, the discussion got interesting.

It’s been many years since I worked on Direct3D and over the years the technology has evolved dramatically.  Modern GPU hardware has changed tremendously over the years achieving processing power and capabilities way beyond anything I dreamed of having access to in my lifetime.  The evolution of the modern GPU is the result of many fascinating market forces but the one I know best and find most interesting was the influence that Direct3D had on the new generation GPU’s that support thousands of processing cores, billions of transistors more than the host CPU and are many times faster at most applications.  I’ve told a lot of funny and political stories about how Direct3D was created but I would like to document some of the history of how the Direct3D architecture came about and the profound influence that architecture had on modern consumer GPU’s.

Published here with this article is the original DirectX 2 documentation for Direct3D when it was first introduced in 1995.  Contained in this document is an architecture vision for 3D hardware acceleration that was largely responsible for shaping the modern GPU into the incredibly powerful, increasingly general purpose ubiquitous consumer supercomputers we see today.

D3DOVER

The reason I got into computer graphics was NOT an interest in gaming, it was an interest in computational simulation of physics.  I studied 3D at Siggraph conferences in the late 1980’s because I wanted to understand how to approach simulating quantum mechanics, chemistry and biological systems computationally.  Simulating light interactions with materials was all the rage at Siggraph back then so I learned 3D.  Understanding 3D mathematics and light physics made me a graphics and color expert which got me a career in the publishing industry early on creating PostScript RIP’s (Raster Image Processors).  I worked with a team of engineers in Cambridge England creating software solutions for printing screened color graphics before the invention of continuous tone printing.  That expertise got me recruited by Microsoft in the early 1990’s to re-design the Windows 95 and Windows NT print architecture to be more competitive with Apple’s superior capabilities at that time.  My career came full circle back to 3D when, an initiative I started with a few friends to re-design the Windows graphics and media architecture (DirectX) to support real-time gaming and video applications, resulted in gaming becoming hugely strategic to Microsoft.  Sony introduced 3D in a consumer game console (the Playstation 1) and being responsible for DirectX it was incumbent on us to find a 3D solution for Windows as well.

For me, the challenge in formulating a 3D strategy for consumer gaming for Microsoft was an economic one.  What approach to consumer 3D should Microsoft take to create a vibrant competitive market for consumer 3D hardware that was both affordable to consumers AND future proof?  The complexity of simulating 3D graphics realistically in real-time was so far beyond our capabilities in that era that there was NO hope of choosing a solution that was anything short of an ugly hack that would produce “good enough” 3D for games while being very far removed from the mathematically ideal solutions we had little hope of seeing implemented in the real-world during our careers.

Up until that point only commercial solutions for 3D hardware were for CAD (Computer Aided Design) applications.  These solutions worked fine for people who could afford hundred thousand dollar work stations.  Although the OpenGL API was the only “standard” for 3D API’s that the market had, it had not been designed with video game applications in mind.  For example, texture mapping, an essential technique for producing realistic graphics was not a priority for CAD models which needed to be functional, not look cool.  Rich dynamic lighting was also important to games but not as important to CAD applications.  High precision was far more important to CAD applications than gaming.  Most importantly OpenGL was not designed for real-time highly interactive graphics that used off-screen page buffering to avoid video tearing artifacts during rendering.   It was not that the OpenGL API could not be adapted to handle these features for gaming, simply that it’s actual market implementation on expensive workstations did not suggest any elegant path to a $200 consumer gaming card.

TRPS15In the early 1990’s computer RAM was very expensive, as such, early consumer 3D hardware designs optimized for minimal RAM requirements.  The Sony Playstation 1 optimized for this problem by using a 3D hardware solution that did not rely on a memory intensive data structure called a Z-buffer, instead they used a polygon level sorting algorithm that produced ugly intersections between moving joints.  The “Painters algorithm” approach to 3D was very fast and required little RAM.  It was an ugly but pragmatic approach for gaming that would have been utterly unacceptable for CAD applications.

In formulating the architecture for Direct3D we were faced with enumerable similar difficult choices.  We wanted the leading Windows graphics vendors of the time; ATI, Cirrus, Trident, S3, Matrox and many others to be able to compete with one another for rapid innovation in 3D hardware without creating utter market chaos.  The technical solution that Microsoft’s OpenGL team espoused via Michael Abrash was a driver model called 3DDDI (3D Device Driver Interface).  3DDDI was a very simple flat driver model that just supported the hardware acceleration of 3D rasterization.  The complex mathematics associated with transforming and lighting a 3D scene were left to the CPU.  3DDDI used “capability bits” to specify additional hardware rendering features (like filtering) that consumer graphics card makers could optionally implement.  The problem with 3DDDI was that it invited problems for game developers out of the gate.  There were so many cap-bits that every game would either have to support an innumerable number of unspecified hardware feature combinations to take advantage of every possible way that hardware vendors might choose to design their chips producing an untestable number of possible consumer hardware configurations and a huge amount of redundant art assets that games would have to lug around to look good on any given device OR games would revert to using a simple set of common 3D features supported by everyone and there would be NO competitive advantage for hardware companies to support new 3D capabilities that did not have instant market penetration.   The OpenGL crowd at Microsoft didn’t see this as a big problem because in their world everyone just bought a $100,000 workstation that supported everything they needed.

The realization that we could not get what we needed from the OpenGL team was one of the primary reasons we decided to create a NEW 3D API just for gaming.  It had nothing to do with the API, but with the driver architecture underneath because we needed to create a competitive market that didn’t result in chaos.  In this respect the Direct3D API was not an alternative to the OpenGL API, it was a driver API designed for the sole economic purpose of creating a competitive market for consumer 3D hardware.  In other words, the Direct3D API was not shaped by “technical” requirements so much as economic ones.  In this respect the Direct3D API was revolutionary in several interesting ways that had nothing to do with the API itself but rather the driver architecture it would rely on.

When we decided to acquire a 3D team to build Direct3D I was chartered with surveying the market for candidate companies with the right expertise to help us build the API we needed.  As I have previously recounted we looked at Epic Games (creators of the UnReal engine), Criterion (later acquired by EA), Argonaut and finally Rendermorphics.  We chose Rendermorphics (based in London) because of the large number of quality 3D engineers the company employed and because the founder, Servan Kiondijian, had a very clear vision of how consumer 3D drivers should be designed for maximum future compatibility and innovation.  The first implementation of Direct3D was rudimentary but the API quickly evolved towards something with much greater future potential.

D3DOVER lhanded

Whoops!

My principal memory from that period was a meeting in which I, as the resident 3D expert on the DirectX team, was asked to choose a handedness for the Direct3D API.  I chose a left handed coordinate system, in part out of personal preference.  I remember it now only because it was an arbitrary choice that caused no end of grief for years afterwards as all other graphics authoring tools adopted the right handed coordinate system standard to OpenGL.  At the time nobody knew or believed that a CAD tool like Autodesk would evolve to become the standard tool for authoring game graphics.  Microsoft had acquired SoftImage with the intention of displacing Autodesk and Maya anyway.  Whoops…

The early Direct3D HAL (Hardware Abstraction Layer) was designed in an interesting way.  It was structured vertically into three stages.

DX 2 HAL

The highest most abstract layer was the transformation layer, the middle layer was dedicated to lighting calculations and the bottom layer was for rasterization of the finally transformed and lit polygons into depth sorted pixels.  The idea behind this vertical driver structure was to provide a relatively rigid feature path for hardware vendors to innovate along.  They could differentiate their products from one another by designing hardware that accelerated increasingly higher layers of the 3D pipeline resulting in greater performance and realism without incompatibilities or a sprawling matrix of configurations for games to test against or requiring redundant art assets.   Since the Direct3D API created by Rendermorphics provided a “pretty fast” software implementation for any functionality not accelerated by the hardware, game developers could focus on the Direct3D API without worrying about myriad permutations of incompatible 3D hardware capabilities.   At least that was the theory.  Unfortunately like the 3DDDI driver specification, Direct3D still included capability bits designed to enable hardware features that were not part of the vertical acceleration path.  Although I actively objected to the tendency of Direct3D to accumulate capability bits, the team felt extraordinary competitive pressure from Microsoft’s own OpenGL group and from the hardware vendors to support them.

The hardware companies, seeking a competitive advantage for their own products, would threaten to support and promote OpenGL to game developers because the OpenGL driver model supported capability bits that enabled them to create features for their hardware that nobody else supported.  It was common (and still is) for the hardware OEM’s to pay game developers to adopt features of their hardware unique to their products but incompatible with the installed base of gaming hardware, forcing consumers to constantly upgrade their graphics cards to play the latest PC games.  Game developers alternately hated capability bits because of their complexity and incompatibilities but wanted to take the marketing dollars from the hardware OEM’s to support “non-standard” 3D features.

Overall I viewed this dynamic as destructive to a healthy PC gaming economy and advocated resisting the trend regardless of what the OpenGL people or OEM’s wanted.   I believed that creating a stable consistent consumer market for PC games was more important than appeasing the hardware OEM’s.  As such as I was a  strong advocate of the relatively rigid vertical Direct3D pipeline and a proponent of only introducing API features that we expected to become universal over time.  I freely confess that this view implied significant constraints on innovation in other areas and a placed a high burden of market prescience on the Direct3D team.

The result, in my estimation, was pretty good.  The Direct3D fixed function pipeline, as it was known, produced a very rich and growing PC game market with many healthy competitors through to DirectX 7.0 and the early 2000’s.  The PC game market boomed and grew to be the largest game market on Earth.  It also resulted in a very interesting change in the GPU hardware architecture over time.

Had the Direct3D HAL been a flat driver model for rasterization with just capability bits as the OpenGL team at Microsoft had advocated, 3D hardware makers would have competed by accelerating just the bottom layer of the 3D rendering pipeline and adding differentiating features to their hardware via capability bits that were incompatible with their competitors.  The result of introducing the vertical layered HAL architecture was that 3D hardware vendors were all encouraged to add features to their GPU’s more consistent with general purpose CPU architectures, namely very fast floating point operations, in a consistent way.  Thus consumer GPU’s evolved over the years to increasingly resemble general purpose CPU’s… with one major difference.  Because the 3D fixed function pipeline was rigid, the Direct3D architecture afforded very little opportunity for frequent code branching as CPU’s are designed to optimize for.  GPU’s achieved their amazing performance and parallelism in part by being free to assume that little or no code branching would ever occur inside a Direct3D graphics pipeline.  Thus instead of evolving one giant monolithic CPU core that has massive numbers of transistors dedicated to efficient branch prediction as an Intel CPU has, a Direct3D GPU has hundreds to thousands of simple CPU like cores that have no branch prediction.  They can chew through a calculation at incredible speed confident in the knowledge that they will not be interrupted by code branching or random memory accesses to slow them down.

Up through DirectX 7.0 the underlying parallelism of the GPU was hidden from the game.  As far as the game was concerned some hardware was just faster than other hardware but the game shouldn’t have to worry about how or why.  The early DirectX fixed function pipeline architecture had done a brilliant job of enabling dozens of disparate competing hardware vendors to all take different approaches to achieving superior cost and performance in consumer 3D without making a total mess of the PC game market for the game developers and consumers.  It wasn’t entirely pretty and wasn’t executed with flawless precision but it worked well enough to create an extremely vibrant PC game market through to the early 2000’s.

Before I move on to discussing more modern Direct3D evolution, I would like to highlight a few other important ideas that early Direct3D architecture influenced in modern GPU’s.  Recalling that in the early to mid 1990’s RAM was relatively expensive there was a lot of emphasis on consumer 3D techniques that conserved on RAM usage.  The Talisman architecture which I have told many (well-deserved) derogatory stories about was highly influenced by this observation.

Talsiman

Search this blog for tags “Talisman” and “OpenGL” for many stories about the internal political battles within Microsoft over these technologies

Talisman relied on a grab bag of graphic “tricks” to minimize GPU RAM usage that were not very generalized.  The Direct3D team, heavily influenced by the Rendermorphics founders had made a difficult philosophical choice in approach to creating a mass market for consumer 3D graphics.  We had decided to go with a simpler more general purpose approach to 3D that relied on a very memory intensive data structure called a Z-buffer to achieve great looking results.  Rendermorphics had managed to achieve very good 3D performance in pure software with a software Z-buffer in the Rendermorphics engine which had given us the confidence to take the bet to go with a simpler more general purpose 3D API and driver model and trust that the hardware market and RAM prices would eventually catch up.  Note however that at the time that we were designing Direct3D we did not know about the Microsoft Research Groups “secret” Talisman project, nor did they expect that a small group of evangelists would cook up a new 3D API standard for gaming and launch it before their own wacky initiative could be deployed.   In short one of the big bets that Direct3D made was that the simplicity and elegance of Z-buffers to game development were worth the risk that consumer 3D hardware would struggle to affordably support them early on.

Despite the big bet on Z-buffer support we were intimately aware of two major limitations of the consumer PC architecture that needed to be addressed.  The first was that the PC bus was generally very slow and second it was much slower to copy data from a graphics card than it was to copy data to a graphics card.  What that generally meant was that our API design had to tend to send data in the largest most compact packages possible up to the GPU for processing and absolutely minimize any need to copy data back from the GPU for further processing on the CPU.  This generally meant that the Direct3D API was optimized to package data up and send it on a one-way trip.  This was of course an unfortunate constraint because there were many brilliant 3D effects that could be best accomplished by mixing the CPU’s efficient branch prediction and robust floating point support with the GPU’s incredible parallel rendering performance.

One of the fascinating consequences of that constraint was that it forced GPU’s to become even more general purpose to compensate for the inability to share data efficiently with the CPU.  This was possibly the opposite of what Intel intended to happen with its limited bus performance, because Intel was threatened by the idea that auxiliary processing cards would offload more work from their CPU’s thereby reducing the Intel CPU’s value and central role to PC computing.  It was reasonably believed at that time that Intel deliberately dragged their feet on improving PC bus performance to deter a market for alternatives to their CPU’s for consumer media processing applications.  Recall from my earlier Blogs that the main REASON for creating DirectX was to prevent Intel from trying to virtualize all Windows Media support on the CPU.  Had Intel adopted a PC Bus architecture that enabled extremely fast shared access to system RAM by auxiliary devices, it is less likely that GPU’s would have evolved the relatively rich set of branching and floating point operations they support today.

To overcome the fairly stringent performance limitations of the PC bus a great deal of thought was put into techniques for compressing and streamlining DirectX assets being sent to the GPU to minimize bus bandwidth performance limitations and the need for round trips from the GPU back to the CPU.  The early need for the rigid 3D pipeline had interesting consequences later on when we began to explore streaming 3D assets over the Internet via modems.

We recognized early on that support for compressed texture maps would dramatically improve bus performance and reduce the amount of onboard RAM consumer GPU’s needed, the problem was that no standards existed for 3D texture formats at the time and knowing how fast image compression technologies were evolving at the time I was loathe to impose a Microsoft specified one “prematurely” on the industry.   To overcome this problem we came up with the idea of “blind compression formats”.  The idea, which I believe was captured in one of the many DirectX patents that we filed, had the idea that a GPU could encode and decode image textures in an unspecified format but that the DirectX API’s would allow the application to read and write from them as though they were always raw bitmaps.  The Direct3D driver would encode and decode the image data as necessary under the hood without the application needing to know about how it was actually being encoded on the hardware.

By 1998 3D chip makers had begun to devise good quality 3D texture formats such that by DirectX 6.0 we were able to license one of them (from S3) for inclusion with Direct3D.

http://www.microsoft.com/en-us/news/press/1998/mar98/s3pr.aspx

DirectX 6.0 was actually the first version of DirectX that was included in a consumer OS release (Windows 98).  Until that time, DirectX was actually just a family of libraries that were shipped by the Windows games that used them.  DirectX was not actually a Windows API until five generations after its first release.

DirectX 7.0 was the last generation of DirectX that relied on the fixed function pipeline we had laid out in DirectX 2.0 with the first introduction of the Direct3D API.  This was a very interesting transition period for Direct3D for several reasons;

1)      The original DirectX team founders had all moved on,

2)      Talisman and Microsoft’s internal reasons for supporting OpenGL had all passed

3)      Microsoft had brought game industry veterans like Seamus Blackley, Kevin Bacchus, Stuart Moulder and others into the company in senior roles.

4)       Gaming had become a strategic focus for the company

DirectX 8.0 marked a fascinating transition for Direct3D because with the death of Talisman and the loss of strategic interest in OpenGL support many of the 3D people from these groups came to work on Direct3D.  Talisman, OpenGL and game industry veterans all came together to work on Direct3D 8.0.   The result was very interesting.  Looking back I freely concede that I would not have made the same set of choices that this group made for DirectX 8.0 but in retrospect it seems to me that everything worked out for the best anyway.

Direct3D 8.0 was influenced in several interesting ways by the market forces of the late 20th century.  Microsoft largely unified against OpenGL and found itself competing with the Kronos Group standards committee to advance Direct3D faster than OpenGL.  With the death of SGI, control of the OpenGL standard fell into the hands of the 3D hardware OEM’s who of course wanted to use the standard to enable them to create differentiating hardware features from their competitors and to force Microsoft to support 3D features they wanted to promote. The result was the Direct3D and OpenGL became much more complex and they tended to converge during this period.  There was a stagnation in 3D feature adoption by game developers from DirectX 8.0 through to DirectX 11.0 as a result of these changes.  Creating game engines became so complex that the market also converged around a few leading engine providers including Epic’s Unreal Engine and the Quake engine from id software.

Had I been working on Direct3D at the time I would have stridently resisted letting the 3D chip OEM’s lead Microsoft around by the nose chasing OpenGL features instead of focusing on enabling game developers and a consistent quality consumer experience.   I would have opposed introducing shader support in favor of trying to keep the Direct3D driver layer as vertically integrated as possible to ensure feature conformity among hardware vendors.  I also would have strongly opposed abandoning DirectDraw support as was done in Direct3D 8.0.  The 3D guys got out of control and decided that nobody should need pure 2D API’s once developers adopted 3D, failing to recognize that simple 2D API’s enabled a tremendous range of features and ease of programming that the majority of developers who were not 3D geniuses could easily understand and use.  Forcing the market to learn 3D dramatically constrained the set of people with the expertise to adopt it.  Microsoft later discovered the error in this decision and re-introduced DirectDraw as the Direct2D API.  Basically letting the 3D geniuses design Direct3D 8.0 made it brilliant, powerful and useless to average developers.

At the time that DirectX 8.0 was being made I was starting my first company WildTangent Inc. and ceased to be closely involved with what was going on with DirectX features, however years later I was able to get back to my 3D roots and took the time to learn Direct3D programming in DirectX 11.1.  Looking back it’s interesting to see how the major architectural changes that were made in DirectX 8 resulted in the massively convoluted and nearly incomprehensible Direct3D API we see today.  Remember the 3 stage DirectX 2 pipeline that separated Transformation, lighting and rendering into three basic pipeline stages?  Here is a diagram of the modern DirectX 11.1 3D pipeline.

DX 11 Pipeline

Yes, it grew to 9 stages and arguably 13 stages when some of the optional sub stages, like the compute shader, are included.  Speaking as somebody with an extremely lengthy background in very low level programming and 3D graphics I’m embarrassed to confess that I struggled mightily to learn Direct3D 11.1 programming.  The API had become very nearly incomprehensible and unlearnable.   I have no idea how somebody without my extensive background in 3D and graphics could ever begin to learn how to program a modern 3D pipeline.  As amazingly featureful and powerful as this pipeline is, it is also damn near unusable by any but a handful of the brightest most antiquated minds in 3D graphics.  In the course of catching up on my Direct3D I found myself simultaneously in awe of the astounding power of modern GPU’s and where they were going and in shocked disgust at the absolute mess the 3D pipeline had become.  It was as though the Direct3D API had become a dumping ground for 3D features that every OEM had demanded over the years.

Had I not enjoyed the benefit of decade long break from Direct3D involvement I would undoubtedly have a long history of bitter blogs written about what a mess my predecessors had made of a great and elegant vision for consumer 3D graphics.  Weirdly, however, leaping forward in time to the present day, I am forced to admit that I’m not sure it was such a bad thing after all.  The result of gaming stagnation on the PC as a result of the mess Microsoft and the OEMS made of the Direct3D API was a successful XBOX.  Having a massively fragmented 3D API isn’t such a problem if there is only one hardware configuration game developers have to support, as is the case with a game console.  Direct3D 8.0 with early primitive shader support was the basis for the first XBOX’s graphics API.  For the first XBOX Microsoft selected an NVDIA chip giving NVIDIA a huge advantage in the PC 3D chip market.   DirectX 9.0, with more advanced shader support, was the basis for the XBOX 360, for which Microsoft selected ATI to provide the 3D chip, this time handing AMD a huge advantage in the PC graphics market.  In a sense the OEM’s had screwed themselves.  By successfully influencing Microsoft and the OpenGL standards groups to adopt highly convoluted graphics pipelines to support all of their feature sets, they had forced themselves to generalize their GPU architectures and consolidated the 3D chip market around whatever 3D chip architecture… Microsoft selected for its consoles.

The net result was that the retail PC game market largely died.  It was simply too costly, too insecure and too unstable a platform for publishing high production value games on any longer, with the partial exception of MMOG’s.  Microsoft and the OEM’s had conspired together to kill the proverbial golden goose.  No biggie for Microsoft as they were happy to gain complete control of the former PC game business by virtue of controlling the XBOX.

From the standpoint of the early DirectX vision, I would have said that this outcome was a foolish, shortsighted disaster.  Had Microsoft maintained a little discipline and strategic focus on the Direct3D API they could have ensured that there were NO other consoles in existence in a single XBOX generation by using the XBOX to strengthen the PC game market rather than inadvertently destroying it.  While Microsoft congratulates itself for launching the first successful US console, I would count all the gaming dollars collected by Sony, Nintendo and mobile gaming platforms over the years that might have remained on Microsoft controlled platforms had Microsoft maintained a cohesive media strategy across platforms.  I say all of this from a past tense perspective because, today, I’m not so sure that I’m really all that unhappy with the result.

The new generation of consoles from Sony AND Microsoft have reverted to a PC architecture!  The next generation GPU’s are massively parallel, general purpose processors with intimate access to the shared memory with the CPU.  In fact, GPU architecture became so generalized that a new pipeline stage was added in DirectX 11 called DirectCompute that simply allowed the CPU to bypass the entire convoluted Direct3D graphics pipeline in favor of programming the GPU directly.  With the introduction of DirectCompute the promise of simple 3D programming returned in an unexpected form.  Modern GPU’s have become so powerful and flexible that the possibility of writing cross GPU 3D engines directly for the GPU without making any use of the traditional 3D pipeline is an increasingly practical and appealing programming option.  From my perspective here in the present day, I would anticipate that within a few short generations the need for the traditional Direct3D and OpenGL API will vanish in favor of new game engines with much richer and more diverse feature sets that are written entirely in device independent shader languages like Nvidia’s CUDA and Microsoft’s AMP API’s.

Today, as a 3D engine and physics developer I have never been so excited about GPU programming because of the sheer power and relative ease of programming directly to the modern GPU without needing to master the enormously convoluted 3D pipelines associated with Direct3D and OpenGL API’s.  If I were responsible for Direct3D strategy today I would be advocating dumping investment in the traditional 3D pipeline in favor of rapidly opening access to a rich direct GPU programming environment.  I personally never imagined that my early work on Direct3D, would, within a couple decades, contribute to the evolution of a new kind of ubiquitous processor that enabled the kind of incredibly realistic and general modeling of light and physics that I had learned in the 1980′s but never believed I would see computers powerful enough to model in real-time during my active career.

avatar_movie_based_ubisoft_game_concept_art_1

Ditching the traditional 3D pipeline in favor of pure GPU based game engines may produce real-time ray traced worlds and game mechanics beyond anything we imagined in a few short generations.

 

Direct3D API Fossils:

  • Left handed coordinate system, my bad introduced in DirectX 2.0
  • Microsoft COM API, baggage from the Windows 95 days
  • Anisotropic filtering, the last vestige of Talisman to be found in Direct3D.
  • Shaders, introduced in DirectX 8.0 marked the end of the fixed function graphic pipeline and the advent of the modern, enormously complex, many stage shader pipeline.

UPDATE:

Wow, this blog entry seems to have struck a chord, it had more hits in a couple hours than every blog entry I’ve ever written combined.  It makes me want to go back through the article and check my punctuation again.  I’ve written so many blogs on this subject that I usually don’t try to credit all of the brilliant people who worked on Direct3D over the years in every entry but in this case it seems that some additional credits are appropriate.  Although I had a very hands on role early in crafting Direct3D and in the overall strategy, there were many exceptional people who really made this technology happen.

  • Eric Engstrom was the first DirectX Program Manager and it was his frustration with Microsoft’s OpenGL team that lead him to conclude that if they wouldn’t work with us, HE was going to make his own 3D API.  Eric is a mad visionary who works for Microsoft to this day and he made Direct3D happen.
  • Craig Eisler was the first DirectX developer.  Craig single handedly created several of the early DirectX API’s and his amazing leadership, technical acumen and work ethic made the DirectX team one of the most prolific and groups at Microsoft over many generations of the early DirectX technology.  Craig also still works for Microsoft and is responsible for the XBOX ONE online service having just turned over responsibility for the Kinect project to another early DirectX veteran Bob Heddle.
  • Kate Seekings, Servan Keondijian, Collin McCartney and all of the early Rendermorphics engineers who created the Reality Lab game engine that Direct3D was based on.  Kate went on to become the 3D evangelist for Direct3D working for me at Microsoft where she was tireless at promoting 3D adoption within Microsoft and the game industry.
  • Phil Taylor, who was the first Direct3D technical evangelist working with the game developer community to get their input and feedback into the DirectX team to ensure that the API’s and SDK documentation and sample code were all usable and who worked closely with the very early Direct3D adopters to be successful with it
  • There were many many other amazing people who contributed to Direct3D over the years… even the ones who came from the Talisman and the OpenGL groups eventually made themselves useful and deserve recognition…  :)   Mike Abrash, Otto Berkes, Mark Kenworthy, Chas Boyd to name a few that come to mind years later.
  • Jason Robar and all of the other great evangelists who later joined the DirectX team of course did a fantastic job of supporting the thousands of developers who adopted the API.
  • Of course the contributions and input (criticism) from so many game industry veterans like Seamus Blackley, Zack Simpson and John Carmack were also invaluable during the formative DirectX years.

36 Comments

  1. *For those of you who just can’t get enough of Direct3D technology history, be advised that all of the early Direct3D SDK versions and documentation as well as the documentation for Talisman can be found posted here.

  2. where’s the “here” link? it seems it didnt get through

  3. What’s wrong with anisotropic filtering?

  4. It’s interesting that you say 3D feature adoption mostly stopped from DX 8-11, and that MS was being told to implement OpenGL features.

    My point of view (as a gamer and new programmer at the time) is almost the opposite. Direct3D 9 was a huge hit and in two years, almost everyone was using it for even prettier games (like Half-Life 2, Far Cry). At the same time, OpenGL did nothing and lacked feature parity with Direct3D 9 for 5+ years. It seems the reason no one used D3D 10 was because Vista wasn’t a success, and everyone went to the 360 (a D3D 9-like architecture). Only in the past 2 years has this started to change.

    Recently, I’ve been interested in WebGL. Sure it’s slow, but the ease of use and distribution is incredible.

    At any rate, thank you for the incredible insight.

    • That’s a fair observation, after D3D9 I was not closely engaged with it in that era. I know there was a period when OpenGL advancement stagnated. It’s difficult to characterize the market transition that took place narratively without some statistical support but my instinct was that the community of game developers who lacked 3D skills was lost. I suspect that the folks who went on to appreciate DirectX 9 were professional game developers who learned 3D making console games.

      You found that the 2D game community existed in Flash and in the casual online game market in droves but they were no longer trying to make 2D DirectX games. I’d have to check my calendar here but I recall that it was a big deal back them for Popcap to use Direct3D to make Bejeweled 3. (They were certainly very proud of themselves) My own experience with the WildTangent web driver during the DirectX 9 era when we were trying hard to make 3D accessible on the web for game developers was that there was a huge community of game developers that simply did not have the aptitude for 3D no matter how simple we made it.

      That experience lead me to the conclusion that killing the DirectDraw API probably dramatically narrowed the Windows game development community.

  5. From what I understand, CUDA and C++ AMP are currently only useful for parallel number crunching. It is really hard to imagine how a game engine could be made on top of them. Is this actually possible in their current form or will the shader languages need to be extended?

    A fascinating article by the way. I really enjoyed reading it.

    • That is almost true. I have written a CUDA/DirectX hybrid game engine that goes like a bat out of hell. The sample code for how to do it is posted on this site. (It needs updating) It’s not easy, but it’s potential is amazing if you try it. You can find several articles I’ve written about my experiences and frustrations with CUDA and AMP programming in the GPU programming category of this blog. Both AMP and CUDA support DirectX interoperability instructions, CUDA’s are more robust and also support OpenGL. Oddly Nvidia actively promotes CUDA for scientific computing and NOT for gaming. I suspect that they do this for a few practical reasons.
      1) They don’t want to have to be religiously tied to backwards compatibility with themselves
      2) Their CUDA tools and drivers aren’t tested to commercial grade stability
      3) CUDA is proprietary to their hardware and they’d like to keep it that way a while longer

      That said the engine I’m working on is cloud based which gives me the luxury of picking a specific hardware version to support. Because the Direct3D and CUDA programming paradigms are so radically different, it has been hard for me to discern when the Direct3D pipeline is the beneficiary of hardware acceleration features that are not accessible to me from CUDA. My instinct increasingly is not to care. It’s so much easier to work with CUDA that I’d rather write my graphics code directly to it and trust that Nvidia will eventually accelerate it for me. Because the interop functionality between CUDA and DirectX/OpenGL is relatively robust, I expect that I’ll eventually have time to performance test different approaches to mixing and matching them. Even so, it’s not hard to see a time in the near future when I can do all of my graphics programming directly from CUDA. I’m inclined to expect that game engines written this way will be more likely to make use of ray-tracing than traditional 3D pipeline designs.

  6. Tekken 1 for Playstation 1 didn’t have an Insert Coin logo. That’s the arcade version in the screenshot. The PS1 version said Push P2 Start.

    Besides that great read.

    • Good eye, thanks! I’m having a difficult time finding a good screen shot of Playstation One graphics on google that illustrate the painters algorithm polygon clipping issue. Let me know if you see one.

  7. I see some debate on Reddit about the old D3D vs OpenGL API issue. I don’t expect to be able to put it to rest at this point but I’ll give it one more stab. I think most people who get wrapped up in this debate don’t understand the difference between an API and a driver layer. An API provides a standard interface to a set of functionality that is implemented by some combination of hardware and software layers beneath the API. All of the functionality of an API is provided by the lower PROPRIETARY layers which can vary greatly from platform to platform. In the case of OpenGL, it was not difficult to implement the Direct3D API on an OpenGL driver layer or OpenGL on top of a Direct3D driver layer. These layers were relatively interchangeable. The famous Quake GL implementation DID NOT use the OpenGL API, it implemented it’s own OpenGL “like” interface to the hardware which the hardware OEM’s supported just for Quake. Microsoft demonstrated this by replacing the QuakeGL driver with one that mapped simply to Direct3D AND RAN FASTER. The API’s we’re pretty interchangeable, Direct3D was uglier owing largely to Microsoft’s strategic desire to impose COM on everybody.

    http://www.descent2.com/archives/articles/art0025.html

    Driver layers are always proprietary to the platforms they run on. There is no “open standard” driver architecture. What was weird about Direct3D was that it was both a high level API AND a driver level API.

    What is odd about people who get religious about OpenGL vs Direct3D is that they usually don’t understand that at the time that Direct3D was introduced Microsoft effectively controlled BOTH API’s, certainly on the Windows platform. There would be zero consumer 3D hardware for the PC today had it not been for Direct3D because OpenGL as a gaming API would have died in SGI’s hands and the few PC OEM’s who were trying to make 3D chips for the PC in that era as a secondary market were all pursuing their own proprietary 3D API’s. The ONLY reason that OpenGL became a leading consumer 3D gaming API is because Microsoft’s OpenGL team competing with Microsoft’s Direct3D team made it one! Without support from Microsoft for SOME 3D driver layer, there would have been NO market for consumer 3D graphics period. Direct3D FORCED Microsoft’s OpenGL team to make consumer 3D support a priority and consequently made it a priority for the ARB as well. As I tried to express in my blog, it wasn’t that the OpenGL API was inappropriate for games, it was the need for $100,000 workstations that didn’t work. It was the Direct3D driver architecture that enabled a consumer market for $200 gaming video cards.

    Read the press release above from 1998… why would Microsoft pledge to support OpenGL if they wanted to dominate consumer graphics API’s unless… they already controlled OpenGL as well? Think people! I was there pulling the strings, I KNOW what was going on. SGI signed a death pact with Microsoft to get a license to WindowsNT, part of that deal was a “face saving” agreement that let Microsoft define future OpenGL features. Microsoft’s vision for OpenGL was TALISMAN, if DirectX had NOT succeeded wildly with game developers, Microsoft would have tried to keep its grip on OpenGL and packed it full of Talisman features. It was Paul Maritiz who signed that deal with SGI and fired me shortly afterwards. I was gumming up the grand plan.

    http://www.microsoft.com/en-us/news/press/1997/dec97/fahrpr.aspx

  8. Ah… here’s a classical email thread I don’t think I’ve released before; Chis is a reference to Chris Hecker a disgruntled Microsoft engineer with friends in the Microsoft OpenGL team who tried to blackmail Microsoft to support OpenGL. Paul did the deal with SGI to get control of OpenGL so it just didn’t matter what anybody wanted. Deborah Black was the Microsoft Executive who had been given DirectX, Talisman and OpenGL to try to sort out. I was fired two weeks later for calling her incompetant over her handling of this issue. I had warned Deborah in advance of her meeting with Hecker that if she met with him, he would take the content of the meeting to the press to support his letter. (Those stories can all be found here in older blog posts)

    —–Original Message—–
    From: Paul Maritz
    Sent: Monday, June 09, 1997 11:02 PM
    To: Deborah Black
    Subject: RE: Chris Hecker

    I would not let this sway us one way or the other. Chris is something a strange animal – mixture of chutzpah and naivete. We should let him go ahead and release the letter, and see what happens. We should give DRG and PR (Waggener) a heads up so that we can answer any questions that come in. Our response should be: “Our current position is that D3D is the primary games API, there are xxx games, drivers, etc. in development/market. We see OGL as being extremely important API for professional market. We will obviously take the opinions expressed into account”.

    —–Original Message—–
    From: Deborah Black
    Sent: Monday, June 09, 1997 7:48 PM
    To: Paul Maritz
    Subject: Chris Hecker

    Chris has a letter which he intends to release as a press release and expects it would be published by several games magazines. It is formatted as an open letter to Microsoft asking that Microsoft release the MCD driver model support (including DDraw integration) on Memphis. Further, it asks Microsoft to allow games ISVs a chance to make their own choice between OGL & D3D – based on technical merit only. It is signed by key technologists at approx 50 companies (eg., Seamus Blackely from Dreamworks, John Carmack from ID, Looking Glass, Bull Frog, Activision, Digital Anvil, Raven, etc).

    Chris asserts that each of these companies would prefer to use OGL, but have been forced to use D3D because of the lack of OGL drivers on Win95. As soon as the drivers are available, he believes that ISVs will move quickly to OGL.

    He has agreed to hold on to the letter until Thursday afternoon in order to give me time to discuss it with you.

    If we release MCD on Memphis, we are clearly enabling OGL game development for the first time. Every indication is that OGL is a technically superior API, so it is entirely possible that OGL will gain broad support in this market.

    If we pull MCD from Memphis, we will endure short term pain in the form of pressure from Chris Hecker’s ISVs, from SGI, and probably from IHVs who have invested in MCD development.

    What do you think?

    Debbie

    • PS> What’s funny about this thread in retrospect is that Maritz thinks Hecker is being Naïve and idealistic about OpenGL when in fact Hecker doesn’t care at all about it, he’s doing a great job of screwing me and helping is friends on the OpenGL team gain control of the Windows 3D strategy, exactly as he intended.

      As annoying as Hecker was to me back then, he did the entire game industry and Microsoft a service. If the OpenGL/DirectX/Talisman issue had not eventually blown up, the era when DirectX was being designed by a consolidated team of Direct3D, Talisman and OpenGL people in concert with game industry veterans like Seamus Blackley might never have happened. That boil needed to be lanced and Chris and I both stuck a fork in it.

      It’s also a better world in which Direct3D and OpenGL are actual market competitors for gaming instead of competing Microsoft initiatives. We ALL won.

    • This was all a very long time ago, but I remember a few things from that era. If Chris asserted that “each of these companies would prefer to use OGL” then I’m disappointed in him, for that is not true.

      Chris emailed me and asked if I would sign his letter. I replied that I preferred Direct3D. He persuaded me that all he wanted was for developers to be able to choose OpenGL if they preferred it, and for it to be supported in hardware as well as Direct3D. On that basis I signed his letter, but still slightly reluctantly – as I could not see how Microsoft would want to maintain two APIs in that fashion for very long. It seemed to me that the intent was eventually to force Microsoft into killing Direct3D, once developer momentum had built up.

      I’ve never particularly liked OpenGL. Of course now I write OpenGL drivers… FML

  9. Tomb raider and spyro or croc had bad polygon clipping and some other games.. the saturn version use quadrilaterals though so it made it slight more hard to see. it more easy to tell in motion it is doing it though.

    unless you are just talking about character joint in the rig only.

    here is some screen shots if you want. Nobody seems to post the ones where it is happening really bad enough to see.

    http://i956.photobucket.com/albums/ae46/darkman_019/TRPS15.png?t=1295012331

    http://img151.imageshack.us/img151/6937/spyro2yk7.jpg

  10. Somebody on Reddit thinks that screwing up the Left handed coordinate system in D3D was a malicious effort to thwart OpenGL. Trust me, I’m a megalomaniac, had I done it on purpose I would be crowing about it to this day. I’m always happy to take credit for a good evil trick, the truth is just boring this time… and NO it’s NOT true that most 3D coordinate systems used in physics are right handed. I just didn’t like the fact that when you draw a 3D object in positive 3D coordinates you have to move the camera in order to be able to see it, requiring a game developer who was just learning 3D programming to have to learn all about the camera in order to figure out how to draw simple 3D objects for the first time. Recall that this was Direct3D 1.0, MOST game developers we expected to use the API had never done any 3D programming.

    Recognizing that Right handed coordinate systems were popular among experienced developers we even documented how to flip coordinate systems in the same paragraph that we described the default Left handed system.

    “In a left-handed coordinate system, rotations occur clockwise around any axis that is pointed at the viewer.
    If you need to work in a right-handed coordinate system—for example, if you are porting an application that relies on right-handedness—you can do so by making two simple changes to the data passed to Direct3D.
     Flip the order of triangle vertices so that the system traverses them clockwise from the front. In other words, if the vertices are v0, v1, v2, pass them to Direct3D as v0, v2, v1.
     Scale the projection matrix by -1 in the z direction. To do this, flip the signs of the _13, _23, _33, and _43 members of the D3DMATRIX structure.”

    It made a ton of sense to me at the time….

  11. I’m surprised not to see any mention about 3DFX and its Glide API which was Direct3D’s main competitor at the very beginning..

    • Yeah, you would think wouldn’t you? 3DFX was a real force in that era but Microsoft’s weapons for dealing with a competitor of that nature were too powerful… we were never really worried about 3DFX. We had the power to put most IHV’s that didn’t comply with our API standards out of business. We fired fatal bullets at Nvidia and 3DFX, Nvidia ducked and quickly joined the Direct3D bandwagon, 3DFX… not so much… resistance was futile. It was the same for SGI, which is why after all these years it’s still odd to me to see people debating the merits of OGL vs D3D when Microsoft controlled them both and was going to do whatever it wanted with both. Microsoft “supported” OpenGL for the same reasons they “supported” Java, to co-opt it.

  12. To me, Direct3D ended at D3D9. When 10 was announced as Vista-only, and the world was choosing to stick with XP, I had no real interest in learning it… And D3D9 even now has a very rich feature set – you have do be doing very high-end stuff to really need DX10/11. (And currently I’m doing mobile dev, so more interested in doing relatively simple things with GL ES…)

  13. So… you’re the one responsible for choosing left handed over right handed? Now go back to your room AND THINK ABOUT WHAT YOU DID!!!

    (I’ve been wanting to say this to the guy responsible… for years!!!)

    Now, it’s a shame you think the D3D11 api is a mess. I’ve been doing DX programming since 7.0; and it felt like a natural transition. I too was shocked though, when I found out DX 8 discarded the DirectDraw API completely. I had the same thoughts you did (how are the non-3D experts going to deal with 2D-only stuff??)

    To help you out understanding the “messy stages” from D3D11, try seeing it like this:
    Vertex Shaders: It’s exactly the same as the code you wrote to transform TnL vertices. But as a bonus you can write your own and it is executed on the GPU instead of CPU.
    In 1998 we wrote the vertex dot matrix4x4 multiplication element by element, in a vertex shader we just do outVertexPosition = mul( worldViewProj, inPosition );
    You can do the gouraud lighting shading here. If you had to write it, it would look something like this:
    output.outPos = mul( worldViewProj, inPosition );
    output.colour = dot( lightDir, inNormal ) * lightDiffuse; //You can use a for loop for more lights
    output.uv = inUV;

    Geometry shaders, hull, tesselator & domain shadesr: Forget about them, they’re optional.

    Pixel Shaders: Think of normal a rasterization process, but you can execute a simple program ran in the GPU that allows to customize the colour of the pixel that is going to get written.
    We usually do the Phong lighting shading here (DX 7 left the flag there but was never supported IIRC!) or other alternate brdfs.
    If you’re emulating D3D7′s gouraud shading, you would only have to write:
    “return tex2D( myTexture, input.uv ) * input.colour;”

    The rest is just the same as it was in DX7.
    Note that, just like you wanted in the past: now DX11 doesn’t have caps flags and the gpu either fully supports DX11 or doesn’t. There *are* still some optional features, but they’re very very very few and usually not relevant.
    The only thing we miss from the old days is that current DX10+ documentation is poor compared to DX7 to DX9 docs which were very detailed, insightful and often went far beyond than just describing the API (went right into general theory).

    In case you want to know about the other stages:
    Geometry shaders: There is no D3D7 equivalent. Runs once per triangle and has access to all three vertices (a vertex shader can’t see any neighbours). Decides if it should output even more triangles, or none. It can also assign an incoming triangle to a specific RenderTarget (eg. environment mapping)

    hull, tesselator & domain shaders: There is no D3D7 equivalent. An akward way to say how we mark the vertices that need to be further tesselated and how (Hull), then generate those extra vertices (tesselator), and a final pass to fix the issues or set final positions (domain)

    Now, with this introduction it doesn’t look that scary, does it?
    Vertex is just moving what you knew (and probably wrote) that was happening in the CPU to the GPU; and Pixel shaders are just a pretty nice finisher to retouch/customize the output of the colour.

    Thanks for the reading :)

    • I forgot to say that Geometry Shaders look nice, but they were one of those features that looks nice on paper but are terrible when implemented.
      Their ability to see all three vertices and dispatch an unknown number of triangles (since it’s value is only known at runtime and can vary per triangle) to an unknown number of render targets, it makes them extremely parallel-unfriendly (in other words, slooooow)

      There are very limited cases where geometry shaders can achieve something you were hoping for without killing performance, but 99% of the time, people skip the GS. They’re almost useless in practice.

      And because everyone wanted to use the GS for tesselation (but killed performance), the DX team came up with the 3 tesselation stages which are much more rigid, but are at least scalable.

    • Hey I’m the only one who gets to do use the patronizing tone around here!

  14. Thanks for making it real and accessible. To me DirectX was an eye opener, a great tool. Great API. At that time OpenGL was not an option.

  15. Here’s a cool historical email. Bill Gates first reaction on meeting Seamus Blackley at DreamWorks

    ———-
    From: Bill Gates
    Sent: Friday, February 07, 1997 3:08 PM
    To: Ed Fries; Jay Torborg
    Cc: Alex St. John; Aaron Contorer; Pete Higgins; Jim Kajiya; Nathan Myhrvold
    Subject: Dreamworks technical approach

    I was AMAZED at the technical sophistication of the DreamWorks Interactive team. The way they are doing physical modeling including the acoustics and physics is very state of the art. Their rendering algorithms draw on Talisman ideas.

    Somehow I think Microsoft should draw on this technology in 2 ways:

    a) We should get our games group up to this level of sophistication by making sure we get to use the code and getting people who have this kind of ability.
    b) We should make sure our platform work and graphics plans are able to match what they are having to do for themselves. They admitted that other will clone their work so I don’t think they would mind the system taking over some of it.

    The mail I got was about us discussing their use of Direct3D. This is fine but what I want is for our people to understand their whole approach and learn from it as well as making sure they like our DirectX plans.

    It was very interesting that he said that having the AGP port with Klamath (including MMX) is better than any of the 3D cards that are out there. Also it was interesting how he had taken Talisman and was using some of the good ideas from it in his software.

    I hope our seperation between ActiveMovie and DirectX isn’t going to prevent us from doing good work. It seems like these games guys are so far ahead of what we are doing right now that our work is not very leveraged. Our strategy is to take our work and put it in a Sega game and have this change the video game world. However unless DWI thinks what we are doing is fantastic and build on top of it then it’s a false dream.

    I think we need to get their technical leader backup in the next few months to make sure we take full advantage of his expertise which I found very impressive.

  16. I found my response to Bill on that thread as well.

    _____________________________________________
    From: Alex St. John
    Sent: Saturday, February 08, 1997 2:03 PM
    To: Bill Gates; Ed Fries; Jay Torborg; Nathan Myhrvold
    Cc: Aaron Contorer; Pete Higgins; Jim Kajiya; Gregory Faust; Eric Engstrom; Craig Eisler
    Subject: RE: Dreamworks technical approach

    I assume this is a reference to Seamus Blackley. Very sharp guy, the DirectX guys have met with him a couple times. If he’s doing something new and interesting, I’ll see that they all touch base again.

    -It was very interesting that he said that having the AGP port with Klamath (including MMX) is better than any of the 3D cards that are out there.
    I think you guys would be really surprised to know how weird the 3D business is these days. At the moment 3D hardware accelerators are obsolete and slower than the latest PC in software at about the time they hit the market give or take a few months. The pace of 3D engine innovation in software + improvements in each new generation of system is making it tricky to actually ship a 3D accelerator that is an accelerator for very long. Also the way the software engines are being built to achieve these performance improvements often diverges from the way the latest hardware was designed making it difficult to efficiently accelerate them even if the hardware is good. It’s becoming a very complex dynamic.

    -It seems like these games guys are so far ahead of what we are doing right now that our work is not very leveraged.
    Ooh a pulpit, I’m going to preach something at you guys while you’re listening. All the wizzy high level API’s and fat multimedia technologies we make represent substantially less leverage to us in practically every market we care about next to some very basic, simple to address, unglamorous OS and driver problems that only we can fix. There are fundamental architectural limitations to ALL multimedia advancement inherent in our OS’s. If we were to do nothing more than the following two things, we will win 90% of any multimedia platform battles that arise in the next three years.

    1. Ensure consistent, robust multimedia drivers for all new and existing hardware. Busted driver related problems are our number one ISV support headache, and consumer adoption limiter.
    2. Tune the OS for real-time applications. Provide real-time apps (video, games, video conferencing, 3D animation/modeling, interactive web browsing) with the control they need over memory, the cache, working set, and the scheduler to have the kind of responsiveness that’s fundamental and essential to their operation.

    Focus on these two things and you will have a bigger market, with more innovation for functionality no other OS will be able to duplicate. I have never spoken to a single multimedia ISV who didn’t have those two requests on their multimedia technology wish list. These two things are universally clear and fundamental to any successful multimedia strategy we’re going to have. Anything we build on top of this is icing. Any multimedia strategy we build without achieving this, is going to be inherently flawed. All multimedia applications at all levels absolutely depend on us and the OS for this support, if we deliver it, they’ll belong to us. If we achieve it any high level strategies we formulate will be substantially more successful because of it. We will be state of the art, and Sega and DWI will absolutely love us for accomplishing this.

    I don’t think that we clearly recognize this and focus on it as a company right now, and we have a lot of “interesting multimedia projects” in the works that are suffering in functionality, performance and complexity because of it.

    -Do you guys ever wonder why you can actually see a web page with some text and a few graphics getting drawn on your screen on a 150mhz Pentium even when the page is cached while a game like Quake can render 640x480x30fps virtual worlds in real time over the net without a shudder?

    ———-
    From: Nathan Myhrvold
    Sent: Friday, February 07, 1997 3:13 PM
    To: Bill Gates; Ed Fries; Jay Torborg
    Cc: Alex St. John; Aaron Contorer; Pete Higgins; Jim Kajiya; Gregory Faust
    Subject: RE: Dreamworks technical approach

    We are trying to get their key guy to come up and talk at the multimedia retreat on 2/18.

    Nathan

    —–Original Message—–
    From: Bill Gates
    Sent: Friday, February 07, 1997 3:08 PM
    To: Ed Fries; Jay Torborg
    Cc: Alex St. John; Aaron Contorer; Pete Higgins; Jim Kajiya; Nathan Myhrvold
    Subject: Dreamworks technical approach

    I was AMAZED at the technical sophistication of the DreamWorks Interactive team. The way they are doing physical modeling including the acoustics and physics is very state of the art. Their rendering algorithms draw on Talisman ideas.

    Somehow I think Microsoft should draw on this technology in 2 ways:

    a) We should get our games group up to this level of sophistication by making sure we get to use the code and getting people who have this kind of ability.
    b) We should make sure our platform work and graphics plans are able to match what they are having to do for themselves. They admitted that other will clone their work so I don’t think they would mind the system taking over some of it.

    The mail I got was about us discussing their use of Direct3D. This is fine but what I want is for our people to understand their whole approach and learn from it as well as making sure they like our DirectX plans.

    It was very interesting that he said that having the AGP port with Klamath (including MMX) is better than any of the 3D cards that are out there. Also it was interesting how he had taken Talisman and was using some of the good ideas from it in his software.

    I hope our seperation between ActiveMovie and DirectX isn’t going to prevent us from doing good work. It seems like these games guys are so far ahead of what we are doing right now that our work is not very leveraged. Our strategy is to take our work and put it in a Sega game and have this change the video game world. However unless DWI thinks what we are doing is fantastic and build on top of it then it’s a false dream.

    I think we need to get their technical leader backup in the next few months to make sure we take full advantage of his expertise which I found very impressive.

  17. Rendermorphics founder Servan and my 3D evangelist in the UK on early D3D adoption:

    _____________________________________________
    From: Alex St. John
    Sent: Saturday, February 08, 1997 4:09 PM
    To: Bill Gates; Nathan Myhrvold; Aaron Contorer; Paul Maritz; Jay Torborg; Ed Fries; Eric Engstrom; Craig Eisler
    Cc: Morris Beton
    Subject: FW: Sucessful UK Direct3D Event

    This is an example of a recent report from one of our D3D developer conferences in the UK. The interesting points here are;

    1.) It’s pretty popular among game developers and receiving a lot of support.
    2.) It’s just a very low level standard interface to consumer priced 3D HW.
    3.) All of its support lies in being very close to the iron, and having lots of drivers.
    4.) 90% of the feature requests listed here can be categorized as “Make your driver architecture faster and more robust.” There are no requests for it to be acquire more abstract higher level functionality.
    5.) People who started using the low level API’s because they thought that’s what they needed, started migrating to the higher level more abstract retained mode API all by themselves. They never would have given retained mode a second look, if D3D hadn’t included the low level stuff they knew they wanted.
    6.) Notice the PowerVR chip problem. 3D HW is diverging one way to gain speed, the software engines are headed another, and our API and driver are stuck in the middle. D3D wins because even though it isn’t necessarily the most optimal mapping between software and HW, it’s the most consistent one and provides a smooth transition between software acceleration and HW acceleration. D3D can balance lighting, transformation and rendering between the CPU and the iron to get the best mix of performance. A great problem to be solving when many 3D cards are actually de-celerators.

    I assert again that most of our multimedia leverage will come from the bottom of the OS in the form of better drivers, memory management, and real-time scheduling. This is the reason that DirectX has been such a successful strategy.

    ———-
    From: Steve Lacey
    Sent: Wednesday, February 05, 1997 1:26 PM
    To: Jason Robar; Jason White; Eric Engstrom; Craig Eisler; Bob Heddle; Alex St. John
    Subject: Sucessful UK Direct3D Event

    —-
    Steve Lacey
    Program Manager – Microsoft RenderMorphics
    http://www.microsoft.com/mediadev

    —–Original Message—–
    From: Servan Keondjian
    Sent: Wednesday, February 05, 1997 8:15 AM
    To: Direct3D Team; Mike Gamble; Ty Graham; Kate Seekings
    Subject: FW: 3dLabs D3D event

    FYI
    On Monday and Tuesday 3DLabs held a D3D developer event. It was positioned as a sort of D3D master class for game ISV’s. Mike Gamble and I were there and gave presentations. UK ISV’s were very pleased to have a local evangelist as UK ISV’s that did not have a previous relationship with RenderMorphics have felt in the dark with respect to MS and DX.

    I think this event went extremely well. I think pretty much every major UK game developer was there including Virgin/EA/Eidos/Bullfrog/DID/Microprose/SCI/Simis/Psygnosis. The 3DLabs presentations were very good and overall there was very high technical content. There were also good case study presentations from both Psygnosis on getting wipeout from the playstation to D3D and Innerworkings on how they wrote Plane Crazy and got it to run so fast on D3D. The major difference I felt with US conferences was the large proportion of very competent 3D developers. We had a open discussion about John Carmac’s comments and it was surprising to see that not a single developer there seemed to agree with him. Even more so developers were saying they wanted D3D to become the standard and were keen to push it to be the standard.

    Everyone was happy with the render triangle interface and most people with on the fly scene construction said they would use it. other people with static meshes or titles far down the line are sticking with execute buffers. There were no performance complaints. The single most frequently asked request was for MS to continue to put effort into the ramp driver as this is what they are all use for their software only solution (we really loose out as we dont have per poly mip, something James was working on for dx5). Even wipeout is now running with ramp mode.

    The most painfull part for me was that Bullfrog even wanted to use the ramp driver as they said ramp was faster when they compared apples to apples than their own code. but they needed certain features that we no longer plan to implement. The modified ramp driver that we had planed would have addressed all their needs. I told them we had no plan to do this anymore they will continue with their own software emulation unless this changes soon. A surprising number of key developers were considering using retained mode and were keen to do so if the performance stayed high enough. Even the tomb raiders guys were thinking about using it for their animations on their next title.

    Alot of people complained about PowerVR problems to me, it just doesent behave like any other card so causes huge pain (nothing new here though). 3DLabs demoed their latest driver that now hits over 1 Million polys/sec on d3d test (on a 200 PPro)

    Nearly all software issues that came up were on our DX5 todo list. I made a list of the most common requests below. All of the below were on our old DX5 list. I dont really see how we can address the ramp issues any more though. Some people but not a large proportion were keen to have multiple texture support in DX5 as they did not see the point unless it can be emulated fast, and they wont use it if it is only supported on one card.

    Most often requested
    IM
    Fix fog table
    enable no Z clear in api and SW
    per poly mip map
    where is subpixel correction.
    is load matrix fixed.
    LOD bias

    Ramp
    optimize 16 bit ramp size 1
    user supplied ramp map with color index alpha
    16 bit copy mode transparency bug
    optimize 16 bit gouruad

    MMX
    enable alpha blend

    RM
    points/lines
    full screen device

  18. Enjoyed your account of early DX days and the tenuous relationship with SGI around OGL. IMV it was exactly like the MS/IBM NT/OS-2 dance (MS getting the better of IBM too). But what’s this “Tallisman”? I thought the project name was (as stated in the cited MS archive): “Fahrenheit”.

    • It was Talisman long before it was was renamed Fahrenheit. You can find the original Talisman spec and lots of documentation about it in my DirectXFiles. Fahrenheit was a face saving joint initiative between Microsoft and SGI after Microsoft basically crushed SGI and they were forced to turn to Microsoft for a Windows NT license. Fahrenheit was Microsoft and SGI’s way of trying to smooth over the OpenGL vs Direct3D war while giving SGI and OpenGL a Talisman suppository. Talisman started out life as a Microsoft initiative to create a proprietary 3D graphics card and make it the PC and Windows standard graphics card… then it became a bag of technologies that Microsoft twisted OEM thumbs to agree to license and support in their Windows chips. Fahrenheit was an effort to infect OpenGL with it. In many respects Talisman was one of Microsoft’s early pro-forays into the console business because we tried to license it to SEGA as the DreamCast GPU. (All stories that can be found in my blog archive.) Also recall that this was the era during which Microsoft owned Softimage.

  19. How do you compare Direct3D to OpenGL? do you see its better than later?

    • It’s funny, in retrospect, both API’s became much better and had more resources poured into them as a consequence of a huge competitive battle. Some of the best people from the OpenGL side worked on D3D at one time or another. In many respects the two API’s have co-evolved to be functionally equivalent over the years. They’ve both become VERY difficult to learn over the years although the edge on comprehensibility has clearly gone to OpenGL. I believe most of the leadership in consumer3D has come from DirectX. Obviously there would have been no XBOX without the DirectX movement and PC 3D chip companies would have died off long ago instead of becoming the dominant consumer and console chips.

      What’s most interesting to me is that neither API would have become very relevant to anything without the massive overhaul to the Windows OS that made ANY kind of gaming practical. Windows was a train-wreck for interactive media, I remain certain that had we not re-plumbed the entire OS for real-time media and HW acceleration. Without all of the other work that made ANY kind of interactivity possible on Windows I believe that entire core PC game market would have died off in the 1990′s leaving only Flash games and Bejeweled derivatives for the kids to play while the game market remained solidly on proprietary Japanese console architectures. Without DirectX, OpenGL might have completely died as a standard for anything given that OpenGL itself WAS NOT a 3D hardware driver architecture… the driver model for OpenGL in the consumer space was created by… Microsoft. Without a PC games market and SGI’s demise it seems likely that any number of proprietary solutions would have dominated professional 3D graphics and CAD applications.

      It’s strange to think that without a “religious movement” for interactivity in Microsoft it appears evident that Windows would have remained an abhorrent gaming and media platform into the present day… Apple would probably completely dominate consumer computing much earlier in history in a parallel alternative universe. Nvidia would not exist and AMD might also well be dead as nothing would have existed to differentiate their consumer chips from Intel without the ATI acquisition.

      It’s hard to guess what would have happened to the US game development companies. I suspect that EA, Activision and others would be much bigger today dominating Western console game development had it NOT been for the API war that opened up the PC game market to thousands of indy developers, many of which went on to become large studios and online game publishers (like Valve).

      It’s also interesting to observe that the success of DirectX was closely linked to very early and aggressive support from ATI which gets very little credit in the history books for really throwing a lot of support behind DirectX when it was very young and just a rogue project run by out-of-control junior Microsoft people. Without the engineering support and marketing dollars ATI provided us with, we might not have had the resources to sell gaming even within Microsoft so I have to credit Ken Nicholson, ATI’s Microsoft liaison for being the early visionary and getting behind it all LONG before anybody else did. No company has ever gotten more bang for their marketing dollars than ATI, I suspect.

Pingbacks

  1. Noticias 28-07-2013 - La Web de Programación
  2. Alex St. John: The Evolution of Direct3D | Scali's OpenBlog™

Leave a Reply

Follow

Get every new post delivered to your Inbox

Join other followers:

Switch to our mobile site

%d bloggers like this: