Vejamos então o que esses testes revelaram.

Análise

O FPU nos núcleos Zen 2 do PS5 ocupam a mesma largura ao longo do lado curto do núcleo, mas parece muito comprimido no outro eixo. Apesar da diminuição do tamanho, uma análise mais cuidada mostra que há muito menos área não usada, mas mesmo assim parece haver menos área alocada para as unidades de execução de ambos os lados.

A redução dessa área não surgiu sem consequências. Houve cortes de tubos (pipelines) FP bem como a eliminação de algumas unidades duplicadas de execução de FP/vetor. O Zen 2 possui um FPU de porta quádrupla, com portas denominadas FP0, FP1, FP2 e FP3. Na PS5, o FP3 foi removido e o FP2 foi relegado a lidar apenas com armazenamentos de FP/vetores, com todas as suas unidades de execução matemática removidas ou movidas para os FP0/FP1.

Resumindo, as alterações foram estas:

Mas as unidades de execução não foram as únicas coisas a encolher. O arquivo de registro, também foi alterado, e embora esteja dividido no mesmo número de blocos, os blocos são mais próximos e menores.

No entanto,  a capacidade especulativa de arquivo de registro FP/vetor obtidas por microbenchmarking indicam que o FPU do PS5 continua a ter o arquivo completo de registro de 160 entradas tradicionais do Zen 2. Ou seja, o arquivo de registo, apesar de mais próximos e menos, estão intactos.

Outros testes mostram que usar adições FP de 256 bits como instruções de preenchimento produz um resultado semelhante ao Zen 2 normal, portanto, cada entrada ainda tem os mesmos 256 bits de largura.

E mesmo o arquivo de registro físico, que agora pode conter registros de 512 bits, teve apenas um crescimento mínimo, uma vez que a área do arquivo de registro é limitada principalmente pela largura e pelo número de portas de acesso, e não tanto pelo número de células de armazenamento por entrada.

Kai Troester, no núcleo Zen 4 da AMD no Hot Chips 2023

Embora a observação de cima tenha sido feita para a implementação AVX-512 do Zen 4, ela é certamente igualmente válida aqui para o FPU Zen 2 reduzido do PS5. E isto porque os testes mostram que neste FPU alterado, o arquivo de registro pode alimentar os canais de execução, mesmo com menos portas.

Alimentar os quatro tubos de execução do Zen 2 pode exigir até 10 entradas, mas o manual de otimização da AMD diz que os barramentos de origem do FP3 são reutilizados para fornecer uma terceira entrada para as unidades FMA no FP0 e FP1.

Isso pode ser interpretado como significando que o arquivo de registro Zen 2 teria apenas oito portas para ajudar a manter a área do arquivo de registro sob controle. A edição Zen 2 da PS5 precisa apenas de seis portas de leitura de registro para alimentar seus canais FP, reduzindo ainda mais a área de arquivo de registro.

A FPU reduzida do PS5 terá então 192 e 128 bytes por ciclo de largura de banda de leitura e gravação, respectivamente, ou 672 GB/s de leitura e 448 GB/s de gravação a 3,5 GHz. Para efeito de comparação, o Zen 2 tem 256 e 192 bytes por ciclo de largura de banda de leitura e gravação. Em 3,5 GHz, seriam 896 GB/s de largura de banda de leitura e 672 GB/s de largura de banda de gravação.

Ou seja, a Sony cortou a largura de banda do CPU para valores mais adequados à sua realidade da consola com 448 GB/s de largura de banda na RAM.

A alteração também deixou intactos o agendador e a fila de não agendamento (NSQ). Portanto, os importantes recursos de ocultação de latência do FPU permaneceram inalterados. Os contadores de desempenho (máscara de contagem = 4 no evento de atribuição de pipe FP) indicam que o agendador ou NSQ ainda pode aceitar quatro micro-operações por ciclo do renomeador. Portanto, o renomeador de FP também não foi eliminado ou alterado.

Mas como é que isso funciona no Zen 2 é uma questão interessante que só os engenheiros da AMD e da Sony saberão responder. Cortar o hardware de execução para além de um certo ponto pode realmente prejudicar o desempenho, assim como optar por uma GPU barata pode levá-lo a um precipício de desempenho. Mas o Zen 2 da PS5 conseguiu esse equilíbrio.

A questão que surge então é corrente: Se esses pipelines foram cortados e tudo funciona na mesma, será que precisamos mesmos deles? E se são dispensáveis, porque motivo a AMD os usa? É a questão que se segue!

