OpenGL vs DirectX: The War Is Far From Over

I’m not going to get into the GL vs DX debate any further than to note that to any professional studio or programmer the API differences are unimportant and the decision is dominated more by issues like the stability of GL vs DX drivers, etc. It’s *really easy* to use a different API on different platforms, so you use the one that works best on each platform. Only very small teams care about the portability of a graphics API to different platforms.

That said let me correct a few factual errors:

1) Your note (2) is incorrect. DirectX 11+ has IncrementCounter() and DecrementCounter() functions that expose this hardware. This is how all modern order-independent transparency per-pixel lists work.

2) Your next box “support for backing up dedicated atomic counters with buffers ARB_shader_atomic_counters)” is sort of misleading and irrelevant. These counters are stored together with buffers in DirectX 11+, so I’d argue you should either remove this line entirely or mark it as supported in DirectX as well.

3) Remove note (4) and put red boxes for OpenGL there… that’s just waffling nonsense. You could put a similar note for every single feature that is red-boxed in DirectX. Copying an entire buffer/texture does not constitute and acceptable workaround.

I know that your intention here is not to do an unbiased comparison, but you really ought to include some of the larger features that DirectX supports and OpenGL does not for completeness. The big ones that you really need to include:

1) Multithreaded rendering and object creation.

2) Compute shader; yes this *is* a graphics feature. It is used in nearly every modern game for everything from shading to texture compression/decompression to post-processing. And no, OpenCL interop does not provide an equivalent mechanism since it causes a scheduling stall at every interop point (compute shader does not since it uses the same scheduler and resources).

Those are the two big ones you really need to add. I’d argue that compiled state handling is still significant superior in DX10+ compared to OpenGL, but it’s not as critical as the above two that you include.

1) No, it’s exactly the same. IncrementCounter() returns an integer. This is separate from Append(). You can use it for whatever you want.

2) Again, you’re incorrect; look it up. No offense, but have you ever actually used DirectX 11? If not, you should at least take my word for it.

And trust me, I’m extremely aware of what both the hardware and software support across OpenGL and DirectX is. I do this professionally.

About compute shader – read what I wrote again please. I did mention OpenCL and why it is not a comparable alternative option.

I’m honestly not trying to “protect” any API. I use them both and have no vested interest in either. I’m actually just trying to correct a few factual errors and give a slightly less biased comparison in your table.

Yes you can copy the counter value to an arbitrary location using ID3D11DeviceContext::CopyStructureCount, including copying it to a staging buffer for readback to the CPU. Just go look up the documentation related to that function, anything with “UAV_FLAG_COUNTER”, IncrementCounter(), etc. The public DirectX documentation is unfortunately pretty bad (one area where OpenGL is way better!) but you should be able to get the idea.

I do follow OpenGL, yes, although probably not quite as much as you (I skim the specs and some extensions, often before they are released). That said, I’m quite aware of what the hardware supports and how various features are implemented so I generally know if there’s something that is not exposed in one API or another.

What I mean with respect to OpenCL is that the OpenCL runtime has it’s own scheduler, command buffers and resource handles. It has it’s own DAG for working out when it’s safe to execute dispatched commands (by tracking input/output buffer dependencies). Because OpenGL has a separate DAG, they do not interact very cleanly. Since there is no global scheduler that decides whether it’s now best to run a compute task or a graphics task, the best you can get is to insert dummy nodes into the other graph and implement them as stalls in one or the other scheduler. This ensures correctness (i.e. a compute task will not start that is dependent on a graphics task), but not efficiency since it is a very coarse-grained mechanism. Thus while you can do this a couple times per frame, you can’t do fine-grained graphics/compute interaction which is a shame since a large portion of future-looking renderers have significant portions that run more efficiently in the compute pipeline. Now don’t get me wrong… having an interop mechanism is better than nothing, but it’s not really good enough to be usable in a shipping game yet.

Anyways I can respect that people have looked this over and I’m not blaming you for getting anything wrong here what-so-ever – it’s subtle stuff that most people wouldn’t catch or really know how it works internally. Hence why I’m just trying to correct the cases that I’m familiar with. Anyways it’s not really a big deal, but your post was going around on twitter and I figured since you obviously spent a lot of time putting the table together there were a couple cases that are worth correcting.

I’ll accept your point that multithreaded rendering is primarily an API/software/driver feature, although it does have some minor implications on hardware. Given that goal in this post, you’re right that it’s fine not to include it.

I totally understand your response in that posts like this typically attract trolls and inexperienced programmers. I can assure you I’m not one of those (my name is in the OpenCL spec among others .

Sure you technically have to “copy” the structure count if you want it somewhere random in a buffer, but copying 1 uint is slightly different than an entire resource

Yes you need a separate UAV for each counter that you want, but note that UAVs are *views* in DirectX, not buffers. So you can have 1 buffer (even with no data) and attach as many counter UAV views to it as you want (up to whatever maximum which will be similar to GL). If you “copy” the counter value it can go to any buffer, not just the one that it is attached to.

And yeah, the public documentation is awful. The spec is slightly better but unfortunately it’s not public.

With regards to OpenCL/OpenGL, the issue is that someone really needs to provide a scheduling interface that would work across vendors and implementations for that to work nicely. Microsoft provides this in the driver interface to DirectX, but currently every vendor does their own, and separate ones for GL/CL. So certainly it’s technically possible, the issue – as always – with GL/CL is getting the vendors to cooperate. For that reason unless there’s a large company with enough ability to force the hardware vendors into line. Such companies exist (not too hard to figure out who I’m hinting at), but so far haven’t been too interested in driving graphics innovation.

I imagined you’d work out who I was from that comment, but I really have no reason to be anonymous And yeah, Intel has only recently gotten serious about graphics so while great strides have been made in Sandy Bridge, there’s still a long way to go, particularly on the OpenGL side. That said, the DirectX drivers are getting pretty decent, although there are still improvements to be made there too.

In any case I’m not directly involved with the driver effort. I’m more on the research side looking at future rendering techniques and trying to get interesting and useful features into the hardware

Sure they are similar CPU overhead, but I don’t think that would be a big issue in this case since the total number of counters that can be bound in a given pass is fairly small. You generally don’t need this function anyways since you typically just directly store the count(s) in a buffer directly when you read/increment/decrement them on the GPU in a shader anyways. You could argue that this copy function is just a convenient syntactic sugar for launching a 1×1 compute kernel that reads the counter and writes it elsewhere.

Yes if the drivers are provided by the same vendor it’s theoretically possible for them to use a shared scheduler, but it does involve having an internal layer where things like resources and jobs are submitted from both frontend APIs, similar to the WDDM layer that Microsoft provides. I’m almost certain that no one does this right now though and I imagine it would take a strong push from game developers for anyone to bother.

I see you put some updates in there – thanks! To be fair though, this is really not correct: “There is no support in Direct3D to use the dedicated atomic counter hardware (supported currently only by AMD GPUs) only by using an append/consume buffer”. The DX mechanism is exactly the same as the GL one and uses the same hardware. The only differences are in the API, and there are no differences in the power or flexibility of either solution. I don’t mind the footnote for the item below it about buffers, but this one really ought to just be green for both GL and DX.

Yup that’s fair – thanks for making the updates!