Continuando a série de artigos sobre as arquiteturas dos chips gráficos, hoje vamos tratar da microarquitetura Graphics Core Next - abreviada por GCN -, da AMD.
Neste momento já não me importo tanto em chamar de ATi / AMD, pois desde as Tera Scale a engenharia da AMD já estava comandando os projetos.
Se nas TeraScale a AMD não focava tanto em GPGPU, as GCN vieram pra mudar a situação da marca no mercado e fazer uma concorrência melhor frente ao 'olho verde' (nVidia).
A GCN teve 5 gerações, e três delas serão mostradas aqui, começando pela...
Os chips que utilizam desta arquitetura são os da família AMD Southern Islands.
Veja abaixo um diagrama simplificado da arquitetura GCN 1.0 utilizado no die Cabo Verde:
Diagrama 1 - Die Cape Verde com a arquitetura GCN 1.0
Observe que existe o barramento interno denominado "Hub" no diagrama. Ele opera da mesma forma que os "Hub" das arquiteturas Tera Scale e que o Giga-Thread Engine das arquiteturas nVidia, ou seja, ele faz a intercomunicação entre os demais blocos de hardware do circuito.
1. Assim como nas arquiteturas TeraScale, existe o Command Processor. Ele distribui os trabalhos relacionados com renderização de games e computação paralela para os respectivos blocos de hardware do sistema. Ligado ao Hub de dados, ele recebe as informações e as distribui para os blocos ACE e para o bloco de Geometria / Rasterização.
2. O "Setup Engine" da arquitetura TeraScale 1, bem como o "Graphics Engine" das TeraScale 2 e 3 foi substituído pelo bloco de hardware Geometry / Rasterizer. Apesar de trabalhar com vértices (etapa de Geometria), faz apenas a montagem, o tesselation, o direcionamento dos dados referentes as coordenadas "Z" (de profundidade) para o Z-Buffer e Z-Stencil e dá início à rasterização, porém, as primitivas gráficas "brutas" (ou outro tipo de dado, afinal é uma GPGPU) já separadas em tarefas serão processadas pelos shaders unificados que vem na sequência. Para entender melhor estes termos e o funcionamento dos circuitos deste bloco de hardware, volte ao Capítulo 4 desta série de artigos.
Em partes, pode equivaler à Unidade Raster Engine, presente em cada GPC da nVidia, no entanto, diferentemente de sua concorrente a AMD colocou apenas um bloco de hardware de "controle de geometria" para todos os agrupamentos de Shaders Unificados.
3. Os novos Asynchronous Compute Engines da AMD servem como processadores de comando para operações de computação de propósito geral. O principal objetivo dos ACEs será aceitar o trabalho e despachá-lo para as UCs pra processamento. Como o GCN é projetado para trabalhar simultaneamente em várias tarefas, pode haver várias ACEs em um die, com cada uma delas decidindo sobre a alocação de recursos, alternância de contexto e prioridade da tarefa. A AMD não estabeleceu uma relação imediata entre ACEs e o número de tarefas que podem ser trabalhadas simultaneamente.
Um efeito de ter os ACEs é que a GCN tem uma capacidade limitada de executar tarefas fora de ordem. A GCN é uma arquitetura em ordem, e o fluxo de instruções em uma frente de onda não pode ser modificado. No entanto, as ACEs podem priorizar tarefas, permitindo que elas sejam concluídas em uma ordem diferente da recebida. Isso permite a liberação dos recursos que essas tarefas estavam usando o mais cedo possível, em vez de fazer com que haja um consumo de recursos por um longo período de tempo em um estado 'quase concluído'. Isso não difere muito das CPUs ordenadas modernas, que lidam com multithreads.
Veja o Diagrama de uma ACE abaixo:
Diagrama 2 - Por dentro de uma ACE (destacada em vermelho)
Cada Asynchronous Compute Engines pode analisar comandos de entrada e despachar trabalho para as unidades de computação (CUs). Cada ACE pode gerenciar até 8 filas independentes. Os ACEs podem operar em paralelo com o Command Processor e dois motores DMA. O Command Processor lida com filas de gráficos e despacha o que é referente à Computação de Propósito geral para as ACEs, já os mecanismos DMA lidam com filas de cópia. Cada fila pode despachar itens de trabalho sem esperar que outras tarefas sejam concluídas, permitindo que fluxos de comando independentes sejam intercalados nos SPs da GPU.
Em resumo:
→ Quando o dado processado é referente à gráficos, o Command Processor direciona para o bloco de hardware "Geometry / Rasterizer Engine". Ele é responsável pelo início do processamento e direcionamento para os shaders unificados das CUs.
→ Quando o dado processado é referente à computação de propósito geral, as unidades ACE dão início à organização das tarefas que vão para as CUs.
Dentro do bloco de hardware Graphics Engine
OBSERVAÇÃO: Perceba que o Geometry / Rasterizer está dentro do bloco GE.
1. O bloco de hardware com o nome genérico "Multi Threaded" é como se fosse o Warp Scheduler na arquitetura nVidia. É um "processador de despacho", distribuindo as tarefas aos núcleos de processamento presentes nas Unidades Computacionais GCN. Ele possui muitas semelhanças com seu antecessor, o Ultra Thread Processor, da arquitetura TeraScale (Capítulo 6 desta série). A grande diferença é que ele está apto para trabalhar com uma quantidade infinitamente maior de tarefas e pode alternar entre tarefas relacionadas ao Sombreador de Vértices, Sombreador de pixels, Sombreador de Geometria, bem como tarefas de computação de propósito geral de uma forma muito rápida afim de otimizar o processamento. Há um nível mas baixo de controle e otimização que será descrito mais adiante.
Note que os blocos de hardware na frente do bloco Multi-Threaded possuem o símbolo "I$" e "K$", Pois bem, assim como em um Stream Multiprocessor da nVidia, é necessário um bloco Instruction Cache (Cache de Instruções - I$) e um bloco Constant Cache (Cache de Constantes - K$) para cada agrupamento de Unidades Computacionais GCN.
2. Da mesma forma que ocorre nos chips nVidia, há uma distribuição de Threads, e nisso vem um encadeamento, onde elas podem trocar informações entre sí para que cada tarefa seja executada da melhor forma, por isso que há o bloco "Data Request Bus", que em português significa "Barramento de Pedido de Dados".
Neste bloco de hardware chamado Data Request Bus (que não está incluso no Diagrama 1) há uma ligação ao bloco Global Data Share, uma ligação com as Unidades Computacionais GCN e também com o Cache L1 e L2.
Com comunicação direta com as ACEs, o Global Data Share (GDS) contém uma memória cache de compartilhamento de dados globais e um "Global Synchronization Registers" que podem ser usadas por WaveFronts para executar um kernel (ou uma tarefa, por exemplo) em todos os Shaders Unificados. Esta memória permite compartilhamento de dados entre vários grupos de trabalho (CUs). O GDS está configurado para fornecer acesso total a qualquer local para uso por qualquer WaveFront ("frente de onda", traduzido literalmente). O bloco GDS permite compactação rápida de dados ou a criação de estruturas de dados complexas na memória.
Cada Unidade Computacional tem seus dados LDS, isto é, dados utilizados pelo grupo de trabalho local, mas que possuem ligação ao bloco Global Data Share.
CURIOSIDADE: Um "Shader" é um pequeno programa que pode ser escrito em GLSL (da API Open GL) para realização do processamento gráfico. Já um "Kernel", mencionado no parágrafo anterior, é um pequeno programa escrito em OpenCL para computação de propósito geral.
OBSERVAÇÃO: Para saber mais sobre a "Frente de Onda" leia o artigo sobre as arquiteturas TeraScale 1, 2 e 3 ou continue lendo este texto.
3. Cada Unidade Computacional GCN possui 64 Stream Processors. No caso do Die Cape Verde são 10 Unidades Computacionais, totalizando 640 SPs (SP é a unidade de hardware equivalente ao CUDA Core da nVidia).
Dentro de uma Unidade Computacional
O grande questionamento vem agora: O que há exatamente dentro das Unidades Computacionais da arquitetura GCN?
Veja o diagrama abaixo:
Diagrama 3 - O que há dentro de uma Unidade Computacional GCN?
Como foi dito anteriormente, uma Unidade Computacional GCN possui 64 Stream Processors, e estas 64 SPs são divididas em quatro blocos, denominados SIMD 0, SIMD 1, SIMD 2 e SIMD 3. Obviamente, cada um desses blocos possui 16 SPs.
Outra coisa notável é que cada SP é uma Unidade Lógica Aritmética (ALU).
A TeraScale 1, 2 e 3 os blocos também são tratados como SIMD. Se você leu o Capítulo 5 desta série, viu a explicação. Para relembrar:
"SIMD (Single Instruction, Multiple Data): Máquinas que executam exatamente o mesmo fluxo de instruções (mesmo programa) em cada uma das suas unidades de execução paralela, considerando fluxos de dados distintos. Um bom exemplo são as unidades de sombreamento de Pixel da arquitetura nVidia Kelvin, Rankine e Curie, que operam executando uma instrução Pixel Shader e com ela processam vários fragmentos que formam a imagem."
→ A TeraScale 1 possui 160 blocos SIMD (Stream Processor Unit - SPU), portanto, conseguindo processar dados com até 160 instruções diferentes simultaneamente;
→ A TeraScale 2 possui 320 blocos SIMD (Stream Processors Unit - SPU), portanto, conseguindo processar dados com até 320 instruções simultaneamente;
→ A TeraScale 3 possui 384 blocos SIMD (Stream Processor Unit - SPU ou Radeon Core), portanto, conseguindo processar dados com até 384 instruções simultaneamente.
Cada um destes quatro blocos SIMD da GCN consegue executar uma instrução, ou seja, uma Unidade Computacional consegue executar quatro instruções simultaneamente. Com isso, podemos concluir também que com apenas uma instrução, 16 SPs conseguem processar dados.
CURIOSIDADE: No caso da nVidia, podemos utilizar a designação SIMT (Single Instruction, Multiple Thread). Veja os Warp Schedulers das arquiteturas nVidia: cada um consegue organizar 32 Threads para serem processadas com uma instrução. Cada uma dessas 32 Threads é direcionada para um CUDA Core. É aí que vem o gargalo da arquitetura Kepler. A nVidia Kepler possui um SMX com quatro Warp Schedulers para 192 CUDA Cores.
Outra curiosidade é que, enquanto um CUDA Core é um núcleo que processa operações escalares, um Stream Processor da arquitetura GCN é um núcleo que processa operações vetoriais.
Voltando pra AMD, numa UC também há o bloco de hardware de controle e a unidade de ramificação, denominada "Front End Fetch & Decode Logic", responsável por buscar, decodificar e programar as WaveFronts e suas instruções. Isso é ainda aumentado com um armazenamento de dados de 64 kB para cada bloco SIMD e 16 kB de cache L1, que também integra o cache de textura.
Assim como na arquitetura TeraScale, na arquitetura GCN o cache L1 também integra dados de textura, e isso não implica em perda de desempenho, pois os textels são compactados dentro deste pequeno bloco de memória.
CURIOSIDADE: Perceba no Diagrama 1 que o bloco Graphics Engine possui 10 CUs dividas em 3 agrupamentos. O primeiro deles possui 4 Undades Computacionais, já o segundo e o terceiro possuem 3 Unidades cada. Observe no Diagrama 3 que o cache L1 é compartilhado entre os agrupamentos.
Finalmente, há uma nova unidade: a unidade escalar. Veremos isso mais abaixo.
O abandono do conjunto de instruções VLIW
Mas antes de prosseguirmos, vamos analisar outro ponto. Agora que sabemos como é uma CU e quais são os pontos fracos do VLIW (leia o Capítulo 6 desta série), podemos finalmente chegar ao centro da questão: por que a AMD está deixando o VLIW e indo para um sistema não-VLIW?
Como mencionamos anteriormente, o ponto fraco do VLIW é que a ordem de execução dos dados é programada estaticamente com antecedência pelo compilador. Como resultado, se quaisquer dependências por outros dados surgirem enquanto o código está sendo executado, não há desvio da programação, a ordem de execução não pode ser mudada. Portanto, a primeira mudança é imediata: em um design SIMD não VLIW, a ordem de execução dos dados é movida do compilador (virtual) para o hardware (físico). É a CU que agora está programando a ordem de execução dos dados.
O agendamento de hardware dinâmico implica perdas também, pois ele pode encobrir dependências e outros tipos de paralisações, mas esse agendador de hardware ocupa espaço físico no chip. A razão pela qual as arquiteturas anteriores da AMD eram VLIW era pelo motivo do compilador poder fazer um bom trabalho para gráficos, e a área do die de Silício era melhor utilizada preenchendo-a com núcleos de processamento. Mover o agendamento para o hardware é mais dinâmico, mas agora estamos consumindo espaço do die com um bloco eletrônico para tal fim, espaço antes usado para unidades de processamento. É uma troca.
Então, o que dá pode fazer com agendamento dinâmico e SIMDs independentes que não poderia ser feito com a coleção de SPs das arquiteturas TeraScale? Você pode contornar dependências e programar as coisas. Note que a GCN não é uma arquitetura fora de ordem. Dentro de uma WaveFront, as instruções ainda devem ser executadas em ordem, então você não pode pular por um programa de sombreador de pixel, por exemplo, e executar diferentes partes dele ao mesmo tempo. No entanto, cada CU da arquitetura SIMD pode trabalhar com quatro diferentes WaveFronts. Pode ser outra frente de onda gerada pela mesma tarefa (por exemplo, um grupo diferente de pixels / valores) ou pode ser uma frente de onda de uma tarefa totalmente diferente.
CURIOSIDADE: O que seria "frente de onda"? Os circuitos das GPGPUs da AMD / ATi são projetados para se destacarem na execução de muitas operações da mesma Thread (Tarefa) em paralelo, dividindo-a em agrupamentos menores chamados de "frentes de onda". No caso da AMD, uma frente de onda é um grupo de 64 pixels / valores e a lista de instruções a serem executadas para o processamento destas variáveis, podendo também ser descrito como "64 itens de trabalho". Portanto, cada Unidade Computacional da arquitetura GCN pode "pegar" um conjunto de WaveFronts que forma uma Thread ou parte de um conjunto de WaveFronts que forma uma Thread e fazer várias operações para processa-la, sendo uma em cada bloco SIMD.
Em resumo:
→ Cada bloco SIMD consegue executar um 'pedaço' (WaveFront) de uma tarefa (Thread). No caso da TeraScale 1, 2 e 3, apesar de possuírem vários blocos SIMD, eles deveriam executar os 'pedaços' da tarefa com uma ordem definida via software e sem a possibilidade de dependência e troca de informações entre WaveFronts durante a execução;
→ Na GCN, a ordem de execução destes 'pedaços' é definido / agendado por um bloco de hardware no chip. Agora, se um WaveFront depender de outro para produzir um resultado, o sistema pode trabalhar com uma troca de informações e um desvio de programação dinâmicas, isto é, via hardware.
→ Com a arquitetura GCN, as CUs não são mais grandes blocos SIMD. Se na TeraScale a CU era formada por 16 blocos SIMD (SPUs), agora o trabalho é mais amplo, porém comportando quatro SIMDs internamente.
CURIOSIDADE: Tanto a TeraScale quanto a GCN processam as threads em 'pedaços', sendo cada grupo de SPs responsável por uma destas WaveFronts. Já na nVidia, cada CUDA Core processa uma thread.
Um Shader (Processamento Gráfico) ou um Kernel (Computação de Propósito Geral) formam processos que não precisam de tantos registros, mas que precisam carregar dados do sistema ou da VRAM. Esta operação vem com latência significativa. A AMD e a Nvidia escolheram abordagens semelhantes para ocultar essa latência inevitável: o agrupamento de vários 'pedaços de código', denominada "WaveFront" pela AMD e de "Dobra" pela Nvidia.
A nVidia chama simplesmente de Thread (Tarefa) e as distribui nos Shaders Unificados pelo Warp Scheduler. Um conjunto de Threads forma a "Dobra". Já a AMD trabalha com a definição de uma grande Thread dividida em pedaços menores, chamados de "Frentes de Onda".
Independente da nomenclatura, um pedaço de código destes é a menor unidade de código executável, a melhor maneira de processar um conjunto de coisas com a mesma instrução. Isso torna as arquiteturas de Shader Unificados da nVidia um sistema SIMT e as da AMD um sistema SIMD.
A Unidade Escalar (Scalar ALU)
Novidade no GCN, a unidade escalar serve para manter ainda mais as operações ineficientes fora dos SIMDs, deixando os ALUs vetoriais das SPUs para executar as instruções em massa. A unidade escalar é composta de uma única ALU escalar, junto com um arquivo de registro (RF - Register File) de 8 kB.
O que uma unidade escalar faz? Em primeiro lugar, ela executa operações matemáticas “pontuais”. Grupos inteiros de pixels / valores passam pelas unidades vetoriais juntos, mas as operações independentes vão para a unidade escalar para não desperdiçar o tempo do SIMD. Isso inclui tudo, desde operações inteiras simples até operações de fluxo de controle, como desvios condicionais (if / else) e saltos e, em certos casos, operações de memória 'somente leitura' de um cache L1 escalar dedicado.
No geral, a unidade escalar pode executar uma instrução por ciclo, o que significa que pode completar 4 instruções durante o período de tempo que leva para uma WaveFront ser concluída em um SIMD.
Conceitualmente, isso confunde um pouco mais a linha tênue entre uma GPU escalar e uma GPU vetorial, mas por ter os dois tipos de unidades, significa que cada uma delas pode funcionar nas operações mais adequadas para tal. Além de evitar a alimentação das SPUs com conjuntos de dados não vetorizados, isso também irá melhorar a latência para operações de fluxo de controle, onde o chip Cayman (TeraScale 3) tinha uma desagradável latência de 44 ciclos de clock.
Agora veremos um diagrama mais detalhado de uma Unidade Computacional GCN 1.0:
Diagrama 4 - Por dentro de uma Unidade Computacional GCN
Para cada um dos quatro blocos SIMD existe um buffer denominado "PC&IB" que consegue armazenar instruções para até 10 WaveFronts. Como uma Frente de Onda é composta por 64 pixels / valores e cada bloco SIMD possui 16 SPs (ALUs), são necessários 4 ciclos de clock para que haja o processamento.
Perceba que existe uma comunicação direta entre o Cache L1 (que está dentro da CU) e o Cache L2, que está junto das saídas de rasterização e controladores de RAM.
Veja no Diagrama 4 o Local Data Share (LDS), sua ligação com o Cache L1. Lembre-se de sua ligação externa com o Global Data Share (GDS).
Assim com nas arquiteturas nVidia, mais precisamente a partir da Kepler, há o suporte para FP16, FP32 e FP64.
Na GCN 1.0 existem 4 TMUs dentro de cada Unidade Computacional. Elas não foram inclusas no Diagrama 2 e 3. Como já foi dito, as TMUs também utilizam o Cache L1, não se fazendo necessário a adição de memória cache exclusiva para texturas no chip.
Saída de Rasterização
OBSERVAÇÃO: Perceba que os blocos de hardware da saída de rasterização também estão inclusos na GE.
1. Após os dados serem processados, eles são direcionados ao Shader Export, um bloco de hardware que distribui os dados entre as unidades ROP e Z-Stencil de forma a otimizar o uso destes blocos de hardware, uma ideia semelhante ao Fragment Crossbar, estudado na arquitetura Curie, da nVidia.
2. E chegamos no bloco de hardware de saída de rasterização (ROP). Nele temos características semelhantes ao bloco utilizado nas TeraScale. Como pode ser visto no Diagrama 1, há um cache Z$ (Cache Z-Stencil) e um cache C$ (Color Cache, também chamado de RGB-Buffer). Assim como nas TeraScale, o Z$ está ligado ao bloco Geometry / Rasterizer.
Cada bloco possui 4 unidades ROP e 16 unidades Z-Sencil. O chip Cape Verde, por exemplo, possui 4 blocos de saída de rasterização.
A arquitetura GCN, assim como as anteriores, tem seu cache L2 ligado diretamente em seus controladores de memória RAM e na saída de rasterização. A arquitetura suporta 64 kB ou 128 kB de cache L2 por controlador de memória. Lembrando que dado os controladores de RAM da AMD têm normalmente 64 bits de barramento cada. O cache L2 é write-back e será totalmente coerente para que todas as CUs vejam os mesmos dados, economizando transferências que gastam ciclos de clock e atrasam o processamento.
A sincronização CPU / GPU também é tratada no nível do cache L2, onde é fundamental manter o sincronismo entre os dois para haver eficiência no processamento de dados. Para APUs, há um barramento de alta velocidade dedicado entre os dois, enquanto as GPUs dedicadas trabalham com o protocolo da interface PCIe.
Veja abaixo o diagrama do chip Curacao com arquitetura GCN 1.0:
Diagrama 5 - Die Curacao
Perceba que o Diagrama 5 possui o dobro de blocos em relação ao Diagrama 1, que representa o die Cape Verde. Se na Cape Verde havia apenas um bloco Graphics Engine (GE) com 10 Unidades computacionais, neste há duas GEs, ou seja, 20 CUs.
CURIOSIDADE: Nas arquiteturas nVidia vemos os "Operand Collectors" fazendo uma intercomunicação entre os blocos de CUDA Cores e demais circuitos do TPC (Tesla) / GPC (Fermi) / SMX (Lepler) / SMM (Maxwell) e etc. Nas arquiteturas AMD temos algo que pode ser dito como 'equivalente', isto é, o Global Data Share, que interliga as ACEs, as Unidades Computacionais e o Cache L2.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
Diferente das TeraScale, a GCN 1.0 já integra um sistema de codificação de vídeo denominado VCE, sigla para "Video Coding Engine", que em português significa "Motor de Codificação de Vídeo". A GCN 1.0 possui a versão 1.0 do VCE, uma implementação completa de hardware do codec de vídeo H.264 / MPEG-4 AVC.
Como seu bloco de codificação de entropia (EC) também é um Video Codec Engine acessível separadamente, ele pode ser operado em dois modos, isto é, modo totalmente fixo e modo híbrido.
CURIOSIDADE: Lembrando que, a compressão de dados com perdas envolvem, generalizadamente, as etapas ME (Motion Estimation), Transformada discreta de Cosseno (DCT) e a EC (Entropy Encode), como mostra os diagramas abaixo:
Diagrama 6 - Representação resumida do bloco de hardware VCE
No modo híbrido, apenas o bloco de codificação de entropia da unidade VCE é usado, enquanto restante do processo é transferido para as Unidades Computacionais da GPU.
O VCE 1.0 é compatível com H.264 YUV420 (quadros I & P), codificação temporal SVC H.264 e Display Encode Mode (DEM).
Já para a codificação e transcodificação, a GCN 1.0 integra o UVD 4, uma atualização do UVD 3 que inclui poucos modificações grandes, como por exemplo a interpolação de quadro melhorada para H.264.
Os chips que utilizam desta arquitetura são os da família AMD Sea Islands.
Na Arquitetura GCN 2.0, o design das Unidades Computacionais continuou quase igual, porém a quantidade de circuito aumentou. Veja abaixo o diagrama do chip Vesuvius:
Diagrama 7 - Chip Vesuvius, com seus 2816 Shaders unificados
Como pode ser visto no Diagrama 7, o Global Data Share interliga todos os Shaders Engine, bem como os blocos ACE e o Cache L2, igual ocorre na GCN 1.0.
Shader Engine
Na GCN 2.0 temos a evolução do bloco Graphics Engine, agora chamado de "Shader Engine". Veja o diagrama abaixo:
Diagrama 8 - Shader Engine GCN 2.0
Em cada Graphics Engine permanece um bloco "Geometry / Rasterizer Engine".
Mas o que há exatamente dentro deste bloco?
Veja o Diagrama abaixo:
Diagrama 9 - Por dentro do bloco "Geometry / Rasterizer Engine"
Perceba que o Geometry Processor é composto por alguns núcleos, sendo cada um deles formado por um Montador de Geometria, um Montador de Vértices e um circuito do Tesselator.
Já o bloco Rasterizer também é composto por alguns núcleos, sendo cada um deles formado por um circuito Scan Converter e um Hierarchical-Z. Lembrando que as coordenadas "Z" são enviadas para a Saída de Rasterização (Render Back-Ends), igual ocorre em outras arquiteturas.
Unidades Computacionais
Agora são 11 Unidades Computacionais por GE, totalizando 715 SPs.
Cada Unidade Computacional agora comporta:
-> 65 Shaders unificados (SPs);
-> 44 TMUs;
-> 16 Kb de Cache L1 / Texture Cache;
-> Permanece a Unidade Escalar;
CURIOSIDADE: Perceba que o número de SPs agora é impar. Se na GCN 1.0 eram 64 SPs por CU agora são 65. A AMD passou a contar a Unidade Escalar como um SP adicional na GCN 2.0, por isto este valor anormal.
Saída de Rasterização
Tal qual na GCN 1.0, 2.0 e 3.0 - e diferente das arquiteturas da nVidia - a AMD manteve o bloco de saída de rasterização acoplado ao Shader Engine (ou Graphics Engine).
Observando o Diagrama 7, na saída de rasterização existem 4 blocos (abreviados no diagrama com "RB"), e neles são distribuídas:
-> 64 unidades Z-Stencil;
-> Z-Stencil Cache (Z$);
-> 16 ROPs;
-> RGB Cache (ou Color Cache - C$).
Interligado com a Saída de Rasterização e com os Memory Controllers de VRAM, um grande bloco de cache L2. São 128 kB de L2 para cada controlador de VRAM. Os 8 controladores juntos garantem um barramento de dados de 512 bits.
O die Vesuvius foi um dos chips topo de linha com arquitetura GCN 2.0. Devido a ser um dos mais completos foi utilizado aqui como exemplo.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
Para codificação de vídeo, a GCN 2.0 integra o VCE 2.0, cuja principal evolução é a adição do H.264 YUV444 (I-Frames), B-frames para H.264 YUV420 e melhorias no DEM.
Já para a decodificação, o bloco de hardware UVD 4.2.
Os chips que utilizam desta arquitetura são os da família AMD Volcanic Islands e Pirate Islands.
A arquitetura GCN 3.0 não trouxe nada de muito revolucionário para as GPUs AMD, apenas foi mais um aperfeiçoamento do que já estava no mercado.
O Shader Engine GCN 3.0
Veja abaixo o diagrama de um Shader Engine GCN 3.0:
Diagrama 10 - Shader Engine (Graphics Engine) da GCN 3.0
São 16 Unidades Computacionais, sendo que cada uma possui:
-> 64 SPs distribuídas nos mesmos quatro blocos SIMD (SPUs);
-> 64 TMUs;
-> 16 kB de Cache L1 / Cache de textura;
-> Permanece a Unidade Escalar.
CURIOSIDADE: Aqui a Unidade Escalar não é mais contada como um SP, ou seja, uma CU volta a ter 64 SPs.
CURIOSIDADES: Chips, como por exemplo o Weston, Topaz e o Meso tinham apaneas um Shader Engine com 6 Unidades Computacionais, totalizando 384 Shaders unificados. o Die Wani possui 8 CUs, totalizando 512 Shaders Unificados e o Stoney apenas 3 CUs, totalizando 192 SPs.
Saída de Rasterização
A saída de Rasterização é igual ao da GCN 2.0, ou seja:
-> 4 blocos por Shader Engine;
-> Cada bloco possui 4 ROPs;
-> RGB Cache (I$)
-> Cada bloco possui 16 unidades Z-Stencil;
-> Z-Stencil Cache (Z$).
O Cache L2 é de 128 kB por controlador de VRAM. No Diagrama 9 vemos 8 controladores de VRAM, portanto há 2048 kB de Cache L2.
Veja abaixo o diagrama do die Fiji (Pirate Islands), já incorporando VRAM do tipo HBM:
Diagrama 11 - Die Fiji com suas 64 Unidades computacionais
Assim como a GCN 2.0, são 8 blocos ACE e a Saída de Rasterização é acoplada aos Shaders Engine.
CURIOSIDADE: O chamado "Motor 3D", isto é, a matriz de Shaders Unificados, denominada pela AMD como "Graphics and Compute Array" é conhecida também como "GFX" e cada geração da arquitetura GCN e algumas anteriores possui uma versão aprimorada. Veja abaixo:
-> Rage 9 e R400: GFX2 (porém com Shaders não-unificados);
-> R500: GFX2 (Com Shaders não-unificados, porém unidades ROP GPGPU);
-> TeraScale 1: GFX3
-> TeraScale 2: GFX4
-> TeraScale 3: GFX5
-> GCN 1.0: GFX6
-> GCN 2.0: GFX7
-> GCN 3.0: GFX8
Com isso podemos notar que, por mais que uma Unidade Computacional GCN permaneça igual a cada geração, existem melhorias no processo de produção, eficiência energética, clock, latências e vários outros fatores que as tornam diferentes uma das outras. Outro exemplo são as TeraScale 1 e 2, que possuem os SPUs VLIW5, enquanto a TeraScale 3 possui SPUs VLIW4. São sutis diferenças na matriz de processadores que as fabricantes fazem a cada geração.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
A GCN 3.0 integra o bloco VCE 3.0 ou 3.1, dependendo do die. A tecnologia incorpora o suporte ao HEVC / H.265, sendo esta a principal evolução.
Já para decodificação, o UVD 5 ou UVD 6, dependendo do die. O UVD 5 trouxe suporte ao 4k de forma mais ampla. Já o UVD 6 trouxe 4k em HEVC / H.265. O suporte ao HDR10 em HEVC / H.265 e ao codec VP9 veio com a UVD 6.3, porém esta faz parte de chips com GCN 4.0.
Devido a extensão e complexidade deste texto, as arquiteturas GCN 4.0 e 5.0 ficarão para o próximo capítulo dedicado aos chips AMD.
Leia os capítulos anteriores desta série pra entender melhor o que foi descrito neste texto.
Para dúvidas, correções ou sugestões, mande um e-mail para hardwarecentrallr@gmail.com.
FONTES e CRÉDITOS
Texto: Leonardo Ritter
Diagramas: GPU-Z; Leonardo Ritter;
Fontes: GPU-Z, AnandTech; Wikipedia(somente artigos com fontes verificadas!).
Última atualização: 08 de Outubro de 2023.