Nuove indiscrezioni sulla GPU GK104 di NVIDIA

[yossarian]

Originariamente inviato da Ren

Sarò io che mi spiego male, ma hai risposto ad una domanda (o deduzione) che non ho fatto...

probabilmente sono io che non ho capito cosa intendevi. Io ho ricollegato il tutto alla possibilità di guadagnare spazio per allocare alu di tipo scalare, riducendso la complessità dei thread processor iin seguito all'eliminazione delle frequenze differenziate tra fpu e resto del mondo .
Quindi la mia risposta era del tipo:"non gudagni praticamente niente facendo questo tipo di operazione, poichè il guadagno in ternmini di transistor è quello di un moltiplicatore di frequenza in meno. In quanto alla possibilità di scheduare n thread per ciclo, questa è indipendente dalla frequenza di funzionamento dello shader core ma dipende dal numero di registri a disposizione per SM. Ogni SM di fermi può schedulare 2 warp, ovvero 2 volte 32 thread, uno per ogni 16 alu. Ossia, ogni gruppo di 16 alu ha a dispsizione 16384 registri da 32 bit in modo tale da poter "caricare" i dati relativi a 32 thread di cui, ad ogni ciclo, ne viene mandato uno in esecuzione, indipendentemente dala frequenza del chip.
Stavolta spero di aver risposto

Originariamente inviato da Ren

ps. se trovi il tempo non mi dispiacerebbe una serie di articoli sulle gpu mobile(adreno,mali,powervr).

non è proprio il mio campo, però vedo se riesco a tirare fuori qualcosa di accettabile

[CrapaDiLegno]

Grazie yossarian.
Ora ho capito. Il fraintendimento è su cosa si intenda per shader a questo punto. Un po' come lo è stato con il VLIW.
Effettivamente è difficile catalogare questo tipo di architetture. Perché contare le semplici ALU senza considerare la dimensione del vettore su cui operano, non è ancora giusto. 100 unità che operano su un vettore x4 sono diverse da 100 che operano su un vettore x2. Tuttavia il fraintendimento è tra il numero di queste ALU e quelle vecchie scalari. Una volta che si è capito come "contarle" allora si possono fare i confronti.

A questo punto la cosa più facile per "indovinare" le presunte prestazioni è vedere quali altre risorse hanno aumentato. Le TMU sono raddoppiate, e se tanto mi dà tanto...

[yossarian]

Originariamente inviato da CrapaDiLegno

Grazie yossarian.
Ora ho capito. Il fraintendimento è su cosa si intenda per shader a questo punto. Un po' come lo è stato con il VLIW.
Effettivamente è difficile catalogare questo tipo di architetture. Perché contare le semplici ALU senza considerare la dimensione del vettore su cui operano, non è ancora giusto. 100 unità che operano su un vettore x4 sono diverse da 100 che operano su un vettore x2. Tuttavia il fraintendimento è tra il numero di queste ALU e quelle vecchie scalari. Una volta che si è capito come "contarle" allora si possono fare i confronti.

A questo punto la cosa più facile per "indovinare" le presunte prestazioni è vedere quali altre risorse hanno aumentato. Le TMU sono raddoppiate, e se tanto mi dà tanto...

e anche, nel caso che l'ipotesi di alu vettoriali sia corretta, capire a quante vie siano. Prendendo per buone le indiscrezioni su numero di unità di fpu, dimensioni del die e numermo di tmu, sarei portato a ipotizzare alu 12-way, quindi non troppo dissimili dalle 16-way di tahiti. In quel caso, si dovrebbe parlare di chip con 128 fpu di tipo vect12 e non di chip con 1536 fpu, perchè in caso di trattamento di dati scalari, capisci che le cose cambiano e di parecchio

[appleroof]

Originariamente inviato da yossarian

probabilmente sono io che non ho capito cosa intendevi. Io ho ricollegato il tutto alla possibilità di guadagnare spazio per allocare alu di tipo scalare, riducendso la complessità dei thread processor iin seguito all'eliminazione delle frequenze differenziate tra fpu e resto del mondo .
cut

esatto, pure io avevo capito così, per questo chiedevo anche un tuo parere al riguardo...