Precisamos mesmo desses canos (pipelines)?

Para uma resposta direta precisamos de comparar o CPU da PS5 com um APU Zen 2 intacto que funcione nas mesmas condições do da PS5, ou seja, com uma memória de elevada latência, e à mesma velocidade de relógio.

É aqui que o Van Gogh, o APU do Steam Deck pode ajudar. Ambos são APUs e ambos têm velocidades de clock limitadas a 3,5 GHz com 4 MB de cache L3 por cluster. A memória LPDDR5 também se aproxima da horrível latência existente na GDDR6, embora a LPDDR5 seja um pouco pior.

Ou seja, podemos então comparar!

Há no entanto que referir uma situação. Há uma grande lacuna entre os dois APUs no que toca à largura de banda, sendo que a largura de banda do CPU no Steam Deck é limitada pela estrutura do chip, ao passo que os núcleos da CPU da PS5 desfrutam da maior largura de banda DRAM disponível para qualquer implementação Zen 2.

A largura de banda obtida em testes mostrou um valor de largura de banda de96.99 GB/s no CPU da PS5 e 35.28 GB/s na Steam Deack. Testes efetuados usando um padrão de leitura-modificação-gravação com uma matriz de teste de 1 GB.

Assim, tanto o Steam Deck quanto o BC-250 foram configurados com o Ubuntu Linux para testes.

As comparações dos CPUs em software diverso.

Compressão/descompressão 7-ZIP

O primeiro programa de testes usado foi o 7-Zip, um programa de compactação de arquivos pesado em operações escalares inteiras, mas que basicamente não afeta o FPU. Ao mesmo tempo, o seu consumo de memória é grande o suficiente para sair da cache. Isso o torna um bom teste para definir uma linha de base para comparação.

Dado que a PS5 lida com alguma compressão/descompressão no seu CPU, é relevante perceber como ela se comporta face a um CPU Zen 2 standard.

Os resultados foram os seguintes num ficheiro de 2,67 GB que foi comprimido:

Steam Deck APU – 21.15 GB/s

BC-250 – 22,01 GB/s

Basicamente o BC-250 revelou-se 4% mais rápido. A latência da memória menor é sua maior vantagem sobre o APU do Steam Deck, sendo, provavelmente, a responsável por este resultado.

Cargas de trabalho vetoriais moderadas: libx264 e SSIM

Para este teste foi usado o libx264, um codec de vídeo popular, onde se fez um transcode de um vídeo a 4K.

Dado que o Zen 2 fornece um evento de monitorização de desempenho que conta as microoperações vinculadas a cada canal FP, no estágio de renomeação, vamos usa-lo. Será de se referir que tecnicamente, este evento não está documentado no Zen 2, mas ele foi testado e parece funcionar conforme o esperado. Além disso,o utilitário perf do Linux suporta-o.

Vamos ver os resultados obtidos:

Podemos ver que a carga da libx264 é distribuída uniformemente pelos pipelines FP do Zen 2, e nenhum pipe se destaca como um gargalo sobrecarregado. No FPU nerfado do PS5, a carga é transferida de FP2 e FP3 para os dois primeiros tubos. Eles ficam assim com uma utilização mais alta, mas não alta o suficiente para se poder indicar um gargalo consistente.

Os núcleos de CPUs fora de serviço podem suavizar picos na demanda por taxa de transferência da unidade de execução, armazenando temporariamente em buffer mais micro-operações no back-end enquanto os canais de execução trabalham para limpar os mais antigos. Mas as estruturas de back-end têm capacidade limitada. Se eles saturarem, podemos inferir que um pico na procura ou uma operação de longa latência excederam a capacidade do mecanismo out-of-service e, portanto, causou  impacto no desempenho. Os contadores de desempenho do Zen 2 permitem-nos saber quando isso aconteceu e determinar o porquê. O teste seguinte concentrou-se por isso no arquivo de registro e no agendador do FPU.

O agendador FP será saturado se muitas operações FPU estiverem na fila de espera para serem executadas. Isso pode acontecer porque os canais FP não estão a acompanhar ou porque há uma longa cadeia de dependências. Para ser mais específico, uma paralisação de despacho devido à falta de recursos do agendador ocorre quando a fila do agendador e a fila de não agendamento estão cheias. Chamaremos a isso uma paralisação (stall) devido ao preenchimento do agendador FP, sendo que a capacidade combinada de 100 micro-ops de ambas as estruturas devem ser usadas antes de tal paralisação aconteçer.

