KhronosGroup / OpenGL-API

OpenGL and OpenGL ES API Issue Tracker
34 stars 5 forks source link

OpenGL 4.6: Buffer object first binding #23

Closed NicolBolas closed 6 years ago

NicolBolas commented 6 years ago

The 4.6 specification says, in Chapter 6.1:

the GL may make different choices about storage location and layout based on the initial binding

However, according to Issue 2 in ARB_direct_state_access, this is not the case:

NamedBufferData (and the corresponding function from the original EXT) do not include the <target> parameter. Does implementations may make initial assumptions about the usage of a data store based on this parameter. Where did it go? Should we bring it back?

RESOLVED: No need for a target parameter for buffer. Implemetations[sic] don't make usage assumption based on the <target> parameter. Only one vendor extension do so AMD_pinned_memory. A[sic] for consistent approach to specify a buffer usage would be to add a new flag for that <flags> parameter of BufferStorage.

It would be best if the GL specification dropped this annotation.

pdaniell-nv commented 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 shouldn't affect the initial buffer object state.

ianromanick commented 6 years ago

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.

pdaniell-nv commented 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.

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.

pdaniell-nv commented 6 years ago

Discussed in the WG meeting. We approve removing that clause from the spec. @oddhack to make the spec change.

oddhack commented 6 years ago

The fixes identified by @pdaniell-nv will be in the next GL & ES spec updates, coming soon.