Originariamente inviato da yossarian

e anche, nel caso che l'ipotesi di alu vettoriali sia corretta, capire a quante vie siano. Prendendo per buone le indiscrezioni su numero di unità di fpu, dimensioni del die e numermo di tmu, sarei portato a ipotizzare alu 12-way, quindi non troppo dissimili dalle 16-way di tahiti. In quel caso, si dovrebbe parlare di chip con 128 fpu di tipo vect12 e non di chip con 1536 fpu, perchè in caso di trattamento di dati scalari, capisci che le cose cambiano e di parecchio

si, perchè Amd in questi anni ha sempre detto X sp di tipo vliw5, o adesso Y sp di tipo vect16

edit: se così fosse l'architettura nvidia, si perderebbe quella "facilità" a programmare i driver che si aveva con la superscalare, e che era imho uno dei punti di forza nVidia da g80 a Fermi?

[yossarian]

Originariamente inviato da appleroof

esatto, pure io avevo capito così, per questo chiedevo anche un tuo parere al riguardo...

sentiamo Ren, per capire cosa intendeva. Io ho risposto sulla base della tua interpretazione

Originariamente inviato da appleroof

si, perchè Amd in questi anni ha sempre detto X sp di tipo vliw5, o adesso Y sp di tipo vect16

sono anni che sto invitando tutti a chiamare le cose con il nome corretto, al di là delle uscite dei reparti di marketing

Originariamente inviato da appleroof

edit: se così fosse l'architettura nvidia, si perderebbe quella "facilità" a programmare i driver che si aveva con la superscalare, e che era imho uno dei punti di forza nVidia da g80 a Fermi?

non necessariamente, ma perderesti l'efficienza di un'architettura superscalare, guadagnando in "forza bruta". Insomma, tante unità di calcolo in più ma minor efficienza architetturale

[appleroof]

Originariamente inviato da yossarian

sentiamo Ren, per capire cosa intendeva. Io ho risposto sulla base della tua interpretazione

si certo

Originariamente inviato da yossarian

sono anni che sto invitando tutti a chiamare le cose con il nome corretto, al di là delle uscite dei reparti di marketing

Originariamente inviato da yossarian

non necessariamente, ma perderesti l'efficienza di un'architettura superscalare, guadagnando in "forza bruta". Insomma, tante unità di calcolo in più ma minor efficienza architetturale

ok grazie, spero comunque non si abbia una situazione tipo la vliw e il compilatore ecc ecc

[unfaced12]

Originariamente inviato da appleroof

ok grazie, spero comunque non si abbia una situazione tipo la vliw e il compilatore ecc ecc

Beh da quello che ha scritto yoss, credo che questo pericolo sia scongiurato. La VLIW in teoria doveva essere più performante dell'approccio della concorrenza (anche Buldozzer a dire il vero ), purtroppo le SP venivano sfruttate male con parecchie unita che giravano a vuoto a causa del codice e driver mal ottimizzati. Con questo approccio non mi sembra ci siano di questi rischi. Almeno e quello che ho capito

[calabar]

Beh a dire il vero, a parte nelle prime incarnazioni, le Vliw mi pare finora abbiano funzionato meglio della concorrenza.
Ma come ha detto Yossarian, due elementi ne hanno favorito l'abbandono da parte di AMD: la difficoltà ad ottimizzare i driver dovuta alla crescente complessità e la necessità di utilizzare la gpu come strumento di calcolo generico fino alla sua integrazione con la cpu (hsa).

[unfaced12]

Originariamente inviato da calabar

Beh a dire il vero, a parte nelle prime incarnazioni, le Vliw mi pare finora abbiano funzionato meglio della concorrenza.
Ma come ha detto Yossarian, due elementi ne hanno favorito l'abbandono da parte di AMD: la difficoltà ad ottimizzare i driver dovuta alla crescente complessità e la necessità di utilizzare la gpu come strumento di calcolo generico fino alla sua integrazione con la cpu (hsa).

