• Drano Rauteon

GPU: Como Funciona - Parte 6

Neste artigo vamos estudar um pouco das Unidades Computacionais da AMD/ATi.

A partir da arquitetura TeraScale (2005 ~ 2013), a AMD/ATi passou a utilizar shaders unificados, porém ainda manteve um bloco de hardware chamado "Setup Engine" para e etapa de Geometria do Pipeline Gráfico, e neste bloco incluiu o circuito Tesselator, que foi integrado via hardware dedicado a partir do DirectX 11, igual já detalhamos no artigo anterior.

Veja abaixo o diagrama da AMD RV770, lançado em 16 de Junho de 2008, sendo um dos chip's mais avançados da arquitetura TeraScale na época.

Diagrama 1 - AMD/ATi RV770 com arquitetura TeraScale


Há grandiosas diferenças entre as arquiteturas de shaders unificados da nVidia. Um delas é o bloco de hardware com todos os núcleos de processamento, isto é, os shaders.

Primeiramente, de praxe, vemos um grande barramento interno do chip interligando todos os circuitos denominado "Hub". Assim como na arquitetura Tesla, há um "Command Processor" responsável pelo controle dos dados que vão ser processados.

O Setup Engine, 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 a 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.


CURIOSIDADE: Um ponto interessante é que a TeraScale 1 não suporta o DirectX 11 nem openGl 4.0 de maneira nativa, portanto não deveria haver o Tesselation. No entanto, as unidades do Tesselador TeraScale permitem aos desenvolvedores pegar uma malha poligonal simples e subdividi-la usando uma função de avaliação de superfície curva. Existem diferentes formas de mosaico, como Superfícies de Bézier com N-patches, B-splines ou NURBS, e também algumas técnicas de subdivisão da superfície, que geralmente incluem mapa de deslocamento de algum tipo de textura. Embora esta especificação não fizesse parte dos requisitos do OpenGL 3.3 ou Direct3D 10.0, e concorrentes como a série GeForce 8 não possuíssem hardware semelhante, a Microsoft adicionou esse recurso de mosaico como parte de seus planos futuros do DirectX 10.1.

A ATi já havia criado a tecnologia TruForm (com base nas superfícies de Bézier com N-Patches) e incorporado no Chip R200, lançado em 14 de Agosto de 2001 e que equipava a Radeon 8500. O R200 já tinha suporte ao DirectX 8.1 (que implementava o Tesselation, mas de forma não muito aceita pela comunidade desenvolvedora de games), portanto foi relativamente fácil criar anos depois um "Programmable Tesselator" para as TeraScale 1.


O bloco de hardware Ultra Threaded Processor é como se fosse o Warp Scheduler na arquitetura nVidia, é um "processador de despacho", distribuindo as WaveFronts (você verá o significado mais abaixo) aos núcleos de processamento. Ele possui muitas semelhanças com seu antecessor, o Ultra Thread Dispatch Processor, da arquitetura R500 (Capítulo 4 desta série). A grande diferença é que ele está apto a trabalhar com uma quantidade infinitamente maior de tarefas e pode alternar entre tarefas relacionadas ao Sombreador de Vértices, Sombreador de pixels e Sombreador de Geometria de uma forma muito rápida afim de otimizar da melhor forma o processamento. Há também um nível mas baixo de controle e otimização que será descrito mais adiante.

O Ultra-Threaded Processor possui uma memória cache de instruções e uma memória cache de constantes, ambas interligadas nos controladores de memória RAM.


Nas arquiteturas AMD/ATi, como já foi dito várias vezes, os Shaders Unificados são chamados de Stream Processors, sendo estes SP's agrupados em várias Stream Processors Units (SPU). Já os clusters de SPU's são denominados CU's (Computer Units - Unidades Computacionais, os núcleos SIMD).


No diagrama da RV770 vemos um grande bloco denominado genericamente como "SIMD Cores", porém este bloco é dividido em 10 CU's. Veja abaixo a divisão do bloco de núcleos da RV770:

Diagrama 2 - Organização das Unidades Computacionais na arquitetura TeraScale


Cada uma das 10 Computer Units (CU's) tem 16 Stream Processors Units (SPU's), 4 unidades TMU, uma unidade LDS (Local Data Share) e 16 kB de Cache L1 (que inclui o Texture Cache).


O Paralelismo das TeraScale


