Eccoci dunque con la trascrizione completa dell'intervista fatta a due membri chiave del team che si è occupato dello sviluppo di Xbox One. Prima d'iniziare, però, è giusto spiegare come sia nata quest'opportunità. Alla Gamescom di agosto era apparso chiaro che Microsoft stesse cercando di migliorare la percezione del proprio hardware dal punto di vista tecnologico. Un'urgenza probabilmente dettata dalle comparazioni poco lusinghiere con l'hardware della PlayStation 4 di Sony, ma che non deve far dimenticare che l'Xbox One è stata progettata con una filosofia molto diversa dalla vecchia Xbox 360, con alcuni elementi ambiziosi quali la gestione di più macchine virtuali. C'è dunque un approccio molto diverso alla gestione della potenza grafica tridimensionale e al suo bilanciamento, argomenti di cui i progettisti erano ansiosi di parlare.

Microsoft peraltro in passato aveva già condiviso i dati relativi all'architettura delle proprie console e la sua presentazione all'Hot Chips 25 di quest'anno presso la Stanford University aveva lasciato intendere che il team di progettazione fosse disposto a parlare in dettaglio del proprio silicio ben più di quanto Sony non fosse disposta a fare. Un atteggiamento comprensibile quando si dispone di una scheda tecnica nettamente in vantaggio rispetto a quella della concorrenza.

La domanda che molti di voi si porranno sarà se stiamo leggendo una libera discussione tecnica o un esercizio di pubbliche relazioni. Cerchiamo di non illuderci: ogni intervista che raggiunge la pubblicazione è in un qualche modo un esercizio di PR tra intervistato e intervistatore, che si parli con Microsoft, Sony o chiunque altro. La delusione maggiore in occasione dell'intervista a Mark Cerny era che il progettista della PS4 non ci avevesse fornito informazioni che non fossero state già riportate in precedenza.

È abbastanza chiaro che specifiche tecniche impressionanti, una line-up abbastanza solida e una strategia di pubbliche relazioni ottimamente gestita in fase di lancio, abbiano messo l'azienda giapponese in una posizione invidiabile. Per Microsoft, le cose sono andate diversamente: bisognava spiegare una filosofia progettuale che i core gamer non avrebbero apprezzato tanto facilmente e veicolare il messaggio che il livello tecnologico di una console non si limita solo alla potenza di calcolo della GPU o alla quantità di memoria. Ironia della sorte, parliamo degli stessi punti di forza che avevano permesso a Xbox 360 di dominare i primi anni della console war dell'attuale generazione.

Ecco quindi l'intervista, probabilmente la più corposa mai pubblicata tra le pagine di questa rubrica, partendo con le presentazioni iniziali.

Andrew Goossen: 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.

Nick Baker: 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.

"Volevamo veramente costruire una console ad altre prestazioni ma anche efficiente come consumi e in grado di prendere possesso di un salotto moderno."

360
Xbox One è stata disegnata dallo stesso team che ha realizzato l'originale Xbox 360 che vediamo qui ritratta nel suo formato di lancio classico. All'epoca si decise di implementare un chip grafico allo stato dell'arte in concomitanza con un approccio multi-core quando invece i PC optavano ancora per un design a core singolo ultraveloce.

Digital Foundry: Quali conclusioni avete tratto dall'esperienza con Xbox 360 al termine del suo ciclo vitale e come ha influenzato la progettazione dell'architettura di Xbox One?

Nick Baker: 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.

Digital Foundry: Siete riusciti a integrare la parte di calcolo centrale e di elaborazione grafica in un'unica soluzione tecnologica: è stata una delle sfide più significative nel design del processore?

Nick Baker: 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?

Andrew Goossen: 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.

"Possiamo completamente riscrivere il gestore della memoria del sistema operativo per CPU e GPU, un'operazione praticamente impossibile senza virtualizzazione."

snap
La possibilità di far girare delle applicazioni in simultanea con un gioco senza che queste vadano a impattare in modo considerevole sulla performance dipende totalmente da un enorme lavoro d'ingegneria di hardware e software. A fare la differenza sarà la qualità delle applicazioni: al momento la gestione dei gruppi e le funzioni di video editing sembrano funzionare veramente bene.

Digital Foundry: Gli 8GB erano quindi il vostro obiettivo sin dall'inizio della progettazione?

Andrew Goossen: 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.

Digital Foundry: Sul fronte della CPU, la curiosità è forte: pesche avete scelto l'otto core Jaguar, invece del, per esempio, quattro core Piledriver? È tutta questione di performance per watt?

Nick Baker: 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.

Digital Foundry: Si tratta del processore Jaguar com'esce dalla fabbrica o avete apportato qualche modifica?

Nick Baker: 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.

Digital Foundry: Si è detto che la console è dotata di 15 processori: potete spiegarvi meglio?

Nick Baker: 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.

Digital Foundry: Ma fino a che punto questo hardware verrà utilizzato, in particolar modo nei titoli cross-platform?

Nick Baker: 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.

Andrew Goossen: "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.".

