In-Depht Xbox One: analisi completa della struttura hardware della console

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.

Le dichiarazioni degli architetti di Xbox One non fanno che confermare le pesanti modifiche apportate alla CPU:

“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:

1. X^start - inizio coordinate X (32 bits)
2. Y^start - inizio coordinate Y (32 bits)
3. Z^start - inizio coordinate Z (32 bits)
4. X^velocity - velocità su asse X (32 bits)
5. Y^velocity - velocità su asse Y (32 bits)
6. Z^velocity - velocità su asse Z (32 bits)
7. α^start(alpha) – inizio orientamento α (32 bits)
8. β^start(beta) – inizio orientamento β (32 bits)
9. γ^start(gamma) – inizio orientamento γ (32 bits)
10. α^rate - Rate di rotazione su asse α (32 bits)
11. β^rate - Rate di rotazione su asse β (32 bits)
12. γ^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.

Ricordiamoci infatti che l'infrasruttura Live/Azure di Xbox One è concessa anche agli studi di terze parti gratuitamente e se uno sviluppatore vorrà sfruttare il cloud computing in futuro su Xbox One non dovrà sborsare soldi o royalty aggiuntive.

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).

Microsoft ha studiato questasoluzione e non è una mera speculazione sia chiaro, bensì una vera conferma, come testimoniano le menti che hanno realizzato e progettato la One

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