While I haven’t read all of the newsletter yet, I have some comments on some stuff I encountered.
Under “Buffer Object Improvements” the word “may” is used way too much for my liking - perhaps especially under “Non-serialized access:”.
The word “may” unfortunately have completely different meaning in english vs. legalese. OpenGL is a software contract (which would be legalese-ish), but the words here are english. I’d prefer if a more formal, perhaps RFC-like, language was used for those parts - to keep the language english, but keep the function specifications more formal and unambigous.
If the specification for any function can’t be, well, specific, it should be reworded or pulled. If the intent is clear, and it can be reworded to remove any shadows of any dubts, it should be done - but only after that’s done should it be reconsidered. For now, I consider this part void.
I find the “const” keyword nowehere. Not that I think ARB missed this vital C language construct - I just wanted to point it out, as I’ve seen larger and more widespread libraries mess this up (f.ex. MS for the longest time thought, and still thinks (!), it should have write-access to your in-system-memory indices, if one is to trust their API).
Another thing about buffers. Partial invalidation. For this to be efficient, it’d have to not only be aligned to source platform’s physical page size (or greater - in case of Win32 you map on at least 64KB boundaries, whether or not you have 4KB pages), but also destination platforms alignment requirement. Will LP provide functions, or enums, to query alignment requirements/enforcement?
If one idea is to have (the ability to have) everything in objects, and be able to only hand over object handles to the functions, wouldn’t it make sense to have an array [a 2-dimensional one] with every row holding a number of object handles (including vertex and index handles), and then have a call to “just draw this batch” that eventually could be evaluated all on the GPU?
I’m thinking of something like:
name = CreateArrayName();
AddArrayType(name, VERTEX3);
AddArrayType(name, NORMAL);
…
Create, either in system memory or in a buffer on the GPU, an array of [N][M], handing it off to the GPU, and it can then switch programs/states/textures/<whatever> as efficient as it possibly can - especially if it can run many of these tasks in parallel (and let’s face it, we can’t predict the future, but we can look at history to say parallelism will grow, as currently sequential speeds can’t be strained much more).
Initially I’d expect such a thing to run mostly on CPU, and mostly sequential, but while we’re anyway designing a new API why not think of what may be possible or even norm tomorrow.
The last part was just an idea, but I think it may have use and performance improving impact.