[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[devAngnew]

Originariamente inviato da yossarian

ciao dev, quello che hai riportato si riferisce alla possibilità di gestire due thread in parallelo per SP (o se preferite, per cluster di alu) grazie alla presenza di 2 thread processor. Questo dovrebbe servire a favorire le operazioni di thread switching (che secondo nVidia sono 20 volte più veloci rispetto a GT200 e G80). Questo vantaggio, però, dovrebbe essere più evidente con la atomic operations e con CUDA che non con applicazioni grafiche che richiedono spesso un approccio di tipo seriale con molte istruzioni di tipo dependent, soprattutto a livello di pixel shading e di texture ops (il motivo per cui, su una gpu, se si escludono gli stadi fixed function, non è possibile fare data prefetch e le operazioni vanno gestite dinamicamente).

Certo, però converrai con me o è almeno quello che credo di aver capito che con tale possibilità si possono eseguire "shader indipendenti" in parallelo.

[yossarian]

Originariamente inviato da devAngnew

Certo, però converrai con me o è almeno quello che credo di aver capito che con tale possibilità si possono eseguire "shader indipendenti" in parallelo.

edit doppio

[yossarian]

Originariamente inviato da devAngnew

Certo, però converrai con me o è almeno quello che credo di aver capito che con tale possibilità si possono eseguire "shader indipendenti" in parallelo.

fermi ha 2 warp scheduler per SP, ovvero per ogni gruppo di 16 alu.
Questo significa che può mandare in esecuzione 2 thread differenti su 2 diversi gruppi di 16 alu. Questo non significa che una singola alu può eseguire 2 thread in parallelo.
Mi spiego meglio: in G80 e GT200, ogni SP può eseguire una istruzione per volta (è un processore di tipo SIMD); questo significa che tutte e 16 le alu di g80 o tutte e 24 quelle di gt200 eseguono la stessa istruzione nello stesso ciclo. In fermi, ogni SP raggruppa 32 alu ma contiene 2 warp scheduler. Un warp equivale a 32 thread. Questo significa che, contrariamente a g80 e gt200, in cui veniva mandato in esecuzione un warp per ogni SP, in fermi si pososno mandare in esecuzione 2 warp per SP, ossia un gruppo di 16 alu può eseguire un'istruzione differente dall'altro gruppo. Questo serve soprattutto epr le operazioni a granularità più fine. Per esempio, se un'operazione richiede un'esecuzione fortemente parallela della stessa istruzione, il vantaggio di avere 2 warp scheduler diventa pari a 0.
In ogni caso, in ciascuna architettura, la singola alu può eseguire una sola istruzione per ciclo.

[Jashugan]

Ma da un punto di vista gaming, visto che le Geforce sono rivolte a questo ambito, che vantaggi può dare avere 2 warp scheduler?
Immagino sia tutta una questione di come i driver riescano a gestire il flusso dati, in maniera da ottimizzare il "parallelismo".

A meno che non mi sbagli del tutto, e che i giochi siano altamente parallelizzabili. Ma mi sembrerebbe quantomeno difficile. Questo per l'alta correlazione tra istruzioni.

A questo punto mi viene in mente un'altra domanda. Cioè, se la correlazione non mi consente di sfruttare i 2 warp scheduler, come si comporta il chip? Immagino che un gruppo di 16 alu lavora a pieno ritmo, ma l'altro? Succede che la Geforce lavora a metà della sua potenza nel worst case?

[yossarian]

Originariamente inviato da Jashugan

Ma da un punto di vista gaming, visto che le Geforce sono rivolte a questo ambito, che vantaggi può dare avere 2 warp scheduler?
Immagino sia tutta una questione di come i driver riescano a gestire il flusso dati, in maniera da ottimizzare il "parallelismo".

A meno che non mi sbagli del tutto, e che i giochi siano altamente parallelizzabili. Ma mi sembrerebbe quantomeno difficile. Questo per l'alta correlazione tra istruzioni.

A questo punto mi viene in mente un'altra domanda. Cioè, se la correlazione non mi consente di sfruttare i 2 warp scheduler, come si comporta il chip? Immagino che un gruppo di 16 alu lavora a pieno ritmo, ma l'altro? Succede che la Geforce lavora a metà della sua potenza nel worst case?

Per la grafica i vantaggi reali non sono molti, in quanto spesso si ripete la stessa istruzione addirittura su più SM (o cluster di alu, se preferisci).
In quanto alla gestione, bisogna considerare il warp scheduler come un'estensione del thread processor principale. E' il thread processor che decide quali warp inviare ed a quale cluster. Questo implica che se il thread processor invia la stessa sequenza di istruzione ad entrambi i warp scheduler, su ciascun gruppo di 16 alu gireranno le stesse istruzioni come se ci fosse un unico warp scheduler. Diciamo che averne 2 rappresenta un vantaggio in determinate condizione e non costituisce un handicap nelle altre.

[Severnaya]

scusa, magari fra le righe l'hai già detto ma fai qualche esempio in che determinate situazioni potrebbe tradursi in un vantaggio?

intendo "Diciamo che averne 2 rappresenta un vantaggio in determinate condizione" in questo pezzo qui

[appleroof]

Originariamente inviato da yossarian

Per la grafica i vantaggi reali non sono molti, in quanto spesso si ripete la stessa istruzione addirittura su più SM (o cluster di alu, se preferisci).
In quanto alla gestione, bisogna considerare il warp scheduler come un'estensione del thread processor principale. E' il thread processor che decide quali warp inviare ed a quale cluster. Questo implica che se il thread processor invia la stessa sequenza di istruzione ad entrambi i warp scheduler, su ciascun gruppo di 16 alu gireranno le stesse istruzioni come se ci fosse un unico warp scheduler. Diciamo che averne 2 rappresenta un vantaggio in determinate condizione e non costituisce un handicap nelle altre.

mi sembrerebbe di capire che anche questa innovazione di GF100 è più legata al GPGPU che al gaming...corretto?

[DarkNiko]

Originariamente inviato da appleroof

mi sembrerebbe di capire che anche questa innovazione di GF100 è più legata al GPGPU che al gaming...corretto?

Anche se fosse non ci vedo nulla di male. Suvvia ragazzi, siamo onesti. Mi dite, tolto Crysis, quali sono i titoli da richiedere allo stato attuale (e penso pure futuro) una potenza di calcolo così mostruosamente elevata per poter essere giocati appieno ?
Gia con una GTX285 si gioca benissimo anche in full HD con i filtri attivi e, per i più esigenti, una 295 svolge perfettamente il suo compito.
Tutta questa continua ricerca di potenze mostruose sulle nuove GPU la ritengo, a mio modesto parere, abbastanza inutile, soprattutto considerando che da un bel pò di tempo l'hardware è nettamente avanti al software e prima che possano uscire giochi tali da mettere letteralmente in ginocchio le schede video attuali, ce ne vuole.
Ovviamente anche io auspico che Fermi sia potente (e mi sorprenderebbe il contrario) ma quand'anche avessero deciso di orientare le loro attenzioni sul GPGPU che non sul gaming, non mi strapperei i capelli (anche perchè sono calvo ).

Originariamente inviato da DarkNiko

Anche se fosse non ci vedo nulla di male. Suvvia ragazzi, siamo onesti. Mi dite, tolto Crysis, quali sono i titoli da richiedere allo stato attuale (e penso pure futuro) una potenza di calcolo così mostruosamente elevata per poter essere giocati appieno ?
Gia con una GTX285 si gioca benissimo anche in full HD con i filtri attivi e, per i più esigenti, una 295 svolge perfettamente il suo compito.
Tutta questa continua ricerca di potenze mostruose sulle nuove GPU la ritengo, a mio modesto parere, abbastanza inutile, soprattutto considerando che da un bel pò di tempo l'hardware è nettamente avanti al software e prima che possano uscire giochi tali da mettere letteralmente in ginocchio le schede video attuali, ce ne vuole.
Ovviamente anche io auspico che Fermi sia potente (e mi sorprenderebbe il contrario) ma quand'anche avessero deciso di orientare le loro attenzioni sul GPGPU che non sul gaming, non mi strapperei i capelli (anche perchè sono calvo ).

Speriamo che Fermi non sia un altro nv30....(anche se vedo ultimanente nel Thread,nascere un pochino di ottimismo su questa nuova GPU)

[yossarian]

Originariamente inviato da Severnaya

scusa, magari fra le righe l'hai già detto ma fai qualche esempio in che determinate situazioni potrebbe tradursi in un vantaggio?

intendo "Diciamo che averne 2 rappresenta un vantaggio in determinate condizione" in questo pezzo qui

Originariamente inviato da appleroof

mi sembrerebbe di capire che anche questa innovazione di GF100 è più legata al GPGPU che al gaming...corretto?

molte delle operazioni legate al gpgpu ma che non fanno uso di fp64. Il doppio warp scheduler equivale ad avere la possibilità di fare dual issue, ossia di schedulare 2 istruzioni differenti per gruppo di alu. In fermi la alu sono 32 per SM divise in 2 gruppi di 16 e accoppiate a 2 a 2 (una di un gruppo con una dell'altro). In caso di fp64 le 2 alu "accoppiate" concorrono ad eseguire un'operazione in DP e quindi si perde il beneficio del doppio scheduler. In single precision è possibile schedulare, ad esempio 2 istruzioni fp32 (ma in grafica è molto frequente che su un gruppo di alu giri la stessa istruzione), oppure una SFU e una INT o una FP, o una FP e una INT, ecc. Le istruzioni di tipo INT sono molto utilizzate per fare codifica e decodifica audio e video. Quindi, diciamo che questa opzione serve in primo luogo per le applicazioni di tipo gpgpu che non richiedono fp64 (il caso tipico è due INT differenbti o una INT e una FP). Per le applicazioni grafiche il vantaggio risidede nella possibilità di velocizzare le operazioni di thread switching rispetto a GT200.

[Severnaya]

grazie!

[yossarian]

Originariamente inviato da Severnaya

grazie!

aggiungo che l'idea del doppio scheduler nasce anche dalla necessità di semplificare l'organizzazione interna del chip e l'accesso alle risorse. Ad esempio, in RV870, ATi ha introdotto un commando processor e fa uso di 2 thread processor, uno per ogni blocco di 10 SM (o cluster). In pratica, ha, di fatto, raddoppiato l'architettura di RV770 introducendo un nuovo livello di logica (ossia un processore che organizza e smista il lavoro tra i due core RV770).
In fermi, nVidia ha adottato un'architettura con 32 alu per SM il che aumenta la granularità rispetto a GT200 e G80 (in ATi per ogni cluster, si hanno sempre 16 alu). Questo significa che le operazioni che richiedono una granularità più fine risulterebbero penalizzate su fermi. D'altro canto, utilizzare la stessa granularità di G80 (18 per SM) avrebbe comportato la presenza di 32 SM il che inizia a creare più di qualche problema nella gestione dell'accesso alle risorse ed con particolare riferimento alla gerarchia delle ram. Quindi, il doppio scheduler è una soluzione per ridurre, quando occorre, la granularità, senza introdurre problemi nell'accesso alle memorie o nello scambio di dati tra thread.

[ciberbastard]

mi iscrivo alla discussione perchè anche io devo cambiare vga ^^

[appleroof]

Originariamente inviato da DarkNiko

Anche se fosse non ci vedo nulla di male. Suvvia ragazzi, siamo onesti. Mi dite, tolto Crysis, quali sono i titoli da richiedere allo stato attuale (e penso pure futuro) una potenza di calcolo così mostruosamente elevata per poter essere giocati appieno ?
Gia con una GTX285 si gioca benissimo anche in full HD con i filtri attivi e, per i più esigenti, una 295 svolge perfettamente il suo compito.
Tutta questa continua ricerca di potenze mostruose sulle nuove GPU la ritengo, a mio modesto parere, abbastanza inutile, soprattutto considerando che da un bel pò di tempo l'hardware è nettamente avanti al software e prima che possano uscire giochi tali da mettere letteralmente in ginocchio le schede video attuali, ce ne vuole.
Ovviamente anche io auspico che Fermi sia potente (e mi sorprenderebbe il contrario) ma quand'anche avessero deciso di orientare le loro attenzioni sul GPGPU che non sul gaming, non mi strapperei i capelli (anche perchè sono calvo ).

si si ma infatti la mia domanda era intesa solo a confermare a me stesso se avevo capito bene o meno leggendo gli interventi di yoss, nessun intento o implicazione ulteriore

credevo si capisse al volo

Originariamente inviato da yossarian

molte delle operazioni legate al gpgpu ma che non fanno uso di fp64. Il doppio warp scheduler equivale ad avere la possibilità di fare dual issue, ossia di schedulare 2 istruzioni differenti per gruppo di alu. In fermi la alu sono 32 per SM divise in 2 gruppi di 16 e accoppiate a 2 a 2 (una di un gruppo con una dell'altro). In caso di fp64 le 2 alu "accoppiate" concorrono ad eseguire un'operazione in DP e quindi si perde il beneficio del doppio scheduler. In single precision è possibile schedulare, ad esempio 2 istruzioni fp32 (ma in grafica è molto frequente che su un gruppo di alu giri la stessa istruzione), oppure una SFU e una INT o una FP, o una FP e una INT, ecc. Le istruzioni di tipo INT sono molto utilizzate per fare codifica e decodifica audio e video. Quindi, diciamo che questa opzione serve in primo luogo per le applicazioni di tipo gpgpu che non richiedono fp64 (il caso tipico è due INT differenbti o una INT e una FP). Per le applicazioni grafiche il vantaggio risidede nella possibilità di velocizzare le operazioni di thread switching rispetto a GT200.

ok, allora avevo capito, almeno a livello di principio

Originariamente inviato da yossarian

aggiungo che l'idea del doppio scheduler nasce anche dalla necessità di semplificare l'organizzazione interna del chip e l'accesso alle risorse. Ad esempio, in RV870, ATi ha introdotto un commando processor e fa uso di 2 thread processor, uno per ogni blocco di 10 SM (o cluster). In pratica, ha, di fatto, raddoppiato l'architettura di RV770 introducendo un nuovo livello di logica (ossia un processore che organizza e smista il lavoro tra i due core RV770).
In fermi, nVidia ha adottato un'architettura con 32 alu per SM il che aumenta la granularità rispetto a GT200 e G80 (in ATi per ogni cluster, si hanno sempre 16 alu). Questo significa che le operazioni che richiedono una granularità più fine risulterebbero penalizzate su fermi. D'altro canto, utilizzare la stessa granularità di G80 (18 per SM) avrebbe comportato la presenza di 32 SM il che inizia a creare più di qualche problema nella gestione dell'accesso alle risorse ed con particolare riferimento alla gerarchia delle ram. Quindi, il doppio scheduler è una soluzione per ridurre, quando occorre, la granularità, senza introdurre problemi nell'accesso alle memorie o nello scambio di dati tra thread.

devo ribadire ancora una volta che i tuoi interventi di questo tipo sono i più interessanti che mi sia capitato di leggere sul forum e non solo, complimenti

[persa]

Originariamente inviato da appleroof

devo ribadire ancora una volta che i tuoi interventi di questo tipo sono i più interessanti che mi sia capitato di leggere sul forum e non solo, complimenti

quoto

[papafoxtrot]

Originariamente inviato da appleroof

devo ribadire ancora una volta che i tuoi interventi di questo tipo sono i più interessanti che mi sia capitato di leggere sul forum e non solo, complimenti

Quotone anche da parte mia!

[Alberello69]

Per "granularitá piú fine" intendi operazioni piú parallelizzabili? L'evoluzione non va verso la parallelizzazione?

[Iantikas]

Originariamente inviato da appleroof

devo ribadire ancora una volta che i tuoi interventi di questo tipo sono i più interessanti che mi sia capitato di leggere sul forum e non solo, complimenti

quoto

Originariamente inviato da appleroof

devo ribadire ancora una volta che i tuoi interventi di questo tipo sono i più interessanti che mi sia capitato di leggere sul forum e non solo, complimenti

come non quotare...

grande Stefano...

[marco XP2400+]

quoto pure io