OpenGL drivers create subbatches anyway. Every time you change state and issue the next draw command, you get a new batch. State machines can do that.
State sorting is a common suggested technique so why not supporting it in the API?
State sorting is effective, because it reduces redundant state changes.
Ie
1)bind Texture A, render
2)bind Texture A again, render
3)bind Texture B, render
4)bind Texture A again, render
1=>2 would be just stupid. If you can’t be bothered to write something like
if (current_texture!=desired_texture) ...
, you deserve punishment.
2=>3 is a good reason for a new batch, okay.
2=>3=>4 is bad luck. I assume this is what you’re trying to get rid of here.
To do this properly, you need to
a)“hold back” a batch for some time, to be able to check it against later batches and merge them.
b)compare state vectors. If they are equal, corresponding batches can be merged. If there are only small differences between two state vectors, the corresponding batches can be moved closer to each other (hello, Mr travelling salesman).
a constitutes added latency, lots of bandwidth, and the memory footprint.
b is a much bigger problem for an OpenGL driver than it is for a scenegraph. GL state is a lot of stuff. Scenegraph state isn’t.
A scenegraph also has its geometry data hanging around in memory already (it submits it to the GL, after all). Why make extra copies?
It can be done, sure, and it can be made consistent. But it can never be as efficient as a well implemented home-grown solution that doesn’t need to handle everything.
Let me get on my little soapbox here.
glDrawRangeElements was an extension and became core. IMO it’s a good addition. Why? Because it can do things that can’t be layered on top of GL. Range couldn’t be specified on the old glDrawElements interface, so the only purpose of the extension (potential for more efficiency) would have been lost in a layered approach.
Can your suggestion be layered on top of GL? Yes, it can be. I don’t see any problems with that.