Instruções que escrevem em um FP ou registo vetorial também precisam de um registrador físico alocado. Se nenhuma entrada estiver disponível, também teremos uma paragem de expedição. Ficar sem espaço no arquivo de registro FP/vetor não implica um gargalo de execução, mas sugere que algumas instruções que gravam em registros FP/vetoriais estão a sofrer de latências altas.

Resumidamente, é difícil perceber a discrepância do processador da PS5 neste tipo de calculo. Mas se os testes não permitem perceber a mesma, permitem concluir que no que toca aos os contadores de desempenho, a redução do Zen 2 seria muito pior se a AMD decidisse reduzir a capacidade do arquivo de registro, além de nerfar os canais de execução. O arquivo de registro já é uma estrutura muito quente e torná-lo menos capaz pode afetar drasticamente o desempenho devido às questões térmicas.

Testes SSIM

Similaridade Estrutural ou SSIM é uma métrica de qualidade de vídeo, e calculá-lo também sobrecarrega a FPU. O BC-250 e o Steam Deck têm desempenho quase idêntico, com o Steam Deck à frente em 0,45%.

STEAM Deck APU – 59.2 Frames por segundo.

BC-250 – 58,93 FPS.

O teste SSIM coloca carga quase uniforme nos quatro tubos FP do Zen 2, mas FP2 acaba com mais trabalho. No FPU nerfado do PS5, mais micro-ops são colocados em FP0 e FP1 como esperado, mas FP2 também recebe uma quantidade razoável de trabalho. O SSIM parece estar a gravar muito conteúdo de registro vetorial na memória, o que significa que o canal FP2 está bem aproveitado.

Carga de trabalho pesada de vetores: Y-Cruncher

O Y-Cruncher é um software que calcula dígitos de Pi. É bastante multithread e aproveita fortemente qualquer extensão SIMD que se possa usar. Se tiver núcleos suficientes em jogo, o Y-Cruncher também pode facilmente ficar vinculado à largura de banda DRAM. Aqui, foi pedido para para calcular 250 milhões de dígitos.

Será de se referir que, mais uma vez, este está longe de ser um tipo de cálculo usado em jogos, que maioritariamente trabalham com inteiros.

Eis os resultados:

Steam Deck APU- 28.693 segundos

BC-250 – 33.348 segundos

Podemos descartar a latência de execução como causa do preenchimento do agendador porque as duas implementações do Zen 2 parecem ter latências de execução idênticas.

Conclusões intermédias

O que vemos é que para trabalho mais genérico, o Zen 2 não alterado pode trazer vantagens, apesar que elas não são variáveis dependendo do tipo de trabalho. Mas a grande questão é que os jogos dão uma utilização bem diferente ao FPU, pelo que a performance nos mesmos é o que se torna relevante aqui. Afinal, a PS5 foi concebida para jogos e não para este tipo de tarefas anteriormente testadas. E isso leva-nos ao capítulo seguinte:

Mas e indo ao que interessa. E quanto aos jogos?

O Zen 2 foi projetado para lidar com uma grande variedade de cargas de trabalho de desktop, dispositivos móveis e servidores com a mesma arquitetura central. A FPU quad pipe permite que o núcleo tenha um bom desempenho na edição de vídeos e fotos e pode ser crucial em cargas de trabalho com limite de rendimento, como o Y-Cruncher. Mas as unidades de execução vetorial podem custar área e energia consideráveis.

Ora há muito, muito tempo atrás, em uma galáxia muito, muito distante, os jogos dependiam do CPU para renderizar gráficos e um FPU melhor poderia levar a um melhor desempenho nos jogos. Mas a realidade é que nenhum jogo moderno faz isso, sendo o uso do FPU bem mais moderado e com utilizações muito específicas, e nesse aspecto, um FPU quad pipe para jogos é um exagero.

Vamos ver a utilização do FPU do Zen 2 num jogo. Neste caso o COD Cold War:

O que se percebe claramente aqui é que um FPU de tubo duplo faz muito sentido para uma consola como a PS5, que se destina apenas a jogos. A CPU do PS5 nunca terá que lidar com a ampla gama de cargas de trabalho que se espera que os núcleos Zen 2, sejam eles de desktops ou de servidores. Uma FPU menor tem a ainda  vantagem de economizar energia e área sem oferecer um desempenho visivelmente diferente, o que é uma ótima opção para uma consola como a PS5, pois o comportamento do CPU não se altera face ao que aconteceria neste mesmo tipo de processamento se fosse usado um Zen 2 sem qualquer corte.

