Optimização para hardware específico… em que consiste?

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.

 



17 Comentários
Antigos
Recentes
Inline Feedbacks
Ver todos os comentários
Eraser
Eraser
23 de Dezembro de 2021 8:21

De certa forma pode-se dizer que a optimização no fundo é o segredo da Apple.

Eraser
Eraser
Responder a  Mário Armão Ferreira
23 de Dezembro de 2021 8:39

Sim e agora com os M1 arrasou.
Os gpu da ps2 e cpu da ps3 tiveram mão da sony no desenvolvimento.

Edson Nill
Edson Nill
23 de Dezembro de 2021 10:09

Parabéns pelo artigo, Mário!!!!

Vitor hugo Reale Pereira
Vitor hugo Reale Pereira
23 de Dezembro de 2021 11:15

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.

Eraser
Eraser
Responder a  Vitor hugo Reale Pereira
23 de Dezembro de 2021 11:38

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.

Juca
Juca
Responder a  Mário Armão Ferreira
23 de Dezembro de 2021 15:19

Ótima informação Mário, não sabia dessa distinção técnica que separava consoles de PCs.

Last edited 2 anos atrás by Juca
Juca
Juca
Responder a  Mário Armão Ferreira
23 de Dezembro de 2021 15:57

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.

Last edited 2 anos atrás by Juca
Vitor hugo Reale Pereira
Vitor hugo Reale Pereira
23 de Dezembro de 2021 11:18

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.

Edson Nill
Edson Nill
23 de Dezembro de 2021 11:21

(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?!

Edson Nill
Edson Nill
Responder a  Mário Armão Ferreira
23 de Dezembro de 2021 12:39

Obrigado pelas explicações, Mário!

error: Conteúdo protegido