Uma nova hierarquia de níveis múltiplos de caches e novo design das unidades de computação. Estas foram novidades que Lisa Su referiu virem a existir na Navi. Estas duas alterações certamente serviram para resolver um dos grandes problemas do GCN.
Antes do mais vamos desde já deixar claro que os dados sobre o Navi continuam uma incógnita, e são muito, muito poucos. Daí que o que aqui vamos referir é, nesta fase, uma especulação, e não passa disso mesmo.
A questão é que Lisa Su referiu que o Navi tinha um ganho de 25% no número de instruções por ciclo de relógio face às anteriores arquitecturas, e nesse sentido tal terá sido consequências das alterações realizadas, resolvendo ou minimizando alguns dos problemas mais conhecidos do GCN. E um deles é o que vamos descrever de seguida.
Para que percebem melhor a coisa, vamos começar por colocar a imagem que vai servir de sustentação a toda a argumentação:
A imagem de cima foi apresentada pela AMD no Game Developers Day, e mostra a consciência da empresa numa limitação da arquitectura GCN. Consciência essa que, ao existir, deverá ter sido tomada em conta no RDNA, sendo corrigida, ou pelo menos minimizada.
Vamos tentar então explicar o que a imagem refere, sendo que para o que vamos referir vamos focar-nos apenas na primeira tabela (a de cima), e ignorar os restantes dados.
Para que percebem o que ali está é necessário que se percebam três noções, uma relativa ao hardware, outra à forma de organização, e outra relativa ao tamanho das caches.
Hardware
As unidades de computação (compute units ou CU) do GCN são constituídas por vários componentes sendo que para explicarmos o que aqui se passa basta que percebam que um deles, e um dos elementos principais, são 4 unidades SIMD vectoriais (ou unidades de processamento paralelo), cada uma com 16 pistas de processamento paralelo. São estas a unidades que fazem o processamento dentro do CU.
Organização
O GCN junta as tarefas a processar em conjuntos de 64, chamando a esse conjunto de 64 threads, uma Wavefront.
No global o GCN tem uma capacidade para armazenar até 2560 threads ou seja, 40 Wavefronts! Basicamente, dado existirem 4 unidades SIMD, o GCN pode atribuir até 10 Wavefronts a cada um deles.
São estas wavefronts que vocês encontram referidas no quadro de cima na referência Max Waves/SIMD.
Caches
Cada CU tem uma capacidade de armazenar 4x 64KB em ficheiros VGPR, ou registos vectoriais de propósito geral. São 256 KB no global, divididos em 4×64. Podem vê-los na imagem que se segue:
Estes dados podem ser confirmados aqui.
E perante isto passemos então a analisar o quadro de cima!
O uso destes registos vectoriais é um dos grandes factores de limitação do GCN! E isto devido à baixa capacidade de armazenamento dos mesmos
O que a tabela mostra é como o tamanho desses registos limita as wavefronts atribuidas aos CU. É que uma vez cheio o registo, o CU não pode processar mais este tipo de operações!
Assim, por exemplo se cada Wavefront trouxer um registo de 64k, ao fim de 4 Wavefronts o registo fica cheio, e isso quer dizer que o SIMD em causa, mesmo capaz de receber mais trabalho, não o pode fazer enquanto não puder limpar as caches, o que ocorre ao fim de cada 10 entregas de wavefronts, pelo que a unidade SIMD que recebeu estas Waves terá de aguardar 6 ciclos de entregas sem processar. Mesmo os restantes SIMD do mesmo CU ficam impedidos de processar este tipo de registo, o que quer dizer que pode não só o SIMD tem ineficiencia, mas igualmente que toda a capacidade do CU pode sofrer..
Basicamente, num caso como este, a eficiência de processamento desce, sendo que num caso extremo, onde não teriamos outro tipo de registos a processar, todo o CU sofreria..
Este é um caso registado na tabela de cima, onde se forem à linha com a dimensão do registo VGPR, e procurarem por 64, irão ver que o limite de waves aceite é 4.
Pela mesma lógica, se os registos forem de 128 k, só serão aceites 2 wavefronts, se forem 48K seráo 5 Wavefronts, 40 serão 6, etc. Basicamente, o número de waves aceite, que terá sempre de ser um número inteiro, e um múltiplo de 4, fica limitado pelo uso da capacidade destes registos.
Para garantirmos que o CU processa na totalidade das 10 waves teríamos de dividir a cache por 10, o que daria 25,6 K a cada uma das wavefronts. No entanto, por termos de lidar com múltiplos de 4, este valor desce para um máximo de 24, que é o valor que vêem na primeira coluna da tabela.
Como se percebe aqui, o processamento no GCN acaba sempre por ser uma questão de compromisso. Se queremos o GPU a processar em todos os ciclos de relógios os registos vectoriais necessitam de ter apenas 24 KB, mas se precisarmos de registos maiores, vamos ter ineficiência.
Existem três formas de mitigar este problema.
O primeiro é o mais usado actualmente, e passa pela escolha cuidada do tipo de operações a serem realizadas feita pelos programadores, havendo vários artigos de diveros programadores nos seus blogs que dão dicas sobre como organizar as instruções de forma a garantir a optimização do processo.
O segundo seria já uma solução de hardware e passaria pelo aumento da capacidade de armazenamento de registos VGPR. Segundo alguns autores, o dobro já seria bom, dado que os registos mais comuns são de 48K. Mas como a arquitectura irá estar connosco na próxima década, o aumento para 640K parece-nos que seria o ideal.
Esta é uma das situações que limitam o GCn e que a Navi, especialmente porque se sabe ter mexido nas caches, se espera ter previsto e alterado.
O terceiro passa por uma alteração que combine os dois pontos de cima, e isso seria feito com uma alteração no design dos CUs, de forma a que o problema diminua ou desapareça.
Ora, sem sabermos o que contemploy, uma alteração aos CU é o que também está referido como tendo acontecido no slide que podem ver no topo do artigo e relativo à apresentação da AMD. Daí que a teoria de alteração referida neste artigo não esteja desprovida de lógica, e talvez explique só por si como a AMD conseguiu ganhos de 25% no IPC.