Comparison of OpenGL and Direct3D

Direct3D and OpenGL are competing application programming interfaces (APIs) which can be used in applications to render 2D and 3D computer graphics. Hardware acceleration of this process has been commonplace since approximately 1999. As of 2005, graphics processing units (GPUs) almost always implement a particular version of both of these APIs, such as these examples: DirectX 9 and OpenGL 2 circa 2004; DirectX 10 and OpenGL 3 circa 2008; and most recently, DirectX 11 and OpenGL 4 circa 2011. GPUs that support more recent versions of the standards are backwards-compatible with applications that utilize the older standards; for example, one can run older DirectX 9 games on a more recent DirectX 11-certified GPU.

Availability

Direct3D application development generally targets the Microsoft Windows platform. The OpenGL API is an open standard, and implementations exist for a wide variety of platforms.

	Desktop Support	Embedded System Support	License
Direct3D	Microsoft Windows and XBox	Windows Embedded and Windows CE (through Direct3D Mobile)	Proprietary
OpenGL	Cross-platform	Cross-platform through OpenGL ES	Open standard (some features patented)

In more detail, the two computer graphics APIs are the following:

1. Direct3D is a proprietary API by Microsoft that provides functions to render two-dimensional (2D) and three-dimensional (3D) graphics, and uses hardware acceleration if available on the graphics card. It was designed by Microsoft Corporation for use on the Windows platform. Direct3D can also be used on other operating systems through Win32 api layer such as Wine, although the subset of features provided is not as complete as the reference implementation.
2. OpenGL is an open standard API that provides a number of functions to render 2D and 3D graphics, and is available on most modern operating systems including but not limited to Windows, Mac OS X and Linux.

Note that many essential OpenGL extensions and methods, although documented, are actually patented, thus imposing serious legal troubles to implement them (see issues with Mesa).

OpenGL and Direct3D are both implemented in the display driver. A significant difference however is that Direct3D implements the API in a common runtime (supplied by Microsoft), which in turn talks to a low-level Device Driver Interface (DDI). With OpenGL, every vendor implements the entire API in the driver itself. This means that some API functions may have slightly different behavior from one vendor to the next. The GLSL shader compilers of different vendors also show slightly different behavior. The following compares the two APIs, structured around various considerations mostly relevant to game development.

Portability

The proprietary Direct3D is officially implemented only on Microsoft's Windows family of operating systems, including embedded versions used in the Xbox family of video game consoles and Sega's Dreamcast. Several mostly functional reimplementations of the Direct3D API have been made by third parties such as Wine, a project to port common Windows APIs to Unix-like operating systems, and Cedega, a proprietary fork of Wine. However, this process is progressively impeded due to the interdependence of DirectX upon many other proprietary components of Windows, and because Direct3D's proprietary nature requires the difficult process of reverse engineering.

OpenGL has implementations available across many platforms including Microsoft Windows, Unix-based systems such as Mac OS X, GNU/Linux. Nintendo and Sony have developed their own libraries which are similar but not identical to OpenGL. A subset of OpenGL was chosen as the main graphics library for Android, BlackBerry, iOS, and Symbian in the OpenGL ES form.

Microsoft's OpenGL driver provides hardware acceleration in Windows Vista; support was dropped in Windows XP, not long after they failed to deliver Fahrenheit Low Level support for an OpenGL/Direct3D merger in the late 1990s. OpenGL hardware acceleration on Windows is achieved by users first installing installable client drivers (ICDs) developed by GPU manufacturers. These ICDs are, in virtually all cases, bundled with the standard driver download package from the hardware vendor (IHV), so installing recent graphics drivers is sufficient to provide hardware OpenGL support.

More recently, Google's ANGLE project provides a means of converting OpenGL ES 2.0 application calls to DirectX 9. This is done so that WebGL (a subset variant of OpenGL for the web) can run on the common Direct3D runtime, which means there will be less variation between vendors.

Ease of use

Direct3D

The first version of Direct3D in 1996 elicited widespread criticism because even simple operations, such as state changes, required creating and submitting objects called "execute buffers". In contrast, in OpenGL most state changes can be performed with one function call. The Direct3D model frustrated many programmers. A very famous complaint was made by high-profile game developer John D. Carmack in his .plan file in which he urged Microsoft to abandon Direct3D in favor of OpenGL. Chris Hecker made a similar request in an "Open Letter to Microsoft" in the April–May 1997 issue of Game Developer Magazine.