A me pare che invece i chip della concorrenza andassero di più Teoricamente dovevano andare di più ma venivano sfruttati al 60-70% a causa di questa incomprensibile combinazione di lettere TWIMTBP. Credo che in AMD abbiano sottovalutato questo aspetto e quando si sono svegliati era tardi oramai. Non vorrei dire una scemenza (yoss mi smonterà il tutto) ma credo che Cayman sia sulla carta più potente di Tahiti..... pero Tahiti viene sfruttato meglio.

[Ren]

Originariamente inviato da yossarian

probabilmente sono io che non ho capito cosa intendevi. Io ho ricollegato il tutto alla possibilità di guadagnare spazio per allocare alu di tipo scalare, riducendso la complessità dei thread processor iin seguito all'eliminazione delle frequenze differenziate tra fpu e resto del mondo .
Quindi la mia risposta era del tipo:"non gudagni praticamente niente facendo questo tipo di operazione, poichè il guadagno in ternmini di transistor è quello di un moltiplicatore di frequenza in meno.

Infatti non intendevo un guadagno in termini di transistor e superficie, ma un peggioramento, volto ad abbassare i consumi.

Rimuovere hotclock, ma mantenere lo stesso throughtput con il doppio delle alu al reference clock.

Se nvidia non spara numeri a caso (0.1mm2|40nm per una FPU, oltretutto a 64bit), stiamo parlando di qualche decina di mm2 in più.

[calabar]

Originariamente inviato da unfaced12

A me pare che invece i chip della concorrenza andassero di più [...]

Andavano di più perchè erano più grossi.
Ma dato che qui stiamo parlando di architettura, ciò che conta è il chip con migliori prestazioni per mm^2 e con certi consumi, non quello che aveva migliori prestazioni in assoluto.

[yossarian]

Originariamente inviato da Ren

Infatti non intendevo un guadagno in termini di transistor e superficie, ma un peggioramento, volto ad abbassare i consumi.

Rimuovere hotclock, ma mantenere lo stesso throughtput con il doppio delle alu al reference clock.

Se nvidia non spara numeri a caso (0.1mm2|40nm per una FPU, oltretutto a 64bit), stiamo parlando di qualche decina di mm2 in più.

ok, ora è chiaro anche se ci sono cose che non mi tornano. La frequenza delle alu non c'entra niente con la capacità di eseguire calcoli in fp64. Le alu sono fp32 e solo le operazioni di load/store e addressing avvengono a 64 bit. Il fatto di poter schedulare un warp a 64 bit al posto di 2 a 32 bit dipende esclusivamente dal fatto che, quando lavorano a 64 bit, le alu sono accoppiate (quindi, al posto di 32 alu fp32 per SM hai 16 alu fp64).
Sul risparmio energetico, invece, è vero che se ho il doppio delle unità di calcolo a frequenza dimezzata consumo di meno.

[Ren]

Originariamente inviato da yossarian

ok, ora è chiaro anche se ci sono cose che non mi tornano. La frequenza delle alu non c'entra niente con la capacità di eseguire calcoli in fp64. Le alu sono fp32 e solo le operazioni di load/store e addressing avvengono a 64 bit. Il fatto di poter schedulare un warp a 64 bit al posto di 2 a 32 bit dipende esclusivamente dal fatto che, quando lavorano a 64 bit, le alu sono accoppiate (quindi, al posto di 32 alu fp32 per SM hai 16 alu fp64).
Sul risparmio energetico, invece, è vero che se ho il doppio delle unità di calcolo a frequenza dimezzata consumo di meno.

Il riferimento alla FPU 64bit era solo per chiarire la sua grandezza in mm2, non per menzionare il metodo di esecuzione dei calcoli 64bit di Fermi.

Per la serie, se una fpu 64bit occupa 0.1mm2, quella da 32bit occuperà ancora meno...

[yossarian]

Originariamente inviato da Ren

Il riferimento alla FPU 64bit era solo per chiarire la sua grandezza in mm2, non per menzionare il metodo di esecuzione dei calcoli 64bit di Fermi.

Per la serie, se una fpu 64bit occupa 0.1mm2, quella da 32bit occuperà ancora meno...

