Link alla notizia: http://www.hwupgrade.it/news/software/14846.html

NVIDIA si prepara a introdurre supporo attivo per architetture multiprocessore all'interno delle future revision dei driver Forceware

Click sul link per visualizzare la notizia.

.. 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?

QUESTA è una bella notizia per chi prenderà un dual core :)

ecco come saturare il pci-express !!!
era ora

Interessante anche per chi ha l'Hyper threading ;)

Interessante anche per chi ha una macchina smp da una vita.

saturare il pci-express? siam ben lontani...

NUove tecnologie, nuovi driver. Ci sarà da divertirsi, ancora pollice su per nVidia

Molto interessante.
Finalmente si prospetta un "vero" salto di prestazioni nel prossimo futuro. ;)

QUESTA è una bella notizia per chi prenderà un dual core :)Interessante anche per chi ha l'Hyper threading ;)
oltre che per l' ovvia implicazione del più efficiente sfruttamento dei sistemi HT/SMP/DC, la notizia è interessante se la si guarda da un certo punto di vista...

si considerano gli abbinamenti scheda grafica + driver perchè a meno di mod, solitamente il driver è utilizzabile solo con uno specifico pezzo di hardware o famiglia di pezzi di hardware
il che implica l' acquisto della scheda grafica più costosa per avvantaggiarsi di quello che magari solo il driver o solo la scheda, ha in più rispetto alla versione gaming... che per quel che ricordo, si tratta di:
-eventuali peculiarità che aumentino la qualità visiva in utilizzo professionale (qualche tempo fa era il caso dell' antialiasing per linea in wireframe, appannaggio delle versioni firegl/quadro... oppure maggiore precisione interna a livello della render pipeline)
- appunto la certificazione opengl dei driver, il che dovrebbe portare a un debug esaustivo
- ma anche prestazioni opengl "ottimali" (o comunque migliori), il che riporta a driver più curati già a livello di progettazione, di modo che tecniche quali appunto il multithreading (che a livello di opengl serve sostanzialmente per tenere aperte più viste non fullscreen senza perdita prestazionale eccessiva) siano implementate in maniera safe... ;)

riassumendo, magari altri mi smentiranno ma per ora lo vedo come un assottigliarsi delle differenze tra l' HW game-oriented e quello della nicchia professionale...

- ma anche prestazioni opengl "ottimali" (o comunque migliori), il che riporta a driver più curati già a livello di progettazione, di modo che tecniche quali appunto il multithreading (che a livello di opengl serve sostanzialmente per tenere aperte più viste non fullscreen senza perdita prestazionale eccessiva) siano implementate in maniera safe... ;)


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!
:sofico:

.. 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?
Non regge... Inanzitutto non considerare Hyperthreading. Se sgravi a una cpu un processo che può essere eseguito in parallelo dall'altra l'occupazione totale viene dimezzata. Ma ciò non è comunque vero perchè un gioco usa sempre tutta la potenza di calcolo, tu vedrai il gioco più fluido.
cosa intendi per "meno si "intacca" la CPU, meglio è per il driver!"??

Aggiungo forse leggermente ot

Potrebbe essere l'inizio di uno sviluppo teso a sfruttare le capacità di calcolo della GPU anche per applicativi non perfettamente grafici, mi spiego: ricordo che qualche tempo fa è stato lanciato sul mercato un applicativo per audio mixing che si appoggiva alla capacità di calcolo della GPU, poichè questo tipo di processori per le loro caratteristiche sono molto adatti a gestire flussi di calcolo parallelo se il produttore dei driver creasse delle librerie specifiche per accedere a queste funzionalità ci si potrebbe sbizzarire (penso in particolare ad apllicativi per conversione di flussi audio video DivX... :p )

certo nn considero l'HT.
I dirver video (anche audio insomma!) dovrebbero essere una "porta" verso cui la CPU "scrive" i valori da "rappresentare".
Quindi se "scarico" la CPU da ogni altra cosa, la periferica è più "intelligente". Vagamente è simile agli hd ... ma è difficile da spegare, mi viene voglia di cancellare tutto ...
OK, ci sono applicazioni molto particolari che possono sfruttare la GPU per eseguire dei calcoli, ma ritengo che se si fa carico la seconda CPU ci quanto dorebbe invece fare la vga, si entra in un campo non proprio multitasking quindi solo per applicazioni particolari che certo non girano in parallelo. ecco quindi perchè scrivo "solo giochi".
Accidenti devo dormire di più la notte, sto scrivendo come un cretino!

Secondo me non ci si puo' sbilanciare troppo con percentuali messe li a caso... Bisognerebbe fare dei veri e propri test, mirati.
Comunque vedremo, è sicuramente una cosa interessante e avrà sicuramente i suoi bei vantaggi.

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!
:sofico:


sorry per non aver visto prima... no non mi riferivo all' UBB :O
mi riferivo a ciò che (qualsiasi cosa sia) rende due schede di pari generazione, una gaming ed una professionale (geforce / quadro), MOLTO diverse quando si tratta di manipolare viste opengl che, non occupando il 100% dello schermo, contendono per il redraw, tra di loro e con il desktop
(la vera cosa a cui secondo me il multithreading a livello dei driver metterebbe una pezza, se il costo maggiore della soluzione prof. è da imputare ad una miglior "progettazione" (non solo "stesura" - diff. engineering vs coding ) del driver stesso, studiato magari per minori latenze dei code path, miglior gestione degli interrupt... quello che si percepisce come "occupazione della cpu" in compiti i/o bound come diventa spesso la grafica quando si tratta di inviare uno stream di comandi alla gpu, dipende anche da questo...)