Uma Stream Processor Unit trabalha com um design chamado de "Very Long Instruction Word 5". O VLIW5 pode ser traduzido como "Palavra de Instrução Muito Longa", um conjunto de instruções utilizado pela AMD/ATi desde a época dos shaders separados, sendo a base do Sombreador de Vértices. O número "5" se refere a quantidade de blocos de hardware Stream Processors (SP's) que compõem este sistema.

VLIW também é outro tipo de “Instruction Set Architecture” (ISA). Lembre-se de que um ISA compreende o conjunto de instruções que um chip pode entender, e que os ISA's podem ser de tipos diferentes:

→ x86 é um tipo RISC ISA

→ x86–64 é um tipo CISC ISA;

→ ARM é um tipo RISC ISA.

→ A TeraScale é uma plataforma VLIW ISA.


Simplificando, VLIW é outra tentativa de acelerar os chips. Enquanto as abordagens óbvias envolvem simplesmente construir núcleos mais rápidos que conseguem trabalhar com mais instruções por ciclo de clock, outra é simplesmente fazer mais coisas de uma vez. Esta última abordagem necessita de múltiplos núcleos de processamento em um único sistema, o que explica as CPU's de muitos núcleos de hoje, até mesmo os celulares agora ostentando CPUs de 8 núcleos.

Ter vários núcleos é uma coisa, utilizá-los com eficácia é outra bem diferente. Quando você executa um programa, ele cria um processo no sistema (visível no Gerenciador de Tarefas) que, por sua vez, gera uma ou mais “threads”. Uma Thread é um conjunto de dados / instruções autossuficientes aguardando a atenção da CPU para execução (autossuficiente, pois contêm todos os dados e informações de estado necessários para sua execução). Uma Thread é, portanto, a menor sequência de instruções que pode ser planejada para execução por um agendador.


Uma abordagem simples para utilizar mais núcleos é fazer com que sejam executados vários Threads independentes em paralelo. Essa abordagem é usada por CPU's e é chamada de Thread Level Parallelism (TLP).

O paralelismo de nível de instrução (ILP) é uma abordagem alternativa do processamento paralelo. Com o ILP, uma Thread é a junção de vários “pedaços de código”, nos dando o que é chamado de Very Long Instruction Word (VLIW). Este thread VLIW é então enviado para o processador, onde é desmembrado no tempo de execução e os “pedaços” resultantes são executados pelos núcleos de processamento disponíveis.


No entanto, as abordagens ILP e TLP compartilham um requisito crítico comum: as operações em execução em paralelo devem ser independentes umas das outras, sejam Threads diferentes ou os "pedaços de código" dentro de uma Thread VLIW. Isso faz sentido, pois se uma operação depende da saída de outra, ela simplesmente terá que aguardar esses resultados antes de poder ser executada.

Considere um exemplo muito simples abaixo:


A + B = C


X + Y = Z


C * Z = R


Enquanto as duas primeiras são totalmente independentes uma da outra, a terceira depende das duas anteriores e, portanto, terá que aguardar sua execução.

Isso pode parecer uma coisa boba, mas levanta uma questão muito importante: de quem é a tarefa de identificar esses dados independentes para execução paralela?

Com o TLP, essa carga é compartilhada pelo programador do aplicativo e pelo hardware. Enquanto o programador é responsável por escrever código para tirar proveito de vários núcleos de processamento, o próprio processador em última análise agenda Threads para execução paralela, maximizando a utilização. O TLP, portanto, segue uma abordagem dinâmica para o agendamento, em que o próprio processador atua como o agendador.

Com uma abordagem ILP, as coisas não são tão simples: o próprio compilador deve identificar “pedaços” do processo independentes a serem empacotados em uma única thread. Isso deixa todo o fardo do agendamento no software.


CURIOSIDADE: Em linguagem de software, um compilador é um programa especial que converte o código escrito em uma linguagem de alto nível (Java ou C / C ++, por exemplo) em código de máquina de baixo nível com base no ISA do processador, agindo assim como um tradutor intermediário.


Enquanto o compilador obtém a vantagem de uma visão completa do programa e, portanto, pode-se esperar que agende de forma inteligente, existem condições para as quais o compilador permanece cego, pois alguns resultados permanecem desconhecidos até o tempo de execução real. O que exacerba esse problema é o fato de que a programação definida pelo compilador não pode ser alterada no momento da execução pelo processador.

Portanto, o ILP é uma abordagem de escalonamento estático que complica o design do compilador e deixa os recursos de computação inevitavelmente ociosos às vezes. Por que usá-lo então? Porque os gráficos são altamente paralelizáveis podem aproveitar muito bem uma abordagem ILP.

As três gerações da TeraScale conseguem trabalhar tanto com o paralelismo em nível TLP quanto em nível ILP. É o que você verá na sequência.


Um Núcleo SIMD


Agora que já temos uma noção de paralelismo, vamos ao funcionamento da TeraScale.

Uma GPU busca vários pontos de dados ou pixels de uma vez em um agrupamento chamado “vetor” junto com a instrução correspondente de acordo com sua natureza SIMD. Esse “vetor” eu chamo de “pedaço de código”. A AMD gosta de se referir a esses vetores como WaveFronts ("frentes de onda").

Na arquitetura TeraScale, 64 pixels / pontos de dados são agrupados em uma frente de onda e despachados para um núcleo SIMD (Unidade Computacional) para processamento.

Com 16 SPU's por núcleo SIMD (isso vale pras 3 gerações da TeraScale), toda a frente de onda com 64 encadeamentos é executada em quatro ciclos de clock.

Com cada SPU processando um encadeamento, vemos o paralelismo de nível TLP em ação quando 16 encadeamentos são processados num mesmo ciclo.

O paralelismo de nível de instrução (ILP) vem em seguida conforme cada encadeamento é dissecado pelos 5 processadores de fluxo dentro do SPU.


Temos abaixo o diagrama de um SPU composto por 5 SP's (daí o nome VLIW5) e um pequeno bloco "Branch":

Diagrama 3 - O que há dentro de um SPU


Como podemos ver, são quatro SP's com a função de Unidade Lógica Aritmética (ALU), uma unidade ALU que também suporta instruções transcendentais (a SFU dos diagramas da nVidia) e a unidade Branch, que apenas está ali pra controle / realimentação (veja os diagramas de núcleo Pixel / Vertex Shader da nVidia no Capítulo 4).


RECAPTULANDO: São estas cinco SP's que formam uma SPU (esta SPU opera com um conjunto de instruções VLIW 5) e 16 SPU's formam um CU. O CU também pode ser chamado de "Matriz SIMD", pois cada Unidade Computacional pode utilizar uma instrução para executar os 64 encadeamentos de uma WaveFront. Lembre-se que SIMD significa "Single Istruction, Multiple Data".


Com isso, podemos notar que os Stream Processors da nVidia (chamados de CUDA Cores) são muito mais complexos que os SP's da ATi / AMD. Veja abaixo, o diagrama de uma Unidade Computacional da TeraScale 1 e 2:

Diagrama 4 - Unidade Computacional da TeraScale com 16 SPU's e 80 SP's


Para completar o raciocínio, esses 5 SP's executam 5 unidades matemáticas fundamentais.


A utilização continua sendo uma grande preocupação para os SPU's e os SP's dentro deles. Não apenas o compilador deve fazer o melhor para identificar 5 dados independentes para cada encadeamento, mas também 64 encadeamentos independentes devem compor cada frente de onda.


Imagine um cenário em que um encadeamento é executado com uma instrução totalmente diferente de outras 63. Isso abre espaço pra ciclos de clock adicionais e perda de desempenho, portanto, o compilador deve fazer o melhor para organizar todos estes encadeamentos, bem como agendar as WaveFronts.


Deforma semelhante aos chip's nVidia, onde há um gerenciamento de Threads, na TeraScale há um gerenciamento de WaveFronts, até permitindo que elas possam 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 Data Request Bus há uma ligação ao bloco Global Data Share, Cache L1 e L2.

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 um processo) em todos os Shaders Unificados. Esta memória permite compartilhamento de dados entre vários grupos de trabalho (CU's). O GDS está configurado para fornecer acesso total a qualquer local para uso por qualquer WaveFront. Os dados podem ser pré-carregados na memória antes do lançamento do kernel e escritos na memória após a conclusão do kernel. 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 sua Local Data Share, isto é, dados utilizados pelo grupo de trabalho local, mas que estão ligados ao Global Data Share.


CURIOSIDADE: Os circuitos das GPGPU's da AMD/ATi são projetados para se destacarem na execução de muitas operações de uma mesma Thread em paralelo, Threads estas que são dividas em 'pedaços de código' menores chamados de "frentes de onda".

Com 5 SP's em cada SPU, para atingir 100% de utilização, são necessários 5 dados em cada um dos 64 encadeamentos, já mencionados anteriormente. Esse é o melhor caso. No pior caso, um encadeamento inteiro é composto de apenas 1 único dado, resultando em uma utilização abismal de 20%, já que 4 SP's simplesmente ficam ociosos.

A AMD observou uma utilização média de 68%, o que dá 3,4 SP's por ciclo de clock. Um diagrama do artigo da AnandTech descrevendo este cenário é mostrado abaixo:

Diagrama 5 - O fluxo de instruções em um SPU AMD/ATi com VLIW5


Mais a frente você vai ver que foi este um dos motivos da AMD/ATi passar a utilizar o VLIW4: ascensão da computação paralela e com isso mais instruções dependentes.


Anteriormente havia falado do gerenciamento de WaveFronts, feito pelo bloco Ultra Threaded Processor, pois bem, há um nível de gestão de eficiência mais baixo, onde cada Unidade Computacional tem seu próprio sequenciador e árbitro. O árbitro decide qual frente de onda processar em seguida, enquanto o sequenciador tenta reordenar os encadeamentos para o melhor desempenho possível do núcleo SIMD.

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.


O Cache L2, que também possui ligação com os controladores de memória VRAM, possui comunicação bilateral com o bloco Crossbar, que por sua vez se comunica de forma unilateral com o cache L1 / Cache de Textura de cada CU e com o Vertex Cache. A função do bloco Crossbar, de forma genérica, é um management de informações entre os diferentes caches de memória.


Saída de Rasterização


Veja abaixo, todo o conjunto de hardware que compõem a saída de rasterização:

Diagrama 6 - Saída de rasterização: Z-Stencil e ROP


Quanto à saída de rasterização:


-> São 4 blocos de hardware, sendo que cada um deles tem 4 unidades ROP e 16 Unidades Z-Stencil. O cache Z-Stencil está ligado ao bloco Setup Engine, estudado anteriormente neste artigo;

-> Para cada 4 unidades ROP há um RGB-Buffer (ou Color Cache);

-> São 4 blocos de Cache L2, sendo que cada um deles possui 32 kB de memória e estão ligados ao Data Request Bus;

-> Cada bloco de hardware possui uma Memória Color Cache (com compressor e descompressor, assim como ocorre com o Cache Z-Stêncil).


Os controladores de memória RAM possuem contato com o Hub (barramento principal) e o Color Cache, que alimenta as Unidades ROP. O Shader Export também possui comunicação unilateral com os controladores.


Informações complementares


CURIOSIDADE: Essa arquitetura ainda possui ponto semelhantes as arquiteturas da época dos Shaders separados. Uma das coisas feitas pela AMD/ATi foi manter o conjunto de instruções VLIW 5 e consequentemente o hardware da SPU igual aos núcleos Vertex Shader das seguintes arquiteturas:

-> Rage 8 (2002 ~ 2007);

-> Rage 9 (2002 ~ 2008);

-> R400 (2004 ~ 2008);

-> R500 (2005 ~ 2007).


A AMD usou um design VLIW nos Sombreadores de Vértices porque lhes permitia processar um produto escalar de 4 componentes (por exemplo, w, x, y, z) e um componente escalar (por exemplo, iluminação) ao mesmo tempo, que era de longe a operação gráfica mais comum. E isso perdurou até a unificação dos Shaders, que ocorreu com a chegada do Tera Scale.


Para finalizar este tópico, a Radeon HD 2900 XT serviu como carro-chefe de estreia da TeraScale. Fabricada pela TSMC com o processo de 80 nm ela possuía apenas 4 núcleos SIMD, colocando em perspectiva o quão longe essa tecnologia chegou.

A série HD3000 seguiu com especificações semelhantes, embora no mais recente processo de 55 nm da TSMC e como seu predecessor, provou ser nada assombroso contra as ofertas da Nvidia na época.

As coisas realmente mudaram a favor da AMD com a série HD4000, já que o carro-chefe HD 4870 aumentou drasticamente a contagem de núcleos SIMD, além de adotar a VRAM GDDR5 mais recente, com ganhos de 1,5x na largura de banda da memória.


CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO


Para codificação de vídeo não há nenhum sistema dedicado, apenas alguns modelos que podem utilizar tecnologias para captura de sinal e codificação com um ASIC suplementar, mas nada relacionado ao nível atual de codificação para captura e streaming multimídia.


Já para decodificação e transcodificação a TeraScale 1, ainda nas placas da série HD2000, utilizou o Avivo+ em alguns modelos. O Avivo+ (ou Avivo HD) é uma melhoria da tecnologia Avivo utilizada na arquitetura R500.

O Avivo+ consiste em todo o pacote Avivo original e a adição de um bloco controlador de áudio HDMI 5.1 surround integrado, chave de criptografia HDCP dupla integrada para cada porta DVI (para reduzir custos de licença), um atualizado chip Theater para recursos de captura de vídeo analógico e o chip de TV Xilleon para correção de overscan e underscan.

A série Radeon HD 2900 ainda recebeu o rótulo ATI Avivo HD, porém em outros modelos já sé inclui o UVD (Unified Video Decoder).


-> UVD1 na Série HD2000: Ao contrário dos blocos de aceleração de vídeo Avivo nas GPU's da geração anterior, que exigiam um envolvimento considerável da CPU, o UVD trabalha com todo o processo de decodificação de vídeo para VC-1 e H.264, lida com VLC / CAVLC / CABAC, transformação de frequência, predição de pixel e desbloqueio inloop, só não trabalha o pós-processamento de vídeo e a decodificação MPEG-2, que são transferidos para os Shaders Unificados (exceto a decodificação de bitstream / entropia do MPEG-2 que não é executada no hardware). O pós-processamento inclui denoising, desentrelaçamento e dimensionamento / redimensionamento.

O decodificador atende aos requisitos de desempenho e perfil de Blu-ray e HD-DVD, decodificando fluxos de bits H.264 até uma taxa de 40 Mbit/s. Também possui suporte para codificação aritmética binária adaptável ao contexto (CABAC) para H.264 / AVC.


CURIOSIDADE: A AMD também declarou que o bloco de hardware UVD que está sendo incorporado ao núcleo da GPU ocupa apenas 4,7 mm² de área em um processo de fabricação de 65 nm.


-> UVD+ na Série HD3000: Uma variação do UVD, chamada UVD+ foi introduzida com a série Radeon HD 3000. O UVD+ suporta HDCP para fluxos de vídeo de alta resolução. O UVD+ também estava sendo comercializado simplesmente como UVD.


-> UVD 2 na Série HD4000: Apresenta decodificação bitstream completa de H.264 / MPEG-4 AVC, VC-1, bem como aceleração de nível de iDCT (Transformada Discreta inversa de Cosseno) de fluxos de vídeo MPEG2. As melhorias de desempenho permitem a decodificação de fluxo de vídeo duplo e modo Picture-in-Picture. Isso torna o UVD2 totalmente compatível com o BD-Live.

Em termos de SP's, a TeraScale 2 (2009 ~ 2015) trouxe o dobro, isto é, 1600 Shaders Unificados no chip topo de linha. O SP se manteve igual, com o conjunto de instruções VLIW 5 e também ficou igual a quantidade de SPU's por CU.

O chip mais poderoso da TeraScale 2 foi a Cypress, com litografia de 40 nm, sendo lançado em 14 de Janeiro de 2013. Este chip, além de ter o dobro de Shaders unificados em relação ao anterior, também tem 80 TMU's, 32 ROP's, Shader Model 5.0, suporte à memória GDDR5, DirectX 11.2 (11_0), OpenGL 4.4 e OpenCL 1.2.


CURIOSIDADE: A TeraScale 2 já suporta de forma nativa o Tesselator, especificado pelo DirectX 11 e OpenGL 4.0.


Veja abaixo a imagem da AMD Radeon 6870 1600SP Edition:

Imagem 1 - Placa de vídeo com o chip Cypress


Veja o diagrama do chip Cypress abaixo:

Diagrama 7


A explicação aqui será mais sucinta pois a ideia é a mesma da TeraScale 1. Vou dar mais espaço para o teraScale 3, pois esta sim há mudanças grandes na estrutura. A arquitetura do TeraScale 2 permanece muito semelhante com a TeraScale 1: Acompanhe os próximos parágrafos.

São 1600 SP's agrupados em 320 SPU's. Esses 320 SPU's são agrupados em 20 CU's (Núcleos SIMD). Há apenas um bloco de hardware "Graphics Engine" (que equivale ao bloco Setup Engine) e um bloco "Ultra-Threaded Dispatch processor" para os dois blocos de núcleos SIMD.

Cada CU possui 8 kB de Cache L1 (Texture Cache) e um GDS (Global Data Share) de 64 kB. Perceba que o Cache L1 e o Texture Cache das TeraScale 1, 2 e também da 3 são o mesmo bloco de hardware. Não ocorrem problemas de falta de espaço pois os textels são muito bem compactados.


Saída de Rasterização


A saída de rasterização (ROP) possui:


-> São 8 blocos de hardware, sendo que cada um possui 4 unidades ROP e 5 unidades Z-Stencil. O cache Z-Stencil está ligado ao bloco Graphics Engine;

-> Para cada 4 unidades ROP há um RGB-Buffer (ou Color Cache);

-> São 4 blocos de Cache L2, sendo cada um com 128 kB e todos ligados ao Data Request Bus, barramento de pedido de dados onde também está ligado o Cache L1 e o GDS.

-> Assim como na TeraScale 1 e 3, cada um dos blocos de hardware da saída de rasterização possui uma memória Color Cache (com compressor e descompressor) e uma Z-Stencil Cache (também com seu compressor e descompressor).


Informações complementares


Como já foi mencionado anteriormente, na TeraScale 1 e 2, o conjunto de instruções VLIW 5 e o hardware das SPU's são iguais ao Vertex Shader das arquiteturas ATi / AMD anteriores. Isso ocorre pois, na época em que a nVidia estava começando com computação paralela nas GPU's, ainda eram poucas as aplicações desta tecnologia, então foi resolvido criar um design suportando o DirectX 10.0 e Shader Unificado, porém mantendo o VLIW 5 visando o mercado de jogos (que ainda era DirectX 9.0) e ignorando a Computação Paralela, apesar dela já estar tomando força na época.

Conforme os anos foram se passando, os jogos foram evoluído e abandonando o DirectX 9.0, os softwares utilizando computação paralela foram sendo lançados e o mercado mudou. Nisso a TeraScale 2 foi lançada ainda com VLIW5 e se viu uma gradativa perda de eficiência nos Shaders Unificados da AMD / ATi. A própria AMD, ao fazer uma pesquisa interna viu que o uso era de 68% em cada SPU, não sendo mais necessário manter o VLIW5. Essa ociosidade também se deve ao que já foi mencionado anteriormente, o compilador sofre com a organização e agendamento de encadeamentos e WaveFronts conforme as aplicações para as GPU's iam ficando mais complexas, nisso as SPU's não foram mais sendo utilizadas da melhor forma.

RESUMO: Isso significa que os dados e instruções pertencentes a uma das Wavefronts podem ser interdependentes ou depender de dados e instruções de outra ou de várias outras Wavefronts que compõem uma tarefa.

Característica da própria natureza do VLIW, o compilador cria uma ordem de execução dessas Wavefronts com base no próprio software, e não garante a independência total entre estes 'pedaços' de threads durante o efetivo processamento feito pelo hardware.


Apesar da eficiência visivelmente ruim, a série HD 5000 inauguraria o apogeu do TeraScale. Estreando a arquitetura TeraScale 2 em um novo processo de 40nm, a família Radeon HD 5000 de GPU's permanece indiscutivelmente a melhor da AMD até hoje e é de fato muito bem vista, tanto que as placas RX 5000 baseadas na arquitetura RDNA da AMD foram nomeadas em homenagem a esta família de GPU's. Com a HD 5870, a AMD mais uma vez dobrou o número de núcleos SIMD.


Com a visível perda de desempenho de sua arquitetura e com o avanço do mercado de jogos e computação paralela, a AMD / ATi deu sua última cartada com o VLIW: a arquitetura TeraScale 3.


CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO


Assim como na TeraScale 1, não há nenhum sistema dedicado de codificação para captura e streaming multimídia.


UVD 2.2 na Série HD5000: O UVD 2.2 é apenas o bloco de hardware UVD2 da Série HD4000 com algumas melhorias. Apresenta uma interface de memória local redesenhada e aprimora a compatibilidade com vídeos MPEG2 / H.264 / VC-1. No entanto, foi comercializado com o mesmo pseudônimo de "UVD 2 Enhanced" como o core-logic especial, disponível nas séries RV770 e RV730 de GPU's, para decodificação de vídeo MPEG2, H.264 e VC-1 com fluxo duplo de decodificação por hardware.

A AMD, na tentativa de reduzir a ociosidade de cada SPU, resolveu por utilizar o VLIW4.

O principal produto da AMD com TeraScale 3 foi o chip Cayman, lançado em 14 de Dezembro de 2010. Ele trazia 1536 Shaders unificados, isto é, 64 a menos que a TeraScale 2, porém tendo um aproveitamento melhor da GPU para aplicações atuais para a época, no entanto ainda estava longe do que devia ser realmente.

A grosso modo, o Cayman teve suas estruturas de hardware duplicadas se comparado com a geração anterior. Você pode ver isso no diagrama abaixo:

Diagrama 8 - TeraScale 3 do chip Cayman


Neste chip vemos o Command Processor com acesso aos dois blocos "Graphics Engine" e também ao bloco "Shader Export".

Os dois blocos "Graphics Engine" (equivalentes ao Setup Engine), apesar de trabalharem com vértices (etapa de Geometria), fazem apenas a montagem, o tesselation, o direcionamento dos dados referentes as coordenadas "Z" (de profundidade) para o Z-Buffer e Z-Stencil e dão início a rasterização.


OBSERVAÇÃO: A TeraScale 3, assim como a TeraScale 2 elimina o bloco interpolador.


As primitivas gráficas "brutas" (ou outro tipo de dado, afinal é uma GPGPU) já organizadas vão para o Ultra-Threaded Dispatch Processor, que possui sua memória cache de instruções e memória cache de constantes, ambas conectadas aos controladores de memória RAM. Perceba que, diferente da TeraScale 1 e 2, a TeraScale 3 possui duas unidades Ultra-Threaded Dispatch Processor, o que distribui e gerencia melhor as WaveFronts que cada SIMD Core (Unidade Computacional) vai fazer.


Assim como na TeraScale 1 e 2, há uma bloco Global Data Share (GDS) para todas as CU's dos dois "SIMD Engine" e um Local Data Share (LDS) para cada grupo de trabalho. O cache L1 / Cache de Textura é de 8 kB por CU e existem 4 unidades TMU por CU. Na TeraScale 3 o GDS possui 64 kB e cada LDS possui 32 kB.


Cada uma das duas "SIMD Engines" possui 12 Unidades Computacionais (grupos de trabalho - também chamados de núcleos SIMD). Portanto:

-> 24 Unidades Computacionais;

-> Cada CU possui 16 Stream Processor Unit's (também conhecidos na TeraScale 3 como "Radeon Cores");

-> Cada SPU possui 4 Stream Processors;

-> Ou seja, cada CU possui 64 SP's e as 24 CU's totalizam 1536 Shaders Unificados (SP's).


Agora é a arquitetura VLIW4, com uma ULA (Unidade Lógica Aritmética) e também uma SFU (para funções especiais, mas que pode operar também como se fosse três ULA's). Veja o diagrama abaixo de uma unidade SFU VLIW4 para entender:

Diagrama 9 - Unidade SPU com VLIW4


A unidade Branch desta SPU permanece igual.

Pra efeito de comparação, veja um CU da TeraScale 1 e 2 comparado com um CU da TeraScale 3:

Diagrama 10 - SPU com VLIW5 e SPU com VLIW4


O Shader Export funciona de forma equivalente ao Fragment Crossbar da nVidia Curie.


Saída de Rasterização


No que se refere ao bloco de saída de rasterização, a arquitetura também é igual em comparação com a TeraScale 1 e 2, mudando apenas a quantidade de blocos:


-> São 8 blocos de hardware, sendo que cada um possui 4 unidades ROP e 16 unidades Z-Stencil;

-> Para cada 4 unidades ROP há um RGB-Buffer (ou Color Cache);

-> São 4 blocos de Cache L2, sendo cada um com 128 kB e todos ligados ao Data Request Bus, barramento de requisição de dados onde também está ligado o Cache L1 e o GDS;

-> Assim como na TeraScale 1 e 2, cada um dos blocos de hardware da saída de rasterização possui uma memória Color Cache (com compressor e descompressor) e uma Z-Stencil Cache (também com seu compressor e descompressor).


Como ocorre com as outras arquiteturas, os controladores de memória RAM podem ser ligados a vários pontos do diagrama. Eles alimentam o Cache L2, o Color Cache, o Z-Stencil Cache, e claro, o barramento principal, onde é conectado o controlador PCI Express (interface com a placa-mãe), o decodificador de vídeo AMD UVD, a interface CrossFireX (para chip's gráficos operando em conjunto), o Command Processor e os blocos de hardware responsáveis pelas interfaces de vídeo (o Display Controller da TeraScale 1 e o EyeFinity Display Controller da TeraScale 2 e 3).


Informações complementares


O TeraScale 3 seria apresentado apenas na série Radeon HD 6900, que serviria como a última das GPU's TeraScale, mesmo com placas baseados em TeraScale continuando a ser lançados até outubro de 2013.

Conforme os aplicativos de computação começaram a ocupar o centro do palco para a aceleração da GPU, os jogos também evoluíram. A próxima geração de API's de gráficos, como DirectX 10, trouxe shaders complexos que tornaram o design centrado em VLIW do TeraScale ainda mais ineficiente e extremamente difícil de programar.

A série Radeon HD 7000 iria, consequentemente, inaugurar a arquitetura GCN, o sucessor inevitável do TeraScale que abandonaria VLIW e ILP inteiramente e, ao fazer isso, consolidaria o foco da AMD em GPGPU daqui para frente.


CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO


Assim como na TeraScale 1 e 2, não há nenhum sistema dedicado de codificação para captura e streaming multimídia.


-> UVD3 na Série HD6000: Adiciona suporte de hardware para decodificação de entropia no MPEG2, bem como suporte para DivX e Xvid via decodificação MPEG-4 Parte 2 (decodificação de entropia, transformação inversa, compensação de movimento) e Blu-ray 3D via MVC (decodificação de entropia, transformação inversa, compensação de movimento, desbloqueio em loop).

O principal problema é que VLIW é difícil de programar com antecedência e não há programação dinâmica durante a execução. O VLIW5 era bom para games, era relativamente fácil de compilar e agendar shaders de maneira eficiente nessas circunstâncias. Com a complexidade envolvendo a computação paralela, nem sempre é esse o caso, pois simplesmente existe uma gama maior de coisas acontecendo e é difícil descobrir quais dados funcionarão bem ums com as outros, afinal este sistema pode processar instruções NÃO DEPENDENTES uma da outra de forma paralela sem perder a lógica de processamento. Apenas um punhado de tarefas, como hash de força bruta, prosperam sob essa arquitetura.


Enquanto cada Warp Scheduler da nVidia consegue agendar 32 threads, um Ultra-Thread Dispatch Processor (ou Ultra-Thread Processor) da AMD TeraScale consegue agendar uma quantidade de tarefas bem menor, já que o sistema trabalha com WaveFronts. E devido a interdependência de dados e instruções cada vez maior por causa da computação de propósito geral, o VLIW foi perdendo desempenho, pois seus núcleos só operavam com o máximo de desempenho e paralelismo se não houvesse essa dependência.


Além do mais, VLIW "vive e morre" no compilador, e este é um problema quando se trata de expandir o suporte à linguagem, pois mesmo com abstração por meio de linguagens intermediárias, você ainda pode ter complicações, incluindo um compilador produzindo código que o Shader não consegue lidar bem.

Finalmente, a complexidade de um conjunto de instruções VLIW também se destaca quando se trata de otimizar e ajustar manualmente um programa. Novamente, isso normalmente não é um problema para gráficos, mas é para computação. A natureza complexa do VLIW torna mais difícil desmontar e depurar e, por sua vez, difícil prever, localizar e corrigir seções críticas de desempenho do código.

Na arquitetura GCN, a AMD abandona o VLIW para melhorar o uso da GPU em computação paralela e ficar à altura da sua concorrente nVidia, mas isso vai ser visto em outro artigo.


Gostou do artigo? Ficou com alguma dúvida? achou algum erro ou inconsistência? Entre em contato pelo e-mail hardwarecentrallr@gmail.com

FONTES e CRÉDITOS


Texto: Leonardo Ritter

Diagramas e imagens: Tech Power Up GPU-Z;

Fontes: Tech Power Up GPU-Z; AnandTech; Wikipedia (somente artigos com fontes verificadas!).

19 visualizações

© 2020 Hardware Central Tecnologia Entretenimento e Comunicação do Brasil Ltda. Todos os direitos reservados.

Wix Editor / Revisão da web page: 3.1/2020 (16/07/20)