Olhando para o design da nova arquitectura RDNA algo salta à vista. Ela foi concebida para garantir que todo o software pensado para o GCN corre sem necessidade de alterações, garantindo uma compatibilidade perfeita. Este é o conceito que Cerny sempre defendeu para uma retrocompatiblidade garantida a nível de hardware.
O RDNA tem vindo a suscitar muitas conversas sobre as suas raizes GCN. Mas independentemente de tal o GCN é uma alteração radical ao que o GCN oferecia, e isso é inegável!
Basicamente, quando se pensa em evolução do hardware, há três aspectos que podemos considerar.
O aspecto 1 é o acréscimo de novas funcionalidades aceleradas pelo hardware, e essa parte não se altera. Tratam-se de acréscimos ao que já existe e como tal não altera nada face ao suporte que o hardware anteriormente tinha. Este é o tipo de evoluções mais comum e que aparece não só dentro de novas gerações, mas igualmente dentro de revisões de uma mesma geração.
O segundo e terceiro aspecto estão intimamente ligados. Basicamente passam pela forma de, como se evoluir um hardware de forma a que este possa debitar cada vez mais a cada nova geração.
Basicamente estes dois aspectos passam por tornar uma nova geração de GPUs mais rápida usando uma de duas alternativas.
- Aspecto 2 – Torna-lo mais rápido, o que implica melhorar as velocidades de relógio.
- Aspecto 3 – Torna-lo mais amplo, o que implica aumentar a sua capacidade de processamento paralelo.
Ora o GCN foi tendo evoluções ao longo do tempo. E as Compute Units (CU) começaram por serem em número bem inferior aos usados actualmente, bem como as velocidades de relógio eram baixas. Mas rápidamente se percebeu que o GCN era mais virado para o aspecto 3 do que para o 2, e apesar de a cada nova revisão a AMD procurar melhorar as velocidades de relógio, foi no aumento do número de CUs que o GCN se mostrou mais eficaz em permitir a evolução.
Mas a realidade é que o GCN começou a mostrar limitações!
O primeiro limite prendeu-se com os consumos e térmica inerentes à arquitectura que lhe limitavam a velocidade de relógio. A AMD foi melhorando a situação com várias iterações do GCN, mas sem nunca se conseguir libertar desses problemas. Da mesma forma se o GCN se mostrou muito capaz em evoluir basicamente de forma linear até atingir os 48 CU, daí para cima o que se verificava era que o que existia eram ganhos decrescentes.
Basicamente o GCN mostrava que acima dos 48 CUs as melhorias na velocidade de relógio trazia ganhos maiores do que a colocação de mais CU.
Basicamente, devido à limitação das velocidades de relógio a AMD viu-se obrigada a continuar com o aumento dos CU, mas o que se percebe é que se colocarmos à mesma velocidade de relógio uma Vega 56 e uma Vega 64, as diferenças de performance são inferiores ao ganho teórico que o aumento dos CU traz. Os 8 CU adicionais da Vega 64 não lhe trazem os ganhos que se esperaria. Basicamente, o GCN não permitia subir muito mais as velocidades de relógio e o aumento de CUs já não compensava. A arquitectura GCN estava esgotada.
A AMD estava aqui perante um dilema. Uma mudança radical de arquitectura iria colocar entraves ao sonho da Sony de garantir compatibilidades com a PS4 pelo próprio hardware. Mas a manutenção do GCN não lhes permitia melhorar convenientemente os seus GPU, e a evolução iria ser pequena.
Ora o RDNA é a solução para tudo isto. E daí que se acredita ter tido efectivamente, tal como os rumores indicavam, mão da Sony!
Basicamente o RDNA é uma remodelação total do GCN, ao ponto de se tornar tão diferente que se torna numa nova arquitectura. Mas mais do que isso, inteligentemente o RDNA mantêm-se totalmente compatível com o GCN, tal e qual as ambições de Mark Cerny que sempre defendeu as retro-compatibilidades a acontecerem ao nível do hardware. E isso leva-nos a dar alguma credibilidade ao rumor de que a AMD terá mesmo desenvolvido esta arquitectura com a colaboração da Sony para satisfazer as suas necessidades para a PS5.
Este problema da retro compatibilidade foi algo que a AMD não experimentou com a passagem do Terascale para o GCN, e a razão é simples. O API que na altura equipava o Windows, o DirectX 8 era um API de alto nível, motivo pelo qual, não existindo acessos directos ao hardware, a simples existência da driver tratava de garantir a compatibilidade dos jogos. Mas isso não é o que acontece nas consolas com os seus APIs de baixo nível e acesso directo ao hardware, onde a mudança da arquitectura cortaria a compatibilidade.
O mais fascinante do RDNA é a forma como a AMD muda todo o conceito anterior. A nova arquitectura apoia-se no Aspecto 2 da evolução do hardware e permite velocidades de relógio mais altas, acabando com a limitação existente no GCN, ao mesmo tempo que no que toca ao aspecto 3, reduz a amplitude do processamento ao reduzir o número de CUs.
Basicamente o que temos agora é uma arquitectura onde a evolução é novamente possível, seja a nível de maiores velocidades de relógio, seja a nível do aumento das CU. Ou seja, uma arquitectura que garante à AMD vários anos de evolução pelos três aspectos da evolução do hardware, algo que o GCN já não oferecia. Basicamente o Navi foi desenhado para ser 100% retro-compatível ao mesmo tempo que oferece a flexibilidade que o GCN já não tinha para evoluir novamente no futuro. E claro, apresenta uma série de novidades que não existiam sequer no GCN.
As diferenças são enormes, e vão requerer código próprio para se tirar partido de todas as novidades, pelo que se poderá esperar mais e melhores performances dos GPUs Navi no futuro. Mas a forma como a compatibilidade é mantida com a forma de processamento interno do GCN, garante a total compatibilidade com o software pré existente. Isso não quer dizer que alguns jogos não possam precisar de patches devido a timmings internos do hardware diferentes, mas o certo é que o código optimizado e que tirava partido com acessos directos e de baixo nível de características específicas do hardware não requer ser re-escrito, e como tal toda a livraria de jogos da Xbox e da PS4 estão garantidas de serem mantidas nas futuras consolas sem a necessidade de emulações ou máquinas virtuais.
Nota final: Apesar de tal não ser abordado no artigo, falando apenas na vertente da Sony, pelas raizes de retrocompatibilidade do RDNA com o GCN, acredita-se que o Navi seja o resultado do feedback misto da Sony e da Microsoft, com a AMD a criar algo que satisfizesse os dois. Nesse caso será de esperar difererpntes costumizações nos GPUs para ambas as marcas pois, pelo menos nesta fase, a AMD terá deixado as partes mais específicas pedidas e patenteadas por cada um, de fora dos modelos que sairão para PC