Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Are there any feature comparisons on Direct3D 11 and the newest OpenGL versions?

Well, simply put, Direct3D 11 introduced three main features (taken from Wikipedia):

  • Tessellation
  • Multithreaded rendering
  • Compute shaders
  • Increased texture cache

Now I'm wondering, how does the newest versions of OpenGL cope with these features? And since I have this feeling that there are features that Direct3D lacks from OpenGL's side, what are those?

share|improve this question
1  
Since "OGL vs D3D" is somewhat of a holy war topic, I'm going to ask this: What problem are you trying to solve with this information? –  Tetrad Nov 29 '11 at 16:34
    
@Tetrad, wanted to know about tesselation in OGL. –  joltmode Nov 29 '11 at 17:33
    
wouldn't have been better to ask something more specific then, like "what hardware tessellation options a la DX11 exist for OpenGL"? –  Tetrad Nov 29 '11 at 20:54
1  
@Tetrad, but if later on I'm interested in Multithreaded rendering and Compute Shaders? I better ask one global question, than 10 specific ones. But if in any way, that's against the "rules", I can correct myself in the future. –  joltmode Nov 29 '11 at 22:22

3 Answers 3

up vote 14 down vote accepted

When one talks about OpenGL and D3D "features," one could be referring to either:

  1. the feature sets supported by hardware that the graphics API exposes, or
  2. the feature sets of the API itself that don't really relate to the hardware.

For example, a programmable tessellation pipeline is something the hardware generally has to support (let's ignore, for the purposes of practicality, that an API could in theory implement missing hardware features in software as that's generally too slow to be of real use). Presupposing it does, you can gain access to that pipeline in both D3D and OpenGL. D3D builds the interfaces for doing so into the core API of D3D11 via the hull/domain shaders and tessellation APIs. OpenGL provided an extension that was eventually promoted to part of the core API. When it comes to hardware features, OpenGL and Direct3D are generally equivalent in terms of what you can make the hardware do via either API. The differences come in how.

There are hundreds of small API features (unrelated to actual hardware capability) that differ in both APIs. It's not practical to list them all in an answer. Aside from the fact that D3D is a "traditionally COM-like" API and OpenGL is a "traditionally C-like" API, one of the biggest differences in the feature set is that OpenGL has its rich extension mechanism (and D3D has no such thing). This tends to mean that OpenGL is in theory more flexible and adaptable to new capabilities, at the cost of being slightly more cumbersome to use (thus the plethora of OpenGL extension assistance APIs like GLEW).

share|improve this answer
1  
-1: "OpenGL provides an extension." That extension is core OpenGL in 4.0. And since any hardware that could implement that extension could implement the rest of 4.0... not many use it as an extension. And even then, using it as an extension doesn't change the code, because the tessellation extension is a core extension. The functions and enums don't have an "ARB" suffix. So code that uses it as an extension looks the same as regular core GL code. –  Nicol Bolas Nov 29 '11 at 18:42
    
Fair point, I edited my answer slightly to reflect that. –  Josh Petrie Nov 29 '11 at 19:06
2  
It was not "eventually promoted" to anything; ARB_tesselation_shader was released on the same day as GL 4.0. If anything, it was the core functionality that was spun off into an extension form. The ARB simply does that these days as a matter of course. –  Nicol Bolas Nov 29 '11 at 19:15
    
I think the confusion here stems from the more primitive ATI tesselation extension (which was actually something completely different), with perhaps a mixture of GLU tesselation (which didn't even run in hardware) thrown in? –  Jimmy Shelter Nov 29 '11 at 23:35

Taken from Wikipedia, too: there aren't many differences. Strictly speaking, OpenGL is usually slightly behind Direct3D in terms of features, because the standardisation takes time. However, many of these features are available as OpenGL vendor-specific extensions first, then in the standard itself after some time.

  • Compute shaders are available in GLSL shader model 5.
  • Tessellation is available in OpenGL 4.x (see a tutorial here).
  • Multithreaded rendering is tricky in OpenGL, but certainly possible, and in all honesty I believe most of what D3D does is manage a big global lock and the interaction with the GPU is still single-threaded.
  • I don't know exactly what's implied by "Increased texture cache" but I believe they just raised the lowest common denominator for that feature.

As for your last question, in my opinion, the features that Direct3D lacks the more are a Mac OS X version, a Linux version, an Android version, an iPad/iPhone version, and a PlayStation 3 version :-) (while the last three platforms actually support OpenGL ES rather than OpenGL, it makes porting software a lot easier than porting Direct3D to OpenGL ES)

share|improve this answer
    
That last list took me by suprise, haha. –  Tili Nov 29 '11 at 16:51
    
