L'intervista completa con gli architetti di Xbox One

Il mio nome è Andrew Goosen, sono un tecnico di Microsoft e uno degli architetti di Xbox One. Sono stato fondamentalmente coinvolto sul fronte del software ma ho lavorato molto con Nick e il suo team per finalizzare il silicio che avrebbe trovato posto sulla console nella sua forma definitiva. Per disegnare una buona console, occorre considerare tutti gli aspetti chiave dell'hardware e del software: la combinazione di questi due elementi permette di ottenere un buon bilanciamento di prestazioni. Siamo stati davvero molto lieti di avere l'opportunità di parlare con voi circa la progettazione di Xbox One. C'è un sacco di disinformazione a riguardo visto e vi posso dire immediatamente che siamo davvero molto orgogliosi del nostro design. 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.

Sono Nick Baker e gestisco il team architettura hardware. Abbiamo lavorato su quasi tutte le istanze dell'Xbox One: la mia squadra ha avuto il compito di progettare la console tenendo in considerazione tutte le tecnologie disponibili. Siamo costantemente alla ricerca delle ultime novità nel campo della grafica e abbiamo lavorato molto con Andrew e la squadra di DirectX per avere le migliori informazioni possibili al momento di iniziare lo sviluppo della console. Abbiamo un buon rapporto con un sacco di altre aziende nel settore dell'hardware. Potreste aver visto John Sell che ha presentato la console al recente Hot Chips mentre io mi ero occupato della presentazione dell'Xbox 360 all'Hot Chips 2005 con Jeff Andrews.

Difficile scegliere pochi aspetti da discutere in un ristretto lasso di tempo: probabilmente l'elemento chiave riguardava l'approccio ad un'architettura multiprocessore. La volta scorsa ci eravamo presi dei rischi e uno di quelli era di utilizzare un approccio multiprocessore piuttosto che utilizzare un piccolo numero di core CPU in grado di svolgere un elevato numero d'istruzioni ma con un altrettanto alto consumo energetico. Stavolta abbiamo intrapreso la strada di un numero maggiore di core che lavorano in parallelo per arrivare a un obiettivo che permettesse di raggiungere il miglior rapporto consumo/prestazioni. C'erano anche alcuni aspetti collaterali come la necessità di scaricare i task dell'audio su un chip diverso: fin dall'inizio volevamo avere un unico chip integrato posizionando la memoria il più vicino possibile al blocco CPU/GPU per dare al sistema la più bassa latenza e la maggiore banda possibile. Questa è stata la linea guida principale del progetto.

Ovviamente non abbiamo potuto fare a meno di occuparci di una nuova configurazione di memoria visto che non potevamo passare i puntatori dalla CPU alla GPU e così abbiamo dovuto affrontare questo problema facendo transitare gli shader attraverso GPGPU. Anche la compressione ci ha dato un sacco di lavoro, in particolare per come i Data Move Engine la gestiscono. Abbiamo posto molta attenzione anche al carico della GPU, ai servizi di sistema per non farli impattare con la compatibilità e così via.

C'era un sacco di roba complicata da fare: dovevamo essere sicuri che il sistema fosse capace di effettuare correttamente la virtualizzazione di molti compiti e tutti gli IO fossero essere associati ai vari processi che la compongono. Anche gli interrupt virtualizzati... dovevamo essere sicuri che l'IP integrato nel chip fosse allineato al resto del sistema. Andrew?

Come Nick ha detto, bisognava svolgere un mucchio di lavoro prettamente ingegneristico che si doveva concludere con successo e il software era un aspetto chiave nella virtualizzazione. Abbiamo avuto una serie di requisiti sul lato software che derivavano dalla configurazione hardware. Per rispondere alla tua domanda Richard, fin dall'inizio il concetto di virtualizzazione è stato prioritario nella fase di progettazione. Sapevamo fin dall'inizio che avremmo dovuto far girare un ambiente di background molto complesso in concomitanza con il gioco proprio grazie alla virtualizzazione. Per noi è stato molto importante quello che abbiamo imparato con l'Xbox 360 ovvero costruire un sistema in grado di disturbare il gioco il meno possibile pur spingendo al massimo le possibilità del processo virtualizzato grazie al software che lo gestisce.

Il vantaggio di avere una virtualizzazione efficace è che possiamo fare cose come l'aggiornamento del sistema operativo evitando problemi di retrocompatibilità tra giochi vecchi e giochi più recenti. Allo stesso modo, la possibilità di avere un OS flessibile permette tutta una serie d'innovazioni anche sul fronte del gioco stesso: per esempio parlando di SDK possiamo completamente riscrivere il gestore della memoria del sistema operativo per CPU e GPU, un'operazione praticamente impossibile senza virtualizzazione. Nick aveva parlato prima delle tabelle di pagina e anche in quel campo ci sono parecchie belle novità: la GPU ha due strati di tabelle di pagina per la virtualizzazione e credo che questa sia la prima grossa applicazione consumer che permette una cosa del genere. In questo modo la virtualizzazione garantisce quel genere d'isolamento dal resto dei processi che permette non impattare la performance del gioco che sta girando.

Abbiamo costruito la virtualizzazione in modo tale da non aver alcun costo per la grafica che non sia la gestione degli interrupt. Abbiamo escogitato tutto il possibile per evitare interruzioni e ne facciamo soltanto due per fotogramma. Abbiamo dovuto apportare cambiamenti significativi all'hardware e al software per arrivare a questo risultato. Abbiamo gli overlay hardware dove diamo due strati al gioco e uno al sistema operativo e possiamo rendere completamente asincrono tutto questo processo.

Il sistema operativo è tutto integrato con il desktop manager di Windows, ma il gioco si può aggiornare anche se c'è un problema tecnico come quando lo schedulatore di Windows rallenta. Abbiamo svolto un sacco di lavoro sulla virtualizzazione che permette di gestire in simultanea molti task: anche questo è uno dei motivi per cui troverete in esecuzione task che a loro volta ne pilotano molti altri. Sapevamo che la memoria finale sarebbe stata di 8GB e questo ha guidato buona parte dell'approccio alla virtualizzazione.

Si, credo che sia stata una decisione presa abbastanza presto, quando stavamo pensando a che genere di applicazioni avrebbero dovuto girare in concomitanza con il gioco e di conseguenza quanta memoria ci serviva. Il target degli 8GB è stato individuato abbastanza presto.

Lo spazio sul die e il consumo energetico non rendono il Piledriver adatto nonostante il boost prestazionale: non è scelta giusta da prendere per una console. Essere in grado di centrare il giusto rapporto tra potenza/prestazioni per area e renderlo una questione di parallelizzazione dei task è stato il nostro obbiettivo soprattutto in relazione a come partizionare l'uso dei core tra gioco e sistema operativo.

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. In ogni caso non abbiamo cambiato nulla dell'ISA o aggiungendo istruzioni supplementari quindi il core è praticamente rimasto lo stesso.

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.

Il blocco audio è completamente nuovo ed è stato progettato da noi nella sua interezza. Si basa su quattro core DSP Tensilica e diversi strumenti di elaborazione programmabili. Questi sono stati separati in un core di controllo, due core per il codice vettore, uno per la voce e uno per il DSP in generale. Abbiamo accoppiato quest'unità a quelle in cui sono inserite le unità dedicate alla frequenza di campionamento, filtraggio, mixaggio, equalizzazione, compensazione dinamica e quindi anche il blocco audio XMA. L'obiettivo era quello di ottenere 512 voci simultanee per l'audio, oltre ad essere in grado di pre-processare i comandi vocali di Kinect.

Andrew si occupa dello sviluppo della parte middleware, ma alcune di queste risorse sono riservate al sistema per effettuare compiti strettamente legati alla gestione dei task di Kinect: processi di sistema e parte di questi sono dedicati al Kinect stesso.

"Un sacco di quello che abbiamo progettato mira a gestire le risorse in tempo reale e quelle che devono essere pronte all'uso per fare in modo che il maggior numero dei compiti di elaborazione vengano traslati dal gioco ai sistemi hardware con grande facilità e il minimo sforzo per gli sviluppatori. Per esempio la modalità di riconoscimento vocale viene gestita dal sistema da un processore dedicato mentre altre piattaforme non si fanno carico di queste di attività che dovranno essere gestite dagli stessi sviluppatori a livello di programmazione e quindi di budget. La stessa cosa vale per il Kinect e la maggior parte delle nostre interfacce NUI [Natural User Interface], una caratteristica fornita gratuitamente per tutti i giochi in via di sviluppo dedicati ai Kinect così come le funzionalità di registrazione video digitale.".

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.

Si trattava essenzialmente di capire quale tecnologia fosse disponibile, in un dato momento, per stipare della eDRAM su un singolo die.

No, volevamo un processore singolo: come ho detto se ci fosse stato un periodo di tempo diverso o altre opzioni tecnologiche forse avremo scelto una strada differente, ma in questo periodo storico, dal punto di vista tecnologico, l'ESRAM è stata la scelta migliore.

Molti l'hanno messo in dubbio, ma ti posso confermare che è possibile usare l'ESRAM e la RAM principale per la GPU e che la ESRAM e la RAM DDR3 arrivano a comporre otto controller per la memoria complessivi. Quindi ci sono quattro controller esterni di memoria a 64-bit per la RAM DDR3 e altri quattro a 256-bit che gestiscono la ESRAM. Sono tutti interconnessi tra loro e quindi è possibile accedere simultaneamente alla RAM e alla ESRAM.

Ecco la spiegazione. 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.

Quindi il computo totale di 200 GB/s presentato all'Hot Chips 25 è fondamentalmente la somma del valore ottenuto calcolando con applicazioni pratiche il massimo potenziale combinato di ESRAM e DDR3 (140-150 GB/s + 50-55 GB/s) tenendo conto delle limitazioni logiche di entrambe e del fatto che non è possibile sostenere cicli di scrittura continui. Il ciclo di scrittura è noto per inserire nel processo una "bolla", ovvero un ciclo perso ogni otto che sfalsa le valutazioni teoriche di prestazioni per un pool di memoria. Il valore finale di 204 GB/s è quindi la somma della misurazione di codice reale in fase di elaborazione, sia per la memoria interna sia per quella esterna, non una diagnostica o simulazione.

Non è corretto parlare di ESRAM nel suo complesso ma di un architettura che permette di svolgere un lavoro in parallelo tra i vari moduli tra loro. Ovviamente se si continua a lavorare sempre nella stessa area di memoria in continuo non si usa tutta la banda a disposizione ma solo 140-150GB/s rispetto al picco massimo teorico di 204 GB/s. Si tratta di un sistema complesso che può essere usato più o meno efficacemente a seconda di come si gestisce l'accesso alle risorse e che permette letture e scritture simultanee da e verso l'ESRAM e da e verso la DDR3 ed uno degli aspetti tecnicamente più complessi che volevamo chiarire."

Quindi, se lavorando con la ESRAM state solo scrivendo o leggendo dati il sistema non può andare oltre i 109GB/s. In una situazione normale che prevede un alternarsi di cicli di letture e scritture questo valore aumenta per forza visto che questo movimento bidirezionale dei dati è tipico di un pool di memoria in cui i render e i depth buffer vengono aggiornati di continuo e quindi traggono un grosso vantaggio da cicli simultanei di lettura/scrittura.

Si, è già stato misurato.

Eravamo partiti da una banda minima di 102GB/s poi è diventata 109GB/s dopo l'aumento del clock della GPU: il fatto è che si trattava solo di velocità teorica e ci siamo quindi resi conto, solo all'atto pratico, che si poteva arrivare molto più in alto.

Tutta la polemica montata sull'uso della RAM per noi è stata piuttosto sorprendente, soprattutto se si pensa che l'ESRAM è l'evoluzione dell'eDRAM presente su Xbox 360. Nessuno ha messo in dubbio che su Xbox 360 siamo stati in grado di sfruttare la larghezza di banda dell'eDRAM facendola lavorare in parallelo con la larghezza di banda della memoria esattamente com'erano state dettate le specifiche di sistema. Su Xbox 360 avevamo fondamentalmente affiancato tutti i nostri vertex buffer e tutte le nostre strutture di memoria di sistema agli indirizzi di rendering, colore, profondità, buffer stencil che in precedenza venivano gestiti dalla eDRAM. Con Xbox One abbiamo fatto la stessa cosa: nell'architettura del pool di memoria, l'ESRAM è la stessa estensione naturale dell'eDRAM su Xbox 360. Si tratta fondamentalmente di una bella evoluzione del design di Xbox 360 che ci ha permesso di aggirare un sacco di limitazioni che avevamo incontrato usando l'eDRAM.

L'Xbox 360 è stata indubbiamente la piattaforma console più semplice su cui lavorare finora e non è stato così difficile per i nostri sviluppatori adattarsi all'uso delle eDRAM. In molte situazioni ci siamo trovati a chiederci quanto sarebbe stato bello dal punto di vista tecnico se un intero target di rendering potesse essere gestito al di fuori dell'eDRAM . E così abbiamo fatto in modo che su Xbox One fosse possibile eseguire un overflow dei dati dall'ESRAM su DDR3. In questo modo l'ESRAM è completamente integrata nelle nostre tabelle di paging e così è possibile integrare perfettamente ESRAM nella memoria DDR. Dal nostro punto di vista si tratta di un grande miglioramento nella performance piuttosto che di una semplice evoluzione nel design dell'Xbox 360: in tutta onestà, siamo stati molto sorpresi delle polemiche che sono seguite all'annuncio delle nostre specifiche tecniche.

Oh, assolutamente si e si può usare anche in modo che porzioni del render abbiano pochissimo overdraw, (il rallentamento del frame rate quando si cercano di renderizzare più oggetti di quelli che il sistema riesce a gestire ND Digital Foundry). Per esempio se ci si trova a sviluppare un gioco di guida e il cielo è causa di rallentamenti si possono salvare i subset di memoria nella RAM DDR e liberare spazio per gestire al meglio 32 MB di ESRAM. A questo si aggiunge anche la possibilità di aggiungere istruzioni personalizzate che permettono di gestire in tempo reale l'allocazione di quei preziosi 32MB di RAM.

Si, è possibile ma è molto lento.

Hai ragione. Le GPU risentono meno della latenza, ma al momento non abbiamo ancora discusso la questione in dettaglio.

In larga misura abbiamo ereditato un sacco del design DX11. Quando abbiamo scelto AMD quello della compatibilità piena con le DX11 era a un requisito di base e quando abbiamo iniziato il progetto avevano già pronto un design molto bello basato sulle DX11 con l'API stessa in cima al processo di sviluppo. Penso che da questo trarremo un grande vantaggio. Abbiamo svolto un sacco di lavoro per rimuovere un sacco del carico supplementare in termini d'implementazione. Non succede molto spesso che in una sia possibile effettuare una chiamata API D3D che scrive direttamente nel buffer di comando per aggiornare i registri della GPU proprio di quella funzione API senza fare altre chiamate. Non ci sono strati e strati di software che dialogano tra loro e che sovraccaricano il sistema: il lavoro svolto in questo senso è stato enorme.

Abbiamo anche colto l'occasione per andare a personalizzare il processore dei comandi della GPU: l'interfaccia di comando è una componente fondamentale nel rendere il più efficiente possibile l'overhead del processore grafico. Conosciamo l'architettura AMD abbastanza bene visto che su Xbox 360 il chip grafico era loro e ci siamo ritrovati a usare alcune caratteristiche tecniche che avevamo già usato in quell'occasione. Avevamo elementi come il buffer dei comandi precompilato dove gli sviluppatori potevano precostruire un sacco di stati a livello di oggetto e dove potevano semplicemente dire "esegui questo". Abbiamo scelto questa strada su Xbox 360 e in quel contesto, con l'esperienza, abbiamo maturato un sacco di idee su come rendere il processo più efficiente grazie a un'API più pulita. Così abbiamo colto quest'opportunità con Xbox One e con il nostro processore di comandi personalizzati che lavora sopra le D3D. Un qualcosa che vorremmo integrare di nuovo su PC nel gestire la sottomissione dei comandi di draw a basso livello.

Esattamente come i nostri concorrenti, 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?

Il bilanciamento è la chiave per una performance efficiente: è stato bello lavorare su Xbox One con Nick e il suo team: i ragazzi dedicati al design del sistema hanno creato un ambiente in cui abbiamo avuto la possibilità di effettuare alcuni aggiustamenti dell'ultimo minuto. Si trattava della prova del nove che avrebbe risposto alla domanda cruciale che ci eravamo posti due anni fa in fase di analisi e simulazione della performance finale cercando d'indovinare le richieste hardware dei giochi di oggi: abbiamo preso le giuste decisioni in relazione al bilanciamento delle specifiche hardware? Alzare leggermente la frequenza di clock ha risposto a questa domanda e alla nostra esigenza di avere uno spazio di manovra in questo senso.

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

Aumentando la frequenza si condizionano le prestazioni dell'intero processore grafico mentre aumentando le unità di calcolo migliorano gli shader e le ALU.

Esatto. Modificando il clock, non solo si aumenta la performance delle ALU ma anche il vertex e pixel rate e persino la banda della ESRAM per non parlare della diminuzione dei colli di bottiglia che stanno tutto intorno al sistema come le chiamate di rendering che si muovono lungo la pipeline e la performance delle letture sui pool di ram GPR (General Purpose Ram).

Le specifiche della PS4 di Sony confermano la nostra tesi: loro dicono che il loro sistema era bilanciato per 14 unità di calcolo. Hanno usato un termine preciso: "bilanciato" proprio perché il bilanciamento è cruciale per un design efficiente. Noi tuttavia abbiamo scelto un percorso diverso visto che i test che abbiamo eseguito mostravano spazi di miglioramento sotto il profilo del numero di unità di calcolo perché abbiamo messo in conto più CU di quelle che ci servivano. Per i nostri titoli ci sarà quindi spazio di crescita nel tempo in termini di utilizzo del potenziale di calcolo tridimensionale. Loro invece scommettono sul fatto che le CU addizionali andranno a tutto vantaggio dei carichi di lavoro dei processi di GPGPU. Il nostro approccio è stato diverso visto che la nostra scommessa va nella direzione di avere tanta banda in lettura e il nostro sistema è pensato per questo.

Al momento non so quale delle due soluzioni pagherà maggiormente, se il maggior numero di CU o una gestione più efficace della memoria coerente. Per parte nostra abbiamo un sacco di esperienza in termini nell'uso dalle GPGPU (general-purpose computing on graphics processing units) visto che con il Kinect di Xbox 360 abbiamo svolto un sacco di lavoro a riguardo e sappiamo cosa servirà ai giochi del futuro. Qualcosa come Exemplar, una soluzione che ironicamente non richiede molto alle ALU del sistema. Si tratta molto più di gestione della latenza: per noi si tratta di una sorta di evoluzione basata sulla memoria di sistema che è più importante per alcune applicazioni GPGPU rispetto ad altre.

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.

La relazione tra il fill-rate e l'ampiezza di banda della memoria è un buon esempio di come il bilanciamento sia necessario per una console di qualità. Un fill-rate elevato serve a poco se la memoria di sistema non riesce a sostenere la banda richiesta da quel fill rate. Per esempio, consideriamo quel tipico scenario di gioco dove l'obiettivo di render è di 32bpp [bits per pixel] con il blending disabilitato e la superficie/profondità di stencil è 32bpp con lo Zbuffer attivato. L'ammontare di 12 byte di banda richiesti per la creazione del pixel è di otto byte in scrittura, quattro in lettura. Al nostro picco massimo di fill-rate da 13.65GPixel al secondo servono 164GB/s di banda passante reale che è esattamente quello che serve per non saturare la banda della nostra ESRAM. In questo caso anche se avessimo raddoppiato il numero delle ROP il fill-rate effettivo non sarebbe cambiato perchè avremmo avuto un collo di bottiglia sulla banda. In altre parole, abbiamo bilanciato il numero delle nostre ROP per avere la possibilità di sfruttare al massimo la banda di sistema in ogni situazione.

Abbiamo scelto di lasciare agli sviluppatori la possibilità di scegliere tra risoluzione e qualità dei pixel nel modo più adeguato ai contenuti del loro gioco. Una risoluzione più bassa in genere significa che ci può essere più qualità per ogni singolo pixel. Con uno scaler di alta qualità e l'uso dell'antialiasing o risoluzioni da 720p o 900p alcuni giochi possono avere un aspetto migliore in quanto più GPU lavorano su meno pixel. Altri titoli invece risaltano a 1080p con un impegno minore della GPU sui singoli pixel. Abbiamo costruito Xbox One dotandola di uno scaler di qualità superiore rispetto alla versione di Xbox 360 e aggiunto un piano di display aggiuntivo per offrire una maggiore libertà agli sviluppatori in questo senso.

È stata una lezione che abbiamo imparato dall'Xbox 360, dove al momento del lancio avevamo imposto un requisito tecnico che obbligava tutti i giochi a 720p a girare con una correzione antialias di almeno 2X. Abbiamo poi finito per eliminare quel requisito perché ci siamo resi conto che era meglio consentire agli sviluppatori di prendere la loro decisione sulla risoluzione senza obblighi particolari. Gli sviluppatori sono naturalmente incentivati a rendere le immagini della migliore qualità possibile e sono capaci di scegliere da soli il compromesso migliore tra qualità e numero di pixel per i loro giochi.

Una cosa da tenere a mente quando si fanno delle comparazioni tra le risoluzioni è che attualmente l'Xbox One riserva un 10% delle risorse della GPU per calcoli di sistema. Questa potenza di riserva viene utilizzata sia per la lavorazione di comandi di GPGPU per Kinect sia per il rendering di contenuti di sistema concorrenti come la modalità snap. La riserva attuale prevede un forte isolamento tra le risorse dedicate al gioco e quelle di sistema e semplifica lo sviluppo dei videogiochi. In futuro, abbiamo in programma di aprire più opzioni per gli sviluppatori per sfruttare questa potenza di riserva a disposizione della GPU, pur mantenendo la piena funzionalità del sistema.

Per facilitare questo, oltre alle code di calcolo asincrone, l'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.

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.

Per quanto riguarda il sistema operativo abbiamo sempre in esecuzione un gestore generico di memoria di Windows che ci permette di non preoccuparci di problemi di retrocompatibilità per i giochi. È molto facile per noi riscrivere il gestore di memoria per ottenere memoria coerente, ovvero lo stesso indirizzamento virtuale tra i due gestori che permettono meccanismi di sincronizzazione per il coordinamento tra la CPU e la GPU. Voglio dire, abbiamo inventato il DirectCompute e stiamo svolgendo ricerche su AMP in concomitanza con tutta una serie d'investimenti su Xbox One per utilizzare l'hardware della GPU con carichi di lavoro GPGPU.

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.

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.

Un altro aspetto interessante in termini di design della console era fare in modo che il sistema permettesse il miglior flusso possibile dei frame: curiosamente il collo di bottiglia in questo senso derivava dalla CPU, non il processore grafico. L'aggiunta di un certo margine di prestazioni in termine di clock può essere molto vantaggiosa sopratutto per quei titoli che richiedono molte prestazioni al processore centrale. In questo senso il nostro incremento è andato nella direzione giusta per mantenere frame rate il più solido possibile, anche grazie ad una serie di ottimizzazioni mirate che liberano la CPU dalla necessità di svolgere operazioni complesse.

Abbiamo un sacco di elementi dedicati a questo compito come il processore di comando SHAPE e questo ci ha dato spazio di manovra nella gestione della velocità di clock superiore. 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. Abbiamo due strati: uno è riservato alla gestione del 3D mentre l'altro è pensata per elementi bidimensionali come possono essere l'hud. Anche lo scaler è di alta qualità rispetto a quello dell'Xbox 360 e ci permette di cambiare i parametri della risoluzione dinamica praticamente frame per frame. Ho parlato dei problemi della CPU che causano colli di bottiglia al frame rate. I carichi di lavoro della GPU sono in genere più coerenti nelle successioni di frame dovuti al fatto che non incontrano grossi picchi nelle prestazioni e quindi lo scaler dinamico può lavorare basandosi su quello.

Sempre con i nostri titoli di riferimento abbiamo visto che l'adozione della risoluzione dinamica è molto efficace nell'evitare frame rate incostanti. Quando il gioco entra in un area dove il limite si avvicina è possibile diminuire la risoluzione al volo mantenendo quella dell'HUD inalterata mentre la schermata 3D diminuisce in tempo reale. Come giocatore preferisco un frame rate solido e un piccolo compromesso nella qualità dell'immagine piuttosto che uno stuttering molto evidente.

Si, anche in questo caso possiamo dire che il margine di prestazioni che ci siamo tenuti inizialmente ci ha dato un minimo spazio di manovra nelle fasi finali dello sviluppo. 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.

Da un punto di vista di rapporto potenza/risparmio energetico, gli elementi hardware dedicati a compiti specifici permettono di risparmiare parecchia corrente. La compressione dati è un buon esempio o anche la decodifica dei filmati che permette di alleggerire il carico di lavoro quando il Kinect è attivo. In realtà, quando si parla di soluzioni dedicate all'interno di Xbox One, c'è molto di più dei Data Move Engine che spostano blocchi di memoria da una parte all'altra del sistema.

Usiamo la eMMC NAND come cache di sistema per migliorare la risposta del sistema operativo e non disturbare la performance dei giochi in esecuzione. In questo modo il caricamento della console è più veloce, sopratutto quando avviene da zero, non stiamo parlando del recupero dallo sleep mode. In pratica il sistema operativo viene immagazzinato qui in cache pronto all'uso, o anche altri dati di sistema che possono tornare utili. Diciamo che l'utilità è quella di evitare di intasare l'accesso all'hard disk da parte di task non legati al gioco, andando a inficiare sulla performance del gameplay.

Sapevamo di avere un certo margine ma non sapevamo quanto fino a che non abbiamo avuto a disposizione titoli reali su cui farlo girare. Quanto si possa effettivamente spingere GPU e CPU per migliorare la performance è effettivamente difficile a dirsi se non si ha a disposizione il software reale di riferimento.

Potrà sembrare banale ma si tratta di un vero e proprio lusso quando si tratta di lanciare una console: normalmente bisogna ridurre le frequenze di calcolo. Per una volta abbiamo avuto l'opportunità di decidere dove e come migliorare la performance e per farlo è stato molto piacevole avere titoli di lancio che ci permettessero di prendere una decisione consapevole a riguardo.

Non è un dato che possiamo divulgare al momento.

In altre occasioni abbiamo già specificato dell'implementazione di un sistema di alimentazione multiplo in grado di gestire il consumo energetico in base al carico di lavoro richiesto alla console: dal massimo a un misero 2.5% a seconda della situazione.

Certo, dare vita a un oggetto così complesso come questo è una grande soddisfazione, ma il mio team è sempre al lavoro su altri progetti paralleli quindi non saremo completamente fermi a goderci le celebrazioni.

Per me il premio più grande è di giocare ai titoli e renderci conto che sono effettivamente belli e tecnicamente solidi anche grazie al nostro duro lavoro. Come grafico, posso garantirti che vedere i pixel in movimento sullo schermo è fonte di grande soddisfazione.