Digital Foundry vs. arquitetos da Xbox One
"Existe muita informação errada cá fora e muitas pessoas que não compreendem. Na verdade estamos extremamente orgulhosos do nosso design."
A dois meses da chegada na nova geração de consolas, muitos já se decidiram sobre qual máquina oferece jogos mais poderosos antes de um único jogo ter chegado. Comparem especificações básicas de largura de banda da memória e gráficas lado a lado e parece de caras - a PlayStation 4 bate a Xbox One de tal forma que uma discussão sensata sobre os respetivos méritos de cada consola parece impossível. Usam a mesma tecnologia AMD, só que a Sony tem memória mais rápida e um chip gráfico muito maior. Mas é assim tão simples?
Na ressaca de notícias de fontes desconhecidas que sugerem que a PS4 tem uma grande vantagem sobre a rival Xbox, a Microsoft quis colocar tudo preto no branco. O Digital Foundry conversou com dois funcionários principais por detrás do projeto Xbox One - engenheiros apaixonados que queriam a oportunidade para passarem as suas histórias numa discussão técnica forte onde todas as controvérsias poderiam ser discutidas. Momentos depois da conversa começar, rapidamente ficou claro que o equilíbrio seria o tema.
"Para desenhar uma boa e bem equilibrada consola tens mesmo que considerar todos os aspetos do programa e equipamento. É mesmo sobre a combinação dos dois e alcançar um bom equilíbrio em termos de performance," diz Andrew Goossen, técnico na Microsoft.
"Na verdade estamos muito contentes pela oportunidade de falar convosco sobre o design. Existe muita informação errada e muitas pessoas que não percebem - estamos na verdade extremamente orgulhosos do nosso design. Pensamos que temos um equilíbrio muito bom, uma performance muito boa, temos um produto que pode gerir outras coisas além de apenas ALU em bruto (poder computacional GPU). Também existe um bom número de outros aspetos e requisitos de design que colocamos me redor de coisas como latência, rácios de fotogramas estáveis e que os títulos não sejam interrompidos pelo sistema e outras coisas como isso. Irás ver isto como um continuado tema impregnante no nosso design de sistema."
"O Andrew disse-o muito bem: queremos realmente construir uma máquina de alta performance eficiente no consumo," adiciona Nick Baker, gestor da equipa de arquitetos de equipamento. "Queríamos mesmo torná-la relevante na sala de estar moderna. Falando sobre AV, somos os únicos a colocar AV in e out para a tornar no equipamento de media que está no centro do teu entretenimento."
Nós vimos a dash da XO e as funções media são bem fixes, mas primeiro, é tudo sobre os jogos. Podemos dizer que existem duas áreas principais de controvérsia em redor do design da XO - especificamente as áreas nas quais é considerada mais fraca que a PS4: o esquema de memória e a quantidade de poder GPU. Ambos os sistemas tem 8GB de RAM, mas a Sony escolheu 8GB da mais larga e mais rápida GDDR5, com pico de passagem nos 176GB/s enquanto a Microsoft optou por DDR3, com uma largura de banda máxima apenas de 68GB/s - significativamente mais baixa. No entanto, isto é fornecido por uma ESRAM on-chip, que maximiza a 204GB/s. Na teoria, apesar de baralhar e dividir recursos entre as duas piscinas de memória ser um fator, a XO claramente tem a sua própria abordagem para assegurar uma adequada largura de banda por todo o sistema.
A gestão de memória é um dos pontos mais divisores que separam os dois sistemas. A questão certamente será se a GDDR5 é o esquema preferido, porque não o escolheu a Microsoft? Ainda rica ao extremo, claramente a companhia poderia suportar o extra pela GDDR5. Ficamos a pensar se é justo presumir que esta RAM com maior largura de banda foi descartada bem cedo no processo de produção, e se sim, porquê?
"Sim, penso que está certo. Em termos de obter a melhor combinação possível de performance, tamanho de memória, poder, a GDDR5 leva-te um pouco para um lugar desconfortável," diz Baker. "Ter ESRAM custa pouquíssima energia e tem a oportunidade de te dar uma largura de banda muito alta. Podes reduzir a largura de banda na memória externa - isso poupa muito consumo de energia e a comodidade da memória é mais barata para conseguires suportar mais. Essa é mesmo a razão por detrás disso...se queres uma alta capacidade de memória, relativo baixo consumo e muita largura de banda não existem muitas formas de resolver isso."
A controvérsia do sistema de largura de banda combinado
Baker insiste em abordar a ideia errada que a equipa criou um design que não pode aceder às suas piscinas de memória ESRAM e DDR3 ao mesmo tempo. Os críticos dizem que estão a juntar as larguras de banda disponíveis para inflacionar os seus números e que isto não é possível num cenário real.
"Podes pensar na ESRAM e na DDR3 como oito controladores de memória no total, portanto existem quatro controladores de memória externos (que são 64-bit) que vão para a DDR3 e depois existem quatro controladores de memória externos que são 256-bit e vão para a ESRAM. Estão todas ligadas através de uma trave e portanto será verdade que podes ir diretamente, simultaneamente da DRAM e ESRAM," explica.
A controvérsia em redor da ESRAM apanhou a equipa de design de surpresa. A noção que a XO é difícil de trabalhar é talvez bem difícil de engolir para a mesma equipa que produziu a 360 - de longe a consola mais fácil para a qual desenvolver, especialmente nos anos iniciais da atual geração de consolas.
"Esta controvérsia é bem surpreendente para mim, especialmente quando vês a ESRAM como a evolução da eDRAM da 360. Ninguém questiona na 360 se podemos ter a concorrente largura de banda eDRAM com a largura de banda a sair da memória do sistema. De facto, o design de sistema precisou disso," explica Goossen.
"Tivemos que encostar todos os nossos buffers de vértices e todas as nossas texturas da memória de sistema concorrente ao seguir com alvos de renderização, cor, profundidade, buffers de matriz que estavam na eDRAM. Claro que com a XO seguimos com um design no qual a ESRAM tem a mesma natural extensão do que tínhamos com a eDRAM na 360, ter ambas a seguir concomitantemente. É uma bela evolução da 360 pois pudemos limpar muitas limitações que tínhamos com a eDRAM.
"A 360 era a consola mais fácil para a qual desenvolver, não era assim tão difícil para os nossos programadores se adaptarem à eDRAM, mas havia um número de locais onde dissemos, 'seria fixe se todo um alvo de renderização não tivesse que viver na eDRAM' e então corrigimos isso na XO onde temos a capacidade de transbordar da ESRAM para a DDR3, portanto a ESRAM está completamente integrada nas nossas tabelas de página e portanto podes tipo misturar e igualar a memória ESRAM e DDR consoante continuas...Da minha perspetiva é basicamente uma evolução e melhoria - uma grande melhoria - sobre o design que tínhamos na 360. Estou surpreso com tudo isto, muito francamente."
"A 360 era a consola mais fácil para a qual desenvolver, não era assim tão difícil para os nossos programadores se adaptarem a eDRAM...a [ESRAM] é basicamente uma evolução e melhoria...sobre o design que tínhamos na 360."
A sério, o nível de coerência entre as piscinas de memória ESRAM e DDR3 soa muito mais flexível do que se pensou antes. Muitos acreditavam que os 32MB de ESRAM é um limite duro para alvos de renderização - portanto podem os programadores realmente "misturar e igualar" como sugere Goossen?
"Oh, absolutamente. E até podes fazer para que porções do teu alvo de renderização tenham muito pouco falta de cobertura...por exemplo se vais fazer um jogo de corrida e o teu céu tem pouca cobertura, podes colocar esses sub-conjuntos dos teus recursos na DDR para melhorar a utilização ESRAM," diz ele, enquanto explica também que formatos personalizados foram implementados para tirar mais daqueles preciosos 32MB.
"Na GPU adicionamos alguns formatos de alvos de renderização comprimidos como o nosso 6e4 [6 bit mantissa e 4 bits exponente por componente] e formatos HDR 7e3 [onde é formatado o 6e4] que foram muito, muito populares na 360, que ao invés de aplicar um fluturar de 16-bit por componente 64bpp de alvo de renderização, podes fazer o equivalente no qual usamos 32 bits - portanto focamo-nos muito para realmente maximizar a eficiência e utilização da ESRAM."
Como a largura de banda ESRAM duplicou em equipamento de produção
Mais ceticismo rodeia o súbito salto na largura de banda da ESRAM dos iniciais 102GB/s para o que tem agora - 204GB/s. Apresentamos a notícia baseado primeiro numa fuga de um programador numa entrada de blogue que a equipa de tecnologia na Microsoft em Abril, mas secções da "internet" não ficaram convencidas. Os críticos dizem que os números não batem certo. Então como surgiu o massivo aumento na largura de banda?
"Quando começamos, escrevemos umas especificações," explica Baker. "Antes de entrarmos mesmo em quaisquer detalhes de implementação, tivemos que dar aos programadores algo sobre o qual planearem antes de termos o silício, antes de o termos sequer a correr em simulação, e dissemos que a largura de banda mínima que queríamos da ESRAM era 102GB/s. Isso tornou-se em 109GB/s [com o aumento na velocidade da GPU]. No final, assim que implementas isto, a lógica acabou por ser que podias ir muito mais acima."
A grande revelação foi que a ESRAM poderia ler e escrever ao mesmo tempo, uma declaração que aparentemente veio do nada. Alguns acreditaram que baseado na informação disponível dos papeis que escaparam, isto simplesmente não era possível.
"Existem quatro faixas de 8MB, mas não é um pedaço contíguo de 8MB de memórica dentro de cada uma dessas faixas. Cada faixa, esses 8MB são separados em oito módulos. Isto deve abordar se podes mesmo largura de banda para escrita e leitura na memória em simultâneo," diz Baker.
"Sim podes - existem atualmente muitos mais blocos individuais que compõe toda a ESRAM portanto podes falar com eles em paralelos. Claro que se estás a atingir a mesma área consecutivamente, não consegues espalhar a tua largura de banda portanto essa é uma das razões para em testes reais teres 140.150GB/s ao invés do pico de 204GB/s...não são apenas quatro pedaços de 8MB de memória. É muito mais complicado do que isso e dependendo do padrão podes usar isso ao mesmo tempo. É o que te deixa ler e escreve ao mesmo tempo. Tens que adicionar largura de banda para escrita e leitura assim como adicionar largura de banda para escrita e leitura na memória principal. É apenas uma das ideias erradas que queríamos clarificar."
Goossens apresenta a conclusão:
"Se apenas vais fazer uma leitura estás bloqueado a 109GB/s, se estás a fazer apenas uma escrita estás bloqueado nos 109GB/s," diz. "Para ir além disso tens que misturar as leituras e escritas mas quando fores olhar para as coisas que estão tradicionalmente na ESRAM, tais como os teus alvos de renderização e os teus buffers de profundidade, eles tem intrinsecamente muitas escritas de leitura modificadas nas misturas e nas atualizações do buffer de profundidade. Essas são as coisas naturais para colocar na ESRAM e as coisas naturais das quais tirar partido nas coincidentes leituras/escritas."
O argumento da Microsoft parece bem direto. Na teoria, os 200GB/s de largura de banda "real" da XO bate o pico de 176GB/s da PS4. A questão é até que ponto canalizar recursos através dos relativamente pequenos 32MB da muito mais rápida ESRAM irá causar problemas para os programadores. O argumento da Microsoft é que os criadores de jogos já tem experiência com isto devido ao esquema eDRAM na 360 - e a ESRAM é a evolução natural do mesmo sistema.
A largura de banda de memória é uma coisa, mas a capacidade gráfica é outra. A PS4 desfruta de uma clara vantagem em termos de unidades computacionais GPU on-board - uma estatística em bruto além de qualquer dúvida, e que por sua vez oferece um enorme aumento às invejáveis especificações da PS4. Goossen confirma primeiro que a tecnologia gráfica das duas é derivada da mesma família "Island" da AMD antes e abordar em profundidade a aparente deficiência GPU da consola Microsoft.
"Tal como os nossos amigos somos baseados na família Sea Islands. Fizemos um bom número de alterações em diferentes partes das áreas...A maior coisa em termos do número de unidades computacionais, que tem sido no qual tem sido muito fácil se focarem. É tipo, hei, vamos contar o número de CUs, contar os gigaflops e declarar um vencedor baseado nisso. A minha opinião é que quando compras uma gráfica, vais pelas especificações ou na verdade corres alguns testes?" diz ele.
"Primeiro, não temos jogos disponíveis. Não podes ver os jogos. Quando vês os jogos irás dizer, 'qual é a diferença na performance entre eles'. Os jogos são os testes. Tivemos a oportunidade com a XO de verificar muito do nosso equilíbrio. O equilíbrio é realmente fulcral para uma boa performance numa consola de jogos. Não queres que um dos teus engarrafamentos seja o principal engarrafamento que te atrasa."
Ajustando o equilíbrio e performance da Xbox One
A abordagem da Microsoft foi ir para a produção sabendo que existiria espaço para aumentar a performance no silício final. Goossen descreve-o como "sob-ajustar" o sistema. Jogos em produção foram depois usados para determinar como fazer uso do espaço disponível.
"O equilíbrio é tão fulcral para uma performance mesmo eficaz. Tem sido mesmo bom na XO com Nick e a sua equipa - o pessoal do design de sistema construiu um sistema no qual tivemos a oportunidade de verificar os nossos equilíbrios no sistema e fazer ajustes de acordo," revela Goossen. "Fizemos um bom trabalho quando fizemos todas as nossas análises e simulações há um par de anos atrás, adivinhando onde os jogos iriam estar em termos de utilização? Tomamos as decisões corretas no equilíbrio na altura? Assim sendo aumentar o relógio da GPU é o resultado de ajustar o nosso equilíbrio."
"Sabíamos que tínhamos o espaço Não sabíamos o que queríamos fazer com ele até termos jogos para testar. Em quanto aumentas a GPU? Em quanto aumentas a CPU?" pergunta Baker.
"Tínhamos o espaço. É uma coisa gloriosa de ter no lançamento de uma consola. Normalmente falas em ter um downclock," diz Goossen. "Tivemos uma oportunidade única para ir e escolher os pontos onde queríamos melhoriar a performance e foi fantástico ter os jogos de lançamento para usar como forma de conduzir uma decisão informada sobre melhorias na performance que poderíamos tirar do espaço extra."
Goossen também revela que o silício da XO contém adicionais unidades computacionais - como especulamos anteriormente. A presença de equipamento redundante (duas CUs são desativadas em consolas de venda) permitiu à Microsoft julgar a importância do poder computacional versus velocidade do relógio:
"Todos os kits de desenvolvimento XO tem na verdade 14 CUs no silício. Duas delas são reservadas para a redundância na manufaturação, mas poderíamos experimentar - se houvessem mesmo 14 CUs que tipo de benefício teríamos sobre as 12? E se o relógio GPU fosse aumentado que tipo de vantagem na performance teríamos? E vimos os títulos de lançamento - olhamos para muitos jogos com muita profundidade - e descobrimos que seguir com 14 CUs não era tão eficaz quanto o aumento de 6.6 por cento que fizemos no relógio."
Presumindo crescimento do poder computacional com a adição de duas CUs extra, as matemáticas podem não soar corretas aqui, mas como a nossa recente análise - sem mencionar testes PC - revela, as unidades computacionais AMD não crescem de forma linear. Existe uma lei de retornos diminuitivos.
"Cada um dos kits de desenvolvimento XO tem na verdade 14 CUs no silício....E vimos os jogos de lançamento...Descobrimos que seguir com 14 CUs não era tão eficaz quanto o aumento de 6.6 por cento que fizemos ao relógio."
"Todos sabem da internet que seguir com 14 CUs nos deveria ter dado quase 17 por cento mais performance," diz, "mas em termos de jogos medidos - o que ultimamente conta realmente - é que foi uma melhor decisão de engenharia aumentar o relógio. Existem vários engarrafamentos no encadeamento que podem impedir-te de ter a performance que queres se o teu design não estiver equilibrado."
"Aumentar a frequência afeta toda a GPU enquanto adicionar CUs aumenta os shaders e ALU," diz Bkaer.
"Certo. Ao corrigir o relógio, não só temos um aumento na nossa performance ALU, também aumentamos o rácio de vértices, aumentamos o nosso rácio de pixeis e ironicamente aumentamos a largura de banda ESRAM," continua Goossen.
"Mas também aumentamos a performance em áreas em redor de engarrafamentos tais como levantamentos a passar pelo encadeamento, a performance na leitura de GPRs da piscina GPR, etc. As GPUs são imensamente complexas. Existem infinidades de áreas na conduta que podem ser o teu engarrafamento em adição à performance ALU e de procura."
Computação GPU e a importância da CPU
Goossen também acredita que documentos Sony que escaparam via VGLeaks reforçam o argumento da Microsoft:
"A Sony estava até a concordar connosco. Disseram que o seu sistema estava equilibrado para 14 CUs. Eles usaram esse termo: equilíbrio. O equilíbrio é tão importante em termos da tua eficiência de design. As suas 4 adicionais CUs são muito beneficiais para a sua carga adicional GPGPU. Na verdade seguimos por algo muito diferente nisso. As experiências que fizemos demonstraram que tínhamos espaço extra nas CUs também. Em termos de equilíbrio, fizemos índice mais em termos das CUs do que necessário para termos CU de sobra. Há espaço para os nossos jogos crescerem com o tempo a respeito do uso das CUs."
A abordagem da Microsoft à computação GPU assíncrona é um pouco diferente da da Sony - algo que iremos cobrir mais tarde. Mas essencialmente, ao invés de se concentrar extensivamente no poder computacional em bruto, a sua filosofia é que tanto a CPU como a GPU precisam de acesso de latência menor à mesma memória. Goossen aponta para o sistema de registo de esqueletos Exemplar no Kinect na 360 como um exemplo de terem seguido essa direção.
"A Exemplar ironicamente não precisam de muita ALI, É mais sobre a latência que tens em termos de procura de memória, portanto esta é uma espécie de evolução natural para nós," diz ele. "É tipo, ok, é o sistema de memória que é mais importante para algumas cargas de trabalho GPGPU particulares."
A equipa também salienta que o aumento de 150MHz na velocidade do relógio CPU é na verdade muito mais importante do que muitos acreditam que é.
"Interessante é que a maior fonte para as nossas quedas no rácio de fotogramas na verdade vêem da CPU, não da GPU," revela Goossen. "Adicionar a margem da CPU...na verdade tivemos títulos que perdiam fotogramas em grande parte porque estavam direcionados para a CPU em termos de encadeamento principal. Ao providenciar o que parece como um pequeno reforço, é na verdade uma grande vitória para nós para assegurar que temos os rácios de fotogramas estáveis na nossa consola."
Isto em parte explica porque vários dos blocos de equipamento personalizado - os Data Move Engines - são direcionados para libertar tempo CPU. O traçar de perfil revelou que este era um problema genuíno, que foi equilibrado com uma combinação do aumento na velocidade do relógio e silício de função fixa - os processadores adicionais inseridos no processador XO.
"Tivemos muito descarregamento CPU a decorrer. Temos o SHAPE, o processador de comandos mais eficiente relativo ao design padrão, temos o aumento no relógio - é em grande parte para assegurar que temos o espaço livre para os rácios de fotogramas," continua Goossen - mas parece que os DME do sistema também podem ajudar a GPU.
"Imagina que renderizaste para um buffer de profundidade ali na ESRAM. E agora estás a passar para outro buffer de profundidade. Podes querer e sacar do que agora é uma textura para a DDR para que possas texturizar dela mais tarde, e não estás a fazer toneladas de leituras dessa textura portanto faz mais sentido que esteja na DDR. Podes usar os DME para mover esas coisas assincronamente juntamente com a GPU para que a GPU não perca qualquer tempo na passagem. Colocas o motor DMA a fazer isso. Agora a GPU pode ir e trabalhar de imediato no próximo alvo de renderização ao invés de simplesmente mover pedaços."
Outras áreas de silício personalizado também foram desenhadas para ajudar a performance gráfica.
"Fizemos coisas na GPU assim como nas nossas sobrecamadas de equipamento para assegurar rácios de fotogramas mais consistentes," adiciona Goosssen. "Temos duas camadas independentes que podemos dar aos títulos onde uma pode ser conteúdo 3D, uma pode ser o HUD. Temos um conversor de maior qualidade que na 360. O que isto faz é que te permite mudar os parâmetros do conversor numa base de fotograma a fotograma."
A conversão dinâmica de resolução não é novo - vimos isso implementado em muitos jogos de atual geração. A sério, o primeiro exemplo na atual geração é um jogo Sony: WipEout HD. O impacto na qualidade de imagem pode ser brusco a 720p, mas em resoluções maiores e juntamente com conversão superior, pode ser uma medida viável para equalizar a performance.
"Falei sobre erros CPU a causar erros nos fotogramas...cargas de trabalho GPU tendem a ser mais coerentes fotograma a fotograma. Não tendem a haver grandes picos como tens na CPU e portanto podes adaptar-te a isso," explica Goossen.
"O que estamos a ver em jogos é o adotar da noção da conversão dinâmica de resolução para evitar rácios de fotogramas com erros. Quando começam a entrar numa área em que começam a chegar à margem onde potencialmente poderiam exceder o orçamento, podem começar a dinamicamente baixar a resolução e podem manter o seu HUD em termos da resolução verdadeira e o conteúdo 3D é apertado. Novamente, na minha opinião enquanto jogador prefiro ter um rácio de fotogramas consistente e alguma redução do número de pixeis do que ter erros no rácio de fotogramas."
"Também de uma perspetiva de eficiência/consumo, funções fixas são mais amigas do consumo em unidades de função fixa," adiciona Baker. "Colocamos compressão de data ali também, portanto temos compressão/descompressão LZ e também descodificação JPEG de movimento que ajuda com o Kinect. Portanto existe mais nos DME do que mover de um bloco de memória para o outro."
Temos falado em profundidade há mais de uma hora e o nosso tempo está a terminar. Toda a discussão tem sido completamente centrada na tecnologia, ao ponto de quase ter esquecido que o lançamento da Xbox One em Novembro provavelmente ser altamente importante para Nick Baker e Andrew Goossen pessoalmente. Como é ter a consola a começar a sair da linha de produção após anos em desenvolvimento?
"Sim, lançar alguma coisa é sempre, sempre uma sensação fantástica [mas] a minha equipa funcionou em múltiplos programas em paralelo - estamos constantemente ocupados a trabalhar na equipa de arquitetura," diz Baker.
Goossen tem a palavra final:
"Para mim, a maior recompensa é ir e jogar os jogos e ver que tem um aspeto fantástico e isso sim, é por isto que trabalhamos tão arduamente. Como um tipo de gráficos é tão recompensador ver aqueles pixeis no ecrã."