nVidia developing multithreaded drivers

J

jebo_4jc

[H]ard|DCer of the Month - April 2011
Joined
Apr 8, 2005
Messages
14,567
http://techreport.com/onearticle.x/8459

Wow this kind of came out of nowhere, for me at least. I think this is quite significant. So if I understand correctly, in a nutshell, the driver will basically work around XP's crappiness in order to offload some of the 3d work onto the separate CPU core. It brings a lot of questions to my mind. Such as:
1. Will HT Pentium's benefit?
2. If so, why haven't we seen this sooner? Hasn't there been enough HT-capable CPU's and 2P systems out there to warrant bringing somthing out like this?
3. ATi's answer?
 
jebo_4jc said:
the driver will basically work around XP's crappiness

in order to offload some of the 3d work onto the separate CPU core.
Click to expand...
I know that was a bash at WinXP, but I doubt you'll see multi-threaded video drivers on any other desktop OS anytime soon. That should answer your #2 question.

The article linked says that nvidia already does load balancing for vertex processing in current drivers. There should be a benefit by moving it to another thread, definitely on another core, but iffy with HT unless the CPU isn't already under 100% load.

Depending on how tricky is it to write a multi-threaded video driver, ATI may not have an "answer" for quite a while. Wait until the release 80 driver to come out to see if it's even worthwhile. The 5-30% speedups mentioned by De Waal may not be from just multi-threading (most likely, multi-threading speed gains will be small).
 
hmm, seems like HT was included in the discussion. I could sure go for a 30% performance increase :)
 
pxc said:
I know that was a bash at WinXP, but I doubt you'll see multi-threaded video drivers on any other desktop OS anytime soon. That should answer your #2 question.

The article linked says that nvidia already does load balancing for vertex processing in current drivers. There should be a benefit by moving it to another thread, definitely on another core, but iffy with HT unless the CPU isn't already under 100% load.

Depending on how tricky is it to write a multi-threaded video driver, ATI may not have an "answer" for quite a while. Wait until the release 80 driver to come out to see if it's even worthwhile. The 5-30% speedups mentioned by De Waal may not be from just multi-threading (most likely, multi-threading speed gains will be small).
Click to expand...
QFT and QFT
But how does that answer #2?

I've only looked at my CPU utilization once while gaming, which was when I was playing LOTR:BFME. I was trying to see how folding would impact my gaming, and I decided that, since BFME was only utilizing ~70% of my CPU, I could run one instance of F@H at the same time. I would think that a modern RTS would be towards the top of the scale in terms of CPU utilization, so I'm thinking there is some potential there. But you are exactly right, I don't think the article said we would get 30% from multithreading, but he did say improvements with the driver in general (and who knows, this may be only when using 7800).

Also, I'm no XP basher. I've used it exclusively on my PC's since it came out. But it was new info to me when he said that API calls have to be run on the same thread as the actual app.
 
How I see it is that the current multithreaded drivers will not bring raw performance boosts, but it will bring efficiency to the drivers. Efficiency on its own can increase performance (which tends to be small but smooths out fps flux more).

One thing I would like to see is that if my game crashes the video on one core, the drivers would automatically detect this and use the other core to process video while the OS does the same thing and terminates the program. Basically if a program dies, it gets offloaded onto the other core to be terminated instead of spreading across multiple cores which causes all of them to stall. This goes for intel's HT. Atm when one of my multithreaded program crashes, the whole system crashes. Maybe it is suppose to automatically do this, but it doesn't seem like it is working for me.
 
qkool said:
How I see it is that the current multithreaded drivers will not bring raw performance boosts, but it will bring efficiency to the drivers. Efficiency on its own can increase performance (which tends to be small but smooths out fps flux more).

One thing I would like to see is that if my game crashes the video on one core, the drivers would automatically detect this and use the other core to process video while the OS does the same thing and terminates the program. Basically if a program dies, it gets offloaded onto the other core to be terminated instead of spreading across multiple cores which causes all of them to stall. This goes for intel's HT. Atm when one of my multithreaded program crashes, the whole system crashes. Maybe it is suppose to automatically do this, but it doesn't seem like it is working for me.
Click to expand...

