Multithreading anche per i driver video

.. al 30% ???

perchè il driver dovrebbe essere al più basso livello del S.O., che è quello che fa "vedere" un sistema multitasking (in maniera rasparente: io nn so quante CPU ci sono).
Se una delle due CPU del mio sistema dual viene sfruttata dal GIOCO allora questa si impadronisce della risorsa (CPU) saltando il S.O.
Inosmma OK per i giochi, ma per altre applicazioni penso si rimanga ad un più risicato 5-10%. E solo in particolari punti/applicazioni.
Già una applicazione come CAD può usare bene un sistema a doppia CPU, ma non vedo come possa un DRIVER di una scheda grafica possa sfruttare così tanto una seconda CPU: meno si "intacca" la CPU, meglio è per il driver!
O sbaglio?

Ti riferisci al cosiddetto Unified Back Buffer?

In realtà la differenza tra versioni game e versioni professionali è già molto sottile, per quello che riguarda le schede nVidia e Ati. Ormai è noto a tutti che tra GeForce e Quadro o tra Radeon e FireGL le differenze siano ridotte a pochi pin che danno l'"identità" al chip grafico.
Il vero punto debole di una Quadro o di una FireGL, rispetto ad esempio alle Wildcat vecchio tipo, sta nel fatto di non supportare al 100% le chiamate OpenGL. Mi spiego: fate eseguire un rendering OpenGL a una Quadro e a una Wildcat. magari entrambe hanno le stesse prestazioni, ma se osservate la percentuale di occupazione della CPU troverete 85% per la Quadro e 15% per la Wildcat. In sostanza, le schede Quadro e FireGL si appoggiano comunque alla potenza della CPU per eseguire il loro lavoro, quindi secondo me lo sviluppo di driver specifici per smp va nell'ottica di fornire maggiore potenza per quella parte di lavoro che la scheda video non è in grado di svolgere.
Comunque, ottima iniziativa: sapevo che con l'avvento dei processori dual core, ci sarebbe stata nuova linfa anche per i classici sistemi biprocessore!