Os últimos rumores apontam no sentido que a Navi será mesmo GCN. No entanto isso não quer dizer que será forçosamente igual às suas antecessoras, podendo apresentar novidades de peso.
Pois bem, ao que tudo indica confirma-se que a Navi será mesmo GCN. Não que houvesse muitas dúvidas nisso, sendo que a grandes questão estava mais centrada no que ela poderia mudar face às suas antecessoras, do que realmente em discutir se ela seria ou não uma arquitectura diferente.
Eis os rumores que parecem confirmar a Navi como GCN:
GFX 1010 = Navi 10!
— 比屋定さんの戯れ言@Komachi (@KOMACHI_ENSAKA) 24 de abril de 2019
“EF_AMDGPU_MACH_AMDGCN_GFX1010”
— 比屋定さんの戯れ言@Komachi (@KOMACHI_ENSAKA) 24 de abril de 2019
“AMDGCN”
— 比屋定さんの戯れ言@Komachi (@KOMACHI_ENSAKA) 24 de abril de 2019
Mas há uma coisa que não devemos confundir. Uma arquitectura nova é uma coisa, alterações são outra coisa. A Navi apresentará aqui a sua versão 6.0 do GCN, e como tal apresentará novidades face às anteriores versões.
Possível novidade 1 – Apoiada em dados reais confirmados pela AMD
Uma das novidades que poderá aparecer é a remoção do limite de 64 CUs. Uma situação que aliás nem é novidade no historial da AMD, uma vez que este limite já foi em tempo, e já dentro do GCN de 48 CU. Foi exactamente numa revisão do GCN que os restantes 16 CU foram adicionados!
A arquitectura GCN prevê uma divisão das Compute Units (CU) por Compute Engines (CE), sendo que os GPU AMD possuem 4 desses Compute Engines. Tal pode perfeitamente ser visto no seguinte esquema da AMD.
Cada Compute Engine (CE), possui assim um total de 16 Compute Units (CU), e uma das alterações anteriores criadas numa revisão do GCN foi exactamente o acréscimo de um quarto CE, que aumentou as CU em 16 unidades, passando-as de 48 para 64.
O que impede a AMD de fazer agora novamente o mesmo? Absolutamente nada!
E não sou eu que o digo, são os engenheiros da AMD.
Eis uma citação de um artigo de 2014, publicado pelo o website Anandtech, na apresentação dos GPUs Vega.
Num breve aparte, o número de Compute Engines tem sido um assunto de discussão inesperadamente interessante ao longo dos anos. Em 2013 soube-se que a iteração da altura do GCN tinha uma contagem máxima de Compute Engines de 4, algo a que a AMD tem estado presa desde então, incluindo nas novas Vega 10. E tal por sua vez despoletou a discussão da escalabilidade dos designs da AMD, e racio de computação/texturas para as ROP.
Falando com os Engenheiros da AMD acerca desse assunto, eles não fizeram nada nas Vega para mudar isso. Eles deixaram claro que 4 Copute Engines não é uma limitação fundamental – Eles sabem como criar um design com mais Engines – no entanto tal iria requerer trabalho adicional. Por outras palavras, os compromissos de engenharia continuam aplicados, com os engenheiros focados em coisas como o controlador HBCC e a rasterização, em vez de tratar da canalização necessária para criar Compute Engines adicionais na Vega 10.
Estas palavras dizem tudo. A Navi não está limitada! Caso a AMD queira, e certamente ao redesenhar o GCN para a sua sexta iteração teve o tempo para isso, até porque o Navi estava em desenvolvimento em paralelo com a Vega e foi a grande aposta da AMD, levando metade dos engenheiros da AMD para a sua concepção, ela poderia ter removido o limite de 64 CUs ao acrescentar pelo menos uma CE adicional, subindo assim o limite para 80.
Claro que, pelo menos nesta fase, 80 CUs é um número utópico do ponto de vista do custo e da dimensão do chip, mas o certo é que a AMD não precisa verdadeiramente de usar 16 CUs adicionais, apenas precisando de alguns mais para garantir que em questões de produção os chips com 64 CU saem aproveitáveis. Fosse como fosse, o alargamento para 80 CUs poderia permitir à AMD responder a atempadamente a movimentações da Nvidia, algo que com 64 se mostraria difícil dado que atualmente os seus GPUs de topo já usam esse limite.
Possível novidade 2 – Apoiada em patentes aprovadas da AMD
Mas há outras formas que o Navi pode ser modificado. Uma delas é no rendimento dos seus Shader Processors (SP), aplicando mais ALUs que lhes aumentariam o rendimento para o dobro. Esta é uma situação patenteada pela AMD, e que como tal pode desde já aparecer. Não há nada nesta patente que prenda a situação a qualquer tipo de arquitectura especifica, pois trata-se apenas de alterações na capacidade das ALUs ao se colocar um misto de pequenas ALUs misturadas com novas ALUs mais capazes e igualmente patenteadas, que duplicam a capacidade de cálculo do SP.
Este mudança nas ALUs poderá trazer rendimento extra que, em teoria, poderá ser tanto quanto o aumento da capacidade das ALU (Exemplo: Alu = 2x mais => rendimento duplo face ao anterior).
Possível novidade 3 – Apoiada em patentes aprovadas da AMD, mas mais adequado a uma arquitectura VLIW
As alterações nas ALU acima expostas são a base de uma outra tecnologia patenteada pela AMD, o SuperSimd, que poderá estar igualmente aqui implementada, e que permitirá computação paralela mais extensa ao criar o conceito de Small CU associado ao CU.
Mas esta é uma situação que não se tem falado, pelo que a vamos deixar cair.
Possível novidade 4 – Mera teoria, atualmente descartada perante os valores de velocidade que se fala para os GPUs das consolas e mesmo os Navi para PC (1400 Mhz ou mais).
Uma situação que correu os foruns num rumor que chegamos mesmo a falar aqui na PCManias prendia-se com uma outra possível alteração, e que substituiria o acréscimo de Compute Engines. Tratava-se de um aumento, neste caso uma duplicação do número de Shader Processors (SP) por CU, que passariam de 64 para 128.
Esta situação para além da duplicação dos SPs traria duas situações novas:
- A capacidade de processar 4 instruções por ciclo de relógio em vez de apenas duas ao manter as Wavefronts em 64, e processar duas de cada vez.
- A capacidade de processar Wavefronts de 128 instruções, abrindo assim novas portas para o futuro.
Esta situação permitira descer o número de CUs, sendo que desta forma um GPU com 20 CUs se equivaleria a nível de hardware a um de 40. Mas a descida poderia ainda ser maior devido ao aumento da capacidade de processamento das instruções.
Fora a ideia de que os dados do Benchmark estarem aldrabados com dados falsos no firmware do GPU, o que será o mais provável, esta foi a teoria alternativa usada para explicar o Benchmark que apareceu do GPU Navi 10, e que é reportado como tendo 20 CUs e correndo a 555 Mhz, batendo uma Vega 56 com 10.57 Tflops.
Ora pela metodologia clássica de cálculo, este GPU teria:
20 CU x 64 SP x 2 Instruções por ciclo x 555 Mhz = 1 420 000 ou 1.42 Tflops (menos que a PS4).
Mas com estas alterações teria:
20 CU x 128 SP x 4 instruções por ciclo x 555 x 2 (pela duplicação da capacidade das ALU) = 11 366 400 ou 11,37 Tflops, um valor que justificaria o bater a Radeon Vega 56.
Como referido logo no início, esta teoria, está actualmente descartadas pelas velocidades de relógio que se referem poder vir a existir nos GPUs e que atirariam as performances para cima dos 20 Tflops, mas mesmo assim, achamos por bem referir a mesma uma vez que até ao momento tudo o que há de concreto sobre as consolas são rumores, e valendo todos eles o mesmo (pouco ou nada), porque considerar as velocidades referenciadas e ignorar este?
Outras novidades
Há muito mais que o Navi pode oferecer. Sabe-se que ele reformula completamente a componente de geometria do GCN, de forma a torna-la mais eficiente. Existe ainda a possibilidade de este poder suportar Ray Tracing, nem que seja por um modulo externo ao GPU, mas ligado pelo Infinity Fabric ou pelos canais de comunicação mais standarizado. Remodelações na performance, no rendimento, enfim, tudo está em cima da mesa. A arquitectura, ou seja, a forma interna de funcionamento, será a mesma, mas isso não impede grandes mudanças e melhorias. Mas dados concretos sobre novidades… não há nada! O Navi está fechado a sete chaves e os seus segredos vão sendo revelados a conta gotas. Teremos de aguardar!