Durante il CES di Las Vegas, AMD non annuncia la data di debutto del nuovo chip Vega ma rilascia svariati dati tecnici piuttosto interessanti.
Diverse le migliorie apportate:
- efficienza delle ALU
- miglior accesso con la cache l2
- rop’s più efficienti
- compressione migliorata
- HBM2
- reparto geometrico totalmente rivisto a livello di poligoni
- rasterizzer migliorato
- Core compreso tra i 520/550mmq2
[nextpage title=”Da Polaris a Vega”]
Prima di parlare di Vega, rivediamo velocemente il chip Polaris, ed analizziamo le migliorie.
Analizzando lo schema notiamo i 36 CU (compute engine), 9 CU per shader engine. Ogni CU integra 4 unità vettoriali capaci di elaborare 16 ALU per ciclo di clock. In sintesi funziona così:
1° Vettore = 16 ALU (shader)
2° Vettore= 16 ALU
3° Vettore=16 ALU
4° Vettore=16 ALU.
Un CU è composto da 64 ALU e 4 vettori, in cui accedono alle 4 TMU (texture mapping), set istruzioni e relativa cache L1.
Ogni istruzione necessita di 4 cicli per elaborare tutti i vettori, più uno tra vettore 1-2-3, quindi 7 cicli di clock.
Il rasterizzer, estrapola i pixel e li manda in lavoro verso le rop’s, che si occupano di lavorare nei restanti stadi, sino a raggiungere la cache l2, banda, ramdac e lo schermo.
La memoria è di 256 bit, ogni memory controller da 32 bit, è collegato a 128mb di cache l2, per un totale di 2mb e 4/8gb di ram.
VEGA
Dopo aver fatto un riassunto sulla struttura elaborativa di Polaris, fulcro e cuore della GCN, cominciamo a vedere le migliorie di Vega.
Con Vega, AMD ha implementato un sistema HBCC (High Bandwidth Cache controller), che permette di migliorare la gestione del frame buffer tra Ram di sistema e VRAM, per fare in modo che nelle HBM si trovino sempre e solo i dati che al momento dell’elaborazione risultino più adeguati. È bene sapere che la GPU in base alla memoria del sistema, può allocare tanti dati inutili in RAM, che necessitano di accessi più lenti e complessi, sopratutto per caricare oggetti in lontananza, ma se il sistema vede una VRAM molto ampia, satura i dati li piuttosto che in RAM, purtroppo in VRAM è bene sottolineare che ci devono passare solo dati primari, e ridurre spazio è determinante quando si elabora una scena complessa.
L’HBCC cerca di velocizzare questo processo, non allocando in VRAM dati inutili, però velocizzando e massimizzando i dati esterni come se praticamente fossero praticamente presenti nella VRAM, anche se questa è sgravata.
[nextpage title=”Innovative HBM2″]
L’aspetto più valorizzato della prossima architettura Vega sono le nuove HBM2, le memorie avanzate già viste con la Fury.
DRAM |
GDDR5 |
GDDR5X |
HBM1 |
HBM2 |
|---|---|---|---|---|
I/O (Bus Interface) |
32 |
64 |
1024 |
1024 |
Prefetch (I/O) |
8 |
16 |
2 |
2 |
Maximum Bandwidth |
32GB/s (8Gbps per pin) |
64 GB/s (16Gbps per pin) |
128GB/s (1Gbps per pin) |
256GB/s (2Gbps per pin) |
tRC |
40ns(=1.5V) 48ns(=1.35V) |
40ns (1,35v) |
48ns |
45ns |
tCCD |
2ns (=4tCK) |
2ns (=4tCK) |
2ns (=1tCK) |
2ns (=1tCK) |
VPP |
Internal VPP |
Internal VPP |
External VPP |
External VPP |
VDD |
1.5V, 1.35V |
1.35V |
1.2V |
1.2V |
Command Input |
Single Command |
Single Command |
Dual Command |
Dual Command |
HBM
Le memorie HBM standard viste con la Fury, potevano trasportare, su un bus di 4096bit ben 128 gb/s a canale, per un totale di ben 512gb/s teorici. Parliamo di teorici perchè i dati finali non raggiungevano mai questo bandwidth per via della complessità tra rop’s e geo engine.
Il vero problema delle HBM1 stava però nel rapporto tra densità e BW, in quanto i tagli da 1GB, costringevano ad usare ben 4 stack su tagli VRAM spesso criticati dagli enthusiast di soli 4GB.
HBM2
HBM2, una vera rivoluzione.
I nuovi chip Samsung e Hynix, migliorano davvero tanto e soddisfano ogni richiesta. Ora con i nuovi Chip è possibile utilizzare tagli di 2/4/8 GB su vari stack.
Vega sarà costruita utilizzando i nuovi moduli con tagli ram da 8 e 16gb, 8 per il gaming, 16 per le versioni professionali utilizzate per doppia precisione FP64.
I 2 stack trasportano sino a 512gb/s e garantiscono ben 8GB di ram, ma non è tutto, oltre a consumare di meno, grazie alle migliorie ai geo engine ed al motore di rasterizzazione, unità alla nuova compressione delta color rop’s, si riuscirà ad avere una banda finale molto più elevata di fury. Pensiamo di toccare ben 640gb/s finali, quasi il doppio di Fury, malgrado lo stesso bus.
[nextpage title=”Compute engine e nuovo rasterizzatore”]
Il Compute unit è un fattore sulla quale AMD non ha dichiarato molto, sappiamo con certezza che rimane il medesimo, ma per massimizzare l’incremento di clock, è stata migliorata l’unità interna ora più efficiente.
Questo ci fa subito capire che le vere migliorie sono relative alle unità di esecuzione ed alla miglior parallelizzazione del flusso dati, ovvero ingresso cache migliorato e ALU lasciate meno in idle, fattore che ha costretto AMD ad introdurre gli shader asyncroni per migliorare il lavoro dello shader core.
L’accesso alle varie cache, impatta notevolmente a livello di frame minimi, spesso si assiste a dei crolli inspiegabili, durante i game, e questo è dovuto sopratutto alle ultime fasi di rendering, fattore su cui nVidia con Maxwell ed ora con Pascal ha puntato tantissimo.
Totalmente modificato il rapporto tra le floating point in valori da 8/16/32/64 bit.
Con Polaris, AMD ha introdotto le unità FP16 programmabili come se fossero FP32, e le ha rapportate a livello 1/1, ovvero quando tali applicazioni potevano essere effettuate in FP16, lo spazio sui registri diminuiva e con essi anche il peso in cache e in banda.
Utilizzare le FP32 per calcoli FP16, significa sprecare risorse inutilmente. Se questo è stato l’inizio dell’innovamento, con Vega, AMD ha raddoppiato i bits per clock, ora è possibile utilizzare 2 FP16, sullo stesso registro, per rendere meglio l’idea, ora si può utilizzare una sola ALU, per fare il lavoro di due FP32.
Ora:
2 ALU da 16 bit-registro-cache banda.
1 ALU da 16/32 bit-registro-cache-banda.
Inutile dire che utilizzare una ALU per due operazioni, è nettamente migliore, purtroppo i giochi moderni non sempre possono avvantaggiarsi delle FP16, ma diverse applicazioni le utilizzano, ricordiamo che anche nVidia con Tesla ha puntato al doppio stadio di floating.
La potenza teorica di Vega è elevata, e la inquadriamo quindi così:
12/12,5 tera flops FP32
24/25 tera flops FP16
750 giga flops FP64 (16 cicli FP32 emulano una FP64)
6/6,25 giga flops FP64 Vega pro compute (2 cicli ALU)
50 tera flops FP8 bit.
New Geometry Engine
Uno degli aspetti su cui Vega stravolge tutto è senza dubbio il reparto geometrico, un reparto troppo debole per competere con i chip di fascia enthusiast nVidia, dotato di Polymorph engine e diversi stadi di tassellazione via raster come il back face culling ( Heaven benchmark fa ampio utilizzo di quest’ultimo).
Nonostante Polaris potesse, tramite il nuovo primitive discard, migliorare notevolmente l’eliminazione poligonale inutile, il tallone di achille rimaneva l’elaborazione geometrica, legata ad un solo triangolo per ogni rasterizzatore (4 in totale).
Vi sarete spesso chiesti perchè una Fury non raggiungeva ottimi punteggi su Heaven benchmark? Bene diamo vita al nuovo motore.
Cosa cambia?
Bella domanda, non molto ma è il numero poligonale ad aumentare notevolmente.
Come detto prima, ogni geo engine tramite i 5 stadi del rasterizzatore elaboravano 1 triangolo, ora tale motore può lavorare su ben 2,6 triangoli per clock, questo significa un teorico di quasi 11 poligoni al secondo.
Se Polaris con 4 poligoni a 1250mhz, elaborava 5 giga/tris/s, ora Vega riesce a toccare picchi teorici di oltre 16 g.tris/s, praticamente oltre il triplo rispetto a prima.
Se volessimo fare un rapporto con una GTX 1080, seppur questa mantenga sempre un’efficienza maggiore per semplificazione, noteremmo come i 12 g.tris/s di quest’ultima siano ben superati, malgrado la complessità, sempre legata ai 4 geo engine e non ha motori indipendenti.
Siamo in ogni caso fiduciosi sulla superiotà AMD.
Il nuovo motore non possiamo ancora valutarlo, a livello di numeri finali, ma il lavoro di AMD è stato pensato sopratutto per l’espulsione dei micro triangoli inutili, ovvero quelli che percola della mancata espulsione venivano ricalcolati a vuoto, perdendo prestazioni e saturando i buffer.
Sottolineiamo un’altra miglioria, già vista con Maxwell e Pascal, ovvero la compressione nei vari stadi (8:1 / 4:1 / 2:1)
Le migliorie legate dalla compressione migliorano l’efficienza delle rop’s e sgravano notevolmente cache e banda che può usufruire di latenze migliori e di conseguenza ne risentono anche i frame minimi.
[nextpage title=”AMD Freesync 2″]
AMD Freesync 2 è un altro dei temi caldi, malgrado la prima versione fosse piuttosto valida , ma non impeccabile, anche in base al pannello adottato. Con il nuovo standard si cerca di risolvere, o limitare al massimo, gli artefatti video legati ai fenomeni di stuttering e di tearing e con FreeSync 2 AMD punta principalmente a ridurre la latenza di input e contemporaneamente ad offrire agli utenti display che siano in grado di generare immagini più belle.
La vera novità HDR
Il gioco esegue la mappatura dei toni colore (Tone Mapping) utilizzando il motore grafico che sta renderizzando la scena attraverso la scheda video. In un secondo tempo, quando l’immagine viene passata al monitor, i colori vengono mappati nuovamente per adattarsi alla gamma supportata dal display.
Questo processo genera per sua natura della latenza, che sarà più o meno percepibile agli occhi dell’utente in funzione delle caratteristiche dello schermo. Uno schermo certificato FreeSync 2 verrà riconosciuto dai driver video del proprio sistema, che avrà quindi a disposizione tutte le informazioni tecniche specifiche del display che verranno fornite al game engine, evitando di effettuare una ulteriore mappatura, riducendo il lag dovuta a quest’ultima.
Attraverso un processo plug-and-play, FreeSync 2 si assicurerà che la modalità freesync 2 venga impostata all’avvio di un gioco , garantendo un miglior livello di colore e luminosità attraverso il proprio monitor. Tornando al desktop il colore tornerà quello standard RGB.
FreeSync 2 ha quale requisito minimo obbligatorio anche la tecnologia LFC, Low Frame Compensation, che richiede un refresh rate di almeno 2.5x volte quello minimo (ad esempio dai 30Hz ai 75Hz).