It actually works great for me. Whenever a program stalls (and it's the only one using 100% of a logical processor) I can terminate it much easier and faster then on a non-ht single core machine.
 
I doubt we will see the true benefits of multithreaded drivers until longhorn comes out .. as for right now i bet this is more of a testing/proving ground for these drivers than anything real world in impact.
 
Godmachine said:
I doubt we will see the true benefits of multithreaded drivers until longhorn comes out .. as for right now i bet this is more of a testing/proving ground for these drivers than anything real world in impact.
Click to expand...

lol
 
Godmachine said:
I doubt we will see the true benefits of multithreaded drivers until longhorn comes out .. as for right now i bet this is more of a testing/proving ground for these drivers than anything real world in impact.
Click to expand...

I don't understand how longhorn will help in this respect. Also, why wouldn't the drivers give you a real world impact under XP, but they would under longhorn? :confused:
 
Talonz said:
I don't understand how longhorn will help in this respect. Also, why wouldn't the drivers give you a real world impact under XP, but they would under longhorn? :confused:
Click to expand...


Maybe because Longhorns 2D interface (if you wanted to call it that) is supposed to be D3D accelerated.

As for second CPU's carrying on the system if a process (game) locks up in one, I dont think it will help. Not as much as simply having two monitors...if a game locks in one screen, you can usually alt-tab out and end the task from the other screen without total reboot and possible data corruption (the only tricky part to this is to move the task manager over to the second display with the keys alone). It's saved me numerous times.
 
I see it as tipping the scale, you know blind justice and all...loading one side and then the next. There are two there; not physically but the balance can be equalized - I haven't *seen* an application take advantage yet. I can't see why drivers haven't been written already to take advantage of the odd cycle of a processor, virtual or not.
 
gah, and I just bought an x850xt for this xeon system, I guess I can wait for ati's multithreaded drivers... loler.
 
It can't really make any odds to a HT processor as it is spliting a task that needs the same part of the processor, if anything it'll slow it'll down with time spent spliting then reforming the task... still maybe wrong :rolleyes:
 
I haven't seen this mentioned anywhere so I'll just say it.

Could it be possible that the next version of Direct X could have some built in multithreaded support (like putting directsound on the second core)? Microsoft had to have worked on that for the Xbox 360 so couldn't they bring it to the PC as well? If multi core CPUs are really the future, then it makes sense for DirectX to simplify some of the performance gains. This makes more sense to be included in Longhorn though.

Just some massive speculation on my part. :cool:
 
It is already possible to run sound processing in a second thread. In fact, this is a very natural way to do things and has no doubt been in use by many games for a long time. I did game development work 4-5 years ago that was architected in exactly this manner.

The difficulty in making a video driver multithreaded is in managing the threads. Usually they just piggyback on the thread from the application that tells them what to do. Now they'll have to manage the thread(s) in each process that they are being invoked from. Luckily Windows has a lot of provisions for simplifying this type of development, with a built-in thread pool (which lets you re-use threads for short-lived tasks, so you don't have to recreate threads all the time and incur the overhead of doing so).

The comment of "working around XP's crappyness" is completely without justification -- Windows is actually very well engineered and fast, at the kernel level. Once you get to the user level (the UI, the shell, etc) things are much more open for opinion, but the kernel is rock solid.

The real problem comes when you start making everything multithreaded to balance load. So if the game starts divying up work to 2-3 threads, and the video driver is using 2 threads, and then maybe those threads create more "sub" threads to do their work ... And then all the other apps in the system are doing the same and overall system resource usage goes way up (each thread uses memory just by existing, and requires CPU time to be managed!). Anyway it's very interesting stuff, and so it's a good time to be a dev who is concerned with and responsible for performance (like me) :)
 
ch0s3npimp said:
you think these would wrok for older Nvidia GFX cards such as the 5700? and up?
Click to expand...
I don't see why they couldn't. It's not something that would need to be tied to any specific GPU architecture unless NVIDIA decides to do so for marketing purposes ("GeForce6/7 + Athlon X2 = more faster!") or for validation/testing purposes (why bother testing and enabling the technology with lower-end GPU's that are usually paired with lower-end, single core CPU's anyway?).
 
You must log in or register to reply here.
Back
Top