Drivers & Multithreading

[Deflection]

I can't remember the exact details(Carmack?) but I remember a quote about most of the processing time for a CPU running a 3D game is in drivers. Asssuming this is correct and Intel is set to launch Hyperthreaded processers, what kind of performance gains can be realized in GPU drivers? Is this something could show major gains if properly optimized for multithreading or minimal improvements?

 

[KimB]

First of all, hyperthreading can decrease performance if the application is not properly-optimized.

But yes, obviously there could be fairly significant performance improvements by optimizing for multithreading (even just for dual-processor systems...those optimizations should be very similar to those for hyperthreading). I would hazard to guess 30% performance improvements, for really, really good optimizations.

One quick note: by that 30%, I mean that it would act like your processor was 30% faster...which certainly does not translate directly to 30% increased framerate.

 

[DadUM]

My personal guess would be very little multithreading already exists in the drivers. If there was, running on 2000 or XP-Pro with multiple processers should already be able to exploit that multithreading as it runs at the OS level. Hyperthreading makes a single processor system appear as two processors. That's why WinXP Home users will not see didly unless MS changes something.

 

[MfA]

I think Carmack made those comments in the pre hardware T&L days ...

 

[ERP]

I'm going to go out on a limb and say that most modern drivers are multithreaded or more they no longer hog the CPU on Busy waits.

The Issues with Drivers and CPU usage used to largely come down to the push buffer. It's basically a Fifo and when it fills up, the CPU has to wait for enough space to be freed before it can continue submitting primitives. I'm going to guess that the big change that happened in the NV 12.xx drivers when they got the big performance jump was running that push buffer submissions on a seperate thread and that thread sleeping on the pushbuffer wait rather than busy waiting on the condition and tieing up the CPU.

You can still cause the GPU thread of your application to busy wait by explicitly locking resources, but well behaved apps should double or tripple buffer resources they need to do that to.

 

[mat]

That's why WinXP Home users will not see didly unless MS changes something.

nope
XP Home supports HyperThreading (they only count physical CPUs)

 

[LeStoffer]

Ack, it's a damn damn shame that BeOS never made it.

Be showed how much there is to gain if you accept that you really need to write the OS from ground up with true emphasis on multiple threads. BeOS would have it key (and naturally) to write applications and drivers with massive multithreading.

Intel Hyper Threading on Windows XP? Blah!

 

[tobbe]

On a related note,
After browsing some old 3DLWildcat review I was thinking about the difference between "consumer" and "pro" drivers. AFAICS there seems to be a fact or consensus that "pro" drivers generally have significantly lower cpu usage, can anyone comment on that?

Specifically I was thinking about these questions:
-The above statement is IIRC relevant for "pro" apps. true or not, or generally relevant?
-If true, why? Apart from "pro" apps generally pushing more vertex data and less texel data, I was thinking whether they generally use more efficient api calls (compared to games) for pushing geometry (since geometry performance is important), or if they use less efficient calls (since it seems plausible those apps dont use the latest and hottest gl extensions)?
-Is high cpu usage a generally bad thing, or can it have some positive aspects, such as higher throughput for some apps/cases, ie games/specific games?

 

[JohnH]

If the majority of time spent in drivers is waiting for the HW to complete, and the HW is being driven in the correct manner, then no amount of optimisation/multi-threading will make things go faster. I'd say this is typically the case these days, with most performance gains in later drivers coming from improved use of the HW itself.

John.

 

[Humus]

On a related note,
After browsing some old 3DLWildcat review I was thinking about the difference between "consumer" and "pro" drivers. AFAICS there seems to be a fact or consensus that "pro" drivers generally have significantly lower cpu usage, can anyone comment on that?

Specifically I was thinking about these questions:
-The above statement is IIRC relevant for "pro" apps. true or not, or generally relevant?
-If true, why? Apart from "pro" apps generally pushing more vertex data and less texel data, I was thinking whether they generally use more efficient api calls (compared to games) for pushing geometry (since geometry performance is important), or if they use less efficient calls (since it seems plausible those apps dont use the latest and hottest gl extensions)?
-Is high cpu usage a generally bad thing, or can it have some positive aspects, such as higher throughput for some apps/cases, ie games/specific games?

On most pro cards the driver can go to sleep for instance while waiting for a vertical retrace and the hardware can generate an interrupt when it's done. On consumer level cards though busy-wait isn't uncommon. There was a topic about this on opengl.org for quite some time ago, things might have changed since then though.

 

[Tagrineth]

I think they're referring to freeing up some CPU time by optimising the driver a little better... not improving GPU performance.

OMG I just said GPU. Damn.