Introduzione a Xbox One:
Microsoft, e ormai è assodato da tempo, non ha mai voluto
fornire dettagli approfonditi sull’hardware di Xbox One. Annunciata oltre due
anni fa, la nuova console della casa di Redmond ha fatto molto parlare di sé,
per tutta una serie di elementi che, in parte, ne hanno anche pregiudicato il
successo all’avvio. Con la presentazione avvenuta nell’ormai lontano 21 maggio
2013 a cura di Don Mattrick, allora ex capo della divisione Xbox, i gamers si
ritrovarono spiazzati, sbigottiti e inorriditi per le nuove politiche adottate
per Xbox One.
Una console che, nelle prime intenzioni, doveva essere
collegata sempre ad Internet, e quindi al Live, per una complessa gestione dei
DRM (Digital Rights Management sui diritti d’autore), l’impossibilità di
avviare copie usate dei giochi e un check ogni 24 ore per il “controllo” del
contenuto presente all’interno della console, senza di esso tutti i giochi non
si sarebbero potuti avviare. E poi come non dimenticare l’impatto, anch’esso
negativo, sul nodo multimedialità, cosa che doveva trasformare la One in un
sistema di intrattenimento a tutto tondo, con feature dedicate allo streaming,
alla TV e allo sport.
E i giochi?
Poco venne mostrato se non qualche breve filmato di Forza
Motorsport 5 e dei full motion su quello che sarà ricordato come uno dei
peggiori Call of Duty di sempre: quel Ghosts che tanto fece discutere per via
delle differenze tecniche con PS4 lato risoluzione. Una enorme debacle che,
unita anche alle altre, scadenti trasposizioni di Battlefield 4 e Assassin’s Creed:
Black Flag fece nascere il cosiddetto “resolution-gate”, ossia la differenza
nativa in pixels tra Xbox One e PS4, con quest’ultima che poteva vantare sin da
subito del supporto al Full HD (1920 x 1080p).
Subito Xbox One venne etichettata come la console meno
performante, quella dotata di una GPU di bassa fascia (AMD GPU Bonaire della
serie 7000), di una CPU da tablet (Jaguar x86-x64 a 8 core a 1.6 GHz prima
dell’upclock) e “miseri” 8 GB RAM in un unico pool di tipo DDR3, con il
processore grafico che può vantare al suo interno una ESRAM da 32MB, da molti
vista come un ulteriore collo di bottiglia del chipset interno.
Purtroppo la situazione non cambiò e numerosi altri titoli
presentarono differenze tecniche di risoluzione, con il Digital Foundry che analizzava
ogni minuscolo pixel all’insegna delle differenze, valutando “erroneamente”
unicamente la risoluzione e senza andare a confrontare altri parametri
(effetti, filtri ecc.).
Xbox One venne ridicolmente ribattezzata come Xbox 720, per
via dei suoi 720p che stavano ad indicare la risoluzione nativa di alcuni
giochi, rispetto ai sempre presente 1080p di PS4. Mese dopo mese tuttavia, Microsoft prese in mano la
situazione e diede il via alla vera rivoluzione di Xbox One, dapprima
rilasciando nuovi SDK aggiornati che potessero andare incontro alle esigenze
degli sviluppatori, dall’altra andando a mostrare, a poco a poco, l’inedita
struttura hardware della console. Si comincia con l’HotChip 2013 dove vennero
diffusi i primi slide ufficiali passando poi per due sessioni della BUILD 2014
e 2015 della stessa Microsoft, ISCA 2014 e, infine, con un assaggio alla IEEE
dello scorso anno.
Tutti eventi che furono di vitale importanza per capire bene
cosa ci fosse dentro Xbox One, poiché era impossibile immaginare un flop di
questa portata per uno dei dispositivi di punta di Microsoft, considerando da
un lato il successo di Xbox 360, dall’altra gli ingenti investimenti fatti
assieme ad AMD per la realizzazione di un hardware proprietario ed unico,
seppur basato su tecnologia x86-x64, molto simile per concezione
all’architettura presente negli odierni PC. Andiamo adesso ad analizzare il
cuore di Xbox One e dei suoi componenti:
CPU:
La macchina è mossa da una CPU derivata dalla configurazione
Jaguar di AMD, ovvero un processore da 8 core a 1,75 GHz, modificato però dalla
stessa Microsoft in cui ha inserito diverse caratteristiche non presenti nel
processore di base. Una customizzazione che è servita alla casa di Redmond per
apportare anche diverse modifiche sul versante GPU, memoria di sistema e alcuni
elementi che saranno sfruttati nel prossimo futuro (VSP, DME, NoC per il cloud,
DSP e via dicendo).
La GPU deriva dalla famiglia Sea Island, lavora a 853 MHz ma
le similitudini finiscono qui, dato che tutto il processore grafico è stato,
anche in questo caso, pesantemente modificato dagli ingegneri di Redmond. La
GPU può far leva su una veloce ESRAM di 32 MB effettivi (47 totali) in grado di
trasferire dati in lettura e scrittura a oltre 200 GB al secondo. Questa
memoria serve per velocizzare i processi provenienti dalla memoria di sistema,
8 GB DDR3-2133 a 256 bit implementata per poter rendere Xbox One un sistema
multimediale veloce con la possibilità di multitasking vero (eseguire cioè due
applicazioni in contemporanea e lo snap-in istantaneo da e verso più elementi,
senza interruzioni).
Le DDR3 lavorano a bassissima latenza e consumo energetico,
sono idonee per i chunk di pacchetti di piccoli dati ma fanno fatica, causa bus
che non va oltre i 68.3 GB al secondo, con i dati (più grossi) adibiti alla
grafica. Questo “svantaggio” di banda viene così superato sfruttando proprio la
ESRAM di sistema, allocata tra GPU e RAM di sistema (ma non diretta alla CPU),
in cui è possibile far eseguire diverse operazioni, quelle ad accesso rapido,
scelte dagli sviluppatori.
La ESRAM ha rappresentato un “collo di bottiglia” della
console, questo perché non utilizzata a dovere o, nel peggiore dei casi, non
presa in considerazione dai dev anche perché i kit attualmente a disposizione
non ne consentono il giusto monitoraggio (PIX level), obbligando a continui
“trial and error”.
Fortunatamente le cose sono cambiate soprattutto già verso
fine 2014 e le ultime produzioni hanno portato ad un pareggio di prestazioni
tra Xbox One e PS4. In più il potente chip interno adibito allo scaler (che
upsacala immagini native sotto al Full HD ai 1080p) svolge un lavoro
eccezionale e in casi come il recentissimo Metal Gears Solid 5: The Phantom
Pain, che gira a 900p su Xbox One e 1080p su PS4, la qualità dell’immagine è
elevatissima, quasi indistinguibile. Anzi, nei giochi non nativi, l’immagine di
output di Xbox One offre anche texture migliori, più pulite e definite rispetto
alla concorrenza soffrendo però di un aliasing un po’ più marcato (le
scalettature dei bordi e delle linee diagonali).
La CPU di Xbox One, come già detto, è un 8 core Jaguar
x86-x64 (due moduli da 4 core utilizzati contemporaneamente con 2MB 16-vie di
L2 cache) altamente customizzato, in grado di effettuare più operazioni per
ciclo (6) rispetto alla CPU di PS4 (ferma a 2-3), tenendo presente anche la
differenza in GHz, Xbox One ha il clock per core a 1.75Ghz mentre i core di PS4
sono bloccati a 1.6Ghz. La CPU di Xbox One è quindi già più veloce di un buon
10% rispetto alla rivale:
PS4 | 1.84 Tflops totali | CPU: 100 Glops
Xbox One | 1.31 Tflops unicamente lato GPU | CPU: 112 Gflops
Ogni core Jaguar ha 32K di 2-vie L1 I$ e 32K di 8-vie L1 D$.
Entrambi i moduli sono coerenti e questa è una prima modifica fatta da
Microsoft poiché la CPU Jaguar originale era prevista solo con un modulo a 4
core. Le due L2s sono quindi coerenti attraverso i due cluster e il resto del
sistema, inclusa la GPU, ma non direttamente “indirizzabili” dalla CPU
nell’ordine di gruppo di quattro.
Un’altra modifica fatta dagli ingegneri di Microsoft è anche
sul data-paths tra la CPU e il north-bridge della main board, completamente
ridisegnati. Ritroviamo così la coerenza sulla memoria di sistema (ma non sulla
ESRAM). In questo caso anche sia la cache L1 che la cache L2 sono state
modificate e potenziate proprio per via della coerenza tra i due moduli da
quattro core.
La CPU è collegata a quattro moduli 64b di RAM ognuno
configurato da 2GB DDR3-2133 per una banda massima di 68GB/sec. CPU e memoria
principale di sistema offrono una banda coerente di 30 GB/sec.
Infine la CPU, posizionata sul north-bridge del chipset, è
anche coerente con i moduli GPU MMU e I/O MMU, un qualcosa che si aspetta su
qualunque sistema che lavora moltissimo con i GPU compute.
AMD ha ovviamente la sua architettura HSA/HUMA, che
ritroviamo nei chip Kaveri/Kabini e che, slide alla mano, possiamo confermare
anche nel chip di Xbox One, anche se modificato per via di altri fattori
presenti (DSP, ESRAM, audio, Data Move Engine ecc.) e che andremo ad analizzare
più avanti.
“Prima di Xbox One nessuno aveva messo in cantiere una
configurazione Jaguar a doppio cluster quindi bisognava apportare alcuni
interventi per fare in modo che tutto funzionasse a dovere. Ci serviva un alto
livello di coerenza di memoria tra la GPU e la CPU e questo ci ha obbligato a
modificare la concezione di molti dispositivi che si trovano intorno al
processore centrale e a come la CPU gestiva la virtualizzazione”.
“Sul SoC ci sono molti motori paralleli: alcuni sono core
CPU e core DSP core: al calcolo di quindici siamo arrivati in questo modo: otto
dentro la componente audio, quattro move engine, due per la codifica/decodifica
video e uno deputato ad effettuare la composizione/dimensionamento video”.
MEMORIA DI SISTEMA ED ESRAM:
Microsoft ha deciso di implementare nell’hardware di Xbox
One un pool unificato di 8 GB DDR3-2133 a 256 bit, suddivisi in 4 banchi da 2GB
ciascuno (operanti a 64 bit), con la banda massima fissata a 68,3 GB al
secondo. Di questi 8 GB ben 5 sono lasciati per i giochi, mentre i rimanenti 3
sono associati al Sistema Operativo (ricordiamo, un sistema completamente
virtualizzato basato su 3 sub-OS), da suddividere in questo modo:
Uno viene utilizzato dal SO che si occupa dei giochi, uno
per il SO che opera il multitasking e le app e uno, tipo hypervisor (un
non-Hyper-V nello specifico), che fa da “collante” tra i due. Tutto
virtualizzato quindi. Ma si tratta pur sempre di RAM di tipo DDR3, comunemente
utilizzata nei PC. Perché questa scelta? Perché non puntare sulla GDDR5 come ha
fatto Sony per la sua PS4?
Principalmente per due fattori. La GGDR5 è una memoria ad
alta latenza (e scalda anche un bel po’…), ottima per grossi chunk di dati ma
che tende a diventare un problema per la gestione di piccoli pacchetti. La CPU
non va molto d’accordo con le GDDR5 ed è per questo motivo che nei PC non
vengono montate come memoria di sistema: si chiamano appunto GDDR, ossia
Graphic DDR. Microsoft ha puntato molto sulla stabilità di sistema, sulla bassa
latenza, massimizzando ogni ciclo di clock di RAM e CPU ed evitando i fail-over
(perdita di dati o dati elaborati erroneamente e ricalcolati nuovamente): un
problema questo, che si presenta frequentemente in Xbox 360, console poco
equilibrata da questo punto di vista.
Il Pool di memoria principale può essere utilizzato da CPU e
GPU senza limitazioni sfruttando il bus di sistema operante a 30 GB al secondo
(contro i 20 di PS4).
Ovviamente sotto il profilo della velocità le DDR3 impattano
negativamente per le prestazioni grafiche, che non possono reggere il confronto
con le GDDR5 di PS4. E qui entra in gioco proprio la ESRAM, affiancata alle
DDR3 e integrata nella GPU. Questo, effettivamente, serve per avere un boost
delle prestazioni sotto il profilo grafico e ottenere risultati anche maggiori
rispetto alla GDDR5.
ESRAM e suo
funzionamento, punti di forza e punti deboli:
Per capire l’importanza della ESRAM bisogna ricorrere ancora
una volta all’intervista degli architetti di Xbox One, che spiegano benissimo
il suo funzionamento e perché la decisione di inserire uno scratchpad dedicato
alla GPU:
“Pensiamo di avere
realizzato una console molto equilibrata, capace di ottime prestazioni, in
particolare in grado di gestire cose diverse dal mettere in fila tante ALU
(unità aritmetiche e logiche). Ci sono anche un certo numero d'aspetti di
progettazione e requisiti di sistema di cui abbiamo tenuto conto come latenza,
frame-rate e che i giochi non siano interrotti dal lavoro del sistema operativo
e altri elementi che hanno avuto una certa priorità nella stesura delle linee
guida del nostro design”.
“Ci serviva un alto livello di coerenza di memoria tra la
GPU e la CPU e questo ci ha obbligato a modificare la concezione di molti
dispositivi che si trovano intorno al processore centrale e a come la CPU
gestiva la virtualizzazione”.
“Sul SoC ci sono molti motori paralleli: alcuni sono core
CPU e core DSP core: al calcolo di quindici siamo arrivati in questo modo: otto
dentro la componente audio, quattro move engine, due per la codifica/decodifica
video e uno deputato ad effettuare la composizione/dimensionamento video”.
“Per ottenere la migliore combinazione tra prestazioni,
capacità di memoria ed efficienza, la GDDR5 può creare dei problemi. L'ESRAM
invece costa molto poco sotto il profilo del consumo energetico e ha
l'opportunità di dare al sistema una larghezza di banda molto elevata. È
possibile ridurre la larghezza di banda sulla memoria esterna risparmiando un
sacco di corrente e sul costo della materia prima. Nelle scelte progettuali
dell'Xbox One la combinazione tra un'alta capacità di memoria, un consumo
energetico basso e tanta banda passante era un elemento chiave e per ottenerlo
non c'erano molti di modi di farlo se non tramite l'uso della ESRAM”.
“L'ESRAM dispone di quattro controller di memoria ciascuno
da 256-bit per un totale di 1024 bit in entrambe le direzioni. 1024 bit in
scrittura danno un massimo di 109GB/s che sommati allo stesso valore simultaneo
in lettura arriva a un identico picco di 109GB/s. Ma, come abbiamo detto,
usando applicazioni reali questo valore va combinato attestandosi circa a
140-150GB/s e non è l'unico elemento da tenere in considerazione ovvero il limite
di banda della memoria esterna, la DDR 3".
"Quanto può corrispondere infatti la
potenza della banda passante della memoria esterna se si effettua lo stesso
genere di calcolo? Con la DDR3 si prende il numero di bit dell'interfaccia, si
moltiplica per la velocità e si ottiene il valore di 68GB/s: aggiungendola al
valore di 140-150GB/s ottenuto calcolando la banda teorica messa a disposizione
dall'ESRAM si arriva a 218GB/s. Tuttavia è difficile riuscire a mantenere
valori simili con un'interfaccia di memoria esterna per lunghi periodi di tempo
e quindi ci si attesta a circa un 70-80% dell'efficienza possibile che porta la
banda passante della DDR3 a circa 50-55GB/s”.
Ma quali sono quindi i reali vantaggi della ESRAM associata
a GPU e memoria principale di sistema? Grazie a questa particolare architettura
gli sviluppatori godono di massima libertà e possono operare adottando diverse
configurazioni (non solo una come su PS4). Come detto poco fa l’accesso della
GPU alla ESRAM può essere utilizzata in una moltitudine di casi, dato che offre
una banda passante di output velocissima: soprattutto quando si
hanno contenuti di grosse dimensioni, come ad esempio 5GB di dati che potrebbero essere indirizzati per un rendering qualsiasi; ogni elemento che passa alla ESRAM,
che ha una larghezza di banda dell'ordine di 2-10
volte più veloce della DDR3, è un grosso vantaggio per l’intero sistema.
In questo modo si utilizza la ESRAM, inserire cioè
all’interno di essa gli elementi più sensibili e che richiedono un continuo
accesso alla lettura dei dati presenti, come le “shadow map”, e lasciare gli
oggetti che fanno un minor utilizzo delle risorse all’interno della memoria di
sistema. Prendiamo ad esempio un gioco di corse dove l’oggetto meno dinamico è
il cielo: questo elemento può risiedere senza troppi problemi nella DDR3 di
Xbox One, con la ESRAM invece utilizzata per elementi dinamici come la
visualizzazione delle vetture su pista. Questo funziona praticamente
per qualsiasi risorsa D3D, dal buffer alle texture di ogni tipo dato che, in questo caso, non c'è
accesso diretto alla CPU, perché la CPU
non può vedere il contenuto della ESRAM, ma bisogna passare sempre attraverso la GPU
per arrivare ad essa, una imposizione voluta da Microsoft questa.
Come sfruttare quindi a dovere la ESRAM e la RAM di sistema?
Semplice, conoscere quali target vanno diretti alla ESRAM e
quali alla memoria principale, passando sempre su quest’ultima poiché la copia sulla DDR3 è veramente veloce, e
non necessita di un ulteriore passaggio sulla CPU o sulla GPU dato
che, per questi compiti, sono già adibiti i 4 Data Move
Engines. Questo è il metodo più facile e veloce per avere un output a 1080p, e questo è il procedimento per raggiungere i 60 fotogrammi al secondo. Tutto questo
però solo se si utilizzano nuovi engine e non vecchi tool (avete detto Fox
Engine o quello di Call of Duty?).
Questo è un enorme vantaggio a patto di sfruttare anche i 4
(iirc) DME, senza utilizzare banda e cicli di CPU o GPU, combinando quindi
l’altissima banda passante di ESRAM e DDR3.
Se ci pensate PS4 possiede solo due canali diretti verso la
memoria GDDR5 (CPU e GPU) che può scrivere simultaneamente ma entrambi devono essere prima messi in cache. Ed è l’unica soluzione
possibile sulla PS4 mentre Xbox One ha
molte più opzioni (CPU, GPU DD3 a DD3, GPU a ESRAM, Move Engine
a ESRAM, Move
Engine a DDR3) con la
possibilità che in alcuni passaggi si può considerare la lettura / scrittura / copia/ simultanea.
Ribadiamo però che per trarre il massimo beneficio dalle
configurazioni possibili su Xbox One bisogna utilizzare nuovi engine pensati
per i vari passaggi, altrimenti la ESRAM o diventa un collo di bottiglia o non
sfruttata a dovere, soprattutto per via della mancanza del PIX nei devkit
(dovrebbe essere implementato a breve, anche per via dell’arrivo delle DirectX
12).
Di converso PS4 beneficia del veloce pool di GDDR5 che può
già sfruttare l’intera banda passante, ma ciò significa anche che c’è meno
spazio per l’ottimizzazione. Il risultato è quindi un beneficio immediato per la PS4, e un piccolo handicap su Xbox One, allo stato
attuale. Aspettatevi grandi
guadagni nei nuovi motori 3D e
prestazioni al di sotto delle aspettative in vecchi engine che
non utilizzano il concetto
di lettura / scrittura / spostamento della console di Microsoft, nello specifico RAM di
sistema più ESRAM più Data Move Engine.
Più o meno è lo scenario attuale di diversi
titoli multiformato che girano meglio su PS4 che su Xbox
One, ma quando abbiamo nuovi tool come il CryEngine o proprietari come quello
di Turn10, ecco che titoli come Ryse: Son of Rome, la serie Forza o Halo 5 diventano
il fiore all’occhiello della console.
E non dimentichiamoci delle ottimizzazioni
che porteranno le DirectX 12, con un incremento delle prestazioni della console
anche del 30%, come confermato da più parti (chiamatela ottimizzazione,
chiamatela maggior uso intensivo dell’hardware, chiamatelo boost, chiamatela
fonte segreta…), fatto sta che Xbox One non è mai stata una console da 1,3
TFLOPS di potenza ed è una hardware pensato per il futuro, che farà da
apripista a molteplici soluzioni hardware dei principali produttori hardware:
l’unico grosso errore di Microsoft è stato quello di aver lanciato la console
troppo presto, con un chipset difficile da comprendere, mancanza di SDK
completi e supportata da engine vecchi di anni.
L’importanza della ESRAM viene anche
indicata da Wolfgang Engel, fondatore della Confetti FX, importantissima software house specializzata
nella creazione di potenti tool utilizzati dalle più rinomate case.
Per Engel sarà proprio lo sfruttamento ad hoc della ESRAM a
decretare il vantaggio di Xbox One sulla concorrenza, anche perché,
ricordiamolo, questo piccolo pool di memoria sarà sfruttato al massimo
solamente tramite l’utilizzo delle tiled resource che consentirà di “salvare” 6
GB di Ram all’interno proprio di 32 MB della ESRAM.
Engel ha dichiarato infatti: "L’ESRAM è una memoria
molto veloce. In generale la sfida più grande che gli sviluppatori stanno
affrontando sono proprio nei modelli di accesso della memoria, così, mentre
abbiamo un sacco di potenza di calcolo, il costo di accesso alla memoria sta
aumentando notevolmente negli ultimi dieci anni, rispetto al costo delle
istruzioni aritmetiche.
"Finché siete nei “registri” non hai problemi ma non appena hai bisogno di
accedere alla memoria, diventa più lento. La sfida è di accedere alla memoria
in modo più efficiente. Perciò i modelli di accesso alla memoria sono le
strategie di ottimizzazione più importanti. Quindi non si tratta di cicli di
conteggio, ma si tratta di pensare come possiamo sfruttare e ottimizzare un
algoritmo in modo che possiamo accedere alla memoria nel modo più efficiente.
La ESRAM è proprio parte di questo.
"Per esempio, con uno shader è possibile accedere alla cache di memoria (o
nel gruppo di thread della memoria condivisa) in modo da poter rielaborare
l'algoritmo in modo che utilizzi questa memoria a livello superiore, con un
enorme e sostanziali incremento di velocità. Con la Xbox One, l'introduzione di
ESRAM propone un'idea simile.
"La chiamate più pesanti e importanti possono essere salvate nella ESRAM.
Quando non hai bisogno di banda di memoria velocissima, si utilizza la memoria
di sistema regolare. È necessario però pianificare in anticipo, devi pensare
che intenzione hai di utilizzare la memoria, nel modo più ottimale. Così la
ESRAM ti offre un vantaggio a patto che pianifichi tutto dall’inizio. Per uno
dei nostri giochi che stiamo realizzando, abbiamo utilizzato la ESRAM creando
un foglio in excel, che mostra come ci accingiamo a utilizzare la ESRAM
attraverso gli stadi della pipeline di rendering. Questo ci ha aiutato a
utilizzare i miglioramenti di velocità che offre la ESRAM senza impattare
sull’intero sistema e sfruttando al massimo ogni singola risorsa".
Alle parole di Engel
fa da eco anche Crytek, che ha impartito una lezione piuttosto interessante a tutti gli sviluppatori
che intendano sfruttare nel migliore dei modi questo vantaggio di Xbox One.
Tutto un discorso legato alla ottimizzazione e alla
pianificazione, proprio perché l’hardware della nuova console di Microsoft è
una potente “bestia” da saper domare. Xbox One fa della ottimizzazione e del
bilanciamento il suo cavallo di battaglia, ma se utilizzata in maniera non
consona, puntando cioè unicamente alla RAW Power, allora in questo modo escono
fuori i limiti della console, limiti non hardware bensì di utilizzo corretto
del software. Ancora una volta, solamente con i kit basati su PIX, tiled
Resource e DX12 vedremo realmente le capacità tecniche di One.
Per facilitarvi le cose, ecco un esempio tra
la banda e le memorie utilizzate da Xbox One e PS4 (Xbox One a sinistra, PS4 a
destra):
Nel dettaglio abbiamo quindi una configurazione del tipo:
Come si può vedere PS4 ha una struttura semplificata ma, se paragonata a
quella di One, meno performante, numeri alla mano:
-PS4 = 8 GB GDDR5 176 GB/s
Bandwidth (picco teorico)
-Xbox One = 8 GB DDR3 68 GB/s Bandwidth (picco teorico) + 47 MB ESRAM, 208 GB/s
Bandwidth (picco teorico).
Sul versante del Bus di sistema abbiamo invece questa situazione:
-PS4 = 3 Bus Pipelines. Onion,
Garlic e Super Onion. Questi consentono la coerenza HSA e Huma tra CPU e
GPU in connessione diretta con la GDDR5 RAM.
-Xbox One = 8 Bus Pipelines, 2x256 Bit Bus con 4 lanes ognuno (con la DDR3
suddivisa in 4 lane da 64 bit ciascuno e la ESRAM in 4 lane da 256 bit
ciascuno). Una pipeline collegata alla ESRAM e una collegata alla DDR3 RAM.
Sono presenti Bus Pipelines addizionali verso la CPU, verso il chip Audio,
Video e il controller di memoria e di Kinect.
Va da sé che la situazione sulla One è più complicata visti i numerosi bus
e pipeline presenti nel chipset, tuttavia
i due bus principali
sono estremamente robusti: 2x4 lane da 256 bit sono in
grado di spostare una quantità
enorme di dati, permettendo
alla GPU /
CPU la ripartizione del lavoro agli altri sistemi
come suono e memoria, in
corrispondenza anche dei Data Move Engine (altra presenza “scomoda” del chipset
non ancora sfruttata a dovere ma che permetterà un ulteriore boost di banda).
La soluzione migliore per Xbox One è quella di utilizzare
RAM di sistema ed ESRAM come fosse un unico pool, senza distinzione.
-ESRAM e DDR3 non devono essere visti come elementi separati
bensì come un unico sistema. Questo perché, come vi abbiamo mostrato, sono
presenti ben 8 controller per la memoria, 4 per la RAM DDR3 e 4 per la ESRAM
che sono collegati tra loro e quindi vi è l’accesso simultaneo a RAM ed ESRAM.
La ESRAM è dunque completamente integrata nelle tabelle di paging, per questo
motivo è come se ci fosse un unico pool di memoria.
-La banda passante
teorica della RAM DDR3 (8GB) è di 68GB/s che, ma un valore di picco reale può
attestarsi sui 50-55GB/s.
-La banda passante
teorica della ESRAM è di 109GB/s in lettura e 109GB/s in scrittura,
simultaneamente, per questo la sua banda teorica è di circa 204GB/s, con un
picco reale di 140-150GB/s.
Considerando l’uso combinato di RAM ed Xbox One è in grado
di offrire una banda reale più alta dei 200GB/s (50-55GB/s + 140-150GB/s).
Microsoft ha evidenziato performance reali registrando picchi reali di 204GB/s.
GPU E STRUTTURA INTERNA, CU, ROPS,
ALU, BANDA:
La GPU di Xbox One è senz’altro la parte più interessante
dell’intero chip poiché presenta soluzioni e scelte molto particolari, a tratti
avanguardiste e di sicuro fascino. Difficile dire se la strada adottata sia
quella giusta, ma visto il trend dei principali produttori sembrerebbe essere
proprio di sì.
Per paragonare la GPU di Xbox One a qualcosa di concreto mi
piace riportare il seguente aneddoto: prendete una strada a senso unico, con un
semaforo, ove solo una macchina per volta vi può transitare, con quella
seguente che deve attendere prima il passaggio della vettura in testa prima che
la successiva possa partire. La macchina passa e gira, scatta il semaforo verde
e la seconda vettura può passare e così via.
La strada è troppa leggera per sopportare il peso di più due
vetture per volta, da qui l’esigenza di inserire un semaforo. Questo, in ambito
informatico, si può definire come collo di bottiglia (bottleneck). Ora pensate ad una strada sempre a senso unico, ma dotata di
due corsie ove possono transitare due macchine per volta poiché l’asfalto più
resistente.
In informatica questo processo viene definito Dual Lane (o
dual pipeline), ed è la capacità di eseguire due operazioni in simultanea in un
unico task, senza che il primo processa termini l’operazione per far partire la
successiva. Ciò è reso possibile grazie alla presenza di due moduli (GFx
core) che in un unico passaggio riescono ad eseguire due operazioni per volta.
Xbox One possiede proprio due GFx Core (Graphic Command
Processor) e due CP Core (Compute Command Proccessor) adiacenti alla GPU, e
questo permette il famigerato Dual Lane, cosa che invece la rivale PS4 non può
effettuare, vista la presenza di un unico canale CCP.
 |
CP Singolo PS4
|
 |
CP e GFx doppi in
Xbox One (guardate in alto a sinistra dello slide)
|
Qualcuno ha iniziato, finalmente, a notare la presenza dei
doppi core della GPU di Xbox One e ci si sta interrogando sulle funzioni che
possa avere questa doppia pipeline grafica: verrà sfruttata per il rendering? Verrà sfruttata per altri task? Ci si
interroga quindi quale sia il funzionamento corretto della GPU di Xbox One,
quali ruoli può gestire al meglio, se può lavorare in parallelo con due task
simultanei, sincroni o asincroni e via discorrendo.
Ovviamente Microsoft ha solo accennato alla cosa senza
entrare troppo nel dettaglio, ma quello che non viene nascosto è proprio la
presenza di due GFx e due CP all’interno della GPU, come sottolineato dagli
architetti di Xbox One nella
famosa intervista al Digital Foundry:
“Il nostro chip grafico è basato sulla famiglia di chip
denominata Sea Island, ma in realtà abbiamo effettuato alcune modifiche in
molti settori dell’architettura del core. La variante più evidente riguarda il
numero di unità di calcolo inserite sul die ed è stato un aspetto su cui ci
siamo concentrati sin dall’inizio. Come a dire, contiamo il numero di CU e i
Gigaflop e dichiariamo il vincitore in base a questo? È più o meno la stessa
situazione che si pone al momento di acquistare una scheda video. Si
controllano effettivamente solo le specifiche o si guardano anche i benchmark?”
“Xbox One supporta due pipeline di rendering simultaneo: le
due catene di rendering possono consentire il rendering dei contenuti del gioco
ad alta priorità mentre contemporaneamente i task di sistema sono a bassa
priorità. Lo schedulatore hardware della GPU è stato progettato per
massimizzare la banda passante e riempire automaticamente i buchi nell’elaborazione
ad alta priorità. Questo può consentire al sistema di rendering di fare uso
delle ROP mentre il gioco effettua operazioni sincrone sulle unità di calcolo”.
Ecco qui il Dual Lane, presente in Xbox One, questo è certo,
ma ancora non sfruttato a dovere a causa di problemi realativi all’overhead
della CPU castrata nel multithreading –e quindi nella capacità di comunicare
anche con la GPU- per via delle DirectX 11 che non permettono, seppur
ottimizzate per la One, di lavorare molto sul metallo. Con
l’avvento attuale delle DX12, Xbox One permetterà un flusso continuo di dati senza
problemi, e ciò lo si può vedere già dalle ultime produzioni e dai giochi in arrivo (Gears 4, Forza Horizon 3, DX12 nativi).
Come potete vedere nessuna “secret sauce”, nessun miracolo,
ma più semplicemente il vero sfruttamento dell’hardware, capace e potente, di
One. Il problema è che al momento la console viene sfruttata ancora poco (ESRAM
in primis, anche se i risultati si stanno vedendo con le ultime produzioni) e i
tool ancora incompleti (sapete bene che i più recenti sono di giugno ma sono
tutto fuorché definitivi…).
A livello teorico quindi Xbox One potrebbe raggiungere i 2,6
TFLOPS grazie al doppio task di rendering, sommando non solo il dual lane ma
anche tutti i processori di “scarico” integrati nella GPU come i Data Move Engine,
DSP Tensilica, audio chip SHAPE e per gli altri micro controllers integrati
(molto dei quali programmabili, altri dal funzionamento fisso come le swizzle
copy, code/decode ecc.).
Sotto uno slide che fa ben capire come la GPU della One
possa essere sgravata da diversi compiti GPGPU grazie proprio alla presenza di
coprocessori di bilanciamento (cosa che PS4 non possiede, se non semplici DSP
per l’audio):
“Pensiamo di avere realizzato una console molto equilibrata,
capace di ottime prestazioni, in particolare in grado di gestire cose diverse
dal mettere in fila tante ALU (unità aritmetiche e logiche). Ci sono anche un
certo numero d’aspetti di progettazione e requisiti di sistema di cui abbiamo
tenuto conto come latenza, frame-rate e che i giochi non siano interrotti dal
lavoro del sistema operativo e altri elementi che hanno avuto una certa
priorità nella stesura delle linee guida del nostro design”.
“Ci serviva un alto livello di coerenza di memoria tra la
GPU e la CPU e questo ci ha obbligato a modificare la concezione di molti
dispositivi che si trovano intorno al processore centrale e a come la CPU
gestiva la virtualizzazione”.
“Sul SoC ci sono molti motori paralleli: alcuni sono core
CPU e core DSP core: al calcolo di quindici siamo arrivati in questo modo: otto
dentro la componente audio, quattro move engine, due per la codifica/decodifica
video e uno deputato ad effettuare la composizione/dimensionamento video”.
Sicuramente un “disegno” hardware tanto complesso quanto
efficiente, il segreto è solo utilizzarlo a dovere, appena saranno disponibili,
ovviamente, tool in grado di mostrare agli sviluppatori tutti i “lati” della
console.
One è l’unico hardware ad implementare un unico processore
grafico che possiede due Compute Command Proccessor e due Graphic Command
Processor, con ESRAM (scratchpad) integrata nella GPU.
Ma perché il chip grafico di Xbox One presenta un minor
numero di CU, ALU, ROPs e stream processor rispetto a PS4? Una spiegazione ce
la offre il team Xbox:
Su GPU, GPGPU e CPU:
“L'altra cosa che voglio sottolineare è che su Internet
leggo di gente che somma il numero di ALU e CPU aggiungendo a queste alla GPU
dicendo: "Ah, sai, l'overclock sulla CPU di Microsoft non farà molta
differenza". Ma non sanno che un certo numero di carichi di lavoro non
vengono eseguiti in modo efficiente tramite GPGPU. È necessario disporre di
carichi di lavoro paralleli per lavorare in modo efficiente sulla GPU. Sulla
CPU è possibile eseguire carichi di lavoro paralleli di istruzioni diverse
dalla grafica, ma si finiscono per sprecare enormi quantità di risorse. Abbiamo
guardato i nostri titoli di lancio e abbiamo visto che sono effettivamente
sottodimensionati per le prestazioni che il sistema poteva ottenere. Una volta
arrivati i primi prototipi ci siamo resi conto che avevamo la possibilità di
alzare il clock dell'intero sistema e questo è stato un grande vantaggio per i
carichi di lavoro che non possono essere eseguiti in parallelo”.
Sugli ACE:
“Il numero di code di calcolo asincrone delle ACE non
condizionano l'ammontare effettivo della banda o il numero di calcoli in
virgola mobile FLOP o qualsiasi altra performance della GPU. Piuttosto,
condiziona il numero di "contesti" simultanei che lo schedulatore
hardware della GPU può usare in ogni momento. Si possono considerare come dei
thread software gestiti dalla CPU: sono processi logici che condividono
l'hardware con la GPU. Averne in gran numero non significa automaticamente
migliorare la potenza del sistema, anzi, proprio come il numero di programmi
attivi simultaneamente su una CPU, troppi task in simultanea possono peggiorare
la performance complessiva. Noi crediamo che sedici code gestite da due ACE
siano più che sufficienti allo scopo”.
Sui ROPs:
“Si, nel flusso delle immagini, alcune parti dei frame possono
essere legate al numero di ROP (Render Output Units), tuttavia nella nostra
analisi abbiamo trovato che le porzioni dei frame presenti nei giochi
dipendenti dalle ROP e non collegate alla banda sono piuttosto ridotte. Questo
è uno dei motivi per cui l'incremento di un semplice 6.6% nella velocità di
clock è stata una scelta vincente rispetto all'aggiunta di unità di calcolo
addizionali perché ha alzato le prestazioni di tutte le componenti interne
della pipeline quali velocità d'esecuzione di vertex, triangoli, esecuzione di
chiamate di draw e così via. In questo modo, un sistema già definito in ogni
sua parte cresce in modo bilanciato senza essere condizionato da colli di
bottiglia che possono essere presenti in ogni parte del sistema. Alcuni frame possono
dipendere dal fill rate, altri dalle ALU, altri dalla memoria. I colli di
bottiglia possono presentarsi in qualsiasi singola chiamata”.
Sui DME:
“Gli elementi che aiutano la CPU a svolgere il suo lavoro
sono molti, ma pare che i Data Move Engine siano quelli più efficienti nello
scaricarlo di oneri computazionali particolarmente gravosi. In questo senso il
funzionamento dei Data Move Engine merita di essere spiegato: immaginate di
aver renderizzato l'informazione di un depth buffer immagazzinandola nella
ESRAM e poi passate ad un secondo depth buffer. Ora immaginate di aver bisogno
di caricare le informazioni relative a una texture nella memoria DDR per un uso
a breve termine. I Data Move Engine permettono di muovere tutte queste
informazioni tra i pool di memoria per liberare la GPU da questo compito
dedicando quel tempo risparmiato all'elaborazione di un altro render piuttosto
che allo spostamento di dati avanti e indietro attraverso la memoria”.
Sugli ALU e la memoria condivisa virtuale:
“La nostra filosofia è che le ALU sono molto, molto
importanti per il futuro, ma come ho detto abbiamo preso una strada diversa: su
Xbox One i carichi di lavoro di Kinect sono in esecuzione sulla GPU e calcolati
in modo asincrono per tutti i nostri carichi di lavoro GPGPU. Abbiamo quindi
tutti i requisiti per gestire il calcolo tridimensionale in modo efficiente in
termini di memoria coerente. Anche il sistema operativo è importante nella
gestione dei carichi di lavoro e questo ci riporta alle fasi iniziali della
progettazione. Il gestore della memoria per il gioco è stato completamente
riscritto: lo abbiamo fatto per garantire che l'indirizzamento virtuale per CPU
e GPU fosse lo stesso. Mantenere gli indirizzi virtuali permette la
condivisione dei puntatori di memoria per GPU e CPU. Ad esempio, uno spazio
condiviso di indirizzi virtuali insieme all'uso di memoria coerente, permette
di eliminare l'uso delle chiamate di paging e fare in modo che la GPU passi
attraverso le strutture di dati della CPU come ad esempio le liste collegate”.
Sulle CU:
“Ogni console in versione developer dispone effettivamente
di 14 unità di calcolo integrate sul silicio con scopi di ridondanza in fase di
produzione. Noi abbiamo avuto la possibilità di sperimentare quale sarebbe
stato l'effettivo beneficio prestazionale di usarne 14 invece di 12 rispetto invece
a un normale overclock. I risultati non ci hanno sorpreso: abbiamo fatto girare
un sacco di test con molti dei titoli di lancio e abbiamo visto che le console
impregnate a far girare le demo non beneficiavano delle due unità di calcolo
addizionali attivate quanto invece l'overclock del processore che si attestava
a un 6.6% di prestazioni in più.
“Tutte le Xbox One in versione dev kit attualmente hanno 14
unità di calcolo sul silicio e ci siamo accorti con i titoli di lancio che con
quelle due unità in più attivate il guadagno non era efficace quanto l'upgrade
alla velocità del processore Se si fanno le proporzioni in relazione alla
presunta potenza computazionale di due unità di calcolo extra, il conto
parrebbe non tornare ma, come confermato dalla nostra recente analisi, per non
parlare dei benchmark paralleli su PC, l'aumento o diminuzione delle CU non
scala verso l'alto o verso il basso in modo lineare: occorre tenere conto della
legge dei rendimenti decrescenti”.
Si parla sempre di parallelismo, motori paralleli, dual
rendering e di come ogni unità, sia fisica che logica, sia in “comunicazione”
l’una con l’altra. Tutto è stato studiato affinché la console possa reggere
calcoli asincroni e simultanei, grazie allo “sdoppiamento” di diversi elementi che,
come raffigurato nel nuovo slide, danno 2 Graphic Command Processor, 2 Compute
Command Processor, 2 Geometry Primitive Engine, 2 cluster da 6 CU, 4 Render
Backend, 4 DME, 2 cluster da 4 core della CPU, una interessante cache di
secondo livello per le Texture, 4 controller di memoria a 256 bit della ESRAM
(per una banda totale da 1024bit), 4 blocchi da 2GB ciascuno della RAM DDR3,
tutti blocchi separati, indipendenti, ma operanti simultaneamente, senza
escludere nulla.
Proprio per questo motivo il lavoro delle 12 CU contenute
nella GPU della One è come se operassero al doppio delle loro possibilità (dual
lane), proprio perché i due blocchi di 6 CU è indipendente e, al tempo stesso,
interfacciato in parallelo alle due unità GCP e CCP. Inutile dire che lo stesso discorso non riguarda PS4, dato
che la GPU della console di Sony prevede un solo blocco CCP.
Se vogliamo fare un paragone un po’ forzato, è come se la
configurazione della GPU di Xbox One sia in SLI, anche se il blocco fisico
della GPU è soltanto uno, ma, come lasciano presupporre le slide, con 2 unità
logiche (similmente a quanto accade con le CPU attuali). Inoltre questo farebbe capire il motivo per cui i primi
dev-kit di One fossero basati su due schede AMD 7700 in parallelo.
Sempre dalla nuova slide e dalle dichiarazioni di Sell poi,
emergono altri dati prima sconosciuti:
-2 processi GPU indipendenti.
-8 processori indipendenti che condividono la MMU GPU. Questi
motori supportano applicazioni e servizi di sistema ed aumentano l’elaborazione
di calcolo di GPU e CPU.
-4 di questi processori forniscono servizi di copia, format
conversion, compressione, decompressione. I motori di codifica e decodifica
video supportano più flussi e una vasta gamma di formati di motori di input e
output audio-video.
-L’output audio/video include anche il ridimensionamento e
la composizione di tre immagini distinte (display planes), salvando i risultati
nella memoria principale.
-Ogni Command Processor supporta 16 flussi di lavoro, per un
totale di 64 flussi di lavoro (16x4 tra i 2 CCP e i 2 GCP)
-I due primitive engines, con i due blocchi per il calcolo
geometrico, le 12 unità di elaborazione (CU), i quattro render back-end, i motori
di profondità e di colore supportano, tutti presenti all’interno del core
grafico (GPU), supportano due contesti grafici indipendenti.
-Memoria principale unificata, ma non uniforme
-Gestione della memoria virtuale universale host-guest
Queste nuove slide confermano quindi
tanto i rumor del passato quanto la bontà del
progetto Xbox One, che ruota attorno, nemmeno a caso, alle DirectX 12, le API
pensate appositamente per trarre vantaggio dai processi in parallelo,
multithreading e riduzione dell’overhead di CPU e GPU, oltre
all’implementazione di svariati asset quali Tiled Resources, migliore gestione
di DME ed ESRAM.
Se un sistema non è bilanciato e ha colli di bottiglia, può
avere tutte le CU, ALUs, ROPs che vuole ma queste non funzioneranno mai al
massimo della loro possibilità, rappresentando anzi anche un eventuale problema
sui tasks simultanei.
Sappiamo da tempo che l’intero hardware di
Xbox One è unhardware bilanciato che tende a sfruttare e massimizzare l’intero ciclo di risorse senza
dead-cycle, bubble o errori di sistema (che obbligano il chipset a rielaborare
i tasks).
La GPU vista da
vicino, analizziamo le CU e le ALU di sistema:
“Il nostro chip grafico è basato sulla famiglia di chip
denominata Sea Island, ma in realtà abbiamo effettuato alcune modifiche in
molti settori dell'architettura del core. La variante più evidente riguarda il
numero di unità di calcolo inserite sul die ed è stato un aspetto su cui ci
siamo concentrati sin dall'inizio. Come a dire, contiamo il numero di CU e i
Gigaflop e dichiariamo il vincitore in base a questo? È più o meno la stessa
situazione che si pone al momento di acquistare una scheda video. Si
controllano effettivamente solo le specifiche o si guardano anche i
benchmark?”, sono le parole degli ingegneri di Xbox One.
“Xbox One supporta due pipeline di rendering simultaneo: le
due catene di rendering possono consentire il rendering dei contenuti del gioco
ad alta priorità mentre contemporaneamente i task di sistema sono a bassa
priorità. Lo schedulatore hardware della GPU è stato progettato per
massimizzare la banda passante e riempire automaticamente i buchi
nell'elaborazione ad alta priorità. Questo può consentire al sistema di
rendering di fare uso delle ROP mentre il gioco effettua operazioni sincrone
sulle unità di calcolo”.
Async compute, parallelismo, multithreading, task
indipendenti, spazi virtuali, tutti elementi integrati dentro Xbox One e che
spiegano l’importanza dell’avvento delle DirectX 12 anche per One:
Le slide ufficiali di Xbox One e relativi SDK ci offrono una
ricca panoramica sulla composizione della GPU integrata, e balza subito
all’occhio una prima, interessantissima novità. Prendendo le GCN adottate nei
chip grafici di AMD, possiamo già fare una prima differenziazione:
-GCN 1.0 e GCN 1.1 usano un array di CU, che equivalgono a
gruppi di CU per L1 condivisa (CU=Comput Unit, GCN=Graphic Core Next di AMD).
-GCN 2.0 utilizza le CU come gruppi di SIMD per L1 non condivisa.
-Gli Shader Core (SC, che equivalgono alle CU) di Xbox One sono basati su
tecnologia GCN 2.0, dove gli SC utilizzano un gruppo di SIMD per L1, come
evidenziato in figura:
La base di partenza è dunque un GCN 2.0 per Xbox One, dove i
SIMD sono racchiusi all’interno di un singolo core CU/SC, e il CU nel GCN 2.0 è
praticamente composto da un array indipendente di CU. I SIMD possono gestire
tot operazioni, e per ops (operation per second) possono avere un “n” numero di
ALU.
Partendo dal concetto base di GCN 2.0, Microsoft ha
provveduto a realizzare e customizzare i singoli blocchi, ma i SIMD totali per
CU, gli ops totali per SIMD, il numero totale di ops per ALU non sono “fissi”
sulla parte GFx di Xbox One, possono eseguire più thread per ciclo in modo
dinamico e indipendente (i CU non sono disposti a blocchi o gruppi, bensì sono
separati, individuali).
Più nel dettaglio ritroviamo una configurazione del tipo:
Riassumendo Xbox One, ha il modulo Gfx costituito da 12
Tiles Shader Core, con:
1 Shader Core = 16KB L1 + 64KB LSM/LDS (128 ALU per CU). I blocchi di 4 SIMD
possiedono 4 sub-unità logiche, le Execution Unit (EXU) note come VSP, ossia
Vector Scalar Processor (si badi bene che non vengono definiti come stream
processor proprio per la loro natura volatile, virtualizzabili e quindi
configurabili). Abbiamo
quindi 16 VSP per singolo SC (uno SC è costituito da 4 VSP x 4 SIMD) in modo tale che ogni
Compute Unit (se programmabile) può effettuare 4 x operazioni a 32 bit, 12 x 4
= 48, 48 x 16 = 768 (il dato torna con le operazioni per ciclo che può gestire
Xbox One). Un risultato interessante, con il valore 768 che Microsoft non definisce
mai come Stream Processors ma come semplice “operazioni per ciclo”.
L’intera GPU è più di 256bit (notare i 5 canali a 256 bit ciascuno…),
e stiamo parlando del solo blocco GFx senza contare i vari SPP e SHAPE. Da
notare poi come la memoria di tipo L2 e il controller di memoria sono collegati
ad “altri client”, ossia 2 Command CP.
Xbox One utilizza il GCN 2.0 (ibrido) più numerose ottimizzazioni e
aggiunte di rilievo, con lo Shader Core che ha dedicati GFX e compute
processing ed è per questo motivo che ogni SC ha 64 KB, non condivisa, mentre sui
chipset Sea Island i 32KB sono impiegati per il controllo di 64 ALU per CU
(come su PS4).
PS4 utilizza anch’essa chipset Sea island con diverse ottimizzazioni, ma basate
su GCN 1/1.1
-PS4=Sea Island
-Sea island 32KB = 64 ALU per CU
-Xbox One L1 16kB, ha 64KB LDS per singolo CU, 128 ALU per CU
Se preferite, se vogliamo immaginare una struttura GCN 1.0
su Xbox One, possiamo anche dire che per SC possono essere eseguiti 64 ops con
2 ALU per ops, come se fosse un GCN 1.0 ma costituito da 24 CU (a livello teorico).
DATA MOVE ENGINES:
Xbox One è una console pensata per il futuro, e questo
futuro si chiama cloud computing, ossia la capacità della console di
“scaricare” alcune operazioni che vengono invece gestite dai server come
l’intelligenza artificiale, la fisica calcolata in tempo reale e alcuni target
rendering (come l’illuminazione di alcuni ambienti ecc.).
La demo di Crackdown 3 alla Gamescom 2015 ha mostrato proprio le potenzialità del cloud
applicato. Per elaborare in tempo reale la fisica, i crolli e le esplosioni del
gioco in locale sarebbero servite ben 20 e passa Xbox One. Invece così, basta
tenere la console collegata al Live per godersi tutta la rivoluzione del cloud
computing e di Cloudgine. Ma per processare i dati provenienti dalla rete
Azure, cosa ha al suo interno Xbox One che possa agevolarne il lavoro?
Abbiamo innanzitutto l’on-chip network collegato (NoC)
direttamente al northbridge del SoC che può comunicare, grazie anche alla
presenza dei 4 Data Move Engines, direttamente con la CPU e la GPU, senza dover
passare per canali tradizionali (come avviene per i comuni PC, ossia via PCI
Express o southbridge) riducendo al massimo problemi legati alla banda e alla
latenza.
Una configurazione che rimanda a quelle classiche dei “super
computer” utilizzati nei grossi data center e che devono smistare una
grandissima mole di dati attraverso la rete.
Studiando il chipset di Xbox One possiamo constatare come la
console sia stata studiata per sfruttare il cloud computing, a differenza di
PS4 che, sì, potrà sfruttare una simil caratteristica, ma non nativamente a
causa della presenza di un solo DMA e non di special purpose processor (appunto,
come sono i Data Move Engines) come ha la “rivale”.
I DME (Data Move Engines,
di cui Xbox One ne dispone ben 4) hanno accesso diretto all'interfaccia di rete
(NoC): questi sono in grado di comprimere e decomprimere flussi di dati mentre
CPU e GPU sono in “deadlock” per altri compiti (volgarmente in fase di
“stallo”). Nello stesso istante i DME possono effettuare il cosiddetto
Tiling/Detiling, tanto sulla memoria di sistema principale (gli 8 GB DDR3)
quanto sulla ESRAM, sfruttando il bus a loro dedicato che è di circa 25,6 GB/s,
non toccando quindi l’intera banda di CPU e GPU. SoC e Data Move Engine godono
infatti di bus indipendenti e separati.
Un DME può comprimere e decomprimere nativamente anche
immagini in jpeg a circa 200 GB/s, a cui si aggiunge anche la Swizzle Copy che
Xbox One integra come offloading chip. In altre parole sia il processore
principale che il processore grafico sono alleggeriti dal carico di spostare
flussi di dati dalla memoria, cosa eseguita dai DME e che, nella situazione migliore
possibile, consente a CPU e GPU di spostare memoria contemporaneamente alle DME
incrementando l'effettiva bandwith a disposizione in quel preciso lasso
temporale.
La PS4 è priva dei move engine e dunque della possibilità di prelevare i dati
provenienti dalla rete (o meglio, dall'interfaccia di rete) e indirizzarli
nella memoria di sistema (PS4 non dispone nemmeno di una EDRAM o di una ESRAM)
lasciando a CPU e GPU il gravoso compito di gestire anche i flussi di dati
della rete, saturando o comunque diminuendo la larghezza di banda a
disposizione. Sulla PS4 il Tiling (arrivare ad un grosso blocco di dati
partendo da pacchetti più piccoli, come fosse un grosso puzzle) e il Detiling
(il processo inverso, decomporre grossi blocchi di dati in parti più piccoli
posizionandoli per esempio all’interno della ESRAM o della DDR) è gestito dal
SoC (CPU e GPU) e da un comune DMA. Inoltre la presenza delle GDDR5, ottima per
file di grandi dimensioni ma problematica con pacchetti piccoli, non agevola il
lavoro di Tiling/Detiling a causa della forte latenza che ha verso la CPU.
Chi dice quindi che anche PS4 può sfruttare nativamente il
cloud computing dice una falsità, dato che il chipset non è assolutamente
disegnato per gestire compiti di questo tipo. Xbox One sì, invece.
E le richieste
di rete sono davvero esigue e ben compatibili con le linee ADS italiane: il
supporto completo al cloud
richiederà connessioni tra i 2 e 4 Mbit.
Funzionamento del cloud e le risorse di
rete:
La domanda che tutti si pongono è
se il cloud computing sia una cosa fattibile: su molti forum e siti
“specializzati” si legge che la banda richiesta per il corretto funzionamento
debba essere elevata e vi sarebbero problemi di latenza poiché, prendendo ad
esempio uno sparatutto online, con a schermo decine di personaggi che si
sparano a vicenda, richiederebbe una banda enorme e una latenza minima.
Innanzitutto è doveroso fare una
precisazione, che purtroppo in molti si dimenticano di fare (disinformazione?):
cloud gaming e cloud computing sono due cose diametralmente diverse. Il cloud
gaming è usufruire di un gioco sfruttando lo streaming di rete, con il gioco
che “gira” su server e con il client che manda unicamente input sul “movimento”
(in un platform ad esempio direzione e salto, in uno shooter quando si spara o
quando ci si gira ecc.).
Il cloud computing permette invece la comunicazione diretta tra client e server
con molti compiti computazionali gestiti lato server (intelligenza artificiale,
illuminazione indiretta, posizione personaggi, attività fuori dalla portata del
giocatore in quell’istante), con i dati inviati in determinati intervalli o in
determinati frangenti con il client che deve elaborare solo una porzione di
codice lasciando sgravate CPU, GPU e memoria.
Il cloud computing quindi non è
cloud gaming, ma è un sistema assai più dinamico: l’intera scena può essere, ad
esempio, memorizzata già all’interno del cloud (un palazzo, una piazza, una
parte del quadro) che agisce anche sui complessi calcoli della fisica e delle
traiettorie dei proiettili (o esplosioni ecc.) con la macchina in locale che
deve semplicemente riproporre uno spazio più limitato (il giocatore non vedrà
mai l’intero livello, ma solo porzioni ove egli stesso si muove).
L’unica cosa che la console deve
fare è mandare l’input ai server sulla posizione attualmente ricoperta dal
giocatore, eventuali raffiche sparate e andate a segno.
Se supponiamo che ogni singolo
colpo richiede 20 bytes di dati per essere “trasferito” ad Azure (dati forniti
da un nostro collega programmatore) una raffica di 10 colpi necessita di appena
200 bytes. Successivamente i server rispediscono al client i dati rielaborati
in quel momento che ammontano, più o meno, alla stessa cifra. Tanti pacchetti
di pochi KB in download e upload. Il client deve quindi gestire unicamente la
posizione iniziale o quella in cui si trova, la geometria poligonale
circostante, la collisione e forza centripeta dei colpi, mentre tutto il resto
è elaborato dai data center.
Ogni singolo elemento richiede
circa 100 bytes, cosa che rientra nella connessione minima richiesta da
Microsoft: una semplice ADSL da 2 MB con anche 100ms di latenza (o ping).
Prendete Titanfall come esempio e capirete le potenzialità del cloud, anche se
si partecipa a stanze con 100ms di latenza. Fate una prova e diteci se trovate
LAG nell’uccidere i BOT.
Quindi no, non servono super
connessioni per poter usufruire di questa caratteristica e la cosa è stata
smentita proprio da Reagent Games con Crackdown 3. E qui parliamo di
un continuo traffico di dati per l'elaborazione della
fisica in tempo reale, esplosioni, crolli, frammenti che partono in ogni dove,
l'impatto dei proiettili, tutto su vasta scala! Ora possiamo dirlo: il vecchio
trailer dell'E3 2014 di Crackdown 3 girava in tempo reale:
Diamo i numeri: quanto è esoso
Crackdown 3 in termini di banda e ping?
Facendo dei calcoli semplici e
“ottimali”, prendiamo proprio l'IP esclusiva per Xbox One come esempio e
analizziamo quali risorse di rete saranno richieste per una esplosione di media
grandezza e rispettivi detriti gestiti via cloud, quindi presupponendo un
target rendering calcolato sul cloud ed elaborato poi in locale.
Considerando un calcolo in tempo
reale di ogni chunk di dati, che avviene 32 volte al secondo, abbiamo:
- 32 bits * 6 - Float
- 9 bits * 2 - 9 Bit Integer
- Compressione tipica (LZ77 che
Xbox One integra): 85%
- Chunk: 10,000
- Bit totali per Chunk: 210 bits
- Conversione bit totali per
Chunk: 2,100,000
- Bit totali compressi: 315,000
- Configurazione tipica Ethernet
MTU = 1500 bytes = 12000 bits
- Data frame per esplosioni
iniziali di 10.000 Chunk: 27
- Overhead tipico in UDP = 224
bits
- Overhead totale per esplosione
= 6048 bits
- Bit totali necessari da inviare
per esplosione: 321,048
- Banda necessaria per esplosione
inziale: 313Kbps
- Tutti i Chunk collidono in 4
secondi: 2500 Chunk rielaborati ogni secondo
2500*210 = 525000
- Compressi: 78750 bits
- Data Frame per secondo
necessari per la rielaborazione: 7
- UDP Overhead = 1568 bits
- Bit totali necessari per la
rielaborazione: 80318 bits
- Banda necessaria per la
rielaborazione: 78kbps
- Banda necessaria per
elaborazione totale in ogni secondo: 391kbps
- Banda necessaria per la
elaborazione dopo il primo secondo: 78kbps
Calcoli eseguiti considerando le
variabili X, Y, Z partendo da coordinate fisse iniziali e finali nel percorso
della mappa. Ho poi assegnato 9 bit interi per i valori della rotazione sul percorso e il raggio
dell'arco del percorso.
Per fare un confronto diretto con i servizi che vengono
utilizzati ogni giorno, ad
esempio Netflix o YouTube utilizzano 7Mbps per un flusso Super
HD (720p/1080p), uno standard in questi giorni anche in Italia.
Latenza:
- Media RTT (Round Trip Time) verso Azure: 40ms
- Calcolo del tempo verso i Server: 32ms (per 32FPS)
- RTT totale = 72ms
- In secondi = 0.072 secondi
Conclusione:
Per l’elaborazione della sola
fisica delle esplosioni servono solamente 392KB di dati trasmessi via rete.
Questo considerando anche che la perdita dei pacchetti non è più un problema
con le connessioni attuali (ADSL) e i problemi potrebbero derivare solo se si è
connessi a wireless scadenti o ad ADSL che sono attorno al MB (in download).
Con una 2MB è possibile calcolare
sino a 30.000 oggetti. Tutti i dati sono stati elaborati su base ottimale e
prendendo in esame le caratteristiche di Azure,
documentate sul sito Microsoft.
Per rappresentare un semplice
vettore 3D, la rotazione per un oggetto ha bisogno di circa 12 variabili:
- Xstart - inizio coordinate X (32 bits)
- Ystart - inizio coordinate Y (32 bits)
- Zstart - inizio coordinate Z (32 bits)
- Xvelocity - velocità su asse X (32 bits)
- Yvelocity - velocità su asse Y (32 bits)
- Zvelocity - velocità su asse Z (32 bits)
- αstart(alpha) – inizio orientamento α (32 bits)
- βstart(beta) – inizio orientamento β (32 bits)
- γstart(gamma) – inizio orientamento γ (32 bits)
- αrate - Rate di rotazione su asse α (32 bits)
- βrate - Rate di rotazione su asse β (32 bits)
- γrate - Rate di rotazione su asse γ- (32 bits)
Ovviamente ho cercato di rendere il discorso il più semplicistico
possibile e mi sono messe sempre nella condizione ottimale, ma il discorso è
assai più complesso e richiede fondamenti di fisica e matematica
avanzata. E dire che quando veniva presentata Xbox One assieme al cloud,
lo stesso Phil Spencer
veniva deriso e sbeffeggiato sul web: questi, purtroppo,
sono meccanismi che richiedono tanto tempo e forse Microsoft avrebbe dovuto
mostrare prima qualcosa di più concreto che non comunicati o frasi fatte.
Ma il grande giorno è arrivato e adesso nessuno può dire che il cloud
computing non esista o non sia fattibile. Xbox One venne presentata come
una console 8 volte più potente di Xbox 360 (2.6 TF):
Xbox One, quando collegata al cloud,
venne presentata come una console 32 volte più potente di Xbox 360 (11 TF):
Con Crackdown 3 adesso si parla
di una potenza di 20 volte quella di Xbox One, perché? Semplice, in base alle
richieste computazionali, Azure può richiedere più o meno potenza in base alle
situazione, in una struttura scalabile che può consentire a Xbox One tot TF di
scarico! Il tutto gestito in tempo reale, senza la benché minima
"interferenza".
Questo è solo un piccolo
riassunto di quanto viene richiesto in termini di risorse di rete per il
corretto funzionamento del cloud in determinati scenari, ma l'esempio è
indicativo per capire, grosso modo, come le richieste di rete siano comunque
abbordabili, e se Crackdown 3 girerà agevolmente ad un range tra i 2 e i 4Mbit
di banda per lo sfruttamento non solo di esplosioni, ma anche di fisica,
interazione dei colpi, crolli e detriti vettoriali, viene facile pensare come
questa tecnologia possa essere sfruttata in tutte le future produzioni.
Proprio
questa scelta potrebbe inficiare positivamente per gli studi esterni (come già
avvenuto per Titanfall) ma è solo dimostrando ai videogiocatori e gli altri
team interessati al cloud con demo concrete come Crackdown 3 che ci sarà la
vera e propria rivoluzione videoludica,
come
si auspica anche Phil Spencer:
TILED
RESOURCE:
Oltre ai DME una grossa spinta per l’evoluzione grafica su
Xbox One srà garantita dalle cosiddette Tiled Resource, che Xbox One potrà
gestire nativamente grazie alla presenza della ESRAM di sistema e dalle
operazioni dei DME. La ESRAM infatti, che può essere utilizzata per mantenere
in memoria alcuni target rendering (luce dinamica, ombre, vari effetti video
ecc.) ad accesso rapido e, con l’arrivo delle DirectX12, si potranno
implementare senza troppi problemi le Tiled Resource, in grado di mantenere
nello scatchpad di One ben 6 GB di texture ad altissima risoluzione senza gravare
sulla GPU o la banda di sistema.
Ma cosa sono esattamente queste Tiled Resource? Innanzi
tutto dobbiamo fare una importantissima precisazione, ossia che le TR non sono
come le Megatexture o le PRT dato che l’intero processo computazionale è
gestito via hardware e non via software. Inoltre la qualità delle TR è ben più
elevata rispetto alle PRT.
Le Tiled Resource sono una tecnologia incorporata nelle
Direct3D e che servono a rendere maggiormente flessibile l'utilizzo della
memoria nelle situazioni complesse (in gergo “large amount of data”). Queste
sono già integrate nelle DX 11.2 (che possiede Xbox One) ma non sono state mai
sfruttate a dovere a causa anche della mancanza di multi threading, assente in
questa versione delle API ma che sarà presente nelle prossime DX 12.
Prima dell'introduzione di questa interessante tecnologia
era necessario che quasi tutte le texture che ricoprivano le varie superfici
dovessero essere già caricate nella memoria di sistema, la DRAM. Le Tiled
Resources invece sono risorse di memoria le cui pagine (dette tiles)
costituenti possono essere opzionalmente popolate con relativa memoria fisica.
Microsoft, con le Tiled Resource, ha optato per realizzare un’interfaccia di
tipo hardware per l'utilizzo delle risorse in questo modo concepite che non ha
precedenti in questa forma particolare, tanto che tutte le precedenti
implementazioni venivano effettuate via software con svantaggi che vi
mostreremo più avanti.
Dovete sapere che generalmente l'implementazione delle TR
viene gestita tramite l'algoritmo View Dependent Streaming Texture Detail
(VDSTD), quindi ponendo che una determinata superficie sia strutturata con una
tot serie di texture e con un determinato peso con mipmap, solamente la
frazione di texture che sono nella prossimitá immediata della “current view”
viene compilate, gli elementi ai bordi del frame invece vengono smussati
cercando in questo modo di non rivelare il trucco; naturalmente le texture che
ricopriranno queste superfici saranno a bassissimo livello di dettaglio, ma non
direttamente percepibile dall'occhio umano.
Ecco un esempio di Tiled Resource disattivate e attivate:
 |
| Tiled Resource OFF |
 |
| Tiled Resource ON |
Un grande vantaggio di tale tecnica è che le texture vengono
“prefiltrate”, come spiegato poco sopra, mentre con le implementazioni software
precedenti questo lavoro spettava allo sviluppatore.
Ora DirectX 11.2 ed OpenGL 4.4 offrono il supporto alle
Tiled Resource, tecnologia che esiste per affrontare la problematica
dell'utilizzo di una MegaTexture da applicare nello sviluppo di un engine
grafico. Una delle prime software house ad utilizzare le MegaTexture fu id
Software, grazie al lavoro del guru John Carmack, che aveva già precorso i
tempi sviluppando una tecnologia software incorporata nel motore ID Tech 5
(utilizzato nello sparatutto RAGE). La base dell'algoritmo è sempre lo stesso,
ossia il View Dependent Streaming Texture Detail, ma il modo con il quale Id
Software ha ottenuto questo risultato è unicamente via software.
I vantaggi dell'implementazione via hardware sono i
seguenti:
- Eliminazione delle letture nei casi di strutture
dipendenti
- Filtraggio hardware attivo compreso il filtro anisotropico
e non solo
Nella situazione precedente all'impiego delle Megatexture, i
modi per ottenere un alto livello di dettaglio erano o lo streaming continuo da
asset fisici prefissati oppure attraverso la generazione procedurale delle
stesse texture che però implica la problematica della lettura necessaria da
struttura (texture di controllo) ma ha come vantaggio che non richiede molta
banda passante dalla memoria per lo streaming.
Dopo questa lunga introduzione alla Tiled Resource e la loro
differenziazione dalle MegaTexture (o PRT che a dir si voglia) possiamo
analizzare meglio Xbox One e PS4 per capire come sono strutturati i determinati
chipset per sfruttare queste tecnologie.
Xbox One nasce con in mente assolutamente questa tecnologia,
lo dimostra la presenza di componentistica dedicata altrimenti inutile o
controproducente come appunto la ESRAM, i Data Move Engines e le memorie di
sistema tipo DDR3 (ottime per la bassa latenza nella gestione di pacchetti di
piccole dimensioni e per non avere colli di bottiglia verso la CPU, un po’ meno
performanti invece nella gestione di grossi chunk).
Infatti, viste le problematiche sopracitate, possiamo
affermare con certa convinzione che dovendo effettuate continuamente operazioni
di tile-untile per aggiornare la “current view” in base al VDSDT, serviva una
bassa latenza nell'accesso alla memoria dato il grande numero di accessi
simultanei ed un buffer (nel caso di Xbox One costituito dalla ESRAM)
superveloce che potesse salvare i dati relativi al preciso frame per la
“current view” fungendo quindi da tampone e/o sincronizzatore dell'intero
sistema di interfaccia alla memoria.
I quattro Data Move Engines posseggono via hardware proprio
le funzioni fisse di tile ed untile, scaricando quindi il resto delle
componenti di questo compito ed evitando soprattutto allo sviluppatore di
dovere scrivere un algoritmo del genere.
Da questo ne deriva la scelta delle memorie di tipo DDR3 che
hanno minore latenza delle GGDR5 e quindi sono più adatte agli accessi
multipli. Quindi, sembrerebbe che Xbox One sia l'incarnazione hardware della
nuova versione di Direct3D (ossia le prossime Direct3D 12, viste da tutti come
un salto generazionale delle API di ben quattro volte rispetto alle precedenti
DX 9, 10 e 11).
La console è dunque completamente pensata con in mente le
Tiled Resource ed è customizzata per trarre il massimo beneficio da esse, grazie
ai tantissimi acceleratori presenti nell’hardware.
La PlayStation 4 nasce invece con in mente il requisito
opposto, ovvero una memoria velocissima completamente unificata di tipo GDDR5
senza nessuna ED/ESRAM (un framebuffer collegato direttamente alla GPU che
consentirebbe di stoccare anche interamente gli asset di un livello o parte di
esso in memoria e di consumarli senza particolari accortezze) data la velocità
di questo tipo di memorie.
Da notare poi come Xbox One abbia 4 controller
separati per la memoria di sistema, disposta da 4 blocchi da 2 GB (per un
totale di 8 GB di DDR3) mentre PS4 utilizza un unico canale per la memoria,
composta da un blocco da 8 GB.
Playstation 4 non è pensata per effettuare accessi multipli
e repentini alla sua memoria RAM, vista l'alta latenza delle GDDR perché questo
causerebbe diversi errori e perdite di dati (bubble). Se Sony avesse voluto una
macchina del genere avrebbe dovuto quantomeno montare una EDRAM, cosa che
inizialmente era stata anche presa in esame,
come dichiarato da Mark Cerny.
La domanda vien da sé: PS4 può gestire le Tiled Resource?
La risposta è sì, non scordiamoci infatti della tecnologia
Partial Resident Textures, giá da tempo integrata nelle GPU di AMD, grazie
anche alla compatibilità dello standard OpenGL con questa tecnologia, quindi
una gestione via software è possibile. Il problema è però un altro, ovvero che la macchina non
integra acceleratori hardware per questa tecnologia, o quantomeno solo in parte
(appunto, PRT), con tutto il ricasco in caso di utilizzo su compiti
computazionali aggiuntivi che farebbe perdere tempo e potenza.
In altre parole con un utilizzo massiccio delle
TiledResource su PS4 lo sviluppatore dovrebbe gestire molti più processi, processi
che su Xbox One sono invece implementati già nel sistema grazie all’hardware
dedicato. É vero che OpenGL gestisce queste risorse ma non lo effettua nello
stesso modo nel quale viene fatto con Xbox One, proprio perché le GL non sono
disegnate per utilizzare ESRAM o Data Move Engines; queste sono prerogative
esclusive di Xbox One che Microsoft ha fortemente voluto al suo interno
dedicandoci svariati studi e ricerca. Diciamo che Xbox One
rappresenta ad oggi
forse la miglior implementazione hardware di
questa interessante tecnologia.
Ancora una volta possiamo ribadire il concetto che da un
punto di vista hardware in termini di RAW Power la PS4 è senz’altro su un
gradino superiore, ha una framebuffer più diretto e molto più veloce, di contro
paga una certa latenza per accedervi e non dispone di particolari accuratezze
hardware per ovviare a questa carenza. Inoltre l’utilizzo massivo delle Tiled
Resource su Xbox One consentirebbe di liberare ulteriormente compiti
computazionali che potrebbero essere dedicati ad altri fattori.
AUDIO SHAPE:
Il chip audio contenuto in Xbox One è realizzato interamente
da Microsoft e Tensilica e setta nuovi standard qualitativi in ambito home
console. Ma non solo, perché il chip non è solo un qualcosa dedicato all’audio,
ma molto di più, un processore in grado di offrire supporto ad altre
“chiamate”, come il Kinect o, addirittura, all’intera APU costituita da CPU e
GPU.
Come si può notare dallo slide il chip audio (noto come SHAPE),
da solo, fornisce 15 GFLOPs. Il “blocco” è composto da otto
co-processori in grado di generare
audio posizionale e il “beam forming” per il
Kinect. Dobbiamo immaginare questo
processore più come un blocco DSP che una semplice “Sound
Blaster”.
Il chip, nella sua interezza, gestisce 18G
Ops in totale, comprese le funzioni
FP e scalari.
È possibile notare che sul lato
destro del diagramma c'è un collegamento coerente con la CPU e la memoria di
sistema principale. Se questo fosse stato un semplice blocco audio non ci
sarebbe alcun bisogno di avere la “coerenza” verso la CPU, né il ponte AXI che
collega tutto insieme. AXI è il bus ARM, ma perché inserire anche un potente
AXI Bridge in un apparecchio audio? Quale particolare esigenza serviva a
Microsoft per predisporre, anche sul versante audio, una caratteristica così
evidente?
Per dirne una, l’audio in-game di PS4 è gestita direttamente dalla
GPU, in particolar modo sfruttando le GPGPU e due canali DSP, sfruttati per la
chat di gioco e l’audio in generale: un sistema economico non in grado di
fornire un audio di alta qualità.
La parte dell’audio del chip è
gestita dai blocchi giallastri posti in basso e sono l’unità di suono
tradizionale che dovrebbe essere in grado di fare tutto il necessario per i processi
finali, come il numero di canali utilizzati, il bit rate (molto elevato); tutto
questo fa parte di un hardware moderno e molto efficiente.
Grazie al potente chip, Xbox One può
generare senza tanti problemi audio in-game direzionali per coloro che
indossano le cuffie (Dolby) o generare qualcosa come 19,5 configurazioni
Surround per impianti da casa (DTS, Dolby Digital, Virtual Surround ecc.); un
salto notevole per questo genere di cose che è possibile trovare solo in
equalizzatori di fascia alta.
Come molte delle funzionalità, il chip è diviso tra i semplici nuclei audio e,
quanto relativo alle unità superiori, non è stato ancora specificato, ma molto
probabilmente stiamo parlando di
sub-chip FPGA -
ASIC programmabili e determinati dal programmatore
(usarli per avere maggiore banda con la CPU, configurarli sempre per l’audio o
anche per altri compiti).
Detto questo possiamo infatti notare
i link coerenti anche verso la GPU (Host Guest e IO MMU) che si interfacciano
anche al motore DMA, che è specificamente associata con la funzionalità audio.
Il DSP di Controllo, lo Scalar Core e i due Vector Core hanno le proprie cache discrete
e condividono 64K di memoria cache SRAM locale come una sorta di DSP fornita di
L2 interamente indipendente.
2 x 128-bit / 8 = 32 byte, quindi se
l'unità può generare 15.4 GFLOPS con clock tarato a poco meno di 500 MHz, se Microsoft
conteggia i FLOP su banda a 8 bit.
L'intera unità, come già detto, è un progetto interno di Microsoft. Questo
perché si aveva l’esigenza di mantenere operativo sempre il Kinect, che
utilizza i DSP pesantemente per l’interscambio di dati con il SoC principale,
soprattutto considerando i requisiti di coerenza con il resto dei componenti
del sistema.
Questi “percorsi” coerenti dei vari chip servono per mantenere la latenza la
più bassa possibile per il Kinect.
Tornando la discorso dei FPGA (Field
Programmable Gate Array), questi sono circuiti integrati le cui funzionalità
sono programmabili via software.
Questi particolari sub-chip
consentono l'inserimento di funzioni logiche anche molto complessi, e sono
caratterizzati da un'elevata scalabilità. Gli FPGA della One sono
riprogrammabili infinite volte, questo perché nel blocco audio è possibile
notare la presenza di SRAM (Static Random Access Memory) integrata e, in questo
caso, devono essere riprogrammati ad ogni accensione, avendo una memoria di
configurazione volatile.
Ecco svelato il segreto della SRAM
del blocco audio, che, indirettamente, conferma la presenza anche di potenti
FPGA autonomi, ed ecco anche perché all’inizio di questo Inside abbiamo detto
che il blocco audio della One è molto più di un chip audio. Tutto torna, anche
considerando la coerenza su CPU e GPU, cosa di cui un semplice blocco dedicato
a sonoro non ha bisogno. Inoltre c’è da dire che Microsoft utilizza già gli
FPGA per altre sue produzioni, quindi è un campo non nuovo al colosso di
Redmond.
C’è solo da valutare in che modo
possano essere
utilizzati e sfruttati gli FPGA (con la retrocompatibilità di Xbox One verso Xbox 360 senza ombra di dubbio gli FPGA sono stati parte integrante) cosa che Microsoft non ha svelato ancora ma che
dimostra, per l’ennesima volta, la complessità del design dell’intero hardware
che non è un semplice assemblaggio di parti “off the shelves”, come la rivale
PS4 o i comuni PC.
L’IMPORTANZA
DEL LEAK DEGLI XDK E ALCUNE CONFERME:
Perché
i documenti trafugati dei kit di Xbox One hanno giocato un ruolo importante nella
comprensione del suo hardware? Il
materiale fornito dagli SDK (Software Developer Kit) di novembre 2014 di Xbox
One ha portato alla luce alcuni interessanti dettagli sull’intero chipset della
console, confermando anche vecchie “teorie”, prime fra tutte la natività delle
DirectX 12 e del Dual Lane.
Un leak che è sembrato uscito come un fulmine a ciel sereno,
che sta facendo parlare, finalmente, i principali siti specializzati, che
stanno intravedendo in Xbox One un chipset effettivamente “diverso”, nuovo per
certi versi.
Ma facciamo un passo indietro, prima di proseguire: durante
la presentazione di Xbox One nel 2013, pochissimi dettagli sull’hardware
vennero diffusi, se non i principali come velocità del clock di CPU e GPU (poi
leggermente aumentato per entrambi nelle console retail), ammontare di memoria
di sistema, transistor, capienza del disco fisso e del lettore ottico, porte di
input e output.
Successivamente dopo l’E3 2013 vennero resi noti altri
dettagli sull’hardware di One, sconosciuti ai più come la presenza di una
memoria fisica fissa di 8 GB, il numero di Ops/ciclo della CPU (che sono 6) e
tutta la storia sulla banda, bilanciamento e ottimizzazione del sistema.
Era ancora poco, considerando che i numeri “generici” erano
impietosi per la One che dimostrava sulla carta di essere effettivamente
inferiore del 50% rispetto alla concorrente PlayStation 4. Stream Processor,
Rops, ACE, Teraflops, tutto era di circa la metà su Xbox One, tanto che il
numeretto magico 1.84 di PS4 confrontato con i “soli” 1.32 della console di
Microsoft ponevano una prima differenziazione in termini di prestazioni. Il
tutto venne corroborato dalle prime scadenti conversioni della line-up di
lancio di Xbox One, con i vari Call of Duty: Ghosts, Battlefield 4, Assassin’s
Creed: Black Flag girare a risoluzione inferiore.
Iniziò il Resolution-Gate che per la neoarrivata console di
Microsoft fu una vera e propria Spada di Damocle.
Cosa stava accadendo? Innanzi tutto l’idea che Xbox One
fosse uscita anzitempo sul mercato si stava palesando, con il System Update del
day-one e la mancanza di numerose feature, sviluppatori che lamentavano la
pochezza degli SDK e la mala gestione della ESRAM. Con il tempo le cose iniziarono a migliorare e per Microsoft
era tempo di iniziare a parlare dell’hardware della console, prima con
l’intervista agli architetti di Xbox One e successivamente ad eventi dalla
portata mondiale come la GDC, la ISCAA, HotChips, BUILD, ISEEE.
Ad ogni conferenza di faceva luce sempre di più sulle scelte
adottate dagli ingegneri di Microsoft per Xbox One, con slide sempre più
accurate e dichiarazioni tecniche che metteva in evidenza le capacità della
console.
Tutte informazioni centellinate col contagocce, molte delle
quali riservate e tutelate dall’NDA che vige tra Microsoft e AMD. Senza contare
anche le numerose dichiarazioni degli sviluppatori che solo ora, quindi dopo
circa un anno, si stanno trovando a proprio agio con l’hardware di One, con la
ESRAM, tanto per dirne una, che si sta rivelando una scelta più che azzeccata,
se ben sfruttata. Ma pensate un po’ alla cronologia di tutti questi eventi,
culminato col fatidico leak degli SDK. Leak che, grazie ad essi, si sta
conoscendo un po’ meglio l’intero chipset della console e che, in primis, ci fa
vedere come l’hardware era stato pensato effettivamente con le DX12 in mente.
Per chi segue RC e Inside non una grande novità (lo vado dicendo da prima della
presentazione delle nuove API), ma per gli scettici un grande interrogativo su
cui meditare.
Come ben saprete infatti, se è vero che le DX12 saranno
retrocompatibili con le principali schede video in circolazione, solo con i
nuovi chip si avrà il cosiddetto supporto nativo, ossia massima integrazione e
funzionalità delle API. E indovinate un po’ quale sarà il primo hardware a
beneficiare delle DX12?
Si avete capito bene, sarà Xbox One. Una follia? No, basta
leggere alcune parti del documento trafugato (e penso sempre più ad un leak
pilotato, una maniera per “rompere” l’NDA senza andare incontro a sanzioni):
Leggete le parti evidenziate, si parla di task
computazionali paralleli e di nuove nozioni su come intendere la GPU, dato che
le regole sono cambiate e che solo il cielo può esserne un limite (magari
superato con il Cloud Computing…).
Le regole sono cambiate perché l’hardware sta cambiando, ci
sta una scissione con i vecchi termini e i vecchi concetti, qui si parla di un
qualcosa di realmente innovativo, mai visto prima (che poi sia un vantaggio o
un flop è ancora difficile stabilirlo…).
Le Descriptor Tables supportate con i recenti dev-kit, che
preparano l’arrivo delle DX12.
La limitazione delle DX11.X che possono eseguire una
sola operazione alla volta.
La futura (ora attuale) implementazione delle Tiled Resource, al momento
supportate solamente come “demo”, ossia in Preview Mode e quindi ancora
inutilizzabili.
L’utilizzo dei mono driver (Monolithic) in favore dei
Vanilla Code (DX11 a tutti gli effetti, nemmeno ottimizzate a basso livello per
One) che hanno reso possibile i 1080p sui diversi giochi dell’estate/autunno
del 2014 (Sniper Elite 3, Diablo 3, Wolfenstein: The New Order, Destiny, Forza
Horizon 2 ecc.).
Insomma, un’altra conferma delle teoria basate su Mono e
Stereo Driver, rispettivamente DX11 e DX12, come ben spiegato in questo altro
slide:
Ma quello che più sorprende, per lo meno per scettici e
increduli delle X-raysiane teorie, è la parte cardine di questi leak, ovvero la
conferma e la riprova che la GPU di Xbox One è effettivamente capace di gestire
più flussi di rendering, smistati tra bassa e alta priorità ma tutti in grado
di coesistere nello stesso istante gestendo addirittura fino ad 8 flussi in
contemporanea, di cui 7 dedicati al gaming (e 1 per il SO, snap e altri profili
di basso livello). Cosa sarebbero questi 8 flussi? Si tratta della gestione dei
“context graphic”, ossia un contesto grafico contenente tutti i parametri di “disegno”
e le informazioni specifiche utilizzate dal dispositivo per eseguire i comandi
di “disegno” successivi. Questo contiene informazioni base sugli attributi come
disegno (drawing), i colori (colors), l'area utilizzata per ritaglio (clipping),
la larghezza della linea e le informazioni di stile, più altri importanti dati.
Xbox One supporta quindi più flussi di comando della GPU che
contengono le istruzioni per l'elaborazione e il rendering. La GPU della console
processa contemporaneamente entrambi i comandi, consentendo ben due processi
paralleli di rendering e di lavoro di calcolo, che dividono la larghezza di
banda delle stesse risorse. Il risultato è uno scambio di bassa latenza tra CPU
e GPU. Tuttavia dagli SDK non vi è alcuna informazione sul fatto che gli
sviluppatori possano organizzare manualmente questi tipi di comandi o se la GPU
compila automaticamente gli elementi in coda.
Per migliorare le prestazioni, gli sviluppatori sono in
grado di utilizzare un “defferred context” con l'aiuto di un altro thread della
CPU se il gioco sta attraversando il processo di rendering, in modo che i
comandi registrati possano essere eseguiti nuovamente:
Si può notare come l’hardware di Xbox One sia quindi
castrato dagli attuali SDK e di come il potenziale dell’intero hardware possa
essere “sbloccato” grazie all’introduzione di SDK aggiornati, che abilitano
nuove funzioni:
Anche Phil Spencer aveva “spifferato” la cosa mediante un
tweet sulle DX 12, API che sbloccheranno del nuovo potenziale della console:
E non è tutto visto che spulciando il file specifico ci sono
altre particolarità che rubano l’occhio:
Questi sono accenni anche alla coerenza totale dell’intero
SoC di Xbox One, dove sfruttando a regime ogni parte dell’hardware non si
incorre in problemi di latenza o colli di bottiglia (cosa che succede su PS4
quando si utilizzano le 4 CU per le GPGPU con la banda tra CPU e GPU che scende
verso il basso, essendo la PS4 bilanciata solamente per valori di 14:4 CU, non
tutte indirizzate al rendering quindi, pena la perdita di banda).
Inoltre, sempre dal leak, è possibile notare come negli
ultimi SDK si sia andati migliorando sia la gestione della memoria (più
efficiente del 45%) e dallo sblocco del settimo core (prima erano 6 adibiti al
gaming) per un buon 80%, laddove gli sviluppatori non intendano sfruttare i
comandi vocali nei loro giochi del Kinect (rimangono intatti però i comandi
vocali di sistema come “Xbox vai a…” o “Xbox registra questo elemento”).
L’intero settimo core sarà liberato al 100% con futuri kit.
Un mockup riassuntivo e ben dettagliato lo possiamo vedere
in questo slide, che denota anche la presenza di un probabile XDME, da non
confondere coi Data Move Engine e che rappresenta un canale di connessione per
GPU multiple (di solito usato per configurazioni CrossFire di AMD):
Xbox One possiede due GPU? No, in realtà Xbox One vanta una
GPU unica divisa in due “sotto-core”, questo dato è confermato dai più recenti
slide della IEEE 2014 , che mostra nello specifico lo split di 6 CU per gruppo
e la presenza di due Graphics Command Processor e due Compute Command
Processor:
Un altro dettaglio ci mostra il Full HSA di One e la nuova
visione in ambito di sviluppo:
Una cosa molto diversa dalla struttura hardware delle ATI
7700 che possiede un solo CCP:
E anche la PS4 offre un’architettura più simile alla scheda
per PC che a quella di One. Quindi inutile dire che la One fa parte di una famiglia XXX
castrata o customizzata in pochi ambiti: l’hardware di Xbox One è diverso da
qualsiasi cosa che ci sia attualmente sul mercato.
E’ più probabile che la One sia strutturata in base a 2
Schede ATI 7700, non a caso i primi dev-kit erano basati su una configurazione
similare.
Xbox One si poggia, riassumendo, su scelte molto diverse
rispetto alla concorrenza,
come il Full HSA anziché hUMA, un pool di memoria più versatile per ogni tipo di dato, che
offre il massimo se coadiuvato dalla ESRAM (dando una banda passante superiore
rispetto alle GDDR5), un Sistema Operativo virtualizzato su un hardware che può
essere modificato in alcuni parametri (FPGA, schedulatori, operazioni per CU,
arrays ecc.), il dual lane, DX 12, Tiled Resource e Cloud Computing.
Perché PS4 non è Full HSA?
Per quanto detto prima, utilizzando le 4 CU per i ruoli
GPGPU vi è una riduzione di banda tra CPU e GPU, cosa che non avviene su One
poiché le 12 CU sono interamente dedicate al rendering, con i DME che fanno il
lavoro “sporco” di passare dati da un chip all’altro.
Il Full HSA permette proprio l’utilizzo di ogni singolo
componente senza gravare sulla banda generale, non creando quindi colli di
bottiglia o riduzioni in determinato contesti. Inoltre il Full HSA fa leva
proprio su chip di scarico e, in ultimo, di un sistema della memoria
virtualizzato (Unified Virtual Address o Shared Virtual Memory), proprio quello
che ha One:
One poi, a differenza di PS4, utilizza un pool di memoria L1
non condivisa per Shader Core, ma ogni componente ha la sua “memoria”, proprio
come lo standard GCN 2.0.
Su PS4 il discorso è differente e si appoggia sulla
struttura GCN 1.0:
Ecco le differenze tra i due approcci:
ANALISI XBOX ONE:
- Generalmente GCN 1.0 e GCN 1.1 usano un array di CU, che
equivalgono a gruppi di CU per L1 condivisa (CU=Comput Unit, GCN=Graphic Core
Next di AMD).
- GCN 2.0 utilizza le CU come gruppi di SIMD per L1 non
condivisa.
- Gli Shader Core (SC) di Xbox One sono basati su tecnologia
GCN 2.0, dove gli SC utilizzano un gruppo di SIMD per L1, come mostrato nella
precedente slide.
La base di partenza è dunque un GCN 2.0 per Xbox One, dove i
SIMD sono racchiusi all’interno di un singolo core CU/SC, e il CU nel GCN 2.0 è
praticamente composto da un array indipendente di CU. I SIMD possono gestire
tot operazioni, e per ops (operation per second) possono avere un “n” numero di
ALU.
Partendo dal concetto base di GCN 2.0, Microsoft ha
provveduto a realizzare e customizzare i singoli blocchi, ma i SIMD totali per
CU, gli ops totali per SIMD, il numero totale di ops per ALU non sono “fissi” sulla
parte GFx di Xbox One, possono eseguire più thread per ciclo in modo dinamico e
indipendente (i CU non sono disposti a blocchi o gruppi, bensì sono separati,
individuali).
ANALISI PS4:
La GPU di PS4 è costituita da due blocchi di Shader composti
da 3 CU array, 9 per parte che compongono 18 CU totali (bilanciati in 14 più 4
per GPGPU). Ogni array di 3 CU ha in condivisione L1 e K$.
PS4 è basata su chipset Southern Island, con il medesimo
blocco di CU, rappresentando una GPU da 256bit e abbracciando la tecnologia GCN
1.1.
Ancora una volta ci ritroviamo difronte ad una “struttura”
nuova, che è costata ad Xbox One un lancio ballerino, soprattutto con i primi,
inefficienti engine 3D. La cosa è migliorata negli ultimi tempi e sarà
“rivoluzionata” tra circa 4-6 mesi quando la One potrà far leva su SDK
completi, basati nativamente sulle DX12 e sul nuovo Win10 (da qui anche
l’arrivo delle App universali).
Considerando l’atipica struttura del chipset, con molti
parametri “customizzabili” al volo, di cui molti elementi ancora “limitati” per
via delle DX11.X, è veramente difficile fare un calcolo in teraflops
dell’intera macchina, e quello che è possibile dire allo stato attuale delle
cose è che il solo blocco GPU è di 1.3 TFLOPS.
Tutto inizia a tornare, la Xbox One si sta evolvendo nel
tempo e la piattaforma in continuo miglioramento, sia sul fronte multimediale
che videoludico. Le differenze con PS4, in termini grafici, si stanno
assottigliando, ormai son quasi nulle ma il sorpasso imminente, se aggiungiamo
anche Tiled Resource e Cloud Computing.
Vi ricordate quando alcuni utenti esperti dicevano che le
DX12 non avrebbero portato migliorie su Xbox One perché le API della console
lavoravano già sul metallo? E gli stessi dicevano che le DX12 mai sarebbero
arrivate su One, non nativamente.
Oggi possiamo confermare, anche grazie a questi leak e
alcune considerazioni degli sviluppatori (
4A Games su tutti) che le DX12 impatteranno (e lo stanno già facendo da qualche mese) su One aggiungendo benefici assoluti come:
-Sblocco del Dual Lane
-Migliore efficienza della CPU grazie a ridotto overhead
-Migliore efficienza della CPU grazie all’introduzione del
multithreading
-Migliore comunicazione tra CPU e GPU
-Implementazioni nuovi asset come le Tiled Resource
-Migliore gestione della ESRAM (già avuto con i dev di
ottobre)
-Implementazione processi paralleli, asincroni e sincroni
X-Rays
