Probably true, but even so, what’s your point?
I was arguing against Gedolo2’s position that bindless vertex arrays “makes the OpenGL 4.x API compete well with current alternatives.” That it is essential to make OpenGL “Not coming over hopelessly ancient.” And that bindless vertex arrays “Provides a good stepping stone between older OpenGL versions and glNext.”
There is not one shred of evidence for any of those positions. OpenGL already competes just fine with “current alternatives”. It does not “come over hopelessly ancient.” And, given Apple Metal as an idea of what we might see from glNext, there is no reason to believe that bindless vertex arrays would be used in glNext, thus not making it a “stepping stone” towards anything.
In short, my overall point is that his point is founded on ignorance. I make no claim as to whether OpenGL 4.6 should use bindless vertex arrays, only that his reasons for doing so don’t hold water.
However, if you really want to have that discussion:
The problem with bindless vertex arrays can readily be seen by the fact that they’re still an NVIDIA extension. Allow me to explain that.
NVIDIA came out with this feature a bit less than 5 years ago. Since that time, it has progressed precisely nowhere in the OpenGL ecosystem. Oh, plenty of people use it. But nobody but NVIDIA implements it.
Now, you could argue that it’s an NVIDIA extension; of course nobody else implements it. Except that’s not true. NV_texture_barrier is widely implemented, even on Intel hardware. Hell, Apple [i]enforces[/i] compliance to it. Both NV_texture_barrier and NV_vertex_buffer_unified_memory were released in the same batch of extensions. So clearly, the fact that NV_vertex_buffer_unified_memory is an NVIDIA extension has not inhibited anyone from implementing it.
You could try to claim that the extension is covered by patents of some kind. Even if that’s true, it is just as true for ARB_bindless_texture. Yet Khronos and NVIDIA worked out whatever legal issues were necessary to make that a widely implemented extension for hardware that supports it. So again, that doens’t jive, unless NVIDIA wants bindless textures supported elsewhere but not bindless vertex arrays.
And if that’s the case, then you lose by default, since Khronos couldn’t make it core functionality even if they wanted to.
Then there’s ARB_bindless_texture. NV_bindless_texture became ARB_bindless_texture in about 6-9 months. It’s been almost five years since NV_vertex_buffer_unified_memory, yet here we are. ARB_vertex_attrib_binding was in fact the perfect time to introduce the feature, since it was already rearranging how VAOs and vertex format state works. Even with that perfect opportunity, the ARB didn’t take it.
Lastly is OpenGL 4.5. That was rather feature light, and the most feature rich part of the set came from OpenGL ES 3.1. DSA is important to be sure. But the ARB’s workload for the 4.5 release was the lowest it’s been since GL 3.1. And that was a half-year cycle. Clearly, the ARB could have devoted time to bring out bindless vertex arrays, but they didn’t.
Since bindless vertex arrays haven’t happened by now, one of the following must be true:
- The ARB has evaluated and rejected the concept.
- NVIDIA wants it to remain proprietary.
- NVIDIA and the ARB are working on the concept behind the scenes, yet haven’t brought it to market after 5 years.
#3 seems rather unlikely. And both #1 and #2 mean that it’s just not gonna happen.
So it’s not gonna happen.
That being said, stranger things have happened. I would have expected hell to freeze over before we got explicit_uniform_locations, considering that people were asking for that before OpenGL 2.0. So it’s not beyond belief that it could happen.
Just highly unlikely.
As for the merits of the technology on its own, yes, it can help save performance. But the biggest reason I suspect #1 happened is because NV_vertex_buffer_unified_memory uses GPU addresses.
Bindless textures don’t really use GPU addresses. What you get there are 64-bit handles that reference the texture. They’re may be integers, but the value of those integers is completely opaque and meaningless. Oh sure, they probably are GPU memory addresses that reference a data structure of some kind. But you don’t treat them that way; you treat them like references in C++. You can store a reference. You can return a reference. But the only thing you can do with a reference is access the object it refers to.
By contrast, unified memory are pointers. You perform pointer arithmetic on them; indeed, you’re required to do so by the glBufferAddressRangeNV call. It takes a 64-bit address and a size; any offsetting ought to have been done by the user.
If the functionality instead returned an opaque handle (which again could be a GPU address), and glBufferAddressRangeNV took a handle plus an offset, I think that would have gone a long way into making the functionality more acceptable. And I don’t think NVIDIA would like the idea of sacrificing performance by making people do two memory fetches and an add for each buffer non-bind (one fetch for the handle, one for the offset).
Not only that, returning actual GPU addresses has to be some kind of security problem. And with all of the “robustness” stuff coming out in the last few years, I don’t think the ARB is going to start sanctioning such things. At least with 64-bit opaque handles, you can introduce a simple bitshift (perhaps randomized at application startup time) to do some basic obfuscation to the handle. It’s hardly the most secure thing in the world, but it’s something.
Performance relative to D3D isn’t forward thinking.
Forward thinking is for glNext, not OpenGL. And I’d still lay odds that you won’t see GPU memory addresses anywhere in glNext either. Not outside of an NVIDIA-only extension, at any rate.