di  -  lunedì 4 dicembre 2017

Cari lettori, vi presento un altro articolo (qui la prima parte, qui la seconda) del nostro autore Nessuno. Buona lettura e grazie ancora a Nessuno per il suo contributo.

 

#3.0 Le strategie

Inserisco un glossario per meglio far comprendere quelle che sono le capacità di computazione di una GPU trattate in questo capitolo:

FP64 = unità floating point a 64 bit (dette anche DP, double precision)

FP32 = unità floating point a 32 bit (dette anche SP, single precision)

FP16 = unità floating point a 16 bit (dette anche HP, half precision)

All’aumentare delle capacità aumenta ovviamente la richiesta di risorse per eseguire il calcolo, dai transistor per realizzare le unità di calcolo alla banda necessaria per trasportare i dati e i risultati e quindi dell’energia sia per la computazione che per il trasporto delle informazioni.

Nel lavoro di tutti i giorni (videogiochi, rendering grafico, computazione) le unità FP32 sono più che sufficienti a coprire le necessità. Le unità FP64 sono usate quasi esclusivamente nei calcoli scientifici (astronomia, simulazioni fisiche, strutturali, energetiche, chimiche) dova la maggiore precisione mantenuta durante tutte le fasi di calcolo è importante per un risultato finale molto preciso mentre i calcoli FP16 sono usati nei videogiochi (sopratutto nel mondo mobile dove il risparmio di energia e banda, a causa anche di una limitata capacità computazionale, sono importanti) e nella IA (vedesi per esempio i TensorCore di nVidia inseriti in GV100 per rendersi conto di quanto la computazione con questo datatype è fondamentale in questo mercato).

Abbiamo visto che all’introduzione di GCN con Tahiti AMD era partita con una architettura che aveva come peculiarità quella di possedere tutte le caratteristiche necessarie sia per il mercato consumer (videogiochi) che quello professionale (grande banda e capacità di calcolo FP64 altrettanto molto grande). La concorrenza invece aveva risposto con GPU tagliate maggiormente per il mercato consumer, limitando quindi le risorse che sarebbero servite per scopi di calcolo puro, riservandole solo a una specifica enorme GPU usata prima in campo professionale e poi in quello consumer. In questo modo nVidia ha potuto risparmiare diversi milioni (o miliardi) di transistor, quindi millimetri quadri di silicio, quindi diversi Watt di consumo e alla fine aumentare di diversi dollari il proprio margine.

AMD ha affondato il pedale sulle risorse computazionali introdotte nelle proprie GPU con Hawaii, GPU in grado di dare del filo da torcere al GK110, la GPU di nVidia con appunto caratteristiche simili e adottata nel mercato professionale (e server HPC). Quello che si imputava come vantaggio in termini di efficienza dell’architettura di nVidia rispetto all’offerta di AMD era la mancanza appunto di questo supporto “avanzato” in GPU che l’azienda destinava quasi esclusivamente al mercato grafico e non a quello computazionale puro, vantaggio che si assottigliava quando in concorrenza metteva la GPU per il mercato professionale, ben più complessa e simile nelle risorse a quelle offerte da AMD.

Il fatto che nonostante i numeri sulla carta, non ci fossero schede AMD create appositamente per il calcolo era qualcosa di anomalo che è passato inosservato ai più. Così come il fatto che le GPU nVidia con meno risorse di calcolo e meno banda comunque riuscivano a performare similmente (o anche meglio) di quelle della concorrenza (quindi costretta indirettamente a venderle al prezzo deciso da nVidia).

La cancellazione dei 20nm di TMSC ha cambiato parecchio le strategie delle due aziende.

#3.1 Il post 20nm (mai creati)

Con l’arrivo di Maxwell nVidia modifica in via eccezionale la sua offerta: poiché il PP non è cambiato e Maxwell richiede più silicio di Kepler, non è possibile creare una GPU per il mercato professionale con le unità di calcolo FP64, e il GM200, la GPU più grande con base Maxwell, non ha declinazioni per il mercato dei server HPC (che fino a Pascal rimangono legati alla disponibilità di schede con GK110).

Similmente, sempre per mancanza di un rimpicciolimento dei transistor, anche AMD propone con GCN1.2 (base di Tonga e Fiji) una architettura in cui le capacità FP64 sono decisamente tagliate al minimo.

Da questo momento in poi le strategie sono completamente cambiate per le due aziende.

