Most other things I can live with or work around but if debugging is a pain then I tend to get very stabby about life in general. While not perfect VS seems to get this right (mostly anyway, Android guys were complaining yesterday about having to look at memory as the watch window wasn't sane, but that's just Android dev all over it seems).
* Disabling depth testing means that the depth buffer doesn't have to be read/written, which slightly reduces your bandwidth per-pixel (save a 24bit read+write per pixel). * Disabling depth writing means that the depth buffer doesn't have to be written, which (even more) slightly reduces your bandwidth per-pixel (save a 24bit write per pixel).
I'm pretty certain that on anything released in the last few years this would be a 32bit read/write; certainly on GCN as depth and stencil are stored seperately so a D24_S8 format takes up the same memory as a D32_S8 one where depth and stencil are stored as seperate chunks of memory.
(Which doesn't dispute your points, just highlights the extra savings).
Which makes me wonder what Valve were doing to come to their conclusion, or maybe NV's Linux drivers just suck more than the Windows ones in this respect (NV benchmark pretty poorly in the above link too compared to AMD)
Upon slightly more careful reading of the Red Book it seems this is the case... well played GL, well played.
I guess this will make sense once the ARB_multi_bind extension is common as you can use VAOs for VB attributes (types, stride etc) and use multi-bind to replace all the buffer bindings in one shot... either based on the performance and usage case issues I'd pretty much only use it for that right now; bind the attributes to a VAO (probably drag it around with my materials/shaders) and just over write the buffer bindings as required.
So, what if there was a compromise such that: -Scene is still passed around as a parameter where it does not feel like mindless repetition of a fact the code should understand (im basically looking for a statement like "using Scene" here) -It is still obvious where scene might be passed. If its a global, we have no control over where scene can be accessed. -It does not limit the amount of scenes to 1.
The 'code' doesn't understand anything; the whole point of parameters is to express to the person writing/reading/maintaining the code the dependencies and requirements of that function. This 'using' construct does not make it obvious where it is used any more than a global does; lets say in your example you have a function which is called which DOESN'T require the scene parameter, in conventional code this is clear by the lack of parameter passing, with the 'using' system this is unclear as to what is going on.
This whole thing smells of your (terrible) 'contexts' idea from a few months back and is no better.
Do you really think that EA would be investing development resources towards developing a Mantle version of their flagship engine if the whole thing was just a smoke screen put up by AMD?
Given the description of the API, the one line of code from repi's presentation, and block diagram of it's layout it should be obvious to anyone that this is going to be faster than existing APIs. Which is fine as it requires you to write more code than existing APIs, like the consoles, to manage things the driver previously guessed at for you, so that is your trade off.
Also, from the recent AMD conference, there was another demo of a game which apprently pushed 100k draw calls per frame (probably a 33.3ms frame but still..), something which no existing API is going to come close to.