While you are right that SM4 features were really well covered by nVidia at the launch of their G80 chips, i would like to point out that even today ATI does only expose a fraction of those features in OpenGL.
Putting all the SM5 stuff into one big extension might force ATI to support it completely. But maybe before one takes the next step, it would be better to finish the current step. Put the current SM4 stuff into core, maybe even try it with that über-extension idea. Just make sure, that we get sensible SM4 support on ALL hardware, before you concern yourselves with SM5.
To be honest, i can’t give you a top-5 list, since all that i heard about SM5 sounded useless / not important to me. I am not even using all the SM4 stuff, some of it is just too specific for certain problems (which i don’t have right now). SM5 while nice to have, of course, is not of much interest for me, at all.
NV_gpu_program_4 has something similar as it implies availability of NV_{vertex,fragment,geometry}_program4.
Having different parts of SM5 functionality as different specs would be good, both for understanding and partial implementations. And then, a GL_ARB_gpu_feature_lebel_5 would be the catch all extension.
That sounds very good to me. I really like the idea of the “extension package”.
I don’t really have a top 5, per se. My thinking has generally been along the lines of: if I have a SM5 abstraction and I want to implement it with OpenGL, I’d like as few hurdles as possible. To wit, as long as OpenGL exposes all the current hardware features with reliable drivers across the board, I’m in want of nothing.
when thinking about DX11/SM5 what first comes to my mind are not hardware features but API features. i think the current feature level is quite high. from the top of my head the features i seek would look like this:
‘usable’ constant/uniform buffers
state objects
other than that i think much of the DX11/SM5 features could easily be a GPU_shader_5 style as with SM4 features.
One cool feature I would expect is D3D10.1 gather4 … even if it’s not a SM5 feature…
[1]: Command list things. We definetly need an API that’s suite more in multiple cpu core environment.
[2]: Gather4
[3]: tesselator but honestly I’m not sure I will even used it for something serious. More interesting that geometry shaders, it seams a bit to much involving production pipeline changes. I don’t really know how tools are really for displacement mapping and even if the Froblin AMD demo is just amazing, it have some issues to. There are some popping, the resolution is so huge that it doesn’t looking like popping, it looks like flickering. Unfortenatly it’s not really nicer.
And they took so long to do this … I saw the first result of this demo during a Siggraph presentation in 2007 … However, if I saw somekind of CLOD rendering using the tesselator, I could change my mind, it could erase this flickering issue.
I’m seeing some feature requests popping up here, if I could humbly request that you flesh them out and post in the “talk about your apps” thread, that would help us focus the discussion.
Chris Lux, in particular your request for ‘usable’ constant/uniform buffers, if you could elaborate a bit on specific functionalities over in the apps thread, that would be a great place to capture it.
(Just to be clear, we’re not operating in an info vacuum, for example we have StarCraft II running in OpenGL on OS X, and there’s a noticeable difference in efficiency between the ARB-VP parameter setup path and the glUniform API path for GLSL shaders, and this has provided a lot of pressure to develop an alternative API for GLSL uniform setup)