Yeah, I realised this later on. I'm pretty new to vertex programs, handn't used them on something which doesn't support them in HW.
How do people deal with this? AFAIK there is no convenient way of determining whether vertex programs are supported in HW.
As far as I remember VBO's automatically take care of mem selection, if you have GF2 or TNT +vp data is kept off-card. I guess that's not the case with VAR.
AdrianD and Madoc, Madman is correct, but there was a bug in previous drivers that had that problem, but now i think thats fixed and works like it should.
Well, this was using the very latest drivers (45.23, is it? just downloaded from NVIDIA anyway) and the performance was absolutely atrocious, same with NVVP 1.0.
Not resolved for a GF4 440 Go? Haven't had a chance to test it since.
Seems unlikely that such bad performance could simply come from software VP though.
I guess there really isn't an intelligent way to tell whether VPs are running in hw then?
These VPs and FPs really are a pain in the arse. Still not time to make a move to them?
yep. if you want to include vp/fp support in your app, you have to write at least 2 codepaths: one with vp/fp support, and another for standard opengl, just because there only a few users out there with true vp/fp support in hardware. so solution my for this problem is just to check for the presence of vp/fp's and let the user choose his preference.Originally posted by Madoc:
I guess there really isn't an intelligent way to tell whether VPs are running in hw then?
These VPs and FPs really are a pain in the arse. Still not time to make a move to them?
As with most ( or all ) opengl things you should test it for speed before you use it ( itf youre making a serious application anyway) since there is nothing that tells you whatever anything is in hw or sw, or if the sw path is as fast as you need.
I used to do that, benchmark things on startup. It's just not what I consider convenient. Eventually I ended up simplifying it all by reducing to software paths and making assumptions because it was so annoying and I was working for dedicated systems a lot.
Another alternative is to have a little indipendant benchmarking prog that configures an ini file but it would need to run every time the hardware / software config changes and who's going to do that?
Anyway, thanks for your help everyone.
My preliminary conclusion is as follows:
Include a "try vertex shaders" switch in the user interface. This will initially set an internal use_vs flag and an internal vs_are_fast_enough flag. Also set a monitor_vs_fps flag to true.
Monitor frame rates (needed for animation work anyway).
if (monitor_vs_fps&&use_vs)
{
If fps are consistently horrible (<20) over the first fifteen frames rendered && try_vs==true, record an average and deactivate vertex shader usage (fps_with_vs=avg; use_vs=false).
}
if (monitor_vs_fps&& !use_vs)
{
Monitor the next fifteen frames. If the average fps is more than double fps_with_vs, vs_are_fast_enough=false.
If there's no tangible difference, you can also turn vs back on.
monitor_vs_fps=false
}
When the user later checks back with the config settings, display the use_vs flag as the current setting and restart the procedure if vs get turned on.
The problem with that scheme is that you need to be able to switch between vs and fixed function on the fly. That may be a bit tricky, but it can be done.
You also need a good test case that doesn't produce wild fps fluctuations over the monitored frames. And it shouldn't be too simple (such as a GUI), it should be a 'real' scene with representative vertex load.
Ho humm ...
Posting Permissions