ma fermi non ha fpu a 64 bit, per questo non ho chiaro a cosa abbiano fatto riferimento e non mi è chiaro cosa c'entri la frequenza dimezzata delle alu con i calcoli a 64 bit.

[Ren]

Originariamente inviato da yossarian

ma fermi non ha fpu a 64 bit, per questo non ho chiaro a cosa abbiano fatto riferimento e non mi è chiaro cosa c'entri la frequenza dimezzata delle alu con i calcoli a 64 bit.

La fonte è un paper nvidia che parla in generale di scelte di design delle gpu (presenti e future).

Infatti la frequenza non centra niente nei calcoli 64bit.

[yossarian]

Originariamente inviato da Ren

La fonte è un paper nvidia che parla in generale di scelte di design delle gpu (presenti e future).

Infatti la frequenza non centra niente nei calcoli 64bit.

La mia prima risposta a appleroof era relativa a questo post che lui aveva quotato

Originariamente inviato da Ren

I chip nvidia hanno dei circuiti di logica interna che gestiscono il doppio delle informazioni per via del double clock. Se elimini il doppio clock, le alu che occupano pochissimo spazio raddoppiano, ma l'altra logica rimane la stessa. In poche parole, il diesize e le prestazioni non variano di molto, ma i consumi migliorano.

Fermi scalato occuperebbe circa 370-380mm2, quindi non mi sembra difficile integrare il design della vecchia serie mainstream (3cluster-8tmu), togliendo bus e rop's per rientrare sotto i 400mm2.

L'aumento dovrebbe riferirsi al chip top di gamma (in uscita più tardi) ed è di quasi 3X.

in cui parli di gestione del doppio delle informazioni a causa del double clock. Ora, poichè non serve avere il doppio dei circuiti logici per gestire blocchi a differenti valori di clock, mi sono limitato a rispondere che l'unica cosa che si poteva rimuovere era qualche moltiplicatore di frequenza. Tutto questo non ha niente a che vedere con alu a 64 bit. In quanto a queste ultime, di fatto dntro i chip nVidia della serie fermi non esistono fpu a 64 bit dedicate, quindi no ho chiaaro cosa possano rimuovere. Se, invece, ti riferisci a qualche paper del periodo di gt200, allora è un'altra cosa, dato che quella derivata da gt200 è l'unica famiglia ad avere alu fp64 dedicate

[Ren]

Yoss non fissarti su questa benedetta alu fp64, perchè era una semplice unità di misura in mm2, per capire quanto una alu occupi. Non c'entra una mazza (è fuori contesto) con il funzionamento di fermi o altre GPU.

in cui parli di gestione del doppio delle informazioni a causa del double clock. Ora, poichè non serve avere il doppio dei circuiti logici per gestire blocchi a differenti valori di clock, mi sono limitato a rispondere che l'unica cosa che si poteva rimuovere era qualche moltiplicatore di frequenza.

Qui mi sono spiegato male, non intendevo che serve il doppio della logica per gestire il double clock, ma che fermi ha abbastanza logica da gestire un throughput doppio, quindi avere 512x2(hot clock) o 1024alu non è poi così diverso(si tratta di pochi mm2 in più).

Spero di essermi spiegato, perchè comincio ad accusare la stanchezza...

[yossarian]

Originariamente inviato da Ren

Yoss non fissarti su questa benedetta alu fp64, perchè era una semplice unità di misura in mm2, per capire quanto una alu occupi. Non c'entra una mazza (è fuori contesto) con il funzionamento di fermi o altre GPU.



Qui mi sono spiegato male, non intendevo che serve il doppio della logica per gestire il double clock, ma che fermi ha abbastanza logica da gestire un throughput doppio, quindi avere 512x2(hot clock) o 1024alu non è poi così diverso(si tratta di pochi mm2 in più).

Spero di essermi spiegato, perchè comincio ad accusare la stanchezza...

