Quando ouvimos a palavra pipeline, podemos definir como um processo sistemático, dito isso, a CPU contém diferentes núcleos capazes de executar instruções independemente, esse executar é o que atribuimos pipeline, um esquema sistemático de execução chamado CPU pipeline.
Uma unidade de processamento geralmente funciona em uma arquitetura de load/store, em resumo, ocorre a busca por instruções, decodificação, processamento e no final o writeback. Essas operações de instruções vectoriais são controlado por uma unidade de controle (CU).
Registradores são definidos pelo tamanho do barramento na CPU, por meio de registradores é possivel ter acesso a memória, durante a execução de uma instrução, infinitamente superior ao cache L1 ou RAM em termos de latência.
Mas não proporcionam de maneira direta o acesso a memória, registradores são espaços reservados para o acesso durante a execução das instruções vectoriais.
Os registradores de propósito geral, são registradores extras presentes na CPU e são utilizados para qualquer momento quando requisitados. Esses registradores podem ser usados para guardar operadores e pointeiros. Operações ariméticas de pontos flutuantes, são separados por floating point unit (FPU) que aderem normalmente ao padrão IEEE 754 (algumas reduzem parte do padrão por performance ou custo). Implementações paralelizadas de floating point units podem ocorrer mas são diferentes. Caches L1, L2, e L3 são memórias hierarquias de fácil acesso feitas para reduzir a latência em dados frequentemente usados.
A paralelização das instruções vectoriais na CPU ocorre pelo Single Instruction Multiple Data (SIMD), esse método pode poupar até pelo menos 4x do que seria nececssário em uma pipeline sequêncial, mas não necessáriamente um ciclo. Um exemplo onde a operação fosse 4 ciclos, seria apenas 1, se fosse 16, seria 4.
Conjuntos de instruções referece ao conjunto básico de comandos e instruções que um microprocessador pode entender e manipular. Diferentes CPUs do mercado, podem conter conjunto de instruções adicionais que podem aumentar a performance quando executadas em diferentes datas de objetos. Podem incluir SSE (streaming SIMD Extensions) e AVX (Advanced Vector Extensions).
Alguns exemplos: Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2.
Litografia de um processador referece a técnologoia - e um tipo - do semicondutor usado para produzir o circuito integrado, medido em nanomêtro, indicando o tamanho das features construidas no semicondutor.
Um microprocessador stream funciona de forma semelhante a um microprocessador SIMD, a construção desses processadores permitem o uso independentes (grupos) de múltiplas unidades de processamento (evidênciando a perca de memória entre as unidades), como floating point unit (FPU) das GPUs.
É importante destacar que a GPU funciona diferente, nas CPUs o uso do microprocessador envolve instruções mais complexas e que não podem ser altamente paralelizadas, como no caso de instruções envolvendo float(s), lógica e mais longas - otimizadas para instruções mais longas -. Stream processors são constrúidos de forma otimizada, mas com a quebra de flexibilidade é possivel encontrar efeitos negativos, como overflow (perca de precisão) e limites no número de instruções que podem ser executadas.
A construção da GPU é otimizada para paralelizar instruções de números (inteiros, pontos flutuantes) e que são menores e menos complexas do que uma instrução na CPU.
Saindo da construção interna de processadores, a implementação via software de uma GPU é feita pelo driver, o driver é encarregado de trabalhar com o rasterizador embutido da GPU e coordenar o funcionamento das shaders, gerenciando o graphics pipeline.
Graphics pipeline é um conceito de abstração para renderizar objetos na tela. Em termos simples, o graphics pipeline usa do processamento altamente paralelo da construção da GPU para computar com eficiência uma série de processos importantes para renderizar qualquer dado para a tela.
Esses processos são separados por estágios, e cada um desses estágios são shaders programaveis que a aplicação carrega anteriormente na GPU. É importante descrever que esse processo só pode ocorrer se anteriormente você carregou as shaders necessárias para renderizar, configurou a topologia da renderização (se é triangulo, linhas ou pontos), configurou os layouts (basicamente os dados de vértices que são guardados na GPU) para uso nas shaders e carregou as vértices para a GPU (modelo 3D por exemplo).
1- O processo de geometria: Onde é processado a geometria do objeto e preparado para o processo de rasterização, dentro desse processo, é executado inicialmente a shader chamada vertex shader, esse estágio de shader é encarregado de gerar uma transformação para o espaço normalizado - coordenadas que a API/GPU trabalha - vértice a vértice, após esse primeiro estágio, opcionalmente, podem ser feitas alguns estágios adicionais.
2- Processo de geometria adicionais: Geometry shader é uma shader encarregada de emitir novas vértices em tempo de renderização, essa shader é um estágio muito útil, como por exemplo, para renderizar rios e mares em tempo real. Outro estágio adicional - 2 na verdade - é a tesselação, tesselação é um conceito de sub-dividir vértices em mais vértices, mas para isso é preciso criar 2 estágios, tessellation control e tessellation evaluation. Inicialmente, a primeira shader a ser executada é o tessellation control, aonde é definido quantidade de tessellações que vão ocorrer e o primitivo (triangulo, quad, polignos etc) usado para ligar as vértices, enquanto tessellation evaluation é como o vertex shader, usado para transformar essas novas vértices sub-divididas em coordenadas normalizadas para a GPU.
O rasterizador tem como papel converter qualquer tipo de vértice em pixels ou quase isso, pois esses pixels não são de fato pixels ainda, eles vão passar por processos adicionais que são ativados pelo software que utiliza a GPU.
3- Processo de rasterização: Após cada vértice ser transformada no espaço normalizado, a GPU procura por faces definidas pela applicação na renderização (se estamos renderizando triangulos ou quads por exemplo), quando é encontrado a primeria face, é enviado para o rasterizador da GPU e transformado em fragmentos, esses fragmentos atencedem os pixels. Após a rasterização é executado um estágio de shader chamado fragment shader (ou pixel shader), executado pixel a pixel da região formada e visivel da face encontrada anteriormente. Esse shader é aonde podemos definir a cor, transparência, texturização e efeitos de post-processing.
4- Processo de framebuffer final: Após o fragment shader (pixel shader), vai ocorrer algumas operações definidas pela aplicação. O estado fixo blending, quando ativado, computa a transparência entre os objetos renderizados na tela, por meio de interpolações lineares de cores entre cada fragmento sobrepostos. O estado depth testing é encarregado de comparar o depth distance, para escolher quais fragmentos serão exibidos quando sobrepostos com outros (quando um modelo 3D fica a frente de outro por exemplo). O estado stencil buffer mapea uma região por meio de uma mascára e os descarta. Existem alguns outros estados, mas em suma, esses são os mais importantes.
O uso da GPU não fica restrito apenas para renderização, general purpose graphics processor unit (GPGPU) é quando um software, utiliza do poder paralelo da GPU para computar tarrefas e dados. Em sua maioria, o uso da GPU para qualquer tarrefa, pode ser um trabalho mais dificultoso pois dada a explicação acima sobre o funcionamento da GPU e CPU, sua comunicação é custosa. Infelizmente o uso da GPU como processador secundário é um assunto complexo, e não temos dados suficiêntes para construir um argumento sólido sobre os ganhos a longo prazo do uso das GPUs, isso porque, a implementação de tarrefas paralelas com a GPU requer re-aprender a programar e aproveitar o uso da GPU enviando o mais otimizado possivel.
A Nvidia tem mostrado o poder do processamento paralelo com o CUDA desde 2008, seu funcionamento interno mesmo independete do graphics pipeline pode ser implementando em um contexto de renderização. OpenCL é um alternativa que pode rodar em GPUs da AMD. Vulkan é de fato, o concorrente mais pé no chão do que CUDA.
Muitas tarrefas como simulações de física, calculos extensivos de matrizes (IA) são majotariamente implementados com uma API para GPGPU.
Nos consoles, é ligeiramente diferente, todo console contém um hardware fixo, o que permite um foco maior na otimização e visão geral sobre a limitação de features, o trabalho de otimização é mais extremo nos consoles. Voltando no tempo, o PS2 não tem uma GPU, mas microprocessadores especificos para operações vetoriais, chamados de VU, o PS2 contém 2 microprocessadores que executam microcódigos e funcionam como processos de shaders. Um dos motivos para o PS2 conseguir rodar tanta coisa bonita (e.g Peter Jackson King Kong) é por conta do acesso direto do rasterizador e seus dois microprocessadores, os programadores precisavam implementar conceitos (face culling por exemplo) que atualmente em GPUs modernas, você encontra já implementando pela própia GPU.
O papel do OpenGL e do Vulkan é renderizar, mas Vulkan não fica limitado a apenas isso.