Actually right now i am working on a small editor-application, which renders using immediate mode, since it is so much easier and there isn’t much graphics stuff going on.
I was able to test it on a AMD X2 1.6 GHz laptop, with a Geforce 7300 Go (Windows XP).
I could multithread the main worker loop using OpenMP. It decreased speed drastically, although both cores had maximum workload. After disabling multithreading in my app, i found that speed was much better, but still both cores were fully utilized.
I didn’t find any option in the driver to turn it on/off, as mentioned in this thread somewhere, but i guess the gfx driver already uses it’s own thread.
The driver is a few months old, so i assume it is one of the first versions doing that. I also got the impression that it is quite inefficient, since it used the whole processing power of one core, even though the graphics was very simple (a few hundred textured billboards, no shaders, no nothing). Although that’s only my impression, could be wrong entirely.
Originally posted by gdewan: Where is this set? I have a 8800 GTX here on a dual core WinXP machine and I can’t find the setting anywhere.
It’s in the NVidia control panel. It’s called “Threaded optimization”. I think you have to enable the advanced view to see it.
Originally posted by andras: [quote]Originally posted by gdewan: Where is this set? I have a 8800 GTX here on a dual core WinXP machine and I can’t find the setting anywhere.
It’s in the NVidia control panel. It’s called “Threaded optimization”. I think you have to enable the advanced view to see it. [/QUOTE]Its not in 97.44 anywhere. And standard view is disbled so I can’t take it out of advanced view.
Well, I’ll check at work, because this is a Quadro FX 1500M. The 97.44 driver set on the 8800GTXs is very buggy, however. I would drop back to 97.02. I saw a ~200 FPS app drop to 50FPS when I upgraded. Some forum is claiming that the 97.44s severely underclock the memory, and although I can’t verify that specific claim, my benchmarks show something is amiss.
I understand the case of Program A and B.
In the case of program B, if the driver does state control, then it will benifit.
So a separate thread that handles all that work will help. I think drivers don’t do state checks.
In case of C, it’s not clear what is going on.
What is happening in the driver that makes it use 20%-50%?
Can the programmed be fixed?
The IHVs should give advice to whoever is making WoW because 80% increase is insanely high.
If it’s 5%, okay.
What is the driver doing? Culling?
Originally posted by Rob Barris:
[b]
Now, consider Program C: say its work balance can vary drastically depending on what is going on - it might be 80% app and 20% driver, or in some really rough situations it might be 50% app and 50% driver. Scene dependent.
Program C’s benefit from MT-GL will therefore also vary between 20 and 50% reduction in clock time assuming the application thread avoids making any calls that result in synchronization between the app side and the driver side (queries, readbacks, a few other cases).
Thus the “up to 2X faster”… in some weird cases maybe even a little better than 2X when you have less cache contention going on between app-land and driver-land. “2X faster than what?” -> in comparison with the same scene rendered with MT-GL off.
I haven’t seen any claim from Apple saying that this technique is novel or unique to OS X.
If you have WoW on OS X (Intel Mac dual core) you can flip the MT stuff on and off in-game:
/console glfaster X
where X = 0, 1, or 2
0 = off
1 = MT on but with a bit of frame throttling
2 = MT on, no throttling, some mouse lag can occur. [/b]