nVidia sul mercato consumer mette solo ed esclusivamente la sua architettura “povera”, quindi priva di unità di calcolo diverse da quelle FP32, e crea una architettura ancora più spinta per il calcolo destinata esclusivamente al mercato dei server HPC. GP100 (Pascal) e GV100 (Volta) sono due GPU “monster” (soprattutto l’ultima) che integrano nuove unità di calcolo che sono richieste nei compiti di IA e deep learning che sembrano essere la nuova tendenza del momento che assorbe diverse risorse e investimenti (con addirittura Google che crea i propri ASICS per tale lavoro). L’introduzione di una GPU serie Gx102 indica che nVidia non ha più intenzione di usare GPU con caratteristiche non utili al gaming nel mercato consumer, neanche in versione castrata (la differenza di costi sarebbe comunque enorme). L’era delle mattonelle stile GF100 o GK110 nel mercato consumer è finita.

AMD crea Polaris per la fascia media che è priva di quelle caratteristiche che avevamo visto con Tahiti prima e Hawaii dopo. Bus ridotto, no capacità FP64. AMD praticamente si allinea alla scelta di nVidia di creare GPU “semplici” per il mercato consumer. E per il mercato di fascia alta? La sorpresa viene con Vega: anche questa architettura è priva delle capacità di calcolo FP64 delle prime GPU GCN, anche se introduce il packet math che permette di eseguire 2 operazioni FP16 al posto di una FP32, raddoppiando pertanto i TFLOPS con questi calcoli ridotti, caratteristica introdotta da nVidia nella architettura Maxwell destinata esclusivamente al suo SoC (usato poi nella Switch di Nintendo) e usata anche per GP100 (ma non delle versioni consumer di Pascal) e ovviamente di GV100 in forma ancora più avanzata con i Tensor Core.

AMD ha abbandonato la speranza di poter un giorno diventare una alternativa nel mondo delle schede acceleratrici dei server HPC dominato da nVidia e Intel? Non lo sappiamo ancora per certo, ma vediamo che la tendenza è quella di cercare di limitare i danni in millimetri quadri e Watt rispetto alla concorrenza, e quindi sembra che finché alla base ci sarà GCN (e relative revisioni più o meno modificate) non ci sarà spazio per GPU indirizzate ad un mercato in cui AMD non è mai entrata per davvero. Magari con Navi cambierà strategia nuovamente, e sarebbe un segnale di ripresa.

Ci sono un paio di cose da considerare con il lancio di Vega da parte di AMD e le strategie adottate: oltre a non aver fatto una GPU con capacità FP64, con Vega Frontier Edition AMD ha deciso che anche il mercato grafico doveva avere un sacrificio e ha quindi ha introdotto nel mercato prosumer l’accelerazione ad hoc alle applicazioni professionali, fino al giorno prima riservate alle schede professionali con driver appositi pagati molto bene.

Dal punto di vista dell’utente che si ritrova le nuove feature a disposizione con una scheda che costa relativamente poco (e comunque meno di una scheda professionale) la mossa sembra una bella cosa.

Dal punto di vista della strategia aziendale sembra una mossa che uccide le galline dalle uova d’oro. E’ quindi presumibile che AMD non veda (o abbia visto) un grande ritorno economico arrivare dalla vendita delle proprie schede professionali usate per programmi che usano OpenGL e abbia usato questa mossa per dare significato ad una scheda come Vega Frontier Edition che altrimenti non avrebbe avuto grande spazio contro il più potente (e energeticamente efficiente) GP102. Rinunciare ad un mercato a lungo termine per vendere la GPU nel breve sembra essere l’unica mossa possibile e indica una certa disperazione nel tentare di mettere sul mercato una GPU che evidentemente costa più di quel che ci si aspettava e rende altrettanto meno del previsto (annunciata a $1200 arrivata sul mercato a $1000).

Ovviamente questa mossa è intesa anche a mettere in difficoltà il grande rendimento del mercato professionale di nVidia, che non ha potuto che rispondere rilasciando dei driver ottimizzati anche per le Titan basate su Pascal.

Sembra il gioco di uccidere il mercato dove la concorrenza fa soldi, piuttosto che cercare di entrare e fare concorrenza in tale mercato per guadagnarci di più. Evidentemente AMD non vede la possibilità di concorrere in questo mercato, almeno non nel breve periodo (anche se dopo averlo “ucciso” sarà un bel problema ritornare come prima anche se dovesse avere in futuro schede molto migliori di quelle nVidia).

#4.0 Il futuro

#4.1 C’era una Volta…

Abbiamo visto che la caratteristica più interessante di AMD introdotta con Vega è l’uso del packet math che permette di raddoppiare la velocità di esecuzione dei calcoli usando calcoli FP16 invece che FP32. Sottolineiamo che anche le attuali GPU nVidia destinate al mercato consumer possono eseguire calcoli FP16, ma solo a velocità pari a FP32, non doppia come Vega. Non è quindi una funzionalità mancante, manca solo la possibilità si sfruttare l’unità FP32 come fossero 2xFP16.