D3D has more sensible management of multiple monitors/multiple gfx cards too; can't be underestimated with some end-users. –  Jimmy Shelter Nov 29 '11 at 17:45
    
OpenGL lacks an Android/iPad/iPhone/PS3 version too. OpenGL ES is not the same as desktop OpenGL. They are similar, but there are some incompatibilities. –  Nicol Bolas Nov 29 '11 at 18:44
    
Well, well, you're right. I was trying to end in a humorous tone, but I agree it may be misleading. I'll clarify what I meant. –  Sam Hocevar Nov 29 '11 at 20:55
    
@NicolBolas But what if one wrote it all in 'OpenGL ES' which is fully compatible with OpenGL 4.1, which is then indeed OpenGL? :D –  DMan Nov 30 '11 at 2:47

The other answers (Sam and Josh) cover most of what you need to know, but just adding a few extra points.

Before that however, Josh's point about the API not offering features is worth repeating. It's quite incorrect to say things like "OpenGL has vertex buffers" or "D3D has shaders", and was just as incorrect back in the day when you used to read things like "D3D doesn't have a stencil buffer" or "OpenGL has polygon offset". Your gfx hardware has features and the API exposes them; if your gfx card doesn't have a feature no amount of exposition in the API will give you it (unless you use some form of software emulation, which you really don't want to do) and if your gfx card has a feature but the API doesn't support it then you can't use it either.

Moving on with the extra stuff.

D3D has more sensible management of multiple monitors/multiple gfx cards, which can't be underestimated with some end-users.

Explicit memory pools in D3D9 or below were nice (aside from the dreaded D3DERR_DEVICELOST) and it's vertex buffer API is much cleaner and clearer and easier to use. Separation of layout specification from data specification was the right decision IMO. GL has improved with attrib arrays and VAOs but it's still not all the way there.

D3D also guarantees a single consistent shader compiler for all users and on all hardware, whereas each GL implementation has a different shader compiler. The Effects framework is also very nice.

D3D generally has better quality drivers than OpenGL. That's pretty critical.

OpenGL has extensions. That's something of a double-edged sword, as while you can get access to newer vendor-specific features earlier, you may end up with a mess of multiple codepaths all doing broadly the same thing. You make your own choice about which side of that tradeoff you're happier to accept.

OpenGL still has some nice things that D3D is missing. The accumulation buffer (on hardware that accelerates it) can do some neat things; D3D11.1 is apparrently finally going to get logic ops on the framebuffer.

glCopyTexSubImage is very nice in cases where it's implemented properly (which should be everywhere as Doom 3 used it) and D3D has no direct equivalent, to pull another specific example out.

OpenGL is capable of providing software fallback for things required by the spec but unsupported in hardware (not all things however) whereas D3D will normally give you a big ugly crash or error. Another tradeoff where you decide (although I still have nasty memories of a Geforce FX - which supported NP2 textures as required by the GL 2.0 spec - going back to full software emulation without warning if you actually tried to use one...)

OpenGL tends to maintain backwards compatibility through revisions of the API (I'm ignoring core contexts here) whereas D3D does not. There are arguments for and against each philosophy that it's probably not appropriate to retread here; just something to be aware of.

OpenGL still has bind-to-modify whereas D3D does not; you operate directly on the object (or pass it as a param) instead. The OpenGL way tends to mess up any state filtering you might be doing, IMO.

They're the main big ones I can think of right now; nothing too earth-shattering but enough to tip a decision.

Finally, it's also incorrect to state that Android, mobile devices, the PS3, etc use OpenGL, because they actually don't. They use GL ES which is in some ways a subset of full OpenGL and in other ways quite different (and on the PS3 anyone concerned about performance uses libgcm anyway).

share|improve this answer
1  
"D3D also guarantees a single consistent shader compiler for all users and on all hardware, whereas each GL implementation has a different shader compiler." Not entirely true. Only the front-end of the shader compiler is consistent. It compiles to an intermediate form, which the internal driver's compiler compiles to a final form. While that's still a big improvement over the GL situation (minimizing front-end incompatibilities), it's not quite the same thing. –  Nicol Bolas Nov 29 '11 at 18:46
    
Fair point; conceded. –  Jimmy Shelter Nov 29 '11 at 21:17
    
I disagree with what the libgcm comment seems to imply, for the simple reason that PGSL and libgcm are certainly not mutually exclusive. But it’s hard to argue about the specifics or even about usage statistics when so much must be kept secret… –  Sam Hocevar Nov 29 '11 at 21:50
    
I probably should have mentioned something about tools and documentation too... –  Jimmy Shelter Nov 30 '11 at 16:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.