Version 5 (the second version, named to reflect its release as part of DirectX 5) replaced execute buffers with the new DrawPrimitive API, but it was still considered cumbersome. Chris Hecker's "Open Letter to Microsoft" referred to DrawPrimitive as "an immature and poorly-designed clone of OpenGL that's missing some of the architectural decisions that make OpenGL fast."

Despite the controversy, Microsoft continued to evolve the API. A detailed history of releases and added features is given on the Microsoft Direct3D web pages.

Some former critics of Direct3D acknowledge that now Direct3D is as good if not better than OpenGL in terms of abilities and ease of use. In January 2007, John Carmack said that "…DX9 is really quite a good API level. Even with the Direct3D side of things, where I know I have a long history of people thinking I'm antagonistic against it. Microsoft has done a very, very good job of sensibly evolving it at each step—they're not worried about breaking backwards compatibility—and it's a pretty clean API. I especially like the work I'm doing on the 360, and it's probably the best graphics API as far as a sensibly designed thing that I've worked with."

Some design features of Direct3D have remained unchanged since version one, most notably its reliance on Microsoft's COM. One advantage of using COM is that the API can be used in any COM-aware language, notably Delphi, and Microsoft Visual C++, C#, and Visual Basic .NET.

OpenGL

OpenGL is a specification implemented in the C language, though it can be used in other programming languages. It is built on the concept of a state machine, though more recent OpenGL versions have transformed it into much more of an object-based system. As an API, OpenGL depends on no particular language feature, and can be made callable from almost any programming language with the proper bindings. Such bindings exist for Ada, BASIC (BlitzMax (often used to program games), PureBasic, Visual Basic), C#, Delphi, Fortran, Go, Haskell, Java, Lisp, Lua, Pascal, Perl, Python, Ruby, and Tcl to name some.

Comparison

In general, Direct3D is designed to virtualize 3D hardware interfaces. Direct3D frees the game programmer from accommodating the graphics hardware. OpenGL, on the other hand, is designed to be a 3D hardware-accelerated rendering system that may be emulated in software. These two APIs are fundamentally designed under two separate modes of thought.

As such, there are functional differences in how the two APIs work. Direct3D expects the application to manage hardware resources; OpenGL makes the implementation do it. This tradeoff for OpenGL decreases difficulty in developing for the API, while at the same time increasing the complexity of creating an implementation (or driver) that performs well. With Direct3D, the developer must manage hardware resources independently; however, the implementation is simpler, and developers have the flexibility to allocate resources in the most efficient way possible for their application.

Until about 2005, another functional difference between the APIs was the way they handled rendering to textures. The Direct3D method (SetRenderTarget()) is convenient, while prior versions of OpenGL required manipulating pixel buffers (P-buffers). This was cumbersome and risky: if the programmer's codepath was different from that anticipated by the driver maker, the code would have fallen back to software rendering, causing a substantial performance drop. However, widespread support for the "frame buffer objects" extension, which provided an OpenGL equivalent of the Direct3D method, successfully addressed this shortcoming, and the "render target" feature of OpenGL brought OpenGL up to par with Direct3D in this respect.

Outside of a few minor functional differences which have mostly been addressed over the years, the two APIs provide nearly the same level of function. Hardware and software makers generally respond rapidly to changes in DirectX, e.g. pixel processor and shader requirements in DirectX 9 to stream processors in DirectX 10, to tessellation in DirectX 11. In contrast, new features in OpenGL are usually implemented first by vendors and then retroactively applied to the standard.

Performance

Shortly after the establishment of both Direct3D and OpenGL as viable graphics libraries (circa 1995), Microsoft and SGI engaged in what has been called the "API Wars". Much of the argument revolved around which API offered superior performance. This question was relevant due to the very high cost of dedicated graphics processors during this time, which meant the consumer market was using software renderers implemented by Microsoft for both Direct3D and OpenGL.

Early debate

DOS business software such as AutoCAD and DOS games such as id Software's Quake originally had to be optimized to run on many different graphics chipsets. When hardware manufacturers such as 3Dlabs (member of the OpenGL Architecture Review Board) made OpenGL compatible graphics accelerators (e.g., GLint chip), developers such as John Carmack of id Software optimized their products for OpenGL. As multitasking user environments such as Microsoft Windows and the X Window system (X11) on Unix-like systems became prevalent, the relevance of this hardware faded.