Daí que esqueçam os testes de cima. Para jogos, o CPU Zen 2 da PS5 não apresenta qualquer diferença significativa face a um CPU Zen 2 normal.

Conclusões

Os núcleos Zen 2 do PS5 representam um esforço inicial feito pela AMD para reduzir a área central de forma a satisfazer as necessidades da Sony. Eles mostram que a AMD é totalmente capaz de personalizar seus núcleos para atender às demandas dos clientes, mesmo que não anunciem publicamente as opções de configuração como a Arm Ltd faz. O FPU reduzido no Zen 2 faz lembrar a capacidade do Cortex A510 de ser configurado com diferentes contagens de tubos FP, permitindo que os clientes façam a compensação de desempenho e área que desejam.

Basicamente não há do que não gostar desta configuração personalizada da AMD para a PS5. Eles cortaram unidades de execução que, por aquilo que se percebe, não ajudariam nas cargas de trabalho normalmente realizadas pela PS5. Ao mesmo tempo, mantiveram o mesmo número de arquivos de registro FP, agendadores e entradas de fila não agendadas. As latências de execução também permaneceram inalteradas. Um jogo como CoD Cold War precisa executar alguns bilhões de operações FPU por segundo, e o FPU reduzido da PS5 mostra-se mais do que capaz de lidar com isso, pois as suas estruturas fora de serviço absorvem quaisquer picos temporários de procura.

Basicamente a configuração FPU do PS5 seria adequada até mesmo para muitos consumidores que se limitam a usar o CPU em aplicativos não muto intensivos no FPU. E realmente são muitos os aplicativos não usam muito o FPU, e alguns que o fazem (como o cálculo SSIM) podem sobreviver com perda mínima de desempenho como os testes acima mostram. Alguns aplicativos mais pesados, como o Y-Cruncher, apresentam uma perda maior de desempenho, mas uma diferença de 16,4% pode nem sempre ser verdadeiramente consequente.

Já os ganhos a nível de área, e consequentemente, custos, são facilmente perceptíveis. Vejamos:

PS5/BC-250 Cluster

18,92 mm2 de area

Steam Deck APU Zen 2 Cluster

21,1 mm2

Desktop / Server Zen 2 Cluster

31,4 mm2

Com o custo do silício a ser, acima de tudo, dependente da área, e com uma waffer de silício a poder conter mais chips, quanto mais pequenos estes forem, as vantagens a nível de custo são claras!

Agora alguns podem argumentar que embora a AMD já tenha fabricado milhões de chips com FPUs nerfados para a Sony, a estratégia nunca foi repetida em outros processadores seus. O motivo é que reduzir o FPU não faz diferença no preço suficiente para ser significativo no mercado grossista. Uma redução de 35% na área da FPU por si só é impressionante, mas o tamanho de um cluster quad core diminui apenas 5,8%. Isso não é suficiente para permitir um aumento na contagem de núcleos ou um silício muito menor e mais barato. E apenas para quem compra aos milhões de processadores essa diferença se torna notória. No mercado grossista onde uma venda de algumas centenas de processadores já é um grande negócio, a situação não é significativa para justificar, e muito menos pela perda de performance que pode existir em algumas áreas que este mercado mais genérico pode explorar.

A coisa mais parecida que a AMD fez a nível de redução de área passou-se com o Zen 4C! Mas para o Zen 4, a AMD optou por uma estratégia diferente de redução de área. O Zen 4c deixa a arquitetura inalterada e visa velocidades de clock mais baixas para reduzir a área. Notavelmente, até mesmo o FPU e o seu arquivo de registro de largura total de 512 bits permanecem inalterados. Limitar o Zen 4c a cerca de 3,6 GHz permitiu que a AMD usasse SRAM 6T mais densa para as caches L1, armazenamento de previsão de ramificação e caches de tradução. Uma malha de clock menor e outras otimizações permitem que o Zen 4c alcance uma redução de área de 35% para todo o núcleo, e não apenas para a FPU. A AMD cortou ainda a capacidade da L3 para metade, o que faz muito sentido porque o L3 ocupa mais área do que os próprios núcleos nos servidores e desktops Zen 2  (CCDs).

Como resultado, a AMD conseguiu colocar 16 núcleos em uma matriz que é apenas um pouco maior do que o CCD Zen 4 padrão de 8 núcleos. Esse tipo de mudança pode abrir novos segmentos de mercado, ao contrário da redução isolada da FPU do Zen 2.