Closed NicolBolas closed 6 years ago
The full sentence from the spec discussing BindBuffer() is:
Buffer objects created by binding a name returned by GenBuffers to any of the valid targets are formally equivalent, but the GL may make different choices about storage location and layout based on the initial binding.
It's surprising to me that using a name generated by GenBuffers may affect the initial buffer object state vs a user-generated name. I can't think of a reason why that is the case. Maybe what it's trying to say that the state of the buffer name generated by GenBuffer might change after calling BindBuffer() on that name.
In any case, I think you're right that the sentence above should be modified and that
At least "back in the day," drivers certainly made allocations decisions based on the initial binding of the buffer. For example, the open-source driver for Intel i915 GPUs would allocate GPUs addressable memory for pixel buffers, but vertex buffers would go in system memory (see https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i915/intel_buffer_objects.c#n115). I know that other drivers would allocate AGP memory (or similar) for pixel buffers and on-card memory for vertex buffers.
I'm not aware that any modern make use of the target parameter in this way. Part of the problem is that a buffer first bound with one target can later be used with another target, so drivers just have to sort it out even if there is a performance hitch when transitioning from one target to another.
The full sentence from the spec discussing BindBuffer() is:
Buffer objects created by binding a name returned by GenBuffers to any of the valid targets are formally equivalent, but the GL may make different choices about storage location and layout based on the initial binding.
The proposed change is to make it:
Buffer objects created by binding a name returned by GenBuffers to any of the valid targets are formally equivalent.
Discussed in the WG meeting. We approve removing that clause from the spec. @oddhack to make the spec change.
The fixes identified by @pdaniell-nv will be in the next GL & ES spec updates, coming soon.
The 4.6 specification says, in Chapter 6.1:
However, according to Issue 2 in ARB_direct_state_access, this is not the case:
It would be best if the GL specification dropped this annotation.