[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Diobrando_21]

edit

[Rsdj]

Originariamente inviato da Diobrando_21

si, il discorso è tutto qui...per me l'OT finisce qui....vado a giocare a Mass Effect 2, bella

Ma lascia stare ME2, piuttosto fatti un giro a Bad Company 2!!

Cmq ho notato che da quando si è chiuso il CeBIT non ci sono più in giro grosse notizie... non che abbiamo avuto chissà quali notizie però almeno qualcosa si muoveva... secondo voi tra quanto inizieranno ad arrivare le prime notizie attendibili? Intendo prima del 26 marzo...

[ghiltanas]

nn so se era già stato postato:

http://www.semiaccurate.com/2010/03/...ase-dissected/

[gianni1879]

Originariamente inviato da Crysis90

Semplice, c'è scritto che un sacco di gente installando i drivers 196.75, hanno avuto la bella sorpresina: gli si è fritta la VGA!! Il fatto ha fatto incavolare un sacco di clienti e anche i partners, dato che dovranno accettare le richieste di RMA di chi ha subito il danno, perciò dovranno "regalare" delle schede video solo per colpa di NVidia...

Io dico solo una cosa, questo è un altro fatto che testimonia che questi quì si, SECONDO ME, sono COMPLETAMENTE bevuti il cervello. E parlo io che sono sempre stato cliente NVidia...

si era detto basta, considerati ammonito, ci sono le apposite discussioni dove se ne parla

Originariamente inviato da Adone_1985

hai ragione in parte....

questa cosa è successa in un momento un po' brutto per nvidia e quindi è stata la goccia che ha fatto trabboccare il vaso...

cm

come sopra

[appleroof]

Originariamente inviato da yossarian

rispetto a quelli ottenuti con la 1.1 di sicuro.

In ogni caso, unigine è un bel demo e raffigura un posto in cui vivrei volentieri, ma non lo prenderei sul serio per valutare le prestazioni di una vga in game.

quindi Fermi andrebbe meglio in game...

io invece credo che i test sintetici siano utili a dare molte indicazioni che poi, con le dovute proporzioni, possono ritrovarsi nei giochi...di certo non sono da prendere come oro colato, questo si

[gianni1879]

Originariamente inviato da appleroof

quindi Fermi andrebbe meglio in game...

io invece credo che i test sintetici siano utili a dare molte indicazioni che poi, con le dovute proporzioni, possono ritrovarsi nei giochi...di certo non sono da prendere come oro colato, questo si

in realtà non è proprio così, si è visto spesso che vga andavano forte nei vari bench sintetici e poi in game erano invertite le sorti.

[Severnaya]

i test sintetici vanno bene solo nel momento in cui si osserva a parità di sistema il cambio di 1 solo componente e si osserva il risultato, confrontare unigine o un 3dmark con un gioco reale nn ha senso

[appleroof]

Originariamente inviato da gianni1879

in realtà non è proprio così, si è visto spesso che vga andavano forte nei vari bench sintetici e poi in game erano invertite le sorti.

per quello usavo parole come "indicazioni", "dovute proporzioni" ecc

è ovvio che un test sintetico di per sè non basta ed infatti nelle rece è sempre affiancato da più giochi; però ad esempio nemmeno 1 gioco di per sè non basta dipende da come è programmato: anni fà hl2 era fatto su misura di Ati, Doom 3 per Nvidia

diciamo che il test perfetto non esiste perchè Ati e Nvidia da sempre, pur avendo linee guida simili, hanno interpretato le stesse con molte differenze, per cui per forza questa applicazione piuttosto che l'altra andrà meglio sull'una o sull'altra

su unigine la vedo così: poichè implementa la tassellazione in modo massiccio mentre renderizza, mi dà un'idea di come una vga X si comporterà nei giochi futuri; difatti, se è vero che la tassellazione non verrrà mai implementata in quel modo massiccio nei giochi (almeno nei primi dx11), allora l'approccio di Nvidia potrebbe rivelarsi più equilibrato

[Pat77]

Io aspetto la seconda parte dell'articolo di Yossarian sul Tesselator, il primo era molto molto interessante per capire come funziona, il secondo dovrebbe accennare alle interpretazioni Ati e Nvidia dello stesso, e magari accennerà anche all'unigine e il perchè va meglio x o y nell'ambito specifico.
Credo sia il modo migliore per voler entrare nello specifico senza schieramenti e forse sapere meglio cosa ci aspetta fuori dai proclami di marketing.