ora mi sono perso del tutto
512x2 non ha senso. Il fatto che le 512 alu di fermi funzionino a frequenza doppia rispetto al resto del chip non comporta il raddoppio della logica di controllo. Si tratta semplicemente di uno stadio che lavora a velocità doppia rispetto al resto ma i cui risultati sono messi a disposizione dei restanti stadi che lavorano a frequenze "ordinarie". Insomma, non c'è una doppia pipeline una per le frequenze normali e una per le frequenze doppie ma un'unica pipeline con stadi che lavorano a frequenza differente per il semplice motivo che il numero di fpu è sottodimensionato rispetto ai restanti blocchi del chip. Questo significa che le linee di trasmissione controllo, i thread processor, gli scheduler, i sequencer non sono raddoppiati. Questo significa che passare da 512 alu da 1500 Mhz a 1024 alu da 750 MHz ti permette di risparmiare solo i transistor necessari ai moltiplicatori di frequenza (ovvero, praticamente, niente). Quello che ti permette di risparmiare è l'utilizzo di alu vettoriali.
Se fosse vero quello che sostieni, allora nVidia avrebbe, finora, sbagliato tutto, in quanto se avesse sostituito n alu a x MHz con 2n alu a x/2 MHz avrebbe ottenuto le stesse prestazioni con consumi minori, a parità di die size. Invece era proprio questo che non era possibile ottenere e si è dovuti ricorrere al "trucco" delle frequenze doppie per le fpu. Per farlo,è sufficiente inserire dei moltiplicatori di frequenza lungo la pipeline che raddoppino il clock in ingresso allo shader dore e lo dimezzino in uscita dallo shader core.

[appleroof]

Originariamente inviato da calabar

Beh a dire il vero, a parte nelle prime incarnazioni, le Vliw mi pare finora abbiano funzionato meglio della concorrenza.
Ma come ha detto Yossarian, due elementi ne hanno favorito l'abbandono da parte di AMD: la difficoltà ad ottimizzare i driver dovuta alla crescente complessità e la necessità di utilizzare la gpu come strumento di calcolo generico fino alla sua integrazione con la cpu (hsa).

Non hanno funzionato meglio, visto che a causa del lavoraccio sui driver non sono mai state sfruttate bene, hanno svolto il loro compito ossia dare da rv770 in poi gpu piccole ma sufficientemente potenti, ma la vliw è stata un incubo di efficenza intesa non come p/w

Originariamente inviato da calabar

Andavano di più perchè erano più grossi.
Ma dato che qui stiamo parlando di architettura, ciò che conta è il chip con migliori prestazioni per mm^2 e con certi consumi, non quello che aveva migliori prestazioni in assoluto.

No andavano di più perché più efficiente l'architettura, e forse se nvidia non avesse avuto la necessità -di fatto non è stata proprio una scelta- di entrare nel mercato hpc, forse sarebbero state pure più vicine alle p/w della concorrenza in ambito gaming. In ambito gpgpu pensa che fermi è vantaggioso performance/watt.

[calabar]

Originariamente inviato da appleroof

Non hanno funzionato meglio, visto che a causa del lavoraccio sui driver non sono mai state sfruttate bene, hanno svolto il loro compito ossia dare da rv770 in poi gpu piccole ma sufficientemente potenti, ma la vliw è stata un incubo di efficenza intesa non come p/w

No andavano di più perché più efficiente l'architettura, e forse se nvidia non avesse avuto la necessità -di fatto non è stata proprio una scelta- di entrare nel mercato hpc, forse sarebbero state pure più vicine alle p/w della concorrenza in ambito gaming. In ambito gpgpu pensa che fermi è vantaggioso performance/watt.

Non sono affatto d'accordo.

Prima di tutto, l'efficienza intesa come sfruttamento delle alu non è un parametro di paragone. Si sa che VLIW ha più difficoltà a sfruttare tutte le unità di calcolo, ma questo fa parte della scelta di questo tipo di architettura.
Per capirci... che ti importa se riesci a sfruttare solo la metà delle tue alu quando rispetto all'altra architettura, nello stesso spazio, riesci a metterne il triplo? (i numeri sono a caso, è giusto per fare un esempio concettuale).

Per l' "andare di più" non vedo come tu possa affermare una cosa simile, dato che il rapporto dimensione/potenza è sempre stato a favore delle amd con architettura VLIW, con casi eclatanti come le hd4xxx contro le gtx2xx.