Direct3D vs. OpenGL
|
|
Even though Direct3D and OpenGL are a lot more similar than they used to be, there are still differences, and as in all API wars, each side has its followers. A discussion of the most significant areas of debate follows.
| Contents |
Ease of use
Prior to version 8, Direct3D was known to be rather clumsy to use -- to do a state change, for instance, it required a number of complex operations. For example, to enable or disable alpha blending, one had to create a so-called execute buffer, lock it, fill it with the correct opcodes (along with a structure header telling how many opcodes the buffer contained and a special "exit" opcode), unlock it and finally send it to the driver for execution. In contrast, an OpenGL program would do a single "glEnable(GL_BLEND);" call. This model was rather frustrating for many programmers; the most famous example probably comes from John Carmack's .plan where he urged Microsoft to drop Direct3D altogether in favour of OpenGL.
However, with Direct3D version 8, many changes were made, and Direct3D could not be called a clumsy API anymore. Direct3D and OpenGL still follow different paradigms, though -- Direct3D is based on Microsoft's COM technology and thus is in its heart object oriented (so every texture is an object, for instance). OpenGL does not have such a paradigm, but instead is known as a state machine accessed through simple C functions. Which one is ultimately "better" depends on a programmer's preferences. The OpenGL state machine may be wrapped with an object oriented programming interface as part of the game engine. Such an effort was carried out by SGI and Microsoft as the Fahrenheit graphics API, but the project was a failure.
Direct3D tends to be closer to the hardware than OpenGL is. For instance, if a program is minimized and then restored, Direct3D users will get what is known as a lost device, meaning the program has to re-upload all textures, set all vertex shader constants etc. OpenGL does this transparently for the programmer, of course at the cost of less control. A Direct3D application could for instance pause the game while the upload is happening, which would be harder for an OpenGL game.
A widely preferred way of using OpenGL is what OpenGL calls "immediate mode", which allows the programmer to enter vertices (or vertex attributes such as texture-coordinates or colors) to the current vertex-buffer one-by-one (e.g. "glVertex3f(1.0f, 2.0f, 3.0f);"), at the obvious expense of speed. This is a very convenient way of drawing simple things, but in practice it makes the rendering notably slower. This is the same method adopted in Direct3D 5, and then augmented in DirectX 8 with the addition of Vertex and Index buffers - effectively cached buffers of geometry that could be stored locally on the hardware for fast access by the GPU, avoiding a copy of data from the user mode application to the hardware.
With the ability to provide data in an immediate fashion via the DrawPrimitiveUP/DrawIndexedPrimitiveUP APIs and the buffered use of Vertex and Index buffers, the programmer can choose which approach to use based on whichever is required.
OpenGL 1.1 introduced vertex arrays (which perform vastly better than immediate mode for larger amounts of geometry), and a later extension introduced "vertex buffer objects" (VBOs) which are largely functionally equivalent to Direct3D's vertex buffers.
Another significant difference between the API's is the way they handle rendering to textures: Direct3D supplies a rather convenient way for that (SetRenderTarget()) as opposed to OpenGL, where one has to use P-buffers or pixel buffers in order to get the same result. This, however, is widely regarded as the edgiest points of the OpenGL API: if a programmer creates his codepath differently than desired by the driver manufacturer, the changes might be to expense of compatibility, as the code will fall back to software rendering, thus rendering the application essentially unusable. (According to a Gamasutra article (http://www.gamasutra.com/features/20040830/mcguire_02.shtml), the aforementioned John Carmack considered dropping OGL to D3D just because of the contrived use of P-buffers.)
Speed
Shortly after the establishment of both Direct3D and OpenGL as viable graphics libraries, Microsoft and SGI engaged in what several pieces of literature regard as the "API" wars. This war, though often about structure, would also tend to break down into fundamental arguments about which API offered superior performance. Much of this was related to the fact that during this competitive time, both Microsoft's Direct3D and various implementations of SGI's OpenGL were relegated to software renderer implementations in the consumer market (due to the very high costs of graphics hardware at the time). Thus the ability for a specific library to outperform another often fell solely on the library itself and not third-party circumstances, such as a poor graphics card.
Microsoft, who had created an implementation of both Direct3D and OpenGL for their platform, had marketed Direct3D as faster based on performance comparisons of the two APIs that had been completed in-house. At that time, the report had been considered true (with regard to Microsoft's two implementations) laying blame for the performance deficit on the rigorous specification and conformance required of OpenGL. This perception was changed at the 1996 SigGraph (Special Interest Group on Computer Graphics) conference. At that time, SGI challenged Microsoft with their own optimized Windows software implementation of OpenGL called CosmoGL which (through use of various demos) showed that in many cases OpenGL performed at, or above, the capabilities of Direct3D. For SGI, this was a critical milestone as it showed that the lack of performance in OpenGL software rendering was not due to the structure or design of OpenGL, but rather due to a lack of optimization in the implementation shipped by Microsoft.
Since then, the debate drifted increasingly away from software rendering performance and has focused of other issues both sides have attempted to claim victory on various merits, though no sufficient proof to this date has been offered as to which API truly exhibits the best performance. Much of this is related to the fact that performance of an application lies as much on a programmers ability to write good code or the presence of solid hardware and drivers, as it does on the API itself.
Thus, in the case of modern systems, the issue of API speed has become more and more insignificant. As of today, graphic-intensive applications have found themselves to be CPU-bound even on mid-level graphics hardware, or limited by slow IO access across other system components; because of this, the focus has shifted away from the API to the hardware end of computer graphics. As a result, the greater issues that APIs tend to face now fall along the lines of usability, simplicity and features instead of speed.
Structure
OpenGL's API, originally written for the then-powerful SGI workstations, includes a number of commands that are rarely used (typically only in "high-end" rendering situations). The API as a whole contains about 250 calls, but only a subset of perhaps 100 are useful in a gaming context. OpenGL never defined a useful subset to be used in these situations, a set of commands that really should be implemented in the hardware for best performance. MiniGL, released by 3Dfx as a stopgap measure to support glQuake, might have made a bare bones starting point but additional features like stencil were soon adopted by games validating the inclusion of many seemingly high end capabilities. The problem has since disappeared as modern cards support more and more of the API in hardware and have become much more sophisticated and feature rich than the OpenGL version 1.1 or any SGI workstation of that era.
Structurally OpenGL was designed as a feature rich API from the outset although hardware capabilities did not exist the specification required their implementation. A subsequent implementation that managed to accelerate a feature in hardware would automatically deliver performance increases even to older software applications written against the API. This is an example of the implicit hardware abstraction in the API, an example of this in action was when the new GeForce 256 graphics card came out in 1999, games like Quake III Arena could immediately use the Transform & Lighting feature with an OpenGL extension, whereas Direct3D developers had to wait for the next version of the API to be released and rewrite their games to use the new features. Clearly the OpenGL approach makes sense for essential things that would be done in software anyway, for example transformation and lighting, but other non essential slower features might be better avoided by an application altogether until hardware support existed.
The disadvantage of the inclusive approach of OpenGL was that an application had nothing to tell it what is fast and what is slow other than measuring performance, so, for example a feature that might slow a game down on a particular card for example using stencil operations (to use an old example), could slow an application down unacceptably on some cards and the developer would have to check for this. D3D on the other hand was not inclusive and so a developer would check for capability bits to see if a feature existed or not and wouldn't be in danger of falling back to a slow path. The drawback is that many features just didn't exist even in the capability bits or any API stubbs, so until hardware support or stencil support was added to D3D, card makers couldn't expose it to developers and game developers couldn't build advanced support into their games.
Direct3D, was designed with a hardware abstraction layer before Microsoft's initial release where Microsoft developed a lot of the front end to ease driver development. This could make it easier to implement on gaming cards, and with the simpler feature set is likely the primary reason for its fast adoption in the late 1990s. D3D began life as an optimized 3D software engine purchased with the takeover of a company called RenderMorphics so it began with an optimized software rendering capability although this is no longer a concern.
Microsoft had two driver models for OpenGL, the Installable Client Driver which required a full ground up implementation of OpenGL by the maker of the graphics card and the Mini Client Driver where Microsoft supplied a lot of the front end transformation and setup that fed the graphics card. They abandoned the MCD driver model just before hardware makers were about to ship their completed drivers leaving several card makers high and dry and further impeding the availability of OpenGL drivers.
Extensions
The OpenGL extension mechanism is probably the most heavily disputed difference between the two APIs. OpenGL has a mechanism where any driver can advertise its own extensions to the API, thus introducing new functionality such as blend modes, new ways of transferring data to the GPU, or different texture wrapping parameters. This allows new functionality to be exposed quickly, but can often lead to confusion as different vendors implement similar extensions with different APIs. Many of these extensions are periodically standardized by the OpenGL Architecture Review Board and possibly included in future OpenGL revisions.
On the other hand, Direct3D is specified by one vendor (Microsoft) only, which leads to a more consistent API, but sometimes missing vendor-specific features. nVidia's UltraShadow[1] (http://www.nvidia.com/object/feature_ultrashadow.html) technology, for instance, is not yet available in the stock Direct3D APIs at the time of writing. It should be noted that Direct3D also supports texture format extensions (via so-called FourCC codes), but they are little known and rarely used.
An example of the extension difference was the way in which newer graphics cards added support for pixel shaders (known on OpenGL as "fragment programs"). Under Direct3D there is a single "pixel shader 1.1" (PS1.1) standard which works on both the GeForce 3 and up, and Radeon 8500 and up. Under OpenGL the same functionality is accessed through custom extensions.
In theory the Microsoft approach means a single code path can support both cards, whereas under OpenGL the programmer would have to write two separate systems. In reality things are not so simple. nVidia's implementation of shaders is tightly tied to a number of uncommon features of their cards, and so in reality the programmer would likely have to write two sets of code anyway. However, this situation only existed for a short time, second-generation pixel shading cards were considerably more alike, leading to Pixel Shader 2.0. At which point OpenGL introduced its own ARB-approved extensions for both vertex and pixel shader extensions (GL_ARB_vertex_program and GL_ARB_fragment_program).
Portability
For the most part, Direct3D is tied to one specific platform: Microsoft Windows. A partial port of the Direct3D API (and DirectX in general) has been implemented in WINE, and Microsoft itself supplies a modified version for Xbox development. But even considering these exceptions, Direct3D is so tightly integrated into Windows that porting it to a non-Windows operating system is very difficult. In fact Microsoft once promised to deliver a version for the PowerPC-based Apple Macintoshes, but later abandoned this project, thereby killing game development on the platform until Apple standardized on OpenGL. However, a third party company has developed a DirectX port to the MacOSX called MacDX -- the quality of this port has still not been objectively evaluated.
OpenGL, on the other hand, has implementations available across a wide variety of platforms including Windows, UNIX-based systems, Linux, and the aforementioned Mac OS X. In general, almost all modern operating systems capable of rendering 3-dimensional graphics will have a native OpenGL driver of some sort, or access to OpenGL-compliant software renderer such as Mesa 3D.
This makes Direct3D a more limiting choice; however, it is up to the programmer to decide if this "lock-in" is a problem or not. For instance, the games market on non-Windows computer platforms is rather slim at the time of writing, so for many games publishers this might not be a big problem.
Low-end cards (such as the Intel Extreme Graphics line) tend to have better driver support for Direct3D than OpenGL; however both ATI Technologies and nVidia, by far the two biggest players in the market at the time of writing, have OpenGL drivers that range from passable to excellent for all their modern cards (on both Windows and selected non-Windows platforms).