Microsoft had marketed Direct3D as faster based on in-house performance comparisons of these two software libraries. The performance deficit was blamed on the rigorous specification and conformance required of OpenGL. This perception was changed at the 1996 Special Interest Group on GRAPHics and Interactive Techniques (SIGGRAPH) conference. At that time, SGI challenged Microsoft with their own optimized Windows software implementation of OpenGL called CosmoGL which in various demos matched or exceeded the performance of Direct3D. For SGI, this was a critical milestone as it showed that OpenGL's poor software rendering performance was due to Microsoft's reference OpenGL implementation, and not due to alleged design flaws in OpenGL itself.

On the other hand, software rendering by the 3D API was largely irrelevant for both Direct3D and OpenGL applications. Not many DirectX applications used Direct3D's software rendering, preferring to perform their own software rendering using DirectDraw's facilities to access the display hardware. As for OpenGL applications, hardware support was expected, and the hardware was so much faster that software fallback by the OpenGL application constituted a rude surprise to the OpenGL developer.

In any case, by the time SGI had demonstrated that OpenGL software rendering performance could be competitive with that of Direct3D, software rendering was fast becoming irrelevant due to the widespread availability of inexpensive 3D graphics hardware. By 1998, even the S3 ViRGE graphics accelerator was substantially faster than the fastest Pentium II running Direct3D's MMX rasterizer.

Marshalling

A more substantive and modern performance difference arises because of the structure of the hardware drivers provided by hardware developers. Under DirectX, IHV drivers are kernel-mode drivers installed into the operating system. The user-mode portion of the API is handled by the DirectX runtime provided by Microsoft. Under OpenGL however, the IHV driver is broken into two parts: a user-mode portion that implements the OpenGL API, and a kernel-mode driver that is called by the user-mode portion.

This is an issue because calling kernel-mode operations from user-mode requires performing a system call (i.e. making the CPU switch to kernel mode). This is a slow operation, taking on the order of microseconds to complete. During this time, the CPU is unable to perform any operations. As such, minimizing the number of times this switching operation must be performed would optimize performance. For example, if the GPU's command buffer is full of rendering data, the API could simply store the requested rendering call in a temporary buffer and, when the command buffer is close to being empty, it can perform a switch to kernel-mode and add a number of stored commands all at once. This is known as marshalling.

Because Direct3D IHV drivers are kernel-mode, and the user-mode code is out of the IHV's hand, there is no chance for such optimizations to occur. Because the Direct3D runtime, the user-mode portion that implements the API, cannot have explicit knowledge of the driver's inner workings, it cannot effectively support marshalling. This means that every Direct3D call that sends commands to the hardware must perform a kernel-mode switch, which again, takes time in the order of microseconds to complete. This has led to a number of behaviors regarding use of Direct3D, the most important being the need for submitting large batches of triangles in one function call.

Since OpenGL's IHV drivers have a user-mode component to them, IHVs have the ability to implement marshalling, thus improving performance. There is still kernel-mode switching, but the theoretical maximum number of switches under OpenGL implementations is simply equal to the Direct3D standard behavior.

Direct3D 10, the release included with Windows Vista, allows portions of drivers to run in user-mode, making it possible for IHVs to implement marshalling, thus bringing the two back into relative performance parity. Mac OS X's OpenGL system is very similar, where IHVs implement a simpler version of the OpenGL API (with both user and kernel mode components), and Apple's additions to the runtime provide the direct interface to the user code, and some basic work to make IHVs' jobs easier.

Race to zero driver overhead

The introduction of Mantle by AMD lead to increased discussion about modernizing APIs, and updating abstraction concepts used by all APIs to reflect actual GPU operations. Both Microsoft and OpenGL vendors began to showcase their visions for limiting or removing altogether driver overhead (the amount of work the CPU needs to do in order to prepare GPU commands).

In March 2014, Microsoft presented basic assumptions and goals for the DirectX12 3D component (to be ready for December 2015). OpenGL vendors took a different approach, and during GDC 2014 presented a mix of features mandatory in OpenGL 4.3 & OpenGL 4.4 or already ARB extensions, to show fast paths already present in implementations from Nvidia, AMD and Intel.

During the presentation, apitest, a new tool for microbenchmarking specific solutions for given problems emphasizing exploration of fast paths in current APIs, was introduced. Both OpenGL 4.x and Direct3D 11 are supported. Gathered results showed that modern OpenGL can be many times faster than Direct3D 11.

Structure