Ci si chiede quindi se nVidia abbia deciso se mettere o no nelle prossime GPU consumer questa accelerazione dopo averla introdotte nel suo SoC mobile e inserita nelle GPU per server (GP100 e GV100, dove è ampiamente usata negli algoritmi di deep learning).

La domanda è più che lecita, visto che AMD con Vega (e probabilmente con tutte le future GPU) si appresta ad avere qualche vantaggio prestazionale nel caso che le SH volessero ulteriormente ottimizzare per l’architettura AMD. Sappiamo che le DX12 lasciano grande spazio decisionale ai programmatori e che i driver non possono più intervenire nel risolvere certe situazioni come con le DX11 e precedenti. È necessario ora più che mai “inseguire” la concorrenza nel set di feature che viene maggiormente utilizzato per non rimanere esclusi da ottimizzazioni parziali.

Purtroppo nVidia da diversi anni (da quando praticamente è leader incontrastata) non rilascia alcuna descrizione delle sue architetture se non al momento prossimo al lancio. Di GV100 abbiamo avuto una descrizione particolareggiata qualche settimana fa quando nVidia ha rilasciato la documentazione per CUDA 9 dove una minuscola nota dice che “l’unità di calcolo a 32bit è stata modificata in modo che possa eseguire 2x istruzioni a 16bit”, quindi sembra che con Volta non ci siano più le unità a FP16 dedicate ma che è possibile eseguire il packet math con le normali unità FP32 e quindi una funzionalità che potrebbe trovare posto nelle declinazioni delle GPU per il mercato consumer senza particolare consumo di risorse extra.

Della versione consumer invece non si sa nulla, ma qualcosa possiamo comunque prevederlo, sempre dando uno sguardo a quello che sappiamo dell’architettura del GV100.

Di sicuro non vi saranno le funzionalità legate al calcolo puro, quindi no HBM2, i vari bus nVlink, le unita FP64, i tensor core, le cache aggiunte, lo scheduling avanzato e probabilmente la segmentazione delle SM in 64 ALU al posto delle normali a 128 ALU (a meno che la segmentazione correttamente gestita permetta in qualche modo di ottenere prestazioni migliori con i lavori imposti dalle nuove tecniche di Async Computing). È presumibile che il GV102 sia il GV100 senza tutto questo, e quindi con le sole 5376 (se messo in commercio completo con tutti i 42 TPC abilitati) esattamente come il GP102 è rispetto al GP100.

Non si sa se le ALU integer, che in Volta possono funzionare parallelamente a quelle floating point saranno incluse anche nelle GPU minori (non trovo uno scopo utile nel gaming alla cosa, per cui non credo, ma magari nVidia ne ha inventate una delle sue per avere qualche feature nuova rispetto alla concorrenza). Con le nuove unità FP32 che possono eseguire 2xFP16 la presenza o meno del packed math è solo questione di quale strategia vuole adottare, ovvero se crede che l’FP16 nel mondo consumer sia un vero vantaggio o meno.

Ricordiamo che nVidia da sempre bilancia le funzionalità messe a disposizione nel mondo consumer vs il mercato professionale, quindi potrebbe ritenere che dare la possibilità di eseguire il calcolo FP16 in maniera efficiente con le GeForce possa permettere l’esecuzione di algoritmi di Deep Learning sofisticati anche sulle schede da gaming erodendo il proprio (lucroso) mercato Tesla. Viceversa la mancanza di tale accelerazione potrebbe portarla ad avere svantaggi prestazionali rispetto alla concorrenza e quindi dare meno valore aggiunto a tutta la propria gamma GeForce (la quale ha grande impatto sul fatturato). Essendo un periodo di transizione con la questione FP16, dove AMD l’ha resa vantaggiosa solo con Vega (una scheda di fascia alta le cui vendite per quantità non disturberanno certo il sonno a nVidia), è possibile che nVidia decida (o abbia già deciso) che il calcolo FP16 per ora nel mercato consumer “non s’ha da fare” e vedrà come andrà la questione dell’adozione (e dei risultati qualitativi, ricordiamo che la precisione viene notevolmente ridotta con i calcoli FP16 e che quindi non sono adatti a tutti i tipi di calcoli anche nei giochi) nel frattempo.

