I'd like to see if Khronos has any news on OpenGL 5 (or 4.4), unless they're specifically playing "catch-up" with DirectX right now (ie, no news until new DirectX gets released).

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.

OpenGL has never needed to play catch-up to Direct3D.

Almost every feature that was added to Direct3D was available to OpenGL first. Many of the features developed at Microsoft's request for Direct3D and that have Direct3D-style names for their OpenGL extension were co-released for both OpenGL and Direct3D at the same time as the hardware became available. One notable exception to the rule was hardware vertex buffers.

Of the roughly 570 extensions, about 99% of the features were available on OpenGL before or simultaneously with Direct3D.

When ATI and nvidia create new features, they nearly always provide the features to close-relationship developers to test and try out as private OpenGL extensions on development drivers. These are then submitted to the ARB and registered as extensions at about the same time they are made public. This process almost always happens months before the feature becomes available to general developers through Direct3D SDK updates.

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.

I guess I'm on the same boat. My opinion is that further market fragmentation is to be avoided. I don't expect next D3D to add much though.

<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.

OpenGL has never needed to play catch-up to Direct3D.

Almost every feature that was added to Direct3D was available to OpenGL first. Many of the features developed at Microsoft's request for Direct3D and that have Direct3D-style names for their OpenGL extension were co-released for both OpenGL and Direct3D at the same time as the hardware became available. One notable exception to the rule was hardware vertex buffers.

Off the top of my head, missing from the core API while present in D3D; VBO, FBO, efficient frame buffer blitting ability, functional multi-sample render target support, Geo Shaders (and associated functionality), Hull/Domain shaders, Compute shaders, (still missing, last I checked, append/consume buffers), no cross vendor way of dealing with the depth/stencil buffer for ages (DX9 feature), draw indirect (index, instanced and dispatch variants), instancing support (DX9), point sprites where missing and then broken for ages.

I dare say others exist.

While the ARB are getting better, it only took a couple of years post-D3D11's release to sort out the gaps, to claim OpenGL was never missing features is to distort the truth so much it starts to resemble a VW Beatle. Heck, FBOs and associated functionality took YEARS to appear even in extension form as back then the ARB couldn't organise an arse finding competition if they were given a map and complete step by step instructions.

Right now I can only think of two (AMD) OGL extensions I'd like to play with; multi-draw indirect and 'sparse texture' (aka PRT) as they have no D3D version... unfortunately every time I consider writing some code to do so I remember that a) I have to worry about extensions in some manner and b) bind-to-fucking-edit is still OGL's way of doing things which is a pants-on-head retarded API model these days.

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.

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 think anyone with a degree of honesty would agree with that; while D3D is now my preferred API (before the GL3.0 fiasco I was using OpenGL all the way) it is, as you say, not perfect but currently it is the best we've got.

That's partly why my opening post mentions a new API; something akin to NV's Bindless extension/design to remove the overhead that exists in both the APIs. With D3D being considered 'mature' technology now there might be an opening for something to come along; I dare say it would gain some ground reasonably quickly from the AAA speed nuts like myself even if it wasn't used for a couple of years in a real product after release.