What is the difference between opengl and direct3d

Only the immediate-mode interface is considered in this document. Microsoft defines the Direct3D API through its COM interfaces, and the semantics are defined by the the help files and sample code accompanying the software development kit provided by Microsoft. Direct3D first appeared in DirectX 3 with execute buffers as its display paradigm. All subsequent releases, beginning with DirectX 5 there was no DirectX 4 , replaced execute buffers with a more traditional graphics primitive display paradigm.

This basic pipeline design has been present since the earliest days of computer graphics and has been enhanced and extended over the years as hardware has become more capable, but the fundamental paradigm has not changed. Vertices are described to the pipeline as a bundle of data consisting of coordinates in space defining the vertex's location and associated per-vertex data.

A graphics primitive is described to the pipeline as an ordered set of vertices. OpenGL vs DirectX. Free Design Course. Login details for this Free course will be emailed to you. Email ID. Contact No. It is an open-source cross-platform application of interface programming which works on rendering of vector graphics of 2d and 3d graphics.

DirectX is a collection APIs which re using for many different types of multimedia platform as well as game programming. It was developed by the Khronos group but originally Silicon Graphics Inc. The latest version of OpenGL was released 3 years ago means on July 31, , and named 4.

Direct3D expects the application to manage hardware resources; OpenGL makes the implementation do it. This makes it much easier for the user in terms of writing a valid application, but it leaves the user more succeptible to implementation bugs that the user may be unable to fix.

At the same time, because OpenGL hides hardware details including whether hardware is even being used , the user is unable to query the status of various hardware resources. So the user must trust that the implementation is using hardware resources "best". Until recently, another functional difference between the APIs was the way they handled rendering to textures: the Direct3D method SetRenderTarget is convenient, while previous versions of the OpenGL required the manipulation of P-buffers pixel buffers.

This was cumbersome and risky: if the programmer's codepath was different than anticipated by the driver manufacturer, the code would have fallen back to software rendering, causing a substantial performance drop. According to a Gamasutra article registration required , the aforementioned John Carmack considered switching from OpenGL to Direct3D because of the contrived use of P-buffers. However, widespread support for the "frame buffer objects" extension, which provides an OpenGL equivalent of the Direct3D method, has successfully addressed this shortcoming.

Outside of a few minor functional differences, typically with regard to rendering to textures the "framebuffer objects" extension did not cover everything, but the ARB is working to address this , the two APIs provide nearly the same level of functionality. Much of the argument revolved around which API offered superior performance. This question was relevant due to the very high cost of graphics accelerators during this time, which meant the consumer market were using software renderers implemented by Microsoft for both Direct3D and OpenGL.

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. For SGI, this was a critical milestone as it showed that OpenGL's poor software rendering performance was due to Microsoft's inferior implementation, and not to design flaws in OpenGL itself.

With the mainstream adoption of graphics acceleration hardware, the use of one API or another no longer implies the use of a specific optimized software renderer. Instead, the low-level rendering logic is implemented in the graphics hardware and its drivers, and thus is largely the same whether OpenGL or Direct3D is used. This trend has revealed that neither API possesses an inherent speed advantage over the other.

The performance of an application depends instead on the programmer's skill, the quality of the drivers, and the performance of the graphics hardware. OpenGL, originally designed for then-powerful SGI workstations, includes a number of features that are only useful for workstation applications.

The API as a whole contains about calls, but only a subset of perhaps 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.

The specification often drives the implementation of hardware acceleration for these features. Meanwhile, Direct3D developers had to wait for the next version of Direct3D to be released and rewrite their games to use the new API before they could take advantage of hardware-based Transform and Lighting.

The advantage of OpenGL's inclusive, extensible approach is limited in practice, however, by the market dominance Direct3D has achieved. In recent years, games have rarely implemented features until Direct3D has supported them, and graphics cards vendors have been reluctant to implement features that current or upcoming versions of Direct3D will not support.

OpenGL includes 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 lead to confusion if different vendors implement similar extensions with different APIs.

On the other hand, Direct3D is specified by one vendor Microsoft only, leading to a more consistent API, but denying access to vendor-specific features.

These were once little-known and rarely used, but are now used for DXT texture compression. When graphics cards added support for pixel shaders known on OpenGL as "fragment programs" , Direct3D provided a single "Pixel Shader 1. Under OpenGL the same functionality was accessed through a variety of custom extensions. In theory, the Microsoft approach allows a single code path to support both brands of card, whereas under OpenGL the programmer had to write two separate systems.

In reality, though, because of the limits on pixel processing of those early cards, Pixel Shader 1. For the most part, the only cards that claimed PS 1. The only cards that claimed PS 1.

Fortunately, this situation only existed for a short time under both APIs. Second-generation pixel shading cards were much more similar in functionality, with each architecture evolving towards the same kind of pixel processing conclusion.

As such, Pixel Shader 2. An issue has arisen between Direct3D and OpenGL recently mid-to-late , with regard to support for Microsoft's new operating system, Windows Vista.

The Vista OS has a feature called Desktop Compositing which is similar in concept to Mac OS X 's Quartz Compositor that allows individual windows to blend into the windows beneath them as well as a number of other cross-window effects. The new OS's rendering system that allows this to function operates entirely through Direct3D; as such, every Windows application is automatically a Direct3D application. The ICD driver model used in prior versions of Windows will still function however.

Note that this functionality only truly matters for applications running in windowed mode. Full-screen applications, the way most people run games, will not be affected.