Neste artigo será detalhado outras duas microarquiteturas nVidia: a Kepler e a Maxwell. Para entender melhor os termos ditos aqui, recomendo ler os outros artigos da série sobre GPUs, inclusive o Capítulo 2 desta série, sobre arquiteturas, que trata da Tesla e Fermi, as duas primeiras plataformas da nVidia a portarem Shaders Unificados.
Arquitetura Kepler (2012 ~ 2018)
Veja abaixo a imagem do Die GK180:
Imagem 1 - Microarquitetura Kepler na realidade com o chip GK180
Comum até os dias atuais nas placas GT730, a arquitetura Kepler é uma evolução da Fermi. O diagrama de blocos do SMX (Stream Multiprocessors X) pode ser visto abaixo:
Diagrama 1 - Um bloco de hardware SMX da arquitetura Kepler
O SMX é uma evolução do SM da Tesla e do SM da Fermi. Nele podemos ver dois grandes blocos de processamento, totalizando 192 CUDA Cores, 64 DP Units, 32 SFUs e 32 Load / Store Units, além de 16 Unidades de Textura (TMUs).
Observe que os dois grandes blocos de hardware são alimentados por um sistema de gerenciamento e controle dividido em quatro partes e muito semelhante às arquiteturas unificadas de gerações anteriores. Vejamos:
Diagrama 2 - O sistema de controle e gerenciamento de um SMX ficou mais complexo em relação ao que existia anteriormente
1. Instruction Cache: Um cache de instruções que alimenta todo o SMX;
2. Instruction Buffer: Para cada um dos quatro blocos existe um Buffer de Instruções. Também é chamado de "Instruction Chache" (ou "I Cache");
3. MT-IU: Para cada um dos quatro blocos existe um Warp Scheduler;
4. Dispatch: Para cada um dos quatro blocos existem duas unidades de despacho. Também é chamado de "Constants Cache" (ou "C Cache");
5. Register File: O registrador de arquivos possui 65.536 entradas de 32 bits cada, porém divididas em quatro blocos menores, cada um contendo 16.384 entradas de 32 bits cada.
ATENÇÃO: para entender melhor a utilidade de cada bloco citado acima, retorne aos artigos anteriores sobre GPUs, com enfoque no "Arquiteturas de GPUs - PARTE 2", sobre a arquitetura Tesla e Fermi. O mesmo vale para o funcionamento do bloco de hardware "Polymorph Engine", que será brevemente descrito na sequência.
6. Operand Collector: Em tradução livre significa "Coletores de Operandos" e sua função é otimizar o processamento de dados. Como você pode ver no diagrama, existem dois Operand Collectors, um para cada bloco de processamento.
De forma simples, os Operand Collectors estão conectados aos blocos Register File e movimentam os dados a serem processados nos CUDA Cores, SFUs, DP Units, LD/ST Units e TMUs da melhor forma possível para otimizar o processamento. Os Coletores de Operandos também tem como função a troca de dados entre os blocos de hardware de forma dinâmica, pois trabalham com transações em ambos os sentidos.
7. DP Unit (Double Precision Unit): Unidades de dupla precisão processam um ponto flutuante específico conhecido como “Precisão Dupla”. Este tipo de ponto flutuante está presente na linguagem C e linguagem Java. Como a tecnologia CUDA é uma extensão da linguagem C, a nVidia resolveu colocar na arquitetura Kepler 64 circuitos especiais por SMX como forma de aperfeiçoamento, mas que não foram tão citados nos diagramas da arquitetura Maxwell (você notará isso abaixo), todavia, voltaram a ser exibidos em alguns diagramas da arquitetura Pascal lançada em 2016.
CURIOSIDADE: Dupla precisão no formato de ponto flutuante ou simplesmente "Precisão Dupla" é um ponto flutuante de formato numérico digital geralmente binário que ocupa 8 bytes (64 bits em computadores modernos) na memória do computador. Também pode ser chamado de "FP64".
No caso da Kepler, para cada três núcleos CUDA existe uma Unidade de dupla precisão. Como você pode ver no artigo anterior, um núcleo CUDA pode processar números inteiros e também pode pontos flutuantes de 16 e 32 bits (FP16 e FP32, respectivamente), no entanto, o processamento de FP64 é feito de forma virtual utilizando dois núcleos CUDA, o que poderia atenuar o desempenho. Para sanar isso a Kepler veio com as DP Units, que possuem um circuito feito especialmente para FP64, não conseguindo processar FP32, muito menos FP16.
CURIOSIDADE: Jonah Alben, vice-presidente sênior de engenharia de GPU da Nvidia, disse na época de lançamento da arquitetura Pascal (meados de 2016), que o suporte para matemática FP16 por parte das DP Units exigia ajustes até nos CUDA Cores e que a conexão com os blocos Register File teria sido muito limitada para executar as instruções FP16 por meio de ambos os conjuntos de processadores ao mesmo tempo. Mas seria legal se fosse possível fazer isso, e talvez ainda mais legal poder criar um núcleo CUDA que processasse FP16, FP32 e FP64 ao mesmo tempo.
8. Load / Store Controller: Observe que existe um grande bloco Load / Store que alimenta as 32 unidades LD/ST Unit do SMX. Este grande bloco Load / Store possui conexão com o Chache L1 de 64 kB que existe em cada SMX.
9. Cache de Textura: Observe também que, para cada aglomerado de quatro Unidades TMU existe um pequeno Cache de Textura com 12 kB, totalizando 48 kB para as 16 TMUs.
10. Polymorph Engine: Em cada SMX há um bloco de hardware Polymorph Engine de versão 2.0.
No Polymorph Engine 2.0 há 5 circuitos, apresentados em ordem abaixo:
-> Vertex Fetch (Busca de vértice);
-> Tesselator (Tesselador);
-> ViewPort Transform (Transformada de exibição);
-> Atribute Setup (Configuração de atributo);
-> Stream Output (Saída de Fluxo).
Já a versão 3.0 possui dois circuitos Vertex Fetch e dois Atribute Setup. O bloco Polymorph Engine está atrelado a etapa de Geometria do Pipeline de Gráficos, portanto vemos a palavra "ViewPort" e já lembramos dos sistemas de coordenadas descritos em artigos anteriores.
Veja abaixo o diagrama de blocos completo do chip GK180:
Diagrama 3 - Chip GK180 (Graphics Kepler 180)
11. GPC: Os SMX são colocados dentro de unidades GPC (Graphics Processing Cluster), já descritas no Capítulo 5 desta série. No caso da arquitetura Kepler, pode existir no máximo três unidades SMX dentro de um GPC.
12. Raster Engine: Para administrar todos os SMX dentro de um GPC, temos uma unidade Raster Engine. Este bloco de hardware substituiu o Stream multiprocessor controller (SMC) e o Geometry Controller da arquitetura Tesla.
A unidade Raster Engine, também utilizada na arquitetura Fermi, possui a mesma função dos dois blocos da arquitetura Tesla, isto é, o gerenciamento dos dados que são trocados com cada bloco SM (Stream Multiprocessor).
13. Giga Thread Engine: Assim como na arquitetura Fermi, o bloco "Command Processor" da Tesla foi substituído pelo bloco de hardware "Giga Thread Engine", que está ligado na interface PCI Express, nos controladores de memória RAM em em todos os clusters e memória cache L2;
14. As Unidades ROP ficam de fora do SMX, assim como nas arquiteturas unificadas anteriores. No caso da arquitetura Kepler, há vários blocos contendo 8 unidades ROP cada um, sendo todas elas interligadas no Cache L2;
13. No diagrama mostrado não há o "display controller", porém ele também está presente nas Fermi, afinal ele recebe o quadro da Saída de Rasterização (ROP) e empacota os dados no protocolo da interface de vídeo, seja ela DVI, VGA ou S-Vídeo (conversor digital/analógico RAMDAC), HDMI ou DisplyPort;
14. PCI Express Host Interface: Este não precisamos explicar aqui, pois já há dois artigos "desossando" esta tecnologia. Para acessar CLIQUE AQUI (Capítulo 1) e CLIQUE AQUI (Capítulo 2);
CURIOSIDADE: O chip GK180 mostrado no Diagrama 3 possui 12 canais (cada um com 32 bits) de memória VRAM dispostas em 6 controladores, 5 GPCs, 15 SMX, 2.880 CUDA Cores, 960 DP Units, 480 LD/ST Units, 480 SFUs, 240 TMUs e 48 ROPs.
CURIOSIDADE: A arquitetura Kepler é dividida em duas gerações:
-> Kepler: Chips GK104, GK106, GK107, GK110, GK110B e GK180;
-> Kepler 2.0: Chips GK208, GK208B, GK20A e GK210.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
Para finalizar o assunto, a nVidia criou um bloco de hardware chamado NVENC (nVidia Encoder) e implementou na arquitetura Kepler. o NVENC tem a função de ser um codificador de vídeo de alta qualidade, ideal para fazer streaming das jogatinas dos viciados em games. Brincadeiras a parte, o NVENC foi crucial para retirar esta função de codificação de vídeo da CPU e assim aprimorar o desempenho. O NVENC não é mostrado nos diagramas, porém foi implementado desde a arquitetura Kepler e vem sendo aprimorado a cada geração nova de chips, sendo que nas últimas gerações ganhou cada vez mais força com a ascensão gradativa dos streamers de jogos.
Quanto ao hardware de decodificação de vídeo, a Kepler utiliza o mesmo bloco de hardware da arquitetura Fermi, que no caso é de quinta geração. O PureVideo HD 5 melhorou o sistema de decodificação H.264 e permitiu resoluções em 4K (2160p, ou seja, 4x a resolução Full HD).
Arquitetura Maxwell (2014 ~ 2019)
A arquitetura Maxwell parece ter regredido se compararmos o diagrama dela com o SMX da Kepler, no entanto, a quantidade de núcleos no geral aumentou e a eficiência energética subiu, sendo esta o grande diferencial da Maxwell.
Imagem 2 - Comparação básica entre a arquitetura Kepler e a Maxwell
Veja abaixo o diagrama de um SMM (Stream Multiprocessors Maxwell) aplicado em um Die GM20x:
Diagrama 4 - SMM da arquitetura Maxwell
O SMM é uma evolução do SMX da arquitetura Kepler.
Podemos ver a mesma estrutura da geração anterior, composta pelo Cache de Instruções, Buffer de Instruções (I Cache), Warp Schedulers (MT-IU), Unidades de Despacho (C Chache) e os Registradores de Arquivos dispostos da mesma forma que na arquitetura Kepler. O Operand Collector tem o mesmo papel da geração anterior também.
O Register File (Registrador de Arquivos) também possui 65.536 entradas de 32 bits cada divididas em 4 blocos, cada um com 16.384 entradas.
A grande mudança está na redução da quantidade de núcleos em cada SMM. São 4 grandes blocos de processamento (ou partições, como queira), cada um contendo 32 CUDA Cores, 8 SFUs e 8 LD/ST Units. Ao todo são 128 CUDA Cores, 32 LD/ST Units e 32 SFUs. As DP Units também se fazem presente na arquitetura Maxwell.
De forma semelhante a arquitetura Kepler, a nVidia implementou muito menos DP Units em comparação á quantidade de CUDA Cores, porém, a diferença aumentou. Agora, para cada 64 CUDA Cores existem apenas 2 unidades para processamento de FP64.
Dentro de um SMM também há uma quantidade menor de unidades TMU. São apenas 8 unidades, 4 para cada par de partições.
Da mesma forma que ocorre com a Kepler, há um grande bloco Load / Store para gerenciar todas as unidades LD/ST do SMM e que também é alimentado pelo Cache L1.
O cache L1 possui 64 kB para a primeira leva de chips com arquitetura Maxwell, exatamente a mesma quantidade da arquitetura Kepler e da Fermi. Já para os chips com arquitetura Maxwell 2.0 (que é o caso do Diagrama 4 deste texto) o cache L1 sobe para 96 kB.
O bloco de hardware Polymorph Engine ainda é versão 2.0 nesta arquitetura.
Realocar circuitos e retirar alguns deles (como foi o caso da redução de núcleos CUDA e DP Units) reduziu o consumo de energia dos GPCs. Ao contrário do Kepler, os 128 CUDA Cores do SMM, que são divididos em quatro grupos de 32 núcleos, se alinham perfeitamente à maneira como as instruções são agrupadas em Warp Schedulers de 32 threads, reduzindo ineficiências óbvias e aumentando a simetria.
Veja abaixo o diagrama do chip GM200 com arquitetura Maxwell:
Diagrama 5 - Chip GM200 da arquitetura Maxwell 2.0
Cada GPC da arquitetura Maxwell contém no máximo quatro unidades SMM gerenciadas por uma unidade Raster Engine, assim como ocorre na Fermi e na Kepler.
Os circuitos ROP continuam fora dos GPCs, porém agora são organizadas em blocos com 16 unidades cada. O gerenciamento e intercomunicação com os GPCs, Cache L2, memória RAM e PCI Express continua sendo feito pela Giga-Thread Engine.
Para finalizar, o Chip GM200 tem no total 6 controladores de memória RAM (um controlador possui dois canais de 32 bits cada, totalizando 12 canais para VRAM) que podem operar com o padrão GDDR5. Ao todo são 6 GPCs, 3072 CUDA Cores, 768 LD/ST Units, 768 SFUs, 192 TMUs e 96 ROPs.
Assim como a arquitetura Kepler, a Maxwell também possui duas gerações:
→ Maxwell: Chips GM107 e GM108;
→ Maxwell 2.0: Chips GM200, GM204, GM206 e GM20B.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
A arquitetura Maxwell implementa a segunda geração do NVENC, enquanto a Maxwell 2.0 implementa a terceira geração do NVENC. Nas especificações do bloco NVENC é comum encontrar termos relacionados ao formato de codificação, como por exemplo H.264, H.265, I-Frame, P-Frame, B-Frame, especificações de Croma, resolução de imagem, FPS e outros termos, por isso não vamos adentrar no NVENC neste artigo, pois o enfoque é a estrutura de hardware do chip. Num artigo futuro essas informações poderão ser tratadas de melhor forma.
Quanto ao decodificador de vídeo, a nVidia utiliza o PureVideo HD, um bloco de hardware dedicado ao processamento multimídia. O PureVideo possui várias gerações, porém a Maxwell utiliza a PV de sexta geração, enquanto a Maxwell 2.0 utiliza a PV de sétima geração.
A principal diferença em relação a Maxwell 2.0 é que é que GPUs Maxwell anteriores implementaram a reprodução HEVC (H.265 - High Efficiency Video Coding) usando uma solução de decodificação híbrida, que envolveu a CPU e o sistema de computação paralela da GPU. A implementação híbrida é significativamente mais lenta do que o mecanismo dedicado no hardware de decodificação de vídeo do VP7.
CURIOSIDADE: A sexta geração PureVideo HD às vezes é chamada de "PureVideo HD 6" ou "VP6", embora esta não seja uma designação oficial da Nvidia. Esta geração de PureVideo HD corresponde ao Nvidia Feature Set E (ou "VDPAU Feature Set E"). Já a sétima geração corresponde ao Nvidia Feature Set F (ou "VDPAU Feature Set F").
A placa de vídeo GTX970 surgiu no mercado com um Chip GM204 "capado", isto é, com alguns circuitos desativados e desempenho reduzido.
Diagrama 6 - Chip GM204 capado utilizado na placa de vídeo GTX970
Como podemos ver, os 2 MB de Cache L2 da GM204 são divididos em oito blocos de 256 kB cada. Perceba que cada bloco de 256 kB do Cache L2 possui uma ligação com um controlador de memória RAM.
De acordo com o Diagrama 5, são apenas quatro controladores de memória RAM, porém como podemos ver no Diagrama 6, são na verdade oito controladores de 32 bits agrupados em quatro blocos de hardware, totalizando um barramento de 256 bits. Isso se deve a cada chip de memória GDDR possuir um barramento de 32 bits, necessitando que haja um controlador com a mesma largura para controla-lo.
Cada controlador de 32 bits deste consegue operar com dois chips de memória GDDR ligados em paralelo (o acesso é de forma individual feito por uma linha "Select Chip"), ou seja, o GM204 pode funcionar com 16 chips GDDRx, que totalizam os 4 GB suportados pelo sistema.
Com base no Diagrama 6, podemos entender que um controlador de memória RAM de um chip gráfico opera com 32 bits de largura de barramento, porém os controladores podem ser agrupados em dupla no diagrama, dando a impressão de que existem controladores de VRAM de 64 bits.
A grande peculiaridade do chip GM204 são seus circuitos desativados. Observe que existe um bloco de 256 kB de Cache L2 desativado, reduzindo os originais 2 MB para apenas 1,75 MB (1792 kB) de Cache. fazendo com que um dos canais de VRAM de 32 bits seja ligado em outro bloco de 256 kB e o compartilhe com outro canal de 32 bits. Há também 8 unidades ROP desativadas por causa deste corte de Cache L2, fazendo com que o chip tenha apenas 56 blocos de saída de rasterização.
Isso, obviamente, gera um lentidão no sistema, fazendo com que 3,5 GB da memória RAM GDDRx tenha uma largura de barramento de 224 bits e uma velocidade de 196 GB/s, e os 512 MB restantes sejam ligados num controlador de 32 bits limitado a míseros 28 GB/s.
Apenas os 3,5 GB seriam úteis, pois os demais 512 MB iriam limitar o desempenho e gerar bugs, sendo que a única forma de resolver isso é na base da otimização de drivers, para que o controlador mais lento opere com dados menos necessários. Armazenar parte dos frames e parte das texturas de um cenário nesses 512 MB geraria uma perda de desempenho grande.
Para finalizar o assunto, o GM204 completo possui 2048 CUDA Cores distribuídos em seus 16 blocos SMM. O GM204 capado possui apenas 13 blocos SMM em funcionamento, ou seja, existem apenas 1664 CUDA Cores.
PEQUENAS SEMELHANÇAS COM A AMD
Outra coisa que devemos nos atentar: Observe bem que o cache L2 possui uma ligação com os controladores de memória VRAM, com as unidades ROP e ao mesmo tempo, tanto os controladores quanto o Cache e as ROP's se comunicam com o bloco de hardware Giga-Thread Engine, responsável pela intercomunicação geral dentro do chip, como já foi explicado anteriormente.
Isso também ocorre de forma parecida com a arquitetura TeraScale 1, 2 e 3 da AMD, apresentadas no Capítulo anterior, que possuem um grande Hub interno para intercomunicação entre blocos de hardware, sendo que os controladores de VRAM estão diretamente ligados aos blocos de Cache L2 e a este Hub, bem como aos blocos de Color Cache e o Z-Stencil Cache, que alimentam os circuitos que trabalham com profundidade de imagem (coordenada Z).
E este artigo desvendou mais duas arquiteturas da nVidia. No próximo Capítulo vamos estudar a arquitetura GCN (Graphics Core Next) da AMD.
Para sugestões, dúvidas ou reclamações entre em contato pelo e-mail hardwarecentrallr@gmail.com.
FONTES e CRÉDITOS
Texto: Leonardo Ritter.
Diagramas e imagens: GPU-Z; Leonardo Ritter.
Fontes: GPU-Z, hardware.fr; Meio-Bit, Wikipedia (Somente artigos com fontes verificadas!).
Última atualização: 30 de Outubro de 2022.