Create an API function group to test speed of each hardware accelerated function aboard GPU.
This would allow for the number of time sliced effects that could be enabled for a given frame rate to be toggled on or off, either by the program or by the end user in application setup/change options.
Would this help in creation of more GPU intensive or variety of effects to be turned on off by the user or utilise older/slower GPU’s?
It sounds like you’re describing not an API, but a library. If it were an API, and the details were implimentation dependent, then the results would be inconsistent across different implementations (not to mention untrustworthy). An open source library would probably be the way to go for something like this, so there could be oversight of the code. But even still, benchmarks are somewhat subjective in their design–remember the whole nVidia/Futuremark thing. In any case, I don’t see why this has to be incorporated into OpenGL itself.
“It sounds like you’re describing not an API, but a library. If it were an API, and the details were implimentation dependent, then the results would be inconsistent across different implementations (not to mention untrustworthy).”
The objective is to create way the application user could set a minimum frame rate, so as the effect starts to drag down below the frame threshold Hz rate, effects would be blocked like a thread.
“An open source library would probably be the way to go for something like this, so there could be oversight of the code. But even still, benchmarks are somewhat subjective in their design–remember the whole nVidia/Futuremark thing. In any case, I don’t see why this has to be incorporated into OpenGL itself.”
Benchmarks were not the intended thought behind this, but a way of selecting effects from a list tickbox/slider? so as more GPU power arrives (new GPU’s) more effects could run in parrallel. I read one of the id programmer’s wanted to implement functions in a certain way but was concerned that GPU speed was not upto it, by selection of effects this would allow for a wider range to start appearing while GPU catches up - a stop gap solution. While providing the user with more choice.
Originally posted by GetWithIt:
The objective is to create way the application user could set a minimum frame rate, so as the effect starts to drag down below the frame threshold Hz rate, effects would be blocked like a thread.
Applications can do that alone. It’s trivial to measure fps and compare it to a given threshold.
Your proposed feature doesn’t address how details would be reduced, and I think it’s not a good idea to ask for this. Your application is ultimately the only authority that can decide which “effects” are vital and which “effects” can safely be reduced.
Many renderers implement LOD schemes of some sort. Here are some of the things an application can do:
a)Reduce model complexity (geometry load)
b)Reduce shader complexity (mostly fillrate)
c)Reduce particle density (geometry, fillrate, bandwidth load)
d)Reduce maximum texture quality (bandwidth - see http://oss.sgi.com/projects/ogl-sample/registry/SGIS/texture_lod.txt )
e)Reduce decoration density (decals, grass, clouds, etc - geometry, fillrate, bandwidth)
f)Reduce animation quality (full skeletal vs keyframes - geometry/bandwidth load)
Perhaps feedback mode could be extended to provide elapsed time. Add an GL_TIME to the second argument enumeration.
glFeedbackBuffer(bufsize, GL_TIME, buffer);
GL_TIME could perhaps return two floats, elasped seconds, elapsed fraction. Since all feedback returns are floats.