Multi-threaded Drivers

[mikeblas]

This thread mentions multi-threaded video drivers in a few different posts.

What, exactly, could be made multi-threaded in a video driver? I would expect the driver to accept a directive from the presentation layer of the OS, then do whatever hardware-specific commands are required to get the request satisfied.

Isn't the hard work already on a different execution context -- and a different processor altogether! -- in the GPU on the video card?

What would be the point of having extra threads owned by the device driver itself? Would the application then be enabled to make asynchronous requests of the card? What computationally-intensive work is owned by the device driver?

 

[pArTy]

This thread mentions multi-threaded video drivers in a few different posts.

What, exactly, could be made multi-threaded in a video driver? I would expect the driver to accept a directive from the presentation layer of the OS, then do whatever hardware-specific commands are required to get the request satisfied.

Isn't the hard work already on a different execution context -- and a different processor altogether! -- in the GPU on the video card?

What would be the point of having extra threads owned by the device driver itself? Would the application then be enabled to make asynchronous requests of the card? What computationally-intensive work is owned by the device driver?

For furture duel core GPUs? Lol

 

[trinibwoy]

Well since Nvidia seems to be focusing on SLI for their dual-core enhancements I'm guessing the second core will start generating data for the next frame to GPU2 while the first core is calculating/transmitting the current frame to GPU1. There is also some load-balancing overhead that might be shunted off into it's own thread if possible.

 

[kcthebrewer]

As you have probably seen, SLI is sometimes incredibly CPU bottlenecked as performance actually decreases with it compared to a single GPU. From what I understand, the driver will offload the SLI processing onto the non-used core to allow more overall performance with no (very little) SLI CPU impact.

 

[mikeblas]

As you have probably seen, SLI is sometimes incredibly CPU bottlenecked as performance actually decreases with it compared to a single GPU.

Why? And under what conditions or workloads does SLI become CPU-bottlenecked?

 

[kcthebrewer]

Why? And under what conditions or workloads does SLI become CPU-bottlenecked?

You should read the [H] 7800 SLI review.

 

[mikeblas]

You should read the [H] 7800 SLI review.

This one?

It cracked me up because there's a by-line for the "Grammatical & Spelling Editor". Wouldn't any editor worth his salt know to write "Grammar and Spelling Editor"?

Anyway, I don't see any mention of SLI causing the machine to become CPU-bottlnecked. The review does talk about CPU performance, but this to me means that the game has gone from graphics-bound to CPU-bound.

Say you have a program that reads and writes lots of files. The stuff it does to the files is pretty complicated, but your disks are so slow that it still spends most of its time waiting around for the drives and I/O. You go out and buy a really fast, mega-zooty disk subsystem. Now, the disks are faster; you're able to read and write faster. In fact, now the rate of data arriving or leaving memory is higher than the rate that your CPU can process the data.

The same thing appears to be happening with these games and the SLI card under test. If there is something happening, the article doesn't give any details about it -- and I'm all about the details.

I'm still left with my original question: why would a display driver benefit from owning multiple threads?

 

[J-Mag]

This one?

It cracked me up because there's a by-line for the "Grammatical & Spelling Editor". Wouldn't any editor worth his salt know to write "Grammar and Spelling Editor"?

ROFL

Anyway, I don't see any mention of SLI causing the machine to become CPU-bottlnecked. The review does talk about CPU performance, but this to me means that the game has gone from graphics-bound to CPU-bound.

I'm still left with my original question: why would a display driver benefit from owning multiple threads?

You are correct there is no CPU bottleneck, people are inferring this from dayys gone by where current gen games kept getting speed increases from higher CPU speeds. This is no longer the case with Modern Games because they are ALL GPU bound.

ANY 939 proc is up to the task of any game currently out there. Here is one of my fav links:

http://www.firingsquad.com/hardware/athlon_64_geforce_7800_gtx_scaling/page14.asp

OK yes you are right that this doesn't show 7800GTX in SLI, but it does show the differences between a huge DELTA of GPU power, from 6800 to 7800 series.

Overhead from SLI is insignificant.

 

[kcthebrewer]

I believe both WoW and EQ2 both show decreases in performance with SLI. I am pretty sure Kyle talks about it as well. Perhaps you should actually read the article instead of looking at the pretty pictures.

If the CPU processing that SLI requires is offloaded onto the unused core, then it opens up that processing power (that a single core would be processing the SLI) for the game.

Lets name the single core 1.
1 processes the game and SLI.
This causes lower fps on CPU-bound games.

Lets name each core of a dual processor processor 1 and 2.
1 processes the game.
2 processes SLI.
This doesn't make CPU-bound games perform any worse, it should be the same as non-SLI, but you should be able to increase the quality settings.

I don't know if this is clear or not, but I hope you understand.

 

[Shifra]

has nothing to do with SLI. Nvidia is trying to make a driver where some of the video cards driver functions can be offloaded onto a second un-used CPU in a dual core solution, IE X2/Pentium D. They expect the gains to be 5-30%, but they also warn that companies programming games to be multi-threaded are going to make this advantage useless. Its for dual CPU solution benefits, not dual card.

 

