[QUOTE=Alfonse Reinheart;1264435]You can’t really say that yet. D3D12 and glNext are (generally) unknown with regard to their level of abstraction. And Metal, no matter what Apples wants to claim, is generally speaking no closer to the hardware than OpenGL ES.
The biggest structural change for Metal compared to OpenGL is the explicit control over command queues. And that’s not so much a lowering of the abstraction so much as a different abstraction. It’s a sideways move, going from an immediate abstraction to a buffered abstraction. After all, it’s not like you’re writing command tokens into memory buffers and then telling the GPU to execute them. You’re still using API calls to set things like viewports, etc. You’re just calling them in a different way.
But the core abstractions we see in OpenGL are still there in Metal. You have state objects (admittedly immutable, but the object abstraction remains). You have resource objects. You have vertex formats definitions defined by the API. And so forth.[/QUOTE]
I agree with Alfonse mostly here. The Metal API is also designed to be much more tile-based renderer friendly. Indeed, rendering command buffer encoded does not allow the modification of any texture data except for the actual texture target. Blitting commands are done by a separate encoder and so on. The API is quite slick to automagically avoid the use patterns that murder tile-based renderers.
On a side note, you had asked where to dig up documentation for AMD or Intel. Intel has 01.org website, and the public GPU documentation is at Programmer's Reference Manuals . Additionally, the open source project Mesa has a driver for Intel’s GPU family updated and maintained by Intel personal. The source can be found in Mesa at src/mesa/drivers/dri/i965 (that driver covers Gen4,5,6,7 and 8).
The Metal API is also designed to be much more tile-based renderer friendly. Indeed, rendering command buffer encoded does not allow the modification of any texture data except for the actual texture target. Blitting commands are done by a separate encoder and so on. The API is quite slick to automagically avoid the use patterns that murder tile-based renderers.
I hadn’t really thought about that, but that does explain some of the more oddball things in Metal. It also makes me somewhat concerned about glNext, since it is intended (from what I understand) to span both mobile and desktop platforms with a single API.
I want to recap what has just happened in this thread, so that you can fully understand the problem.
You asked for bindless vertex arrays. You linked to various posts, articles, and videos about it. You made various claims about what it would do for OpenGL competitively and how OpenGL would be if this weren’t available.
And yet… you couldn’t be bothered to research it yourself. You couldn’t take 10 minutes of your life to learn exactly what it was you were asking for.
In short, you have asked for something that, by your own admission, you don’t even know what it is!
We’re not talking about digging into the micro-details of various hardware here. We’re not talking about deep knowledge of various drivers and the way hardware works. We’re not talking about being “a hardware specialist”. We’re talking about reading and understanding a publicly available extension specification.
When it comes to asking for something from somebody else, a piece of advice: your time is not as valuable as theirs. So you should never be “in a hurry” to make a suggestion; this forum will still be here tomorrow. Research first, understand first; then bother someone once you have some understanding of the idea.[/QUOTE]
You’re right I should have been more patient.
Somebody suggested it to me, thus I added it to my feature request.
I read the overview section and found it would help in lowering overhead in vertex processing.
Being relevant to the area of graphics processing I was talking about I wrongly assumed this extension would do the thing I wanted.
The extension does help in processing vertex data efficiently and might be useful for OpenGL.