Suggestions for OpenGL 5

[Janika]

Ultimately, the best course of action is to just live with it.

I disagree. That's why the suggestions forum exist.

OpenGL is imperfect, and trying to make it perfect is only going to make the imperfections worse.

I don't buy it that openGL is imperfect. I would say it's less perfect for games maybe...and by suggesting more we can make it less "imperfect."

Oh, and let's not forget a simple, practical fact: your proposal is nothing the ARB hasn't heard dozens of times before. Go ahead; search this forum. It's been suggested over and over since GLSL was adopted. It hasn't happened in almost 10 years. The arguments for it haven't changed a bit.

Again?

And yet, it still hasn't been done. It took almost a decade to get separate shaders and program binaries, and those are also things people asked for even before GL 2.0. So I wouldn't hold my breath.

Again?

[thokra]

I disagree. That's why the suggestions forum exist.

But the sad fact is that there is no open discourse between ARB members (or corresponding spokespersons) and the community. If they pay attention at all, they sure don't care to comment on anything.

[Janika]

If they pay attention at all, they sure don't care to comment on anything.

If this is the case, then what do they care for? Then they probably know things from technical side better than the community in general so they don't bother...

[mhagain]

One I'd like to see is "multi buffers" - analogous to glActiveTexture but for buffer objects. A real shortcoming in the current spec is that there's only one binding point available for each buffer object type (which also makes the old bind-to-modify chestnut even worse). VAOs help some but only for drawing; updating buffers or using buffer types other than ARRAY or ELEMENT_ARRAY aren't served as well. VAOs also complicate the task of updating buffers separately from your drawing code a little more than they should. If it could be implemented in a more lightweight manner than glBindBuffer, and if interaction with other functionality could be worked out sensibly, it would seem useful.

[Alfonse Reinheart]

Why? Why would you ever need that?

glActiveTexture serves a purpose: to allow multitexturing to work.

Also, there is no such thing as a "buffer object type"; there are simply buffer object binding points. Any buffer object can be bound to any bind point, and unlike textures, they do not magically take on a certain type the first time you bind them. You can use the same buffer object for vertex data, transform feedback, uniform blocks, pixel transfers, and buffer textures.

So besides permitting lazy use of the API (passing a parameter to other functions through a global), why would you ever need to do this? Just bind stuff to change it and unbind it when you're done changing it. When it's render time, bind whatever you need to render at that time.

[thokra]

Besides, what would you gain in terms of easing updating a buffer with a mechanism like active textures? You'd still have a hypothetical glActiveBuffer call to swich between binding points to not mess up the currently bound buffer. And you already pointed out the caveat with this:

If it could be implemented in a more lightweight manner than glBindBuffer[..]

I doubt that glBindBuffer is significantly more heavy than a glActiveBuffer call could be. All the state that is set when binding a buffer to a target now, would be no different when changing the active buffer. The difference with glBindBuffer is the additional argument denoting the buffer object handle and I doubt that transferring that argument is too much trouble. Effectively you don't save any calls - only a possibly insignificant amount of time - at the cost of introducing yet another API.

[aqnuep]

Actually, there are even a lot of binding points that don't really bind the buffer to any resource, just for modification.
Think about the TRANSFORM_FEEDBACK_BUFFER, UNIFORM_BUFFER and TEXTURE_BUFFER binding points. If you call glBindBuffer with any of these binding points, you don't actually change any rendering state (the former two change rendering state only with glBindBufferBase/Range and the later doesn't change rendering state at all). Thus that means you can use them for whatever bind-to-modify purpose you want, without having an effect on rendering. So I agree with Alfonse, there is barely any use for your proposal.

Also, as thokra said, glBindBuffer isn't necessary a heavy operation, especially if you don't bind a buffer for actual use (like in case of ELEMENT_ARRAY_BUFFER).

[Eosie]

One I'd like to see is "multi buffers" - analogous to glActiveTexture but for buffer objects. A real shortcoming in the current spec is that there's only one binding point available for each buffer object type (which also makes the old bind-to-modify chestnut even worse). VAOs help some but only for drawing; updating buffers or using buffer types other than ARRAY or ELEMENT_ARRAY aren't served as well. VAOs also complicate the task of updating buffers separately from your drawing code a little more than they should. If it could be implemented in a more lightweight manner than glBindBuffer, and if interaction with other functionality could be worked out sensibly, it would seem useful.

There isn't only one binding point per type. Uniform buffers and transform feedback buffers have multiple binding points. See the <index> parameter in these functions:

void BindBufferBase(enum target, uint index, uint buffer);
void BindBufferOffset(enum target, uint index, uint buffer, intptr offset);
void BindBufferRange(enum target, uint index, uint buffer, intptr offset, sizeiptr size);

[thokra]

Uniform buffers and transform feedback buffers have multiple binding points.

The thing is question is buffer modification - or more generally quick access to the data store to already bound buffers. Binding a UBO or TFBO to an index has nothing to do with modifying the contents of the buffer. glBufferData() and glBufferSubData() only operate on the buffer binding target - not the indexed binding point.

[Alfonse Reinheart]

BindBufferOffset

There is no glBindBufferOffset.

The thing is question is buffer modification - or more generally quick access to the data store to already bound buffers. Binding a UBO or TFBO to an index has nothing to do with modifying the contents of the buffer. glBufferData() and glBufferSubData() only operate on the buffer binding target - not the indexed binding point.

That doesn't change the fact that you generally don't modify buffer objects in the same code you use to *render*. And if you do, it would generally be through mapping the buffer and uploading data.

My point is that the only time this becomes a burden is if you need something bound to the context for rendering, and at the same time, you need to change a buffer. When have you ever needed to do that? Usually, it's "do setup work to render, including buffer modifications", followed by "draw stuff." Your code generally isn't structured as "draw stuff, oh wait, I need to upload some data, then draw more stuff."