[mikeblas]

has nothing to do with SLI. Nvidia is trying to make a driver where some of the video cards driver functions can be offloaded onto a second un-used CPU in a dual core solution, IE X2/Pentium D. They expect the gains to be 5-30%, but they also warn that companies programming games to be multi-threaded are going to make this advantage useless. Its for dual CPU solution benefits, not dual card.

Why wouldn't this happen with normal scheduling? If a second processor is available, then wouldn't the thread issuing the request run on that other CPU? (Or, similarly, run on the same CPU while the other CPU handled the game's work?)

Or is the point to make calls into the driver non-blocking so the presumably single-threaded game implementation could continue with its work? If so, how can that be implemeneted without changing the driver model?

 

[J-Mag]

I believe both WoW and EQ2 both show decreases in performance with SLI. I am pretty sure Kyle talks about it as well. Perhaps you should actually read the article instead of looking at the pretty pictures.

Do you have SLI? Do you play those games?

Perhaps you should read NEWER articles before finger painting time.

http://anandtech.com/video/showdoc.aspx?i=2451&p=11

 

[mikeblas]

I believe both WoW and EQ2 both show decreases in performance with SLI. I am pretty sure Kyle talks about it as well. Perhaps you should actually read the article instead of looking at the pretty pictures.

Nope. Here's a link, and a quote:

Just as we saw in EverQuest II, there were no major differences in performance with SLI [in World of Warcraft].

Why are you being condescening and pretentious? Did your hamster die, or something?

If the CPU processing that SLI requires is offloaded onto the unused core,

What additional processing does SLI require of the host CPU beyond what a single video card would require?

 

[Shifra]

Why wouldn't this happen with normal scheduling? If a second processor is available, then wouldn't the thread issuing the request run on that other CPU? (Or, similarly, run on the same CPU while the other CPU handled the game's work?)

Or is the point to make calls into the driver non-blocking so the presumably single-threaded game implementation could continue with its work? If so, how can that be implemeneted without changing the driver model?

dont ask me, just what they're doin, most people in here for some reason think its an SLI thing, its not.

I spoke recently with Ben de Waal, NVIDIA's Vice President of GPU software, and he revealed that NVIDIA has plans to produce multithreaded ForceWare graphics drivers for its GeForce graphics products. Multithreading in the video driver should allow performance increases when running 3D games and applications on dual-core CPUs and multiprocessor PCs. De Waal estimated that dual-core processors could see performance boosts somewhere between 5% to 30% with these drivers.

Most imminent on the horizon right now is ForceWare release 75, which will bring a number of improvements for SLI performance and 64-bit Windows, among other things, but release 75 will not be multithreaded. The next major iteration of the driver, release 80, is slated to bring support for multiple threads. We may not see this version for a few months; NVIDIA hasn't given an exact timetable for the completion of release 80.

Out of curiosity, I asked de Waal why NVIDIA's drivers don't already take advantage of a second CPU. After all, the driver is a separate task from the application calling it, and Hyper-Threaded and SMP systems are rather common. He explained that drivers in Windows normally run synchronously with the applications making API calls, so that they must return an answer before the API call is complete. On top of that, Windows drivers run in kernel mode, so the OS isn't particularly amenable to multithreaded drivers. NVIDIA has apparently been working on multithreaded drivers for some time now, and they've found a way to fudge around the OS limitations.

De Waal cited several opportunities for driver performance gains with multithreading. Among them: vertex processing. He noted that NVIDIA's drivers currently do load balancing for vertex processing, offloading some work to the CPU when the GPU is busy. This sort of vertex processing load could be spun off into a separate thread and processed in parallel.

Some of the driver's other functions don't lend themselves so readily to parallel threading, so NVIDIA will use a combination of fully parallel threads and linear pipelining. We've seen the benefits of linear pipelining in our LAME audio encoding tests; this technique uses a simple buffering scheme to split work between two threads without creating the synchronization headaches of more parallel threading techniques.

Despite the apparent gains offered by multithreading, de Waal expressed some skepticism about the prospects for thread-level parallelism for CPUs. He was concerned that multithreaded games could blunt the impact of multithreaded graphics drivers, among other things.

 

[mikeblas]

dont ask me,

I didn't. You responded to my thread. But thanks for the quote.

He explained that drivers in Windows normally run synchronously with the applications making API calls, so that they must return an answer before the API call is complete. On top of that, Windows drivers run in kernel mode, so the OS isn't particularly amenable to multithreaded drivers. NVIDIA has apparently been working on multithreaded drivers for some time now, and they've found a way to fudge around the OS limitations.

That's exactly what I'm asking about. It sounds like they're going to make the calls return before the work is actually done, and have another thread go forward with the execution of the call. This isn't what Windows or the client of the driver expect, so I can't understand how they will make it work. Especially: work reliably.

 

[Serpreme]

3dfx had a dual core ;D old news.