In Ogre 2.1 we’ve modernized the whole engine. We started by adopting OpenGL 4.4 as our main API, and then we adopted D3D11 as well.

It’s been an enlightening experience. From a performance point of view there is no definitive answer “OpenGL is always faster” or “D3D11 is always faster”, because the truth is, some of our demos (and real world code) run faster on GL, others run faster on D3D11, while sometimes the reverse happens if you switch GPU vendors.

And sometimes, there is no difference at all. Assuming you’re using modern practices, that is.

It’s been a few months now, and this is what I could gather:

• GL gives you lower access to synchronizations, with fences, memory barriers for asynchronous shaders (they’re a bit lame because they’re too coarse, but far better than D3D11) and Persistent Mapping. Hitting no stalls is very easy now. In contrast, D3D11 sucks on this end, and it’s easy to hit DISCARD memory limits from the driver, which means stalls. Furthermore, the main problem is that map NO_OVERWRITE wasn’t supported on constant & shader resource buffers until D3D11.1 (which means Windows 8.1). This is a huge problem for low level management. One workaround we sometimes do is to use a vertex buffer with no_overwrite and then a CopySubResource to the actual buffer. This can sometimes be even faster because the GPU may use a DMA engine to transfer the data from CPU to GPU. But this trick doesn’t always work, and penalizes also integrated GPUs which don’t have DMA engines and have limited bandwidth. Having no_overwrite on shader & constant resources to be a Win 8.1-only feature was a dick move.

• When dealing with legacy code (aka “the v1 objects” in Ogre) and has therefore “less AZDO in them”, these “DISCARD” semantics that were getting in the way in the previous point really give an edge to D3D11 here. Users with code relying on a lot of legacy v1 objects will notice that D3D11 may perform significantly faster than GL.

• HLSL shaders are often faster than their GLSL counterparts. No surprises here. The fxc compiler is very aggressive (though sometimes too aggressive) and the translation from D3D asm to the GPU ISA has been optimized to death thanks to a bazillion of games relying on D3D.

• HLSL shaders sometimes are optimized too much. Containing precision errors or even blatantly incorrect results (which we’ve reported); whereas their GLSL counterparts produce the correct output.

• Compilation time for HLSL shaders is measured in seconds. Compilation time for GLSL shaders is measured in milliseconds. This is both good (shader optimizations) and bad (why does it still take +3 seconds with skip optimization flag??? sounds like an accidentally quadratic behavior when parsing the syntax, triggered by arrays in const buffers, the bigger the array, the much, much longer it will take)

• D3D is often affected by Driver-tweakable settings in the control panel; while generally GL is not. I was wondering why D3D was looking blurrier (and running faster) compared to GL; until I found out the AMD CCC settings were not set to “maximum quality”. Once I did that, the blurriness was gone, and the performance was more or less the same; which means GL applications were not affected by this setting. I’ve been hearing similar things from our NV testers.

• Texture management on GL is a royal PITA. Implementations have bugs everywhere. Can’t blame them though. TextureStorage is reasonable, but it still lacks the well defined rules and the aggressive validation layer from D3D11. This is more of a problem when the end-user has old drivers; but every now and then we hit a bug in the newest drivers, particularly with the less used features such as texture arrays, 3D textures, and cubemaps.

• Compatibility-wise, D3D11 is a clear winner for Intel cards. For the very latest cards with latest drivers, compatibility is pretty much the same for all three major vendors. The biggest problem comes from older cards which rarely gets updates anymore, and thus D3D11 is more compatible: For Intel, it seems “old” means anything that is more than one year old. For AMD, the Radeon HD 4xxx series went into legacy, while HD 5xxx series are still getting updates. For NV, that means anything older than the GeForce 4xx series. On “old” hardware, D3D11 is much more likely to run without glitches. However remember that as mentioned above, sometimes HLSL is so thoroughly-incorrectly optimized that it produces bad results, ironically making GL more likely to run without glitches in these scenarios (vendor-specific).

• That being said, D3D11 can have very strange anomalies where switching to OpenGL can be an alternative that works (not to mention that Ogre itself can have bugs in the D3D11 implementation that may not be present in the GL implementation, or vice-versa).

• Compatibility-wise GL is the only good choice on Linux. Mesa drivers are yet unable to run our samples though. They’ve made significant progress but it seems likely their GLSL compiler produces bad output.

• D3D’s separation of samplers and textures allows them to use around 12 different samplers and 128 bound textures per shader. Whereas GL, having them together, is often limited to between 16 and 32 depending on the GPU model & driver (and for any practical use… that means 16). At 128 bound textures (which can also be texture arrays), we can almost literally emulate bindless. But I didn’t even care to try how that would perform since GL is so limited.

• D3D’s resemblance of UAVs to RenderTargets is annoying as hell as compared to GL’s resemlance of UAVs to Textures. They may have good reasons being a state-tracking API, but it is annoying as hell.

• Following modern GL, performance on Windows is often around the same as on Linux. We noticed sometimes Linux wins, but sometimes loses. There are several factors, GCC is often more aggressive at optimizing (which means our actual code is what is running faster), by default we compile in 64-bit on Linux while by default we compile in 32-bit on Windows, Linux doesn’t give a damn about GPU security (we suspect in very specific scenarios that performance differences were due to Windows zero’ing GPU memory before returning control to us, while Linux just gave us a buffer right away with garbage on it; that’s a massive security breach). However things like the Unity compositor in Ubuntu can severely degrade the performance. And VSync on Linux is broken. Just broken. It’s a miracle when it works; and often when it works, performance is severely degraded. Because of all this, our benchmarks vary wildly. These factors tend to counter each other giving pretty much the same performance as Windows, while sometimes one of them gets noticed due to specific conditions (making it faster, or making it slower: we’re talking about +/- 30-40% differences here, they’re not minor). And what do we compare against Windows? An out of the box Ubuntu, which is quite common? Or a Lubuntu box which is considerably faster at most of our benchs? At least they all look exactly the same, though Linux drivers tend to have a few more bugs.

• OS X is just… nevermind. Apple just doesn’t take 3D graphics seriously.

Well… both APIs have their own quirks. There is no definitive winner. If you stick strictly to modern practices (ie. our “v2” interface); you will get lower overhead on GL. However we can’t say better performance, since often the HLSL shaders perform slightly faster (and very rarely: significantly faster).

So it ends up as a combination of what is your bottleneck (CPU vs GPU), and how good the driver is at compiling the GLSL shader and how good it is at translating the D3D asm to ISA.

I have yet to determine how much difference the “asynchronous compute shaders / UAVs” can do to GL (with explicit-but-coarse Memory Barriers) vs D3D11 (with implicit memory barriers on every single invocation).

Since Ogre is able to switch between both at runtime, the best answer is to try to support both APIs and let the user decide.

With D3D12 around the corner and Vulkan in the works, this post may sound very late. But if you care about cross platform compatibility and still supporting legacy hardware, it can still be very useful.