OpenGL, originally designed for then-powerful SGI workstations, includes a number of features, like stereo rendering and the "imaging subset", that were generally considered of limited utility for games, although stereoscopic gaming has drawn more interest with the development of consumer-level 3D displays. The API as a whole contains about 250 calls, but only a subset of perhaps 100 are useful for game development. However, no official gaming-specific subset was ever defined. MiniGL, released by 3Dfx as a stopgap measure to support glQuake, might have served as a starting point, but additional features like stencil were soon adopted by games, and support for the entire OpenGL standard continued. Today, workstations and consumer machines use the same architectures and operating systems, and so modern incarnations of the OpenGL standard still include these features, although only special workstation-class video cards accelerate them.

Extensions

The OpenGL extension mechanism is probably the most heavily disputed difference between the two APIs. OpenGL includes a mechanism where any driver can advertise its own extensions to the API, thus introducing new functions such as blend modes, new ways to transfer data to GPUs, or different texture wrapping parameters. This allows new functions to be exposed quickly, but can lead to confusion if different vendors implement similar extensions with different APIs. Many of these extensions are periodically standardized by the OpenGL Architecture Review Board (ARB), and some are made a core part of future OpenGL revisions.

On the other hand, Direct3D is specified by one vendor only (Microsoft), leading to a more consistent API, but denying access to vendor-specific features. NVIDIA's UltraShadow technology, for instance, is not available in the stock Direct3D APIs at the time of writing. It should be noted that Direct3D does support texture format extensions (via FourCC). These were once little-known and rarely used, but are now used for S3 Texture Compression.

When graphics cards added support for pixel shaders (known on OpenGL as "fragment programs"), Direct3D provided one "Pixel Shader 1.1" (PS1.1) standard with which the GeForce 3 and up, and Radeon 8500 and up, advertised compatibility. Under OpenGL the same functions were accessed through a variety of custom extensions.

In theory, the Microsoft approach allows one code path to support both brands of card, whereas under OpenGL, programmers must write two separate systems. In reality, though, because of the limits on pixel processing of those early cards, Pixel Shader 1.1 was nothing more than a pseudo-assembly language version of the NVIDIA-specific OpenGL extensions. For the most part, the only cards that claimed PS 1.1 functionality were by NVIDIA, and that is because they were built for it natively. When the Radeon 8500 was released, Microsoft released an update to Direct3D that included Pixel Shader 1.4, which was nothing more than a pseudo-assembly language version of the ATI-specific OpenGL extensions. The only cards that claimed PS 1.4 support were ATI cards because they were designed with the precise hardware needed to make that functionality happen.

This situation existed only for a short time under both APIs. Second-generation pixel shading cards functioned far more similarly, with each architecture evolving toward the same kind of pixel processing conclusion. As such, Pixel Shader 2.0 allowed a unified code path under Direct3D. Around the same time OpenGL introduced its own ARB-approved vertex and pixel shader extensions (GL_ARB_vertex_program and GL_ARB_fragment_program), and both sets of cards supported this standard also.

Users

Professional graphics

