O que é que pode ser feito num sistema de hardware fixo (como as consolas), que permita que este venha a ter performances tais que, quando um jogo é convertido para PC, seja necessário hardware mais potente para fazer o mesmo.
Nota: Este artigo toca em otimizações derivadas da existência de um Hardware fixo (único e igual em todos os casos). No caso das consolas, para além de hardware fixo, as mesmas dispõem de APIs de baixo nível que lhes permitem ganhos adicionais. Mas neste artigo não vamos tocar na questão dos APIs, até porque acreditamos que este artigo de 2015, onde explicávamos, entre outras coisas, o motivo pelo qual a Xbox One não ganharia muito com o DirectX 12 (recorde-se qua na altura havia quem acreditasse que com o DirectX 12 a Xbox One recuperaria dos 40% de desvantagem do seu hardware), será explicito o suficiente.
Quando falamos de otimizações para consolas, elas existem e são tão elevadas por um único motivo… O facto de as consolas serem um hardware fixo. Ao termos um hardware fixo, isso quer dizer que podemos saber especificamente o que corre melhor naquela máquina e apontar para lá. Por exemplo, quando se fazem gráficos podemos encontra um dilema do género “Hummm… se fizermos isto podemos acelerar os GPUs da AMD… mas o problema é que isto não corre bem nas Nvidia que por sua vez ficam mais lentas”. E isto obriga a que uma otimização que beneficiava a AMD não possa ser usada uma vez que não podemos prejudicar as Nvidia. E o compromisso obriga a encontrar uma opção que seja mais neutra, e neste caso algo que ou não prejudique nenhum, ou que a beneficiar alguma, não prejudique quase nada a outra.
Dado que as consolas são hardware fixo, uma otimização que seja aplicada é garantidamente aplicada com a mesma relevância a todas as consolas existentes. Isso quer dizer que o código que estás a escrever, se te corre bem na tua consola, irá correr bem nas consolas de todos os utilizadores. Algo que não pode ser dito sobre o PC, onde o jogo quando colocado num hardware diferente do que constitui o Devkit pode ter inclusive problemas críticos de incompatibilidade. E isto porque o hardware final vai ter níveis de suporte diferentes, capacidades diferentes, performances diferentes, metodologias para realizar a mesma coisa, diferentes.
Num exemplo sobre o acabado de referir, lembra-me à uns anos atrás um criador de jogos Android ter testado o seu jogo num emulador Android para confirmar se ele correria bem após lançado. Mas o seu jogo parecia ter tido péssima recetividade, com poucos downloads e reviews negativas a alegar problemas. O que se passava era que havia um pedaço de código que corria bem no emulador, mas quando executado em muito do hardware do mundo real despoletava um “buffer overflow”, bloqueando os smartphones e obrigando a um reset de fábrica.
Numa outra perspetiva, com hardware fixo, não precisamos de estar a programar efeitos com nível de detalhe variável. Os efeitos são criados com um nível fixo, o que, curiosamente, permite que o código seja mais rápido. Da mesma forma não é necessário colocar “assets” para maior e menor qualidade. Isto não só reduz o tamanho em disco, como tambem permite que o código corra mais rápido ao não ter de correr rotinas para detetar e escolher a qualidade dos “assets” a usar.
Depois as consolas são hardware personalizado, ou seja, possuem extensões que permitem o uso de alguma tecnologia mais avançada. A Nvidia, por exemplo, possui uma grande quantidade de extensões para Open Gl, e estas extensões podem permitir baixar a sobrecarga no CPU/GPU em valores consideráveis. Em alguns casos até de forma superior ao Vulkan. Mas a AMD, essa não suporta muitas delas, pelo que os motores podem ficar limitados no que poderiam fazer devido à necessidade de compatibilidade com todo o hardware.
Mas as consolas, essas podem, e garantidamente fazem-no, tirar partido de todas as características avançadas. Por exemplo, o Hardware ID Buffer da PS4 permite a realização de Chequerboard rendering de alta qualidade a baixo custo, algo que o PC não pode fazer. A Xbox, pelo menos antes do DirectX 12 Ultimate, tambem possuía uma série de extensões personalizadas para o DirectX.
E note-se que tudo isto corre sobre umas drivers que comparadas com as do PC são extremamente simplificadas e rápidas por serem específicas e não universais. Esta situação permite que as situações geridas pelas drivers possam com uma consola bater um PC topo de gama que se coloque a fazer a mesma coisa. Basicamente a sobrecarga colocada nas chamadas às drivers é extremamente leve numa consola quando comparado com o PC.
Por fim, podemos dizer que as consolas possuem um “contrato” com os criadores de jogos. Basicamente elas garantem que os núcleos do CPU, definindo quais eles são, estão disponíveis para os jogos. E quando um núcleo é apenas disponibilizado parcialmente, o criador sabe exatamente que parte pode aceder para o usar. E isto permite um controlo perfeito de como o jogo pode utilizar os núcleos de CPU disponíveis. Já no Windows a coisa não é assim. Os processos do Windows que correm em segundo plano interferem de forma radical com a forma como um jogo corre, podendo usar qualquer núcleo em qualquer parte. E isso quer dizer que um criador nunca sabe o que esperar de um PC, pois a quantidade de software instalado, e os programas a correrem em segundo plano podem alterar as performances do jogo numa base de máquina para máquina.
Toda esta informação pode ser confirmada em diversas apresentações realizadas na Game Developers Conference (GDC). Um bom exemplo é a apresentação da Naughty Dog chamada “Parallelizing the Naughty Dog engine using fibers” que mostra como a Naughty Dog conseguiu paralelizar o código dos seus jogos de forma perfeita em todos os núcleos da consola. Mas curiosamente o uso de fibras (fibers) é algo que não funciona bem no PC.
Um outro exemplo é a apresentação “Optimizing the graphics pipeline using compute” que nos apresenta uma verdadeira tonelada de truques malucos que apenas fazem sentido em hardware fixo, como o das consolas. Coisas calculadas ao ponto de se poder perceber se são vantajosas de serem usadas ou não.
E basicamente… tudo que venha ou da Insomniac, ou da Guerrilla.
Um exemplo terra a terra
Um exemplo simples de compreender de otimização para hardware fixo, pode ser dado da seguinte maneira.
Imaginem uma caixa… Essa caixa tem uma abertura no topo por onde vocês metem bolas. Existem bolas de duas cores, verdes e vermelhas, e no interior da caixa há um sensor que deteta a cor da bola, redirecionando-a ou para a direita, ou para a esquerda da caixa de acordo com a cor. No fundo da caixa existem duas aberturas, uma de cada lado, por onde as bolas introduzidas são removidas.
Com este dado, vocês começam a meter bolas e mais bolas dentro caixa, percebendo a velocidade a que a máquina é capaz de separar as bolas e as expulsar.
Este dado torna-se relevante, pois com a velocidade de saída determinada torna-se fácil compreender qual a velocidade de entrada. Afinal de contas não vale a pena tentar alimentar a caixa com mais do que ela é capaz de debitar, pois tal só vai criar saturação na entrada.
Dado que a caixa até pode aguentar com algumas bolas lá dentro, podemos perceber por exemplo, que podemos colocar 10 bolas no interior da máquina, mas que a próxima só pode entrar depois de sair uma delas. Assim as seguintes só podem entrar à velocidade a que as bolas saem.
Percebe-se assim que, caso as bolas que se vão meter a seguir forem as que vão sair, qual o ritmo de processamento.
Isto num CPU chamam-se as dependências. Se um novo calculo precisa de um resultado de um cálculo anterior, ele só pode ocorrer quando o calculo anterior existir. Pelo que de nada nos adianta adiantar a coisa, se temos de esperar e temos.
Agora com todo este sistema a funcionar de forma otimizada, imaginem que querem a coisa a funcionar de forma genérica, em qualquer outra caixa que faça o mesmo.
Só que as caixas são todas diferentes. Umas podem levar menos bolas dentro, outras pode levar mais, umas são mais rápidas a separar as bolas, outras mais lentas. Resumidamente, os resultados vão ser uma salgalhada. Se isto forem os “timmings” internos de um videojogo o que teríamos era uma física mais rápida que outra, as personagens a moverem-se a ritmos diferentes de máquina para máquina, etc, etc.
Se queremos que haja alguma coerência nos resultados, temos de verificar qual o mínimo denominador comum, e programar para ele. Só dessa forma podemos garantir que a coisa mantem alguma coerência, e funciona. O resultado… é que a otimização para cada uma das caixas… perde-se! E apesar de podermos até ter resultados superiores com algumas caixas, para reproduzirmos os resultados da caixa original poderemos ter de recorrer a caixas bem mais capazes.
De certa forma pode-se dizer que a optimização no fundo é o segredo da Apple.
A Apple vai mais longe, pois desenha os SOCs à mão de forma a serem mais optmizados para o que eles querem.
Sim e agora com os M1 arrasou.
Os gpu da ps2 e cpu da ps3 tiveram mão da sony no desenvolvimento.
Todos eles tiveram… Muita da tecnologia dos atuais GPUs e CPUs deriva de patentes dos fabricantes de consolas que as cedem depois para reduzir custos de produção.
Parabéns pelo artigo, Mário!!!!
Matrio, se os consoles tivessem cpu e gpu dedicados não seriam mas potentes? Ou o sistema de Apu beneficia mais os consoles? Não entendo muito bem, pois , no PC temos Apus, porém as mesmas ficam longe de consoles.
APU fica mais barato, e a unica que os faz com poder significativo é a AMD.
A AMD para PC não tem APUs ao nível das APUs das consolas, pelo menos em GPU.
Fica mais barato e tem enormes vantagens.
Dado que as consolas não podem ter consumos livre pois para serem definidas como consolas tem de obedecer ao que está definido como consumo máximo das mesmas (é um regulamento energético), elas tambem não se tem de preocupar com o ter a mesma performance dos computadores de mesa.
https://ec.europa.eu/info/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/energy-label-and-ecodesign/energy-efficient-products/game-consoles_en
Nesse aspeto o APU é mais vantajoso, pois elimina as comunicações usando canais externos, ficando tudo internamente ligado. As vantagens são enormes, e permite mesmo a partilha de caches, o que traz performances adicionais se explorado no software. Infelizmente os APUs PC não tiram partido dessas vantagens pois correm o mesmo código dos PCs com GPUs discretos, mas as consolas tiram, porque como o hardware é único e fixo, sabemos que todas podem explorar a coisa da mesma forma.
Ótima informação Mário, não sabia dessa distinção técnica que separava consoles de PCs.
Na realidade há mais… a questão depois é que a maior parte dos entendidos na matéria, que vem para aqui dizer parvoices comparando o jogo A ou B no PC com o da consola, e dizendo que ele corre igual ou melhor, não percebe que isso até pode acontecer se o motor usado foi genérico e com anos de optimização para o PC.
E sim, as consolas são PCs, mas elas tiram partido de coisas que os PCs discretos não possuem, e só existem nos APUs, bem como tem rotinas e caracteristicas únicas e exclusivas. E tudo isso com motores genéricos perde-se, sendo que um motor optimizado para GPUs discretos, pode perder muito nas consolas, e como tal passar muito bem para o PC.
A questão depois é que… nem todos.
O god of war para PC refere uns requisitos elevadissimos. E no artigo eu expliquei que, sem saber se eles são reais, isso pode acontecer, dependendo do nível de optimização específico ao hardware da consola.
Mas os mimimi do PC não percebem isso.
É por isso que há cursos… e aqueles que sem os terem… acham que sabem tudo!
Mário, não sei se se referes um pouco a mim no que diz… Rsrs. Mas quando argumentei sobre a 2070 e o poder dela, não quis dizer que os consoles não podem fazer melhor, mas que nos multiplataformas a otimização dos games tendem a serem também feitos com o PC em mente, então, em nesses casos penso que cabem a comparação apesar de sabermos que nessas situações não se extrai o máximo de nenhum dos hardware nem do PC e nem do console. Meu intúito quando fiz comparações nesse nível foi de afirmar que a DLSS é uma excelente adição a qualquer plataforma de jogo, justamente por não dependerem tanto de API melhores, ou mesmo de uma estrutura de sistema completamente diferente. Mas sim, no geral, não faz sentido a comparação entre maçãs e abacaxis, mesmo que tenham propósitos parecidos de alguma forma.
Nãi Juca.. não és tu… Há muito que se passa nos bastidores que vocês não veem… Muito comentário que não entra!
E sim, os multi tem como plataforma de desenvolvimento principal o PC. Logo são bem optimizados PC.
Então toda essa questão de hardware único em jogos exclusivos ajuda os consoles, porém quando os jogos não são pensados no hardware de cada console, o jogo fica menos optimozado.
Claro que sim… Mesmo que optimizes depois para cada consola, o simples facto de usares um motor genérico, como o Unreal Engine, não permite obter os mesmos resultados que um motor dedicado.
É isso que se tenta fazer perceber quando se diz que alguns jogos PS4 correm muito bem em hardware equivalente em PC… e pode correr, uma vez que a optimização consola é reduzida. Mas quando o motor é criado de raiz para o hardware, a conversão para o PC acaba por exigir muitos mais requisitos.
A maior parte das Thirds, mesmo que desenvolvam exclusivos para uma consola, usa os seus motores genéricos. E como tal os seus jogos não são exemplos quando convertidos para PC. Muitas vezes eles até estão muito optimizados PC e a optimização das consolas passa apenas pela escolha de níveis de qualidade que lhes permita a fluidez a tempo inteiro, mas sem se mexer no código.
(OFF TOPIC) Mário, há um rumor bem forte na comunidade Nintendo do novo sucessor do Switch. Um insider (lembrando que não podemos levar essas informações tão a sério), afirma categoricamente que o switch next gen será como o switch atual, mas com algumas diferenças e terá um hardware acima do ps4, tendo muitos dos seus games em 4k por conta do DLSS. Também ele aponta que esse novo console será lançado no final de 2023, com um novo Mário kart, no caso o MK 9, além de ter o Metroid prime 4 como cross gen. Lembrando que tudo que ele aponta aqui, vai em conjunto com alguns insiders já bem conhecidos que abordam Nintendo, como a Emily Rogers, o Nate Drake, etc… alguns outros insiders afirmam que a Nintendo usará a GPU Ada Lovelace. Sei que vc não curte tantos rumores, mas caso essa informação sobre o hardware do switch esteja certo, até onde ele poderia receber portes futuros e até onde ele poderia quando comparado ao Series S que é o menos potente dos hardwares atuais?!
É prematuro comentar… Um GPU 4K pode perfeitamente ser usado numa Switch em modo Dock, mas não em modo portátil. Uma S tem um consumo que não se adequa ao uso de baterias, pelo que as velocidades de relógio em modo portátil teriam de descer.
Seja como for, a consola nunca deverá ser semelhante à S por vários motivos. Primeiro porque dificilmente a consola terá um SSD, e segundo porque igualmente dificilmente a consola terá memória GDDR6. Tudo isto porque as questões energéticas ligadas ao consumo de bateria não são as mais adequadas a esse tipo de hardware. Não digo que não possa ter, mas digo que é um bom berbicacho meter tudo isso numa bateria que dure bem a executar videojogos.
Só para teres uma ideia, uma Switch usa entre 15 a 30 watts. Um SSD usa entre 7 a 8 watts. Mete-lhe um CPU e GPU mais potente e manteres-te dentro de parâmetros é um problema.
A GDDR6 poderá ser menos problemática. Isto porque ela desceu a voltagem de cada módulo de 1,5 V da GDDR5 para 1.35 V. Mas mesmo assim a LPDDR5 está a gastar 1.05V, o que a torna mais adequada. E mais adequada fica quando ela possui um modo de gestão de energia que alterna esse valor com um mínimo de 0.5V.
Obrigado pelas explicações, Mário!