La memoria affiancata alle nuove GPU sarà presumibilmente la nuova GDDR6 per i modelli high end, con magari qualche strascico di GDDR5(X) sui modelli inferiori (a seconda delle caratteristiche di costi, consumi e disponibilità di tutte le memorie).

Le proprietà del nuovo PP non sono note nei dettagli, quindi non sappiamo esattamente quanto nVidia risparmierà in spazio e/o in consumi.

Un confronto diretto tra GP100 e GV100 indica un aumento di circa il 50% della capacità di calcolo con lo stesso TDP (300W) e frequenza tra le due GPU praticamente uguale.

Il calcolo delle capacità di rimpicciolimento dei transistor (shrinking) è invece più difficile, dato che le due GPU hanno core differenti: GP100 dovrebbe integrare unità FP16 dedicate, il GV100 no, anche se a sua volta integra i Tensor Core che sono raggruppamenti di unità FP16 dedicate al calcolo vettoriale che accelera notevolmente alcune operazioni comuni per il Deep Learning.

Il GV100 è fisicamente grande il 33% in più del GV100 per un totale aumento del 37% dei transistor.

Il che significa che il nuovo PP non permette un aumento significativo né di densità né di frequenza, quindi forse solo di energia consumata (che vediamo comunque essere già bassa con Pascal) e quindi qualsiasi aumento di prestazioni rispetto a Pascal deve essere ricercato nella diversa architettura e soprattutto nell’aumento di dimensioni.

La nuova architettura in particolare sulla carta integra il 40% in più di unità di calcolo e il 50% in più di cache e memoria interna, quindi qualche modifica ai TPC deve essere stata fatta.

Possiamo fare questa similitudine: in una sorta di Tic-Toc, nVidia ha iniziato con Kepler (molto diverso rispetto a Fermi), poi ha creato una architettura più efficiente e potente con Maxwell senza poter adottare un nuovo PP, in seguito ha creato Pascal che gode del suo vantaggio prestazionale per via delle nuove alte frequenze raggiunte e ora è chiamata a ripetere il “miracolo Maxwell” con Volta su un PP che non le concede né spazio né apparentemente ulteriori aumenti di frequenza, a meno che nVidia non abbia deciso di sacrificare buona parte del vantaggio dei consumi del nuovo PP con frequenze ancora più spinte rispetto a Pascal, seguendo la strada della concorrente che punta più alle prestazioni che all’efficienza energetica nel mercato consumer. Non è escluso che come è stato per Pascal, nVidia voglia provare ad usare i 12nm di entrambe le fonderie, cioè sia quelli di TMSC per la fascia alta e quelli di Samsung per la fascia economica.

Il post Volta, come il post Vega, è completamente ignoto. Nessuna delle due aziende ha fatto alcun cenno su cosa verrà. Di nVidia non si sa nemmeno il nome in codice della futura architettura, mentre di AMD si sa che si chiamerà Navi. Entrambe dovrebbero essere basate sui 7nm, AMD su quelli di Samsung/GF, nVidia su quelli di TMSC.

Se e quando passeranno ad un approccio MCM (Multi Chip Module) non è ancora dato a sapersi. Abbiamo visto che AMD ha fatto da apripista con questa nuova filosofia con Zen, pur dovendo andare incontro a diversi compromessi. Per le GPU e i loro parallelismi spinti gli stessi compromessi (come NUMA, Non Uniform Memory Access) sono abbastanza critici.

Forse ne parleremo in un altro articolo ancora. Intanto si aspetta Volta per un balzo in avanti delle prestazioni (Addendum: notizie dell’ultima ora parlano anche di imminenti GPU con architettura Vega per il mercato mainstream, forse con i futuri 12nm di GF quando saranno pronti).

2 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Xeus32
     scrive: 

    Bella la spiegazione sulle FP16.
    In mia modesta opinione è anche da tenere in conto che l’FP16 è fondamentale per l’implementazione del HDR e che con i nuovi standard che avanzano abbiamo una profondità di colore di almeno 10bit (uint16).
    Sono due cambiamenti semplici ma che sballano abbastanza i giochi perchè non sarà più possibile fare le operazioni packed (16x8uint) ma si dovrà fare (8x16uint).
    Adesso è tanto che non lavoro sulle shader ma se non hanno stravolto gli algoritmi, l’implementazione AMD mi sembra mirata a supportare i famosi 4K con HDR e profondità di colore 10bit.
    Specifiche che nel mondo pc non sono ancora molto disponibili ma che penso i due clienti (Sony e MS) siano più propensi a sfruttare.

  • # 2
    Nick
     scrive: 

    Grazie dell’articolo.
    è sembra una (bella) sorpresa aprire appuntidigitali e trovare cose nuove

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.