OpenGL has always seen more use in the professional graphics market than DirectX, while DirectX is used mostly for computer games. (The term professional is used here to refer to the professional production and display of graphics, such as in computer animated films and scientific visualisation, as opposed to games where the graphics produced are for the end user's personal, rather than professional, use.) Currently both OpenGL and DirectX have a large enough overlap in functionality that either could be used for most common purposes, with the operating system itself often being the primary criterion dictating which is used; DirectX is the common choice for Windows, and OpenGL for nearly everything else. Some esoteric applications still divide the applicability of the two APIs: doing accelerated 3D across a network connection is only directly supported by OpenGL with GLX, for example.

At one point many professional graphics cards only supported OpenGL, now virtually all professional cards which work on the Windows platform will also support Direct3D. Part of this has been a change in the professional graphics market from largely Unix-based hardware like SGIs and Suns to less expensive PC-based systems, leading to the growth of Windows in this market segment, while at the same time providing a new market for OpenGL software in Unix-based consumer systems running Linux or Apple OS X.

The principal historical reason for OpenGL's dominance in the professional market was performance. Many professional graphics applications (for example, Softimage|3D, Alias PowerAnimator) were originally written in IRIS GL for high-end SGI workstations, which were far more capable, both graphically and in raw CPU power, than the PCs of the time. Later, many of these were ported to OpenGL, even as the personal computer was evolving into a system powerful enough to run some professional graphics applications. Users were able to run Maya, for example, the successor to Alias PowerAnimator on either SGIs or Windows-based personal computers (and today on Linux, Mac OS X, and Windows). Price competition eventually broke SGI's dominance in the market, but the established base of OpenGL software engineers and the broadening user base for OpenGL in Apple, Linux, and other operating systems, has resulted in a market where both DirectX and OpenGL are viable, widespread APIs.

The other reason for OpenGL's historical advantage was marketing and design. DirectX is a set of APIs that were not marketed towards professional graphics applications. Indeed, they were not even designed with those applications in mind. DirectX was an API designed for low-level, high-performance access to broadly available, lower-performance, consumer-priced graphics hardware for the purpose of game development. OpenGL is a much more general purpose 3D API, targeting a full range of graphics hardware from low-end commodity graphics cards up to professional and scientific graphics visualization well out of the range of the average consumer, and providing features that are not necessarily exclusive towards any particular kind of user.

Gaming developers typically haven't demanded as wide an API as professional graphics system developers. Many games don't need overlay planes, stencils, and so on, although this hasn't prevented some game developers from using them when available. In particular, game designers are rarely interested in the pixel invariance demanded in certain parts of the OpenGL standards, which are conversely highly useful to film and computer-aided modeling.

An attempt was once made to merge OpenGL and DirectX by SGI and Microsoft. The Fahrenheit graphics API was intended to bring together both the high end capability of OpenGL with the broad low-level support of DirectX. Microsoft eventually retreated from the project, having never allocated sufficient resources to produce its portion of the rendering engine. The move was widely held to be purposed to ensure lock-in of developers to the Windows/DirectX platform, which would be lost if the Fahrenheit API became the world de facto standard graphics API. However, Fahrenheit led to a number of improvements in DirectX, and the primary architect of Fahrenheit now works at Microsoft on DirectX.

Gaming

In the earliest days of 3D accelerated gaming, performance and reliability were key benchmarks and several 3D accelerator cards competed against each other for dominance. Software was written specifically for a particular brand of graphics card. However, over the years, OpenGL and Direct3D emerged as software layers above the hardware, mainly because of industry support for a cross-hardware graphics library. Competition between the two rose as each game developer would choose either one or the other.

In the early days of 3D accelerated gaming, most vendors did not actually supply a full OpenGL driver—the reason for this was twofold. On one hand, most of the consumer-oriented accelerators did not implement enough functionality to properly accelerate OpenGL. On the other hand, many vendors struggled to implement a full OpenGL driver with good performance and compatibility. Instead, they wrote MiniGL drivers, which only implemented a subset of OpenGL, enough to run GLQuake (and later other OpenGL games, mostly based on the Quake engine). Proper OpenGL drivers became more prevalent as the hardware evolved, and consumer-oriented accelerators caught up with the SGI systems that OpenGL was originally designed for. This would be around the time of DirectX 6 or DirectX 7.

In the console world proprietary native APIs are dominant, with some consoles (e.g. the PS3) providing an OpenGL wrapper around its native API. The original Xbox supported Direct3D 8.1 as its native API while the Xbox 360 supports DirectX10 as its native API. Most console developers prefer to use the native APIs for each console in order to maximize performance, making OpenGL and Direct3D comparisons primarily relevant for PC platforms.

Mobile phones and other embedded devices

Main article: OpenGL ES

Main article: Direct3D Mobile

OpenGL for Embedded Systems (also known as OpenGL ES) is a subset of the OpenGL 3D graphics API designed for embedded devices. Various versions of smartphone operating systems support OpenGL ES, such as Android, iOS (iPad, iPhone, iPod Touch), Maemo (Nokia N900), and Symbian.

OpenGL ES is available in 5 variants, OpenGL ES 1.0, 1.1, 2.0, 3.0, 3.1. The release of 2.0 remove backwards compatibility with older variants, due to the extensive programmable pipeline functions available in GL ES 2.0, over the fixed-pipeline functions of GL ES 1.0 and 1.1. OpenGL ES 3.0 require new hw over OpenGL ES 2.0, while OpenGL ES 3.1 is meant as software update (new drivers required only).

Direct3D Mobile, a derivative from Direct3D, is supported by Windows CE. Currently all Windows Phone 7 devices use a .NET Framework UI accelerated by Direct3D Mobile 9 on Adreno 200/205 integrated GPUs by Qualcomm.

Windows Phone 8 implements Direct3D 11 (limited to feature level 9_3).

See also

• Direct3D
• Fahrenheit graphics API
• Glide API
• JOGL
• LWJGL
• OpenGL
• Redline
• WebGL

External links

• OpenGL to be fully supported by Vista
• MSDN blog on Vista implementation of OpenGL
• OpenGL 3 & DirectX 11: The War Is Over
• Valve: OpenGL outpaces DirectX, even under Windows