Maybe they wouldn't be so far behind on OpenGL if they weren't devoting so much to Mantle.

Hahahahaha. Apply cold water, AMD.

Maybe I just don't see the benefit. I've never worked with a console and I haven't seen any Mantle vs. OpenGL MDI + bindless performance comparisons. It seems to me that with MDI you are already reducing driver overhead to the point where it is negligible, and you will be limited by things like fill rate or vertex transformation.

Fill/transform rate vs driver overhead is apples and oranges in that one is CPU cost and one is GPU cost.
When working on console games in the past, the tech director almost always hands me a budget to work with; as the rendering guy, I've typically gotten 100% of the GPU (say, 33ms) and a decent share of the CPU (highest was 15ms on the "main thread"). I expect that this will change going forward, with all the other departments now wanting slices of GPU time to do their compute work

No matter what, I'm going to try and use that entire 33ms of GPU time. If we're under budget, I'll try and increase quality until we're closer. Usually you're over budget though, so you spend the whole time creatively optimizing to get into budget while maintaining the quality level you want....
However, if I can reduce the CPU time from 15ms to 5ms, then some other department on the team can have that 10ms I just saved. That might mean that the quality of the AI in the game gets a huge boost, etc...

So, optimizing the CPU-side costs of my graphics code doesn't suddenly make me limited by fill/transform costs. That's a different problem. On the GPU-side, I'm always limited by those things and am trying to optimize the GPU-side workload!
By optimizing the CPU-side costs of my graphics code, I'm reclaiming time for animation, physics, AI, UI, audio, etc to use.


Regarding MDI and bindless, I haven't made an engine around them, so I don't know what the costs of your GL API calls would be in such an engine... but to become "negligible", I'd need the GL calls to all complete in a fraction of a millisecond. If the workload is larger than that, then I'll want to be able to split that workload over several cores.

I also wouldn't invest the time into writing an MDI+bindless engine at the moment, because HW support is not widespread yet. On the other hand, I should be able to do multi-threaded command-buffer-generation on any GL2-level GPU if only the API and drivers decided to support such a thing!!

Single-threaded code is dead. The future is parallel, so every API that I use should support multi-core processing going forward, no excuses (other than, yeah, maybe if it's so trivial in cost that it doesn't even blip on the profiler).

We've been writing multi-core rendering engines for a decade now, using the other APIs out there which actually supported threaded command-buffer-generation and submission... but have had to switch back into single-threaded mode for the PC because GL hasn't kept up with reality. Even some D3D11 drivers fail in this regard... so it's not just GL's fault.
Even if they have optimized the API to the point where it's acceptable performance-wise to just make your GL API calls from a single thread, that's no excuse for this sorry state of affairs.

It's good to see it finally happening, but I can't help remembering how long GL4.3 took to get out of their beta drivers and into release.

OK, that's gonna read as if I'm just being negative about AMD, and any criticism is probably justified, but it is a long time since I've had cause to trust their commitment to getting new GL stuff out: the fact that I currently rank Intel above them - despite lagging a coupla versions behind - is probably telling.

I wouldn't mind that so much if a guy working there wasn't pushing methods which don't work on their drivers on twitter AND if non-4.4 extensions didn't turn up... not that those are documented anywhere either.

The amusing thing is AMD taking part in this AZDO presentation has basically pushed me towards getting an NV GPU because the functionality is cool, I want to use it, but AMD aren't delivering...

And they wonder why people don't test their stuff on their hardware... *sigh*

Looks like your wish came true. The new 14.4 driver supports OpenGL 4.4: http://www.techpowerup.com/200081/amd-catalyst-14-4-rc-available-for-download.html

Feature Highlights of The AMD Catalyst 14.4 Release Candidate Driver for Windows

...

Full support for OpenGL 4.4
OpenGL 4.4 supports the following extensions:

• ARB_buffer_storage
• ARB_enhanced_layouts
• ARB_query_buffer_object
• ARB_clear_texture
• ARB_texture_mirror_clamp_to_edge
• ARB_texture_stencil8
• ARB_vertex_type_10f_11f_11f_rev
• ARB_multi_bind
• ARB_bindless_texture
• ARB_spare_texture
• ARB_seamless_cubemap_per_texture
• ARB_indirect_parameters
• ARB_compute_variable_group_size
• ARB_shader_draw_parameters
• ARB_shader_group_vote

shading language 4.40 still missing though according to opengl extension viewer 4.1.6...

AZDO talk is on GDC Vault (and its free! :P)

http://gdcvault.com/play/1020791/