Neste texto vamos analisar o diagrama dos chips gráficos. Vamos começar pela analise dos chips "Pré-Shaders Unificados". Não vamos focar no nVidia NV30 (arquitetura Rankine), mas abaixo vai o diagrama dele. Compare com o diagrama do chip NV40 (arquitetura Curie), que estudaremos nesse Capítulo e veja as semelhanças.
Diagrama 1 - chip NV30 (arquitetura nVidia Rankine, de 2003 até 2005)
A introdução foi dada no artigo anterior, e agora irei mostrar na prática o funcionamento de um chip gráfico utilizando alguns diagramas de blocos da nVidia e AMD.
nVidia - Arquitetura Curie
Para entendermos melhor, separei alguns diagramas de bloco de arquiteturas nVidia e ATi / AMD. Observe abaixo o diagrama do Chip NV40, lançado em primeiro de Abril de 2004, pertencente a arquitetura Curie:
Diagrama 2 - Chip NV40 por dentro
1. HOST: É de onde vem as primitivas gráficas. A conexão com a placa-mãe e a CPU é feita por um barramento PCI ou AGP (nas placas mais antigas) ou conexão ponto-a-ponto PCI Express (nas mais atuais).
Os controladores de memória, que no Diagrama 3 são os blocos chamados de "Memory Partition", estão ligados num grande barramento interno do chip. Este grande barramento é a "pista principal" que faz a comunicação entre os Vertex Shaders, os controladores de RAM, o controlador PCI, AGP ou PCI Express (que se comunica com a placa-mãe) e as interfaces de vídeo VGA (RAMDAC), HDMI ou DVI;
2. Ali estão presentes 6 blocos de hardware para o sombreamento de vértices (Vertex Shader). Veja o diagrama interno de um processador Vertex, da nVidia Curie abaixo:
Diagrama 3 - Unidade de processamento Vertex
Observe que ele é basicamente composto por uma unidade de cálculo de ponto flutuante de 32 bits para Unidades Escalares (valor numérico e unidade de medida) e outra de 32 bits para Unidades Vetoriais (valor numérico, unidade de medida, direção e sentido). Há também uma unidade de busca de textura que se comunica com a memória cache de textura, que como podemos ver no Diagrama 3, é a mesma memória cache junto dos blocos de hardware do Pixel Shader e TMUs.
A Branch Unit fornece duas opções: uma realimentação das unidades FP32 e da Vertex Texture e uma saída pros dados para a montagem da primitiva (Primitive Assembly). Depois da montagem da primitiva de imagem, ela segue pra ViewPort Processing. Como visto anteriormente, um mundo virtual é infinito, e a ViewPort (janela de visualização) é a "janela" por onde o usuário enxerga esse mundo. A ViewPort Processing é responsável por delimitar essa janela, isto é, todos os polígonos visíveis no quadro, que vai seguir pra renderização.
3. No bloco de hardware "Cull / Clip / Setup" temos a aplicação das instruções do Backface Cull e do Clipping. Para saber mais sobre estas duas tecnologias, abra o PDF abaixo:
CURIOSIDADE: O Backface Cull é um teste de visibilidade primária e o Clip é um teste de visibilidade secundária. Ambos acabam, indiretamente, aliviando um pouco do trabalho o Z-Buffer.
O "Setup", que também faz parte deste bloco de hardware neste chip da nVidia, tem a função de direcionar os dados pro bloco de hardware que dá início ao processo de rasterização, que você verá na sequência.
4. Aqui se dá o início da rasterização, isto é, a transformação da imagem vetorial em fragmentos de imagem (como foi dito anteriormente, os fragmentos são a menor parte da imagem, um "Pixel em construção").
Nesta etapa há um Interpolador (arquiteturas ATi / AMD) ou o Z-Cull (arquiteturas nVidia). Nesta etapa temos um início para o Z-Buffer, isto pois o Z-Cull, ou Interpolador, faz um "abate" de Pixels, isto é, a eliminação inicial de Pixels com base na profundidade da imagem, um método que fornece um aumento no desempenho, pois alivia um pouco do trabalho na saída de rasterização (ROP) onde fica o Z-Buffer;
5. É aqui que temos os sombreadores de Pixels (Pixel Shaders), os blocos de hardware responsáveis por processarem os fragmentos da imagem. Você encontrará diagramas onde estes blocos são chamados de "Fragment Shader", porém é a mesma coisa. Veja um núcleo Pixel Shader do chip NV40 abaixo:
Diagrama 4 - Unidade de processamento Pixel (ou Fragment Shader)
Neste bloco de hardware temos duas unidades de ponto flutuante de 32 bits, sendo a primeira unidade em comunicação com uma TMU. Esta TMU é composta por uma unidade de ponto flutuante que recebe os dados de textura da memória cache principal (que alimenta todos os Pixel Shaders) e também possui um cache de memória pra estes dados.
Na sequência, temos um Branch Processor, com uma saída pra Unidade Lógica e Aritmética (ALU) e outra saída pra realimentação da primeira unidade FP32.
CURIOSIDADE: Um ALU é responsável por operações aritméticas (adição e subtração de bits - sequências de zeros e uns). As operações de divisão podem ser feitas com repetitivas subtrações e operações de adição podem ser feitas com repetitivas adições. As operações lógicas, que executam as aritméticas, são feitas através de portas lógicas (AND, OR, NOT, XOR, NOR, NAND e XNOR). As ALUs são calculadoras fundamentais para qualquer chip, seja ele uma CPU, GPU ou um simples microcontrolador. Veja a tabela abaixo com a listagem de portas lógicas:
Tabela 1 - Portas lógicas
6. Aqui temos o bloco de saída de renderização, com todas as unidades ROP.
O "Fragment Crossbar" pega os fragmentos de imagem processados nos Pixel Shaders e TMUs e os organiza para a distribuição nas unidades ROP. Este circuito faz com que os dados gerados pelos Fragment Shader sejam enviados a qualquer um dos ROPs disponíveis. Isso faz com que as ROPs absorvam melhor a variação de uso dos sombreadores de Pixel, permitindo que o poder de processamento seja aproveitado da melhor forma.
Perceba que as unidades ROP possuem o Z-Buffer e uma conexão direta com os controladores de memória RAM.
Para concluir o raciocínio, são oito controladores de memória (no Diagrama 3, apenas 4 deles são representados), sendo que cada um possui um barramento de 32 bits com o chip de RAM (256 bits no total). Os controladores se comunicam entre si, se comunicam com as ROPs e com o cache principal (que alimenta os Pixel Shaders) e que também possui ligação com as unidades Vertex. Como foi explicado anteriormente, os controladores de RAM também tem comunicação direta com o controlador do barramento ou da conexão ponto-a-ponto responsável pela conexão com a placa-mãe.
Em resumo, o chip NV40 possui:
-> 6 unidades Vertex Shader;
-> 16 unidades Pixel Shader;
-> 16 unidades de textura (TMU);
-> 16 unidades de raster (ROP);
-> 8 controladores de RAM (256 bits no total);
-> Suporta até 512 MB de memória RAM DDR ou GDDR3.
CURIOSIDADE: A imagem renderizada é alocada no Frame Buffer, para então ser enviada ao monitor. Para saber mais alguns detalhes sobre isso e sobre profundidade de Cor, acesse o PDF abaixo:
Agora, vamos ver o diagrama do chip G70, lançado em 22 de Junho de 2005, que também pertence a arquitetura Curie.
Diagrama 5 - chip G70, uma evolução do NV40, que utiliza amesma microarquitetura Curie)
A grande diferença do G70 em relação ao NV40 é que:
→ O G70 utiliza a conexão ponto-a-ponto PCI Express pra se comunicar com a placa-mãe. O NV40 ainda tinha um bloco de hardware para o controlador AGP, necessitando de um Bridge HSI (sigla para "High Speed Interconnect", um circuito SerDes - Serializador-Desserializador) para implementar uma interface PCI Express. Há placas da Serie 7 (chip G70 e versões superiores) em que ainda foi implementado o barramento AGP, porém utilizam um Bridge HSI PCie>AGP para comunicação, reduzindo significativamente o desempenho da GPU.
→ A litografia caiu para 0,11 mícron (110 nanômetros) no G70, diminuindo o consumo de energia e gerando a possibilidade de frequências maiores. O NV40 ainda era fabricado em litografia de 130 nm.
→ O número de unidades Vertex Shader subiu para 8, mas mantendo o circuito interno do bloco igual ao NV40. O mesmo aconteceu com as Pixel Shaders e TMUs, que foram de 16 unidades (NV40) para 24 unidades no G70. A quantidade de ROPs se manteve a mesma.
→ Como você pode notar, o G70 tem menos unidades ROP do que Pixel Shaders e TMUs. Mas isso não limita o desempenho, pois nem todos os sombreadores de Pixel ficam com 100% de uso simultaneamente (pois cada um processa uma parte da imagem), e por haver um Fragment Crossbar, os ROPs são melhor aproveitados. Esta flexibilidade de arquitetura, onde o número de ROPs e Shaders são diferentes, foi cada vez mais utilizada pela indústria, a fim de reduzir custos de produção com adição de mais transistores e ganhar em cima de otimizações do hardware.
No mais, por redução de custos, o barramento de 256 bits se manteve igual, apenas foi aumentado a frequência dos controladores de RAM para operarem com chips de maior taxa de transferência, o que também acabou limitando um pouco do desempenho da placa.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
Esta arquitetura ainda não possui nenhum bloco de hardware dedicado para codificação de vídeo, sendo necessário a utilização da CPU para tal fim.
Quanto a decodificação de vídeo, os chip's NV30 trouxeram consigo o bloco de hardware VPE (Vídeo Processing Engine) responsável por fazer as operações necessárias para exibição de Vídeo sem sobrecarregar tanto a CPU. A Arquitetura Curie, com a série de chip's NV40, trouxe o VPE 2.0, e os chip's Curie da série G70 trouxeram o VPE 3.0.
A primeira geração de PureVideo HD se deu com o VPE. O PureVideo HD reutilizou o pipeline de decodificação MPEG-1 / MPEG-2 e melhorou a qualidade do desentrelaçamento (desfazer o entrelaçamento, o "Interlaced Scan" dos monitores de vídeo) e redimensionamento de imagem. A compatibilidade com o renderizador VMR9 do DirectX 9 também foi aprimorada. Outros recursos do VPE, como o pipeline de decodificação MPEG-1 / MPEG-2 não foram alterados.
O material de imprensa da Nvidia citou a aceleração de hardware para vídeo VC-1 e H.264, mas esses recursos não estavam presentes no lançamento.
Começando com o lançamento do GeForce 6600, a PureVideo adicionou aceleração de hardware para os formatos de vídeo VC-1 e H.264, embora o nível de aceleração seja limitado quando comparados lado a lado com o formato MPEG-2.
O VPE decodifica o pipeline MPEG-2 a partir da transformada discreta inversa de cosseno (iDCT), deixando a CPU para realizar a decodificação de comprimento de execução inicial, decodificação de comprimento variável e quantização inversa, enquanto o PureVideo de primeira geração oferecia assistência VC-1 limitada (apenas compensação de movimento e pós-processamento).
ATi - Arquitetura R500
Veja abaixo, o diagrama do concorrente do G70, o chip ATi R520, lançado em primeiro de Outubro de 2005, pertencente a arquitetura R500.
Diagrama 6 - Diagrama interno do ATi R520
Vamos entende-lo melhor:
1. Antes do "Vertex Shader Engine", temos o controlador PCI Express, que faz a interface com a placa-mãe. Este controlador está ligado num barramento interno do chip, que também dá acesso aos controladores de memória e ao "Vertex Shader Engine". Esse barramento interno também dá acesso ao bloco de hardware com os controladores VGA (RAMDAC), DVI e HDMI.
2. Vertex Shader Engine: Neste caso, temos 8 unidades de processamento Vertex Shader, onde sua saída está ligada num bloco de hardware com várias funções, sendo elas:
-> Backface Cull / Clip: Tem a mesma utilidade do bloco de hardware da nVidia NV40 e G70, Abra o PDF abaixo com as explicações sobre os dois termos:
-> Perspective Divide / ViewPort Transformation: A “Divisão de Perspectiva” é utilizada para converter o SRU em SRN (Sistema de Referência Normatizada) que antecede a conversão para o SRD (Sistema de Referência do Dispositivo) e também utilizada para calcular os objetos mais próximos e os mais distantes dentro do volume de visualização e assim criar os valores de “Z”, que vão preencher o Z-Buffer.
Para se situar melhor nestes sistemas de coordenadas e o ViewPort, retorne ao Capítulo 3 e veja o PDFs anexados ao tópico "Pipeline de Gráficos", pois todas as informações necessárias para entender este bloco de hardware estão lá.
3. Setup Engine (Motor de Configuração): Fica responsável por dar início a fragmentação do quadro para sua rasterização e criar as coordenadas "Z". Da mesma forma que ocorre nos chips nVidia, há um Z-Cull (na AMD é chamado de Interpolador) responsável por fazer a primeira eliminação de Pixels antes do Z-Buffer (que armazena as coordenadas "Z") e as unidades ROP aplicarem profundidade na imagem.
Ainda na Setup Engine, temos o "Geometry Assembly" (Montagem de Geometria), que está conectado por uma conexão bidirecional num bloco de hardware com o Z-Test e o Buffer Z-Stencil.
4. A função do Buffer Z-Stencil é mascarar pixels em uma imagem, para gerar efeitos especiais. A máscara controla se o Pixel é desenhado ou não. Esses efeitos especiais incluem composição, decalque, desintegração, esmaecimento, deslizar o dedo, contornos, silhuetas, e estêncil de dois lados (sombras em objetos do cenário). Alguns dos efeitos mais comuns são explicados no PDF anexado abaixo:
Já o Z-Test tem a função de impedir que Pixels indesejados cheguem ao Z-Stencil. Esses Pixels indesejados podem atrasar o processamento. Vou dar um exemplo:
Em uma desintegração, uma imagem é gradualmente substituída por outra em uma sequência de quadros suavizada. Observe a imagem abaixo:
Imagem 1 - Desintegração
Quando o software executa uma desintegração, ele deve renderizar duas imagens diferentes. Ele usa o Z-Stencil para controlar quais pixels de cada imagem são desenhadas na superfície de renderização. Você pode definir uma série de máscaras de estêncil e copiá-las para o Z-Stencil em quadros sucessivos. Como alternativa, você pode definir uma máscara de estêncil de base para o primeiro quadro e alterá-la de forma incremental.
No início da desintegração, o software define a função e máscara de estêncil para que a maioria dos Pixels da imagem inicial passem no Z-Test (teste de Stencil). A maioria dos Pixels da imagem final deve falhar no Z-Test. Em quadros sucessivos, a máscara é atualizada para que cada vez menos Pixels da imagem inicial passem no Z-Test. À medida que os quadros progridem, cada vez menos Pixels da imagem final falham no teste. Dessa forma, o software pode executar isso usando qualquer padrão arbitrário de desintegração.
O Z-Stencil está acoplado nas unidades ROP, que possuem o Z-Buffer e o RGB Buffer.
O Z-Stencil não é uma exclusividade da ATi / AMD. Ele é amplamente utilizado em todas as plataformas de software, porém apenas a ATi / AMD utiliza blocos de hardware específicos pra Z-Stencil.
CURIOSIDADE: Agora que chegamos nesse patamar, é necessário dizer que o Z-Buffer possui suas falhas, sendo o Z-Stencil fundamental pra corrigir isso.
Clique no PDF abaixo e veja mais informações sobre o Z-Fighting:
5. Pixel Shader Engine: As unidades de Pixel Shader e de processamento de texturas (TMU) são independentes, controladas pelo "Ultra-Threading Dispatch Processor", responsável por pegar os fragmentos criados no bloco anterior, o "Setup Engine", e dividir os trabalhos a serem processados, tentando aproveitar o processamento das unidades de sombreamento de fragmentos e de aplicação de texturas da forma mais eficiente possível. Isso melhorou um pouco a eficiência do chip em relação aos projetos antigos.
As unidades de textura possuem uma memória cache para guardar os valores mais utilizados no momento.
6. General Purpose Register Arrays: São as Matrizes de Registro de Uso Geral, um bloco de 16 circuitos, também conhecidos como ROPs. A ATi / AMD dava este nome para as unidades ROP na arquitetura R500 pois ela já conseguia trabalhar com computação paralela, de uma forma muito primitiva, mas conseguia. O chip R520 foi o primeiro a implementar computação paralela através do Brook+, API detalhada no capítulo 2 desta série.
Perceba que cada ROP do R520 possui ligação com uma unidade Pixel Shader. Diferente da nVidia, que na arquitetura Curie implementou um Fragment Crossbar, circuito que equilibra melhor o aproveitamento das ROPs em relação aos Fragment Shaders, pois nem todos os sombreadores de Pixel ficam em 100% de uso o tempo todo.
O bloco de unidades de textura (TMU) também possui uma comunicação com as ROPs.
A imagem pronta vai para o Frame Buffer, para ser então enviada ao display.
Em resumo, o R520 possui:
-> 8 Vertex Shaders;
-> 16 Pixel Shaders;
-> 16 TMUs;
-> 16 ROPs (Matrizes de Registro de Uso Geral);
-> 256 bits de comunicação com a memória RAM (dividido em 8 controladores de 32 bits cada);
-> Suporta até 512 MB de memória RAM GDDR3.
Uma versão estendida do R520 foi lançada em 2006: a R580. Utiliza a mesma arquitetura R500, porém possui mais unidades Pixel Shader e ROP's. Veja o diagrama deste chip abaixo e compare com o R520:
Diagrama 7 - Chip R580
O R580 possui:
-> 8 Vertex Shaders;
-> 48 Pixel Shaders;
-> 16 TMUs;
-> 48 ROPs (Matrizes de Registro de Uso Geral);
-> 256 bits de comunicação com a memória RAM (dividido em 8 controladores de 32 bits cada);
-> Suporta até 512 MB de memória RAM GDDR3.
Este chip podia gerar limitações jogos mais antigos por possuir menos unidades TMU do que Fragment Shaders.
O R520, R580 e R580+ suportam a API Brook+, porém dentro da arquitetura R500 surgiram vários chips, sendo que muitos deles (chips M52 até o M71 e RV505 até o RV570), apesar de terem as unidades ROP projetadas para uso geral, não suportam a API Brook+, pois são produtos de entrada, de baixo desempenho. Isso também ocorreu com a nVidia, que deixou os chips gráficos onboard com arquitetura Tesla sem suporte a tecnologia CUDA, mesmo eles tendo Shaders Unificados. E a resposta mais simples pra isso é: não adianta incluir o suporte a uma API de computação paralela pra um chip que possui 'meia dúzia' de núcleos aptos para este tipo de trabalho, pois é muito pouco.
CODIFICAÇÃO e DECODIFICAÇÃO de VÍDEO
Esta arquitetura ainda não possui nenhum bloco de hardware dedicado para codificação de vídeo, sendo necessário a utilização da CPU para tal fim, porém alguns modelos mais avançados incluem um pacote de software e hardware necessário para captura de vídeo, como você verá mais abaixo.
Para a decodificação de vídeo, a ATi trouxe para os chip's R100 (arquitetura Rage 6) e para o R200 (arquitetura Rage 7) o o bloco de hardware chamado Video Immersion e Video Immersion 2, respectivamente.
A R300 (arquitetura Rage 8) e a arquitetura R400 trouxeram o chamado Video Shader, bem como o bloco de hardware VPE (Video Processing Engine) em substituição ao Video Immersion.
O Video Shader é um recurso que descreve o processo da ATI de usar Pixel Shaders para melhorar a qualidade da reprodução de vídeo. Também pode ser usado para executar o pós-processamento, como adicionar um Grain Film ou adicionar outros efeitos especiais.
A arquitetura R500 (analisada neste artigo) utiliza a tecnologia ATi Avivo.
Imagem 2 - Logomarca da tecnologia Avivo
ATI Avivo é um conjunto de recursos de hardware e software de baixo nível introduzida em produtos da arquitetura R500 e em todos os produtos ATI Radeon posteriores (até a migração para o UVD e VCE). O ATI Avivo foi projetado para transferir a decodificação, codificação e pós-processamento de vídeo da CPU para uma GPU compatível.
Na decodificação e reprodução de vídeo, a GPU oferece suporte à decodificação de hardware de vídeos H.264, VC-1, WMV9 e MPEG-2 através do Vídeo Shader HD (uma evolução do Video Shader da R300 e R400) para reduzir a utilização da CPU (o processamento de fluxo de bits e a decodificação de entropia ainda requer processamento de CPU). O ATI Avivo oferece suporte a desentrelaçamento adaptável de vetor e escalonamento de vídeo para reduzir jaggies e pontilhamento espacial / temporal, que tenta simular a qualidade de cor de 10 bits em monitores de 8 e 6 bits durante o estágio de processamento.
A tecnologia Avivo também implementa de forma primitiva um codificador de vídeo utilizando um ASIC suplementar chamado de Theater 200 (ou Theater 550, em alguns produtos), capaz de receber sinal de vídeo analógico para conversão. Durante a captura de vídeo, o ATI Avivo amplifica a fonte, ajusta automaticamente seu brilho e contraste. O ATI Avivo implementa transformação de 12 bits para reduzir a perda de dados durante a conversão. Ele também utiliza filtro combinado 3D adaptável ao movimento, controle automático de cor, controle automático de ganho, redução de ruído de hardware e tecnologias de aprimoramento de borda para melhor qualidade de reprodução de vídeo.
Como foi dito, arquitetura R500 (analisada neste artigo) utiliza o Video Shader HD, nada mais que um aprimoramento da versão anterior utilizada na arquitetura R300 e R400. Um dos recursos do Video Shader é o ATI Full Stream. Full Stream detecta as bordas dos frames de vídeo e usa um filtro baseado em Pixel Shader para suavizar a imagem. Outro recurso é o Video Soap, que reduz o ruído do vídeo.
Outros recursos são suporte DXVA (DirectX Video Acceleration) para compensação de movimento via hardware, iDCT (Transformada Discreta Inversa de Cosseno), DCT (Transformada Discreta de Cosseno) e conversão de espaço de cores.
O ATi Avivo recebeu uma nova versão chamada ATi Avivo+ para as TeraScale, porém já estava em processo de substituição pelo Unified Video Decoder (UVD) e Video Coding Engine (VCE).
CURIOSIDADE: A ATI também lançou um software transcodificador denominado "ATI Avivo Video Converter", que oferece suporte à conversão entre H.264, VC-1, WMV 9, WMV9 PMC, MPEG-2, MPEG-4, formatos de vídeo DivX, bem como formatos usados no iPod e PSP. As versões anteriores deste software usam apenas a CPU para transcodificação, mas foram bloqueadas para uso exclusivo com a série ATI X1000 placas gráficas (arquitetura R500). As modificações de software tornaram possível usar a versão 1.12 do conversor em uma ampla gama de adaptadores gráficos. O conversor de vídeo ATI Avivo para Windows Vista estava disponível com o lançamento do AMD Catalyst 7.9 (lançamento de setembro de 2007, versão 8.411).
Em 2011, o Avivo foi renomeado para AMD Media Codec Package, um componente opcional do software AMD Catalyst. A última versão foi lançada em agosto de 2012. A partir de 2013, o pacote não é mais oferecido pela AMD.
Depois de estudar chips gráficos que utilizavam Shaders separados, se pode concluir que, a Pipeline de Gráficos, com os três estágios (Aplicação, Geometria e Rasterização), era levada ao pé da letra na área do hardware, com circuitos projetados pra cada estágio.
No Capítulo 2 sobre as arquiteturas, veremos que tudo isso foi abandonado para dar origem aos Shaders Unificados.
Se encontrou alguma inconsistência, quer mandar alguma sugestão, elogio ou algum complemento a este texto, não deixe de entrar em contato conosco pelo e-mail hardwarecentrallr@gmail.com.
Texto: Leonardo Ritter.
Imagens e diagramas: TechPower Up; Leonardo Ritter.
Fontes: TechPower Up, Wikipedia (somente artigos com fontes verificadas!).
Última atualização: 12 de Outubro de 2022.