Uma Arquitetura de Suporte a Interações 3D ... - DCA - Unicamp
Uma Arquitetura de Suporte a Interações 3D ... - DCA - Unicamp
Uma Arquitetura de Suporte a Interações 3D ... - DCA - Unicamp
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
2.4 <strong>Arquitetura</strong> das GPUs programáveis 33<br />
execução para a GPU através do driver <strong>de</strong> ví<strong>de</strong>o. Este é um processo semelhante ao que ocorre<br />
no mo<strong>de</strong>lo <strong>de</strong> compilação Just-In-Time utilizado em linguagens intermediárias <strong>de</strong> máquinas virtuais.<br />
Mas, contrastando ainda mais com programas tradicionais da CPU, sha<strong>de</strong>rs não são aplicações por<br />
si só, e sempre <strong>de</strong>pen<strong>de</strong>m <strong>de</strong> uma aplicação na CPU que utilize a API gráfica. Essa aplicação é<br />
responsável por configurar as funcionalida<strong>de</strong>s não programáveis das GPUs, alimentar o fluxo <strong>de</strong> ren-<br />
<strong>de</strong>rização com dados <strong>de</strong> primitivas, texturas e valores constantes, e <strong>de</strong>finir os alvos <strong>de</strong> ren<strong>de</strong>rização.<br />
Em nossa proposta <strong>de</strong> uma arquitetura <strong>de</strong> suporte a tarefas <strong>de</strong> manipulação direta <strong>3D</strong> usando a GPU,<br />
essa <strong>de</strong>pendência exige que parte do processamento ainda seja realizada na CPU.<br />
Diferentes versões das linguagens <strong>de</strong> sha<strong>de</strong>rs são disponibilizadas <strong>de</strong> acordo com o mo<strong>de</strong>lo do<br />
ambiente <strong>de</strong> execução <strong>de</strong> cada GPU programável. Tal mo<strong>de</strong>lo, chamado <strong>de</strong> mo<strong>de</strong>lo <strong>de</strong> sha<strong>de</strong>r (Sha<strong>de</strong>r<br />
Mo<strong>de</strong>l), reflete o aprimoramento do conjunto <strong>de</strong> instruções e registradores implementados segundo as<br />
sub-gerações <strong>de</strong> hardware gráfico <strong>de</strong> quarta geração. O primeiro e mais limitado mo<strong>de</strong>lo <strong>de</strong> sha<strong>de</strong>r<br />
é o mo<strong>de</strong>lo 1.1, introduzido em 2000 com a placa NVIDIA GeForce 3. O mo<strong>de</strong>lo 3.0 é o mo<strong>de</strong>lo<br />
exigido na implementação da nossa arquitetura <strong>de</strong> interação. A arquitetura ilustrada na figura 2.3 é<br />
ligeiramente modificada quando se consi<strong>de</strong>ra um hardware compatível com mo<strong>de</strong>lo <strong>de</strong> sha<strong>de</strong>r 3.0. A<br />
principal alteração é a capacida<strong>de</strong> do processador <strong>de</strong> vértices <strong>de</strong> também po<strong>de</strong>r realizar amostragem<br />
<strong>de</strong> texturas. O mo<strong>de</strong>lo <strong>de</strong> sha<strong>de</strong>r 4.0 é o mais atual neste momento, e consta na especificação da API<br />
Direct<strong>3D</strong> 10. Sua principal modificação está na introdução <strong>de</strong> um processador <strong>de</strong> geometria capaz<br />
<strong>de</strong> acessar informações <strong>de</strong> adjacência dos vértices que compõem cada primitiva, além <strong>de</strong> permitir<br />
criar novas primitivas sem <strong>de</strong>pen<strong>de</strong>r da CPU. Para uma comparação entre os diferentes mo<strong>de</strong>los <strong>de</strong><br />
sha<strong>de</strong>rs, veja Microsoft [2006] e Blythe [2006].<br />
2.4.1 Processador <strong>de</strong> vértices<br />
O processador <strong>de</strong> vértices é responsável pela execução <strong>de</strong> um sha<strong>de</strong>r para cada vértice da ge-<br />
ometria obtido após a etapa <strong>de</strong> montagem <strong>de</strong> vértices. Um vértice é composto <strong>de</strong> até 16 atributos<br />
<strong>de</strong>finidos pela aplicação segundo uma lista <strong>de</strong> formato <strong>de</strong> vértices pré-<strong>de</strong>finida pela API. A aplicação<br />
também <strong>de</strong>fine a semântica <strong>de</strong> cada atributo segundo uma lista <strong>de</strong> significados disponibilizada pela<br />
API. A semântica dos atributos é utilizada na etapa <strong>de</strong> montagem dos vértices (e.g., para distinguir<br />
qual atributo possui a posição do vértice) e para que o fluxo <strong>de</strong> função fixa <strong>de</strong> ren<strong>de</strong>rização possa<br />
distinguir, por exemplo, qual elemento correspon<strong>de</strong> ao vetor normal para o cálculo <strong>de</strong> iluminação, ou<br />
quais elementos contêm coor<strong>de</strong>nadas <strong>de</strong> textura para a etapa <strong>de</strong> texturização. Essa lista <strong>de</strong> semânticas<br />
inclui a posição do vértice, vetor normal, vetor tangente e vetor binormal 3 , cor RGBα, coor<strong>de</strong>nadas<br />
3 De acordo com Lengyel [2003], o termo binormal não é apropriado no contexto <strong>de</strong> mapeamento <strong>de</strong> <strong>de</strong>talhes <strong>3D</strong>, pois<br />
sua <strong>de</strong>finição em geometria diferencial não correspon<strong>de</strong> a um vetor tangente a um ponto da superfície, alinhado segundo<br />
a parametrização <strong>de</strong> uma das coor<strong>de</strong>nadas <strong>de</strong> textura nessa superfície. O autor sugere o termo vetor bitangente [Lengyel,