[faber80]

Originariamente inviato da appleroof

diciamo che il test perfetto non esiste perchè Ati e Nvidia da sempre, pur avendo linee guida simili, hanno interpretato le stesse con molte differenze, per cui per forza questa applicazione piuttosto che l'altra andrà meglio sull'una o sull'altra

ecco perchè il test unigine vale meno di zero, poichè calcola solo ed esclusivamente una variante; è lo stesso discorso del physx, una vga che fa solo quello va anche bene, ma se a quella vga fai fare anche il resto..... sappiamo tutti come va. Il discorso tessellator dedicato o emulato è ancora prematuro; ci sono pro/contro in entrambi i casi.

[appleroof]

Originariamente inviato da faber80

ecco perchè il test unigine vale meno di zero, poichè calcola solo ed esclusivamente una variante; è lo stesso discorso del physx, una vga che fa solo quello va anche bene, ma se a quella vga fai fare anche il resto..... sappiamo tutti come va. Il discorso tessellator dedicato o emulato è ancora prematuro; ci sono pro/contro in entrambi i casi.

non è vero, infatti mentre è attiva la tassellazione è attiva anche la "classica" renderizzazione (quest'ultima la puoi escludere ma normalmente il test è fatto "completo")

[faber80]

Originariamente inviato da appleroof

non è vero, infatti mentre è attiva la tassellazione è attiva anche la "classica" renderizzazione (quest'ultima la puoi escludere ma normalmente il test è fatto "completo")

ah mea culpa, pensavo alla sola tessellazione...

[appleroof]

Originariamente inviato da faber80

ah mea culpa, pensavo alla sola tessellazione...

[faber80]

Originariamente inviato da appleroof

ormai ho gli incubi tessellati

[skizzo99999999]

Vorrei fornire un mio contributo per tentare di dirimere la questione sulla tessellazione, visto che mi sembra che non se ne esca.
Il fatto che le operazioni di vertex shading, tessellation, pixel shading, ecc... siano parallelizzabili nonostante facciano parte di una pipeline è corretto, per il semplice fatto che quello che può elaborare in parallelo di uno "stadio" della pipeline (prendiamo come esempio il pixel shading che è molto facile da spiegare) anche di una moderna GPU è una parte microscopica di quello che bisogna fare per ogni frame.
Si parte infatti sempre dall'assunto che ogni frame dipende da quello successivo (magari non sempre nella parte grafica, ma per la fisica, IA e altra roba si), per cui prima di elaborare i pixel del frame successivo si devono elaborare tutti i pixel di quello attuale. Ma se prendiamo ad esempio anche una risoluzione ridicola come 800x600, quanti pixel abbiamo? 800x600=480000, un po troppi anche per le 512sp di fermi... questo perchè ogni shader agisce su ogni pixel, per cui deve essere calcolato per ogni singolo pixel. Ecco perchè gli shader sui pixel (sarebbe più corretto parlare di fragment, ma con pixel ci si capisce meglio) occupano una enorme quantità di tempo nella generazione del frame rispetto, per esempio agli shader per i vertex. E' in quest'ottica che si deve vedere il passaggio da unità per vertex e pixel agli shader unificati. Il tempo di calcolo per ogni pixel è aumentato, ma siccome ci sono + unità disponibili allora il tempo totale per il calcolo del frame è diminuito, oltre al fatto che così sicuramente non si avranno mai sp inutilizzati, visto che vertex o pixel qualcosa da fargli fare sempre ci sarà.

A prima vista anche qui si potrebbe fare la stessa osservazione per quanto riguarda il "sottrarre le risorse" nel discorso sul tessellatore. Cerco di spiegarmi meglio cercando di essere breve. Se ho 10 vertex e 10 pixel nella GPU1 e ho 20 sp unificate nella GPU2, in totale ho sempre 20 sp. Nella GPU2, potrebbero esserci momenti in cui avrò 3 sp che fanno vertex shading e 17 pixel shading. Si potrebbe dire che i 3 sp stanno sottraendo risorse che sarebbero utili per i pixel shader da eseguire (che come detto sopra sono, alla meglio, centinaia di migliaia di pixel da elaborare). Il fatto è che io comunque i calcoli sui vertex li devo pur fare, e per non "sottrarre" risorse allo shading per i pixel dovrei avere unità dedicate per i vertex. Ma allora, per lasciare inalterata la dimensione fisica della GPU dovrei ridurre il numero si sp disponibili per i pixel e quindi ritornerei di nuovo con solo 17 sp per i pixel. Questo presupponendo che unità dedicate occupino lo stesso spazio di quello generiche e che si tralasci il fattore velocità (le dedicate sono + veloci delle generiche). Ovviamente non è così, ma è per rendere più semplice la questione che voglio spiegare. Ovviamente questo rapporto 3/17 varia sempre, è già questo è un segno che la GPU2 avrà una marcia in più. Quindi in realtà non si sottrae niente: se io ho 10000 vertici e 500000 pixel prima o poi le devo elaborare tutti. L'obbiettivo è tenere il più possibile occupato tutto quello che ho a disposizione. Unificando i vertex e pixel si è visto che la perdita di velocità era più che compensata dall'utilizzo sempre totale di tutto quello che era disponibile.

Il discorso per il tessellator è più o meno lo stesso. Non bisogna vedere come "emulati" (che poi non è neanche così corretto: sempre shader, cioè programmi, sono) hull e domain shader. Iniziamo con due concetti:
1) Sicuramente l'operazione più dispensiona della pipeline della tessellazione è largamente quella del tesellator e non quella di hull e domain, almeno se usata con giudizio e non a sproposito (visto che si tratta sempre di shader che scrive il programmatore, può sempre fare cazzate). Non mi sembra utile ai fini del discorso spiegare nei dettagli si cosa si occupano questi due stadi, per cui sorvoliamo.
2) Un'altra cosa che mi sembra essenziale dire è che non si può parlare di fixed function. Per il tessellator si, ma non per hull shader e domain shader. Proprio il nome dovrebbe già dare un indizio... Vengono caricati programmi proprio come per i vertex, pixel e geometry shader, anche se l'input/output è ovviamente molto più vincolante. Proprio per questo passare da una unità dedicata a un sp generico non comporta un rallentamento terrificante.

