Oh man. I was thinking: "Why would he need to make sure that everything is processed before explicitly syncing with SwapBuffers()?" What I didn't see, although fairly obvious, is that you have to orphan the buffer when it fills up because it could do so in mid-frame and some portions of it may not already be processed when trying to write new stuff. That's why there's syncing (i.e. absence of the UNSYNCHRONIZED bit) when you orphan the whole buffer. Damn...Originally Posted by Dark Photon
However, I have to agree with Alfonse on the async invalidation being a little contradictory. If you absolutely know that a well defined range of the buffer will not be in use when mapping, why the need to invalidate? Why not simply do an async write mapping and overwrite your contents with new stuff that fits into said range? If you can't be sure, you need to synchronize anyway if you don't want to possibly risk corruption.
I think you're going towards scenarios where you don't want to further fill the buffer with new stuff if there's some place where clearly unused data resides - so you want to swap portions instead of risking orphaning if it's not absolutely necessary. But how can you be positive about definitely unused ranges if you don't track if data in a buffer has not actually been used for some time? This implies three possible solutions:
1. go Alfonse's way and can the whole thing, thus syncing by orphaning the complete buffer - this will lead to data that has been in use in previously and will be in use afterwards has to be re-uploaded to the buffer
2. go aqnuep's way and invalidate ranges synchronously, thus avoiding corruption of data still in flight - this may force the application to wait which only makes sense if you've got stuff to do. Just like with occlusion queries.
3. employ an eviction strategy akin to commonly used CPU caching and asynchronously replace unused ranges, orphan only when really needed - this used additional CPU cycles and memory because you have to remember what data wasn't used for how many frames. There could be other schemes, however.
Is that about it?
But only with GL_MAP_UNSYNCHRONIZED_BIT, right? Sorry for being obnoxious - just want to make sure I'm not missing something.Originally Posted by aqnuep