Anyway, whatever they're going to peddle, I just don't have the money for it. So I'm staying with my GTX 560 Ti. In any case, its going to be a while before I even learn enough to use OpenGL 4.3 features, and its not like I have much time for gaming these days.

<snip>

I'm not sure that it's wise to start raising the old API war here, but this post - while containing a kernel of truth - ignores the main reasons why people like using D3D - better tools, better consistency (I can write a D3D11 program today and it will run consistently on Intel, NV and AMD hardware) and more robust drivers. Let me know when Intel and AMD have fully featured GL4.3 drivers that don't come with the usual havoc caused by bugs and inconsistencies.

On the other hand, with GL I sure can tap into extra hardware functionality via vendor-specific extensions early, but if I do so then I'm limiting my code to the segment of the market that has that specific hardware. Otherwise I'm looking at writing multiple different code paths with varying performance and quality. Remember when Doom 3 had 5 different rendering backends? We don't want to have to go back to those days.

Microsoft and D3D have done the world a favour by forcing vendors down a path of consistency which has been of benefit to everyone; throwing that away seems a strange thing to want to happen.

The newer vendor-specific extensions are nice for experimental work, but it's a bit disingenuous to speak of them as if they were more generally useful. The real advantages of GL have always been it's portability, it's richer and more flexible API and it's exposure of more modern features (here I'm talking about the core API, not vendor-specific extensions) without requiring an OS upgrade (unless you're Apple, who seem to have missed the point of that part of it).

In reality both APIs bug me but for different reasons. Each has their own strengths but the weaknesses are sufficient that anytime I'm using one I find myself wishing I was using the other.

Bind to edit needs to die in the next GL_VERSION. Fortunately GL_EXT_direct_state_access is quite well supported (and id Software use it so it bloody better well be) but a core API version with an extension available for downlevel hardware is badly needed. This is something that's a purely artificial software construct and there is no good reason for it to continue to exist beyond ARB inertia (and the possibility that someone on the ARB loves it - which I'm not ruling out because even newer functionality like texture storage still uses it). Just bite the bullet and respecify both texture objects and buffer objects; there is a LOT of other cleanup needed in both (the old binding point concept is also a bizarre artificial software construct) and buffer objects in particular are still (even in the days of GL_ARB_map_buffer_range) missing a sensible and performant method of consistently handling dynamic updates for all buffer types - which is incredibly stupid considering drawing from buffer objects is the only way to draw with the core profile.

D3D never had that last problem; DISCARD/NO_OVERWRITE works and works well; it behaves as expected, you ask for specfic behaviour and you get it. I'm eternally bemused that GL continually adds esoteric (and sometimes not-so-esoteric - like vertex attrib binding, which D3D has had since version 9) functionality but still fails to have these really basic problems addressed.

GL FBOs still lack the ability to switch the color buffer without also switching the depth buffer. That's nuts.

On the other hand, I can add something like texture arrays to my GL code without having to also move to a completely different API and rewrite all of the rest of my rendering code in the process, and that's awesome. It's understating how awesome it is by just mentioning it as one point over a few lines so I'll say it again - that's AWESOME.

So overall that's why I'm annoyed by both APIs and that's why I get annoyed whenever anyone talks of either as if they were perfect, because neither is and each has serious flaws that the other doesn't have. I fail to get excited about a new version of either in the current circumstances, but give me a GL with bind-to-edit removed for textures and buffer objects, shared standalone uniforms and a sensible performant way of updating dynamic buffer objects, make this functionality available for downlevel hardware, get bug-free drivers exposing these out in a decent timescale, and I'll be happy. Without those, D3D still wins.