Chiariti questi 2 punti veniamo al succo del discorso. Avendo in mente l'analogia di GPU1 e GPU2 precedente prendiamo il caso di fermi: ho 512 sp 16 tessellator (GPU1). Se avessi hull e domain separati, avrei meno sp; tanto per fare un esempio facciamo 480, cioè 2 sp (hull e domain) per ogni tessellator (GPU2). in realtà sicuramente ne servirebbero di più e non sarebbe una equivalenza 1:1 in termini di spazio come già detto, ma facciamo finta di si per semplificare. Ricapitolando, in questo modo in apparenza non sottrarrei nulla: io avrei sempre disponibili i miei 480sp, ma quando non ho niente da tessellare i 32 dedicati sarebbero "buttati". Anche qui quindi, bisogna guardare le cose da un'altra prospettiva: ho 100000 vertici da processare, 10000 vertici da tessellare, 500000 pixel da elaborare. Ogni tanto nella GPU1 potrò utilizzare + di 480 sp, e ogni tanto meno, ma visto che in totale, per quanto riguarda i pixel, ne avrò sempre 500000, almeno userò SEMPRE tutto quello che ho a disposizione. Come vedete non si sottrae proprio niente: se avessi roba dedicata gli sp generici in + usati per hull e domain non li avrei proprio.
Se veramente il cambio di "ruolo" negli sp fosse sempre 1:1 come velocità e dimensione allora il problema non si porrebbe nemmeno: sarebbe sempre meglio avere più roba generica possibile. Ma siccome non è così bisogna valutare di volta in volta e progetto per progetto. La tessellazione però è una delle cose che si presta con più efficienza a questo giochino (per hull e domain), visti i punti 1 e 2 speficicati sopra. Inoltre saggiamente NVIDIA ha, almeno nelle intenzioni, potenziato in modo significativo il tessellator vero e prorpio rispetto alla soluzione di ATI. per cui il tempo che perde nelle fasi di hull e domain dovrebbe, almeno nelle intenzioni, essere più che compensato dalla maggior velocità del tessellator. Quindi la situazione dovrebbe avere moltissimi vantaggi e pochi svantaggi. Uno degli svantaggi è sicuramente il maggior casino nel dimensionare correttamente bus & cache per gestire il flusso di dati da e verso gli sp, che devono gestire risorse per più compiti.
Ovviamente questo non vuol dire che Fermi sarà una GPU molto performante, ma soltanto che questa particolare scelta architetturale per la tessellazione è più complicata da gestire sotto l'aspetto progettuale ma è altamente probabile che sia più efficiente.

[aledemo]

speriamo che non sia un po come la ps3 che su carta con sto cell doveva essere una bestia e poi complicatissima da programmare ci si ritrova con risultati piu scadenti del 360...

era x vedere il lato drastico della cosa eh..non credo che sia la stessa cosa..

[zorco]

io spero e credo che le gpu fermi non saranno da meno rispetto alle attuali proposte ati,il problema principale al meno parlo per mè,lo farà il prezzo

[Alex656]

Originariamente inviato da aledemo

speriamo che non sia un po come la ps3 che su carta con sto cell doveva essere una bestia e poi complicatissima da programmare ci si ritrova con risultati piu scadenti del 360...

era x vedere il lato drastico della cosa eh..non credo che sia la stessa cosa..

Non credo che l'analogia sia tanto azzeccata; nel caso di PS3 il programmatore del gioco è obbligato ad uscire dal "seminato" delle directx di Pc ed Xbox, per Fermi chi programma il gioco continuerà a lavorare ad alto livello.............la complicazione sarà più per chi deve scrivere ed ottimizzare i driver, ovvero per gli stessi ingegneri Nvidia.

[Pike79]

Grazie Skizzo, bella spiegazione!

[yossarian]

Originariamente inviato da appleroof

quindi Fermi andrebbe meglio in game...

io invece credo che i test sintetici siano utili a dare molte indicazioni che poi, con le dovute proporzioni, possono ritrovarsi nei giochi...di certo non sono da prendere come oro colato, questo si

sono sempre stato un convinto fautore dei bench sintetici ma solo se questi sono eseguiti a parità di condizioni. NOn posso far girare il 3dmark 2001 su una vga e il 3dmark2003 su un'altra e trarre conclusioni in merito sulle prestazioni relative

Originariamente inviato da skizzo99999999

Vorrei fornire un mio contributo per tentare di dirimere la questione sulla tessellazione, visto che mi sembra che non se ne esca.
Il fatto che le operazioni di vertex shading, tessellation, pixel shading, ecc... siano parallelizzabili nonostante facciano parte di una pipeline è corretto, per il semplice fatto che quello che può elaborare in parallelo di uno "stadio" della pipeline (prendiamo come esempio il pixel shading che è molto facile da spiegare) anche di una moderna GPU è una parte microscopica di quello che bisogna fare per ogni frame.
Si parte infatti sempre dall'assunto che ogni frame dipende da quello successivo (magari non sempre nella parte grafica, ma per la fisica, IA e altra roba si), per cui prima di elaborare i pixel del frame successivo si devono elaborare tutti i pixel di quello attuale. Ma se prendiamo ad esempio anche una risoluzione ridicola come 800x600, quanti pixel abbiamo? 800x600=480000, un po troppi anche per le 512sp di fermi... questo perchè ogni shader agisce su ogni pixel, per cui deve essere calcolato per ogni singolo pixel. Ecco perchè gli shader sui pixel (sarebbe più corretto parlare di fragment, ma con pixel ci si capisce meglio) occupano una enorme quantità di tempo nella generazione del frame rispetto, per esempio agli shader per i vertex. E' in quest'ottica che si deve vedere il passaggio da unità per vertex e pixel agli shader unificati. Il tempo di calcolo per ogni pixel è aumentato, ma siccome ci sono + unità disponibili allora il tempo totale per il calcolo del frame è diminuito, oltre al fatto che così sicuramente non si avranno mai sp inutilizzati, visto che vertex o pixel qualcosa da fargli fare sempre ci sarà.

A prima vista anche qui si potrebbe fare la stessa osservazione per quanto riguarda il "sottrarre le risorse" nel discorso sul tessellatore. Cerco di spiegarmi meglio cercando di essere breve. Se ho 10 vertex e 10 pixel nella GPU1 e ho 20 sp unificate nella GPU2, in totale ho sempre 20 sp. Nella GPU2, potrebbero esserci momenti in cui avrò 3 sp che fanno vertex shading e 17 pixel shading. Si potrebbe dire che i 3 sp stanno sottraendo risorse che sarebbero utili per i pixel shader da eseguire (che come detto sopra sono, alla meglio, centinaia di migliaia di pixel da elaborare). Il fatto è che io comunque i calcoli sui vertex li devo pur fare, e per non "sottrarre" risorse allo shading per i pixel dovrei avere unità dedicate per i vertex. Ma allora, per lasciare inalterata la dimensione fisica della GPU dovrei ridurre il numero si sp disponibili per i pixel e quindi ritornerei di nuovo con solo 17 sp per i pixel. Questo presupponendo che unità dedicate occupino lo stesso spazio di quello generiche e che si tralasci il fattore velocità (le dedicate sono + veloci delle generiche). Ovviamente non è così, ma è per rendere più semplice la questione che voglio spiegare. Ovviamente questo rapporto 3/17 varia sempre, è già questo è un segno che la GPU2 avrà una marcia in più. Quindi in realtà non si sottrae niente: se io ho 10000 vertici e 500000 pixel prima o poi le devo elaborare tutti. L'obbiettivo è tenere il più possibile occupato tutto quello che ho a disposizione. Unificando i vertex e pixel si è visto che la perdita di velocità era più che compensata dall'utilizzo sempre totale di tutto quello che era disponibile.

Il discorso per il tessellator è più o meno lo stesso. Non bisogna vedere come "emulati" (che poi non è neanche così corretto: sempre shader, cioè programmi, sono) hull e domain shader. Iniziamo con due concetti:
1) Sicuramente l'operazione più dispensiona della pipeline della tessellazione è largamente quella del tesellator e non quella di hull e domain, almeno se usata con giudizio e non a sproposito (visto che si tratta sempre di shader che scrive il programmatore, può sempre fare cazzate). Non mi sembra utile ai fini del discorso spiegare nei dettagli si cosa si occupano questi due stadi, per cui sorvoliamo.
2) Un'altra cosa che mi sembra essenziale dire è che non si può parlare di fixed function. Per il tessellator si, ma non per hull shader e domain shader. Proprio il nome dovrebbe già dare un indizio... Vengono caricati programmi proprio come per i vertex, pixel e geometry shader, anche se l'input/output è ovviamente molto più vincolante. Proprio per questo passare da una unità dedicata a un sp generico non comporta un rallentamento terrificante.

Chiariti questi 2 punti veniamo al succo del discorso. Avendo in mente l'analogia di GPU1 e GPU2 precedente prendiamo il caso di fermi: ho 512 sp 16 tessellator (GPU1). Se avessi hull e domain separati, avrei meno sp; tanto per fare un esempio facciamo 480, cioè 2 sp (hull e domain) per ogni tessellator (GPU2). in realtà sicuramente ne servirebbero di più e non sarebbe una equivalenza 1:1 in termini di spazio come già detto, ma facciamo finta di si per semplificare. Ricapitolando, in questo modo in apparenza non sottrarrei nulla: io avrei sempre disponibili i miei 480sp, ma quando non ho niente da tessellare i 32 dedicati sarebbero "buttati". Anche qui quindi, bisogna guardare le cose da un'altra prospettiva: ho 100000 vertici da processare, 10000 vertici da tessellare, 500000 pixel da elaborare. Ogni tanto nella GPU1 potrò utilizzare + di 480 sp, e ogni tanto meno, ma visto che in totale, per quanto riguarda i pixel, ne avrò sempre 500000, almeno userò SEMPRE tutto quello che ho a disposizione. Come vedete non si sottrae proprio niente: se avessi roba dedicata gli sp generici in + usati per hull e domain non li avrei proprio.
Se veramente il cambio di "ruolo" negli sp fosse sempre 1:1 come velocità e dimensione allora il problema non si porrebbe nemmeno: sarebbe sempre meglio avere più roba generica possibile. Ma siccome non è così bisogna valutare di volta in volta e progetto per progetto. La tessellazione però è una delle cose che si presta con più efficienza a questo giochino (per hull e domain), visti i punti 1 e 2 speficicati sopra. Inoltre saggiamente NVIDIA ha, almeno nelle intenzioni, potenziato in modo significativo il tessellator vero e prorpio rispetto alla soluzione di ATI. per cui il tempo che perde nelle fasi di hull e domain dovrebbe, almeno nelle intenzioni, essere più che compensato dalla maggior velocità del tessellator. Quindi la situazione dovrebbe avere moltissimi vantaggi e pochi svantaggi. Uno degli svantaggi è sicuramente il maggior casino nel dimensionare correttamente bus & cache per gestire il flusso di dati da e verso gli sp, che devono gestire risorse per più compiti.
Ovviamente questo non vuol dire che Fermi sarà una GPU molto performante, ma soltanto che questa particolare scelta architetturale per la tessellazione è più complicata da gestire sotto l'aspetto progettuale ma è altamente probabile che sia più efficiente.

ciao skizzo, quello che dici su unità dedicate e generiche è vero, ma ciò non toglie che quando ho unità generiche che si occupano di tante cose, all'aumentare della tipologia o dei carichi di lavoro di una o più elaborazioni portate avanti in parallelo, diminuisce la velocità con cui vengono svolte le altre. Paradossalmente, in quest'ottica, se non ci fossero problemi di spazio, la soluzione ideale sarebbe quella di avere solo unità dedicate, perchè sono più veloci nell'esecuzione dello specifico task e perchè non sottraggono risorse ad altre elaborazioni. Il problema è che non posso avere un die size delle dimensioni del ponte di un incrociatore e, di conseguenza, sacrifico l'efficienza nella specifica esecuzione per puntare ad una maggior efficienza dell'intera architettura. Questo è ciò che ha spinto ad adottare il modello a shader unificati.
Entrando nello specifico del tessellator, anche all'interno degli hull shader ci sono delle unità fixed function. Il tessellator vero e proprio è l'equivalente di una blind box all'interno della quale arriva l'istruzione di quanti nuovi vertici creare in base a come sono stati riordinati o modificati i control point negli HS. Il tessellator non è necessariamente il collo di bottiglia (dipende dal tipo di elaborazione richiesta) e il motivo per cui è l'unica unità che non sia stata rimpiazzata da altre di tipo generico è semplicemente che la sua sostituzione prevedeva l'uso di un gran numero di unità per avere le stesse performance (come accade per le unità che fanno texture addressing e texture sampling, ad esempio).
Tornando al discorso sulla sottrazione di risorse, ti faccio un altro esempio.
Hai a disposizione 32 cluster di alu (da 16 ciascuno) per fare PS, VS, GS e texture blending. Immagina di dover fare tutte queste operazioni in contemporanea; in un dato momento avrai, ad esempio, 28 cluster che si stanno occupando di eseguire PS e texture blending e 4 che stanno facendo VS e GS. Improvvisamente arriva un'istruzione relativa alla tessellation. Se hai unità dedicate, tranne il primo passaggio in cui i dati vengono trasferiti dal vertex buffer ai VS, per il resto le unità della tua GPU possono continuare ad eseguire i loro task, senza subire rallentamenti. Se hai unità generiche, allora dovrai, ad esempio, sottrarre 4 cluster di alu per eseguire HS e DS; supponiamo che questo avvenga per quelle che si stanno occupando dei PS, in un determinato momento avrai 4 cluster dedicati a VS e GS, 4 alla tessellation e 24 alle operazioni di PS e texture blending. Fino a che non finisce la tessellation le operazioni di PS hanno subito un rallentamento quantificabile con il 14% (poco più) della loro precedente capacità. Se vuoi aumentare la velocità di tessellation devi dedicare atre unità a HS e DS e, di conseguenza, cala ancora la capacità di elaborazione di altri tipi di istruzione.
Ovvio che se ho un'elaborazione "leggera", posso permettermi di stornare risprse ad altri tipi di calcoli. Se lavoro in wireframe non faccio PS e texture blending e posso dedicare tutte le unità alle operazioni geometriche, tessellation inclusa. Questo senza contare che se ho 32 unità dedicate e 32 generiche, nell'eseguire la stessa istruzione le prime somo molto più efficienti delle seconde.
Ovviamente questo esempio è piuttosto semplificato e non tiene conto del fatto che c'è la possibilità di fare thread switching (ma ai fini di ciò che si deve dire cambia poco, anzi è meglio che un singolo cluster si occuipi di portatre a termine una specifica elaborazione, almeno finchè non rischia lo stallo, e non più tipi di elaborazioni in parallelo perchè il thread switching ha un costo in termini di cicli di clock); infine, non è la singola alu che si dedica ad un task, ma l'intero cluster che lavora su un thread e questo impedisce, in ogni caso, il raggiungimento dell'efficenza teorica del 100% anche in un'architettura a shader unificati