Digital Foundry: La gestione della memoria è uno dei punti più controversi che separano i due sistemi. Ci siamo quindi posti due domande: se le GDDR5 sono da tempo la configurazione preferita per la gestione del calcolo tridimensionale, perché Microsoft non ha fatto questa scelta, visto anche il suo potenziale economico? E poi, era giusto presumere che questa maggiore larghezza di banda di RAM fosse stata esclusa molto presto nel processo di progettazione della console?

Nick Baker: 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.

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

Digital Foundry: E in effetti sembrava che non ci fosse alcuna reale garanzia a proposito della disponibilità di moduli da 4 GB di GDDR5 al momento del lancio. E in effetti l'azzardo pare aver pagato: fino a poco tempo fa gli SDK di Sony si riferivano a soli 4GB of RAM di sistema. Suppongo che il chipset di Intel Haswell con l'eDRAM sia l'equivalente di quello che avete fatto con la ESRAM su Xbox One. Perché l'avete scelta al posto della eDRAM che tante soddisfazioni vi aveva dato su Xbox 360?

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

Digital Foundry: Quindi non avete scelto di optare per un die principale ed uno secondario come avevate fatto su Xbox 360?

Nick Baker: 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.

Digital Foundry: Se consideriamo l'ESRAM, alla presentazione dell'Hot Chips avete spiegato che è composta da quattro blocchi da 8MB ciascuno. Come funziona il suo utilizzo nel dettaglio?

Nick Baker: 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.

Digital Foundry: Simultaneamente? In effetti c'è stata un sacco di controversia su come abbiate sommato la banda passante della memoria e di come questo non fosse possibile nella realtà.

Nick Baker: 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."

Andrew Goossen: 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.

Digital Foundry: Quindi l'ESRAM a 140MB-150MB è un target realistico a cui si possono veramente sommare i valori di lettura scrittura della RAM DDR3?

Nick Baker: Si, è già stato misurato.

"L'Xbox One riserva un 10% delle prestazioni della GPU per elaborazioni diverse dalla grafica. Si tratta di una riserva di potenza usata per compiti di GPGPU, per la gestione di Kinect e per lo snap mode."

kinect
Il tool di debug del Kinect offre un interessante anticipazione su come la telecamera osserva il mondo esterno. La sfida di Microsoft e degli sviluppatori è sarà l'integrazione efficace di questa tecnologia nei giochi. Detto questo, abbiamo visto come Kinect controlla la nuova dashboard e vi possiamo garantire che il risultato è veramente impressionante.

Digital Foundry: Sui documenti trapelati prima della presentazione della console, la larghezza di banda di picco era molto minore e poi improvvisamente pareva che la banda di picco fosse raddoppiata una volta che il silicio era andato in produzione. Era un fenomeno atteso o non ve l'aspettavate? Siete stati conservativi o ve ne siete resi conto quando avete messo le mani sul primo prototipo e vi siete detti, caspita, può fare questo?

Nick Baker: 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.

Andrew Goossen: 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.

Digital Foundry: In effetti, il livello di coerenza tra l'ESRAM e il pool di memoria DDR3 sembrerebbe essere molto più flessibile rispetto a quanto si pensava precedentemente. Molti credono che 32MB di ESRAM siano però pochi per gestire in autonomia interi elementi di rendering: stando a quanto suggerisce Goosen tuttavia, gli sviluppatori possono usare entrambi i pool di memoria per aggirare questo problema?

Andrew Goossen: 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.

Digital Foundry: Ed è quindi possibile accedere dalla CPU in lettura al contenuto della ESRAM, giusto? Questo non era possibile su Xbox 360 eDRAM.

Nick Baker: Si, è possibile ma è molto lento.

Digital Foundry: Online ci sono state parecchie discussioni a proposito della velocità d'accesso della ESRAM e di come si comporti la memoria a bassissima latenza che la compone. La mia comprensione della tecnologia legata alla grafica è che si rinuncia ad una bassa latenza per avere quanta più banda possibile ma per farlo bisogna parallelizzare sul massimo numero di unità di calcolo disponibili. Quindi la bassa latenza condiziona realmente la performance della GPU?

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

Digital Foundry: Le DirectX sono un'API ormai matura e gli sviluppatori hanno accumulato un sacco di esperienza nel loro utilizzo: fino a che punto pensate che questo potrà avvantaggiare Xbox One? Tenendo in considerazione quanto sono solide le vostre API, avete in qualche modo ottimizzato il silicio che gli sta intorno?

Andrew Goossen: 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.

"La variante più evidente riguarda il numero di unità di calcolo inserite sul die ed è stato l'aspetto su cui ci siamo concentrati sin dall'inizio. Come dire, contiamo il numero di CU e i Gigaflop e dichiariamo il vincitore in base a questo?"

gpu
Sony o Microsoft non lo ammetteranno mai, ma l'architettura grafica di base delle loro GPU è largamente basata sul design AMD di Pitcairn (sinistra) e Bonaire (destra) che si possono trovare sulle Radeon HD 7870 e 7790. I progettisti dell'Xbox One stanno facendo molta fatica a convincere un sacco di giocatori che un core grafico meno performante può ottenere risultati simili come anche i benefici che derivano da una CPU più veloce. Anche i vantaggi di avere chip a funzione definita pensati per occuparsi di task specifici e alleggerire il carico di lavoro di processore centrale e quello grafico sembrano essere stati largamente ignorati.

Digital Foundry: Guardando alle specifiche della GPU, sembra che Microsoft abbia scelto il design di AMD Bonaire mentre Sony sia andata verso Pitcairn e la seconda ha ovviamente un potenziale di calcolo superiore. Parliamo della GPU: su quale famiglia di processori è basata? Southern Islands, Sea Islands, Volcanic Islands?

Andrew Goossen: 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

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

Andrew Goossen: 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.

Digital Foundry: A proposito del guadagno di prestazioni del 6.6 per cento del clock della GPU rispetto al 17% di potenza di calcolo in più offerta dalle due unità di calcolo supplementari, ci sono buone possibilità che la concorrenza fosse legata al numero di ROP che volevate integrare all'intero di Xbox One? Le 16 ROP sono un altro punto di differenziazione del sistema rispetto alle 32 della concorrenza.

Andrew Goossen: 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.

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

Digital Foundry: Con la recente rivelazione che Ryse girerà ad una risoluzione di 900p e Killer Instinct a 720p, quali limitazioni possono esserci state che hanno impedito a questi giochi di girare a 1080p?

Andrew Goossen: 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.

Digital Foundry: Quindi qual'è stato il vostro approccio alla filosofia di calcolo 3D tramite GPGPU? Sony ha posto l'accento sulle sue pipeline più ampie in grado di sfruttare meglio le ALU. Qual è la vostra filosofia sul fronte della GPGPU?

Andrew Goossen: 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.

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

Anche se la CPU di Microsoft opportunamente accelerata e il silicio dedicato non forniscono quell'accelerazione di prestazioni che l'azienda di Redmond afferma, la riduzione della risoluzione può sopperire in modo efficace alla mancanza di pura potenza di elaborazione 3D. Ecco Crysis 3 mentre gira a varie risoluzioni sub-HD.

Digital Foundry: Parlando di bilanciamento delle due GPU, la questione sembra quindi essere tutta tra la memoria ad alta coerenza in lettura di Xbox One contro il numero delle ALU di PS4. Le ACE (Asynchronous Compute Engine) aggiunte a PS4 non dovrebbero risolvere eventuali colli di bottiglia che sbilanciano la console Sony?

Andrew Goossen: 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.

Digital Foundry: Quindi spesso siete condizionati dalle prestazioni della CPU: questo spiega l'implementazione dei Data Move Engine in gran numero.

Andrew Goossen: 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.

Nick Baker: 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.

Digital Foundry: Un'altra novità tecnica interessante della presentazione Hot Chip è stata sulla memoria eMMC NAND presente a sistema ma non utilizzabile dai giochi. Quindi, a cosa serve?

Andrew Goossen: 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.

Digital Foundry: Potete spiegarci come siete arrivati all'aumento di prestazioni di CPU e GPU e che effetto ha avuto sul ritmo di produzione?

Nick Baker: 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.

Andrew Goossen: 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.

Digital Foundry: Potete dirci quanta corrente consuma l'Xbox One durante il gioco?

Microsoft PR: Non è un dato che possiamo divulgare al momento.

Nick Baker: 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.

Digital Foundry: Abbiamo avuto modo di parlarne con gli ingegneri di Microsoft per oltre un'ora e mezza. Come avete intuito, il resoconto appena letto è una sintesi dei punti più interessanti e comprensibili a un pubblico comunque tecnicamente molto smaliziato. Siamo andati talmente in dettaglio al punto da aver trascurato la data di lancio della console del prossimo Novembre. Abbiamo quindi chiesto ai nostri interlocutori come ci si sente a vedere uscire una console dai nastri della produzione dopo aver trascorso anni a concepirla e svilupparla?

Nick Baker: 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.

Andrew Goossen: 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.

Traduzione a cura di Matteo Lorenzetti.

Riguardo l'autore

Richard Leadbetter

Richard Leadbetter

Technology Editor, Digital Foundry

Rich has been a games journalist since the days of 16-bit and specialises in technical analysis. He's commonly known around Eurogamer as the Blacksmith of the Future.

Altri articoli da Richard Leadbetter

Commenti (106)

I commenti ora sono chiusi. Grazie per avere partecipato!

Nascondi i commenti coi punteggi più bassi
Ordine
Visualizza

Contenuti correlati o recenti

Per lo sviluppatore di Star Citizen il ray tracing è un "grande mal di testa"

Ben Parry di Cloud Imperium Games accenna alle difficoltà di implementazione della tecnologia.

Un rivenditore polacco regala Fallout 76 in bundle con i gommini per Dualshock 4

Con 5 dollari di gommini per gli stick analogici, il gioco in regalo.

Il gioco più venduto in Giappone nel 2018 è stato Monster Hunter World

Stilata una Top 10 dei titoli più venduti in territorio giapponese lo scorso anno.