H3DGE: UM GERADOR DE IMAGENS 3D EM HARDWARE · Trabalho de formatura apresentado à Escola...
90
JEFFERSON CHAVES FERREIRA JOÃO PAULO CONDÉ OLIVEIRA PRADO H3DGE: UM GERADOR DE IMAGENS 3D EM HARDWARE Trabalho de formatura apresentado à Escola Politécnica da Universidade de São Paulo como requisito para a conclusão do curso de graduação em Engenharia Elétrica com Ênfase em Computação, junto ao Departamento de Engenharia de Computação e Sistemas Digitais (PCS). São Paulo 2011
Transcript of H3DGE: UM GERADOR DE IMAGENS 3D EM HARDWARE · Trabalho de formatura apresentado à Escola...
JEFFERSON CHAVES FERREIRAJOÃO PAULO CONDÉ OLIVEIRA PRADO
H3DGE: UM GERADOR DE IMAGENS 3D EMHARDWARE
Trabalho de formatura apresentado à Escola
Politécnica da Universidade de São Paulo
como requisito para a conclusão do curso de
graduação em Engenharia Elétrica com Ênfase
em Computação, junto ao Departamento de
Engenharia de Computação e Sistemas Digitais
(PCS).
São Paulo2011
JEFFERSON CHAVES FERREIRAJOÃO PAULO CONDÉ OLIVEIRA PRADO
H3DGE: UM GERADOR DE IMAGENS 3D EMHARDWARE
Trabalho de formatura apresentado à Escola
Politécnica da Universidade de São Paulo
como requisito para a conclusão do curso de
graduação em Engenharia Elétrica com Ênfase
em Computação, junto ao Departamento de
Engenharia de Computação e Sistemas Digitais
(PCS).
Área de Concentração:Sistemas Digitais
Orientador:Profa Dra Cíntia Borges Margi
Co-orientador:Pedro Maat Costa Massolino
São Paulo2011
À minha mãe, que sempre acreditouem mim.Jefferson
Aos meus pais e irmãos, que têm mesuportado e dado suporte desde muitoantes do início deste trabalho.João Paulo
AGRADECIMENTOS
Em primeiro lugar, agradecemos à nossa orientadora, Profa Cíntia BorgesMargi, que nos auxiliou e nos acompanhou nas diversas etapas deste trabalho.
Agradecemos também ao nosso co-orientador, Pedro Maat Costa Masso-lino, que nos forneceu auxílio técnico e valiosos conselhos.
Aos membros do Security and EMBedded systems EngineerIng group(SEMBEI), por terem nos acolhido durante os últimos seis meses e ao La-borátório de Arquitetura e Redes de Computadores (LARC) o qual dispôs osmeios técnicos, as ferramentas e toda a estrutura necessária ao desenvolvi-mento deste projeto.
Enfim, à Escola Politécnica da Universidade de São Paulo e à Télécom Pa-risTech, que nos propiciaram seis anos de aprendizado e crescimento dentroda fascinante ciência do engenho humano.
RESUMO
O ray tracing é um algoritmo capaz de gerar imagens 3D a partir de umacena predeterminada. Seu princípio consiste na geração de raios de luz apartir de uma posição da tela e no rastreamento de seus percursos rumo àsfontes luminosas. A partir dos cálculos de interseção com os objetos da cenae por meio da modelagem dos fenômenos ópticos, é possível obter a cor emformato RGB do ponto em questão.
Embora a complexidade computacional do algoritmo seja alta, o ray tracingé interessante para gerar imagens realistas e com alto nível de detalhe para amodelagem de projetos 3D ou mesmo para os jogos eletrônicos, produzindosaídas superiores às fornecidas pelos algoritmos de renderização usuais.
Este trabalho apresenta uma proposta de arquitetura em hardware para oemprego do ray tracing na geração dessas imagens. A combinação de umaarquitetura dedicada com o emprego de cálculos em ponto fixo e com a inde-xação espacial permite executar o algoritmo com uma performance superiore com menos recursos que os necessários para uma implementação equiva-lente em software. Isso é de grande relevância no contexto da intensificaçãodo emprego da modelagem 3D e dos sistemas embarcados no mundo da tec-nologia da informação.
ABSTRACT
Ray tracing is an algorithm to generate 3D images from a scene. It is basedon the generation of light rays from a given position and on tracing their pathsuntil they hit one of the light sources. Given a scene definition, it is possibleto obtain the RGB color of the current position by carrying out intersectioncalculations and modeling the optical phenomena between the light ray andthe scene objects.
Although the computational complexity of the algorithm is high, ray tracingis an interesting choice for high detail 3D image generation for project designor electronic games, yielding outputs of superior quality when compared withthose from usual rendering algorithms.
This work presents a hardware architecture proposal for the generationof those images using the ray tracing algorithm. The combination of a de-dicated architecture, fixed-point calculations and spatial indexing allows for ahigh-performance ray tracing execution, taking up less resources than thoseneeded for an equivalent software implementation. Due to the intensificationof 3D modeling and embedded systems employment in the IT world, this ap-proach becomes specially relevant.
RÉSUMÉ
Le lancer de rayon est un algorithme capable de générer des images 3D àpartir d’une scène prédéterminé. Il s’agit principalement de générer des rayonsde lumière d’une position sur l’écran et de suivre ses parcours vers les sourceslumineuses. Avec les calculs d’intersection et l’application des modèles desphénomènes optiques, il est possible trouver le couleur en format RGB à cepoint-là.
Bien que la complexité computationnelle de l’algorithme soit élevée, le lan-cer de rayon est intéressant pour générer des images réalistes, avec un niveaude détaille appréciable pour la modélisation de projets 3D ou même pour lesjeux vidéo, fournissant des sorties de meilleure qualité que les algorithmes derendérisation usuels.
Ce travail présente une proposition d’architecture matérielle pour l’emploidu lancer de rayon dans la génération de ces images. La combinaison d’unearchitecture dédiée avec l’emploi de calculs en point fixe et l’indexation spa-tiale permet d’exécuter le lancer de rayon avec une performance supérieureet moins de ressources qu’une implémentation logicielle. Cela est très rélé-vant dans le cadre de l’intensification de l’emploi de la modélisation 3D et dessystèmes embarqués dans le monde de la technologie de l’information.
LISTA DE ILUSTRAÇÕES
1 Exemplo de imagem sintetizada utilizando ray tracing. Extraído
de (OYONALE, 2009). . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Comparação entre imagens sintetizadas por rasterização e por
ray tracing. Extraído de (HOWARD, 2007). . . . . . . . . . . . . . 17
3 Interseção raio - plano . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Reflexão de um raio incidente ~I = − ~Iop . . . . . . . . . . . . . . 24
5 Reflexão acompanhada de refração de um raio incidente ~i -
adaptado de (GREVE, 2007) . . . . . . . . . . . . . . . . . . . . . 25
6 Funcionamento do algoritmo de ray tracing. . . . . . . . . . . . . 30
7 Uma árvore k-d bidimensional. Nós internos são nomeados de
acordo com os planos divisores e nós folha são nomeados de
acordo com a região que delimitam no espaço. À direita está
a árvore k-d que representa a divisão espacial especificada à
esquerda. Extraído de: (FOLEY; SUGERMAN, 2005). . . . . . . . . 32
8 Divisão do espaço por mediana espacial. . . . . . . . . . . . . . 33
9 Divisão do espaço por mediana de objetos. . . . . . . . . . . . . 34
10 Divisão do espaço por um modelo de custos. . . . . . . . . . . . 34
11 O valor de uma função de custo para quatro objetos (duas di-
mensões). As posições limites dos objetos possuem grande
influência na seleção do ponto de divisão com o custo mínimo.
Extraído de (HAVRAN, 2000). . . . . . . . . . . . . . . . . . . . . 35
12 Metodologia de projeto empregada. Adaptado de (ERBAS, 2006). 40
13 Passos para o projeto da plataforma de arquitetura. Adaptado
de (CHU, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
14 O ambiente de desenvolvimento do modelo de aplicação. . . . . 44
15 Arquitetura da linguagem SystemC. Adaptado de (GROTKER, 2002) 45
16 Plataforma de desenvolvimento ML507 da Xilinx . . . . . . . . . 47
17 O ambiente de desenvolvimento e de simulação em SystemVe-
rilog do modelo de arquitetura. . . . . . . . . . . . . . . . . . . . 49
18 O ambiente de síntese . . . . . . . . . . . . . . . . . . . . . . . . 50
19 Interface do ISE Design Suite, software utilizado para o posicio-
namento e interligação de células. . . . . . . . . . . . . . . . . . 50
20 Fluxograma do particionamento em hardware e software do ray-
tracer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
21 Arquitetura simplificada do sistema h3dge . . . . . . . . . . . . . 53
22 Arquitetura do coprocessador . . . . . . . . . . . . . . . . . . . . 59
23 Fluxo de dados do módulo de interseção de um raio com um
triângulo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
24 Estrutura interna do bloco de processamento das FPGAs Virtex-
5. Extraído de (XILINX, 2010a). . . . . . . . . . . . . . . . . . . . 61
25 Arquitetura do bus PLB v4.6. Extraído de (XILINX, 2010b). . . . . 63
26 O poliedro, uma das figuras geradas pelo algoritmo de ray tra-
cing utilizado no h3dge. Nota-se os efeitos de transparência
causados pela refração dos raios de luz. . . . . . . . . . . . . . . 70
27 Stanford bunny, uma das figuras geradas pelo algoritmo de ray
tracing utilizado no h3dge: visão frontal. . . . . . . . . . . . . . . 70
28 Stanford bunny, uma das figuras geradas pelo algoritmo de ray
tracing utilizado no h3dge: visão traseira. . . . . . . . . . . . . . 71
29 Influência da árvore k-d no desempenho . . . . . . . . . . . . . . 72
LISTA DE TABELAS
1 Organização de um pixel na memória. Adaptado de (XILINX, 2009). 64
2 Influência da árvore k-d no desempenho . . . . . . . . . . . . . . 72
3 Ocupação da FPGA para o sistema-base . . . . . . . . . . . . . 73
4 Desempenho do algoritmo de ray tracing em software no sis-
tema base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Ocupação da FPGA para o módulo de interseção . . . . . . . . 75
6 Dimensionamento da memória do coprocessador . . . . . . . . . 84
7 Dimensionamento da memória DDR2 necessária para a aloca-
ção de uma árvore k -d de 70000 triângulos . . . . . . . . . . . . 87
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
CAS Column Address Strobe
DDR Double Data Rate
DMA Direct Memory Access
DVI Digital Video Interface
FIFO First in First out
FPGA Field-Programmable Gate Array
FPU Floating Point Unit
GCC GNU Compiller Collection
HDL Hardware Description Language
IP Intellectual Property
JTAG Joint Test Action Group
LED Light-Emitting Diode
LUT Look-up Table
PLB Processor Local Bus
RAM Random Access Memory
RGB Red, Green and Blue
RISC Reduced Instruction Set Computing
RS-232 Recommended Standard 232
RTL Register Transfer Level
SAH Surface Area Heuristic
SoC System-on-Chip
SODIMM Small Outline Dual In-line Memory Module
SRAM Static Random Access Memory
TFT Thin Film Transistor
ULA Unidade lógica e aritmética
USP Universidade de São Paulo
VGA Video Graphics Array
VHDL VHSIC Hardware Description Language
VHSIC Very High Speed Integrated Circuits
XPS Xilinx Platform Studio
SUMÁRIO
1 Introdução 15
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Trabalhos existentes . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Princípios Teóricos 20
2.1 Princípios Matemáticos . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Cálculo de raiz quadrada . . . . . . . . . . . . . . . . . . 20
2.1.2 Interseção de raio com plano . . . . . . . . . . . . . . . . 21
2.1.3 Interseção de raio com triângulo . . . . . . . . . . . . . . 22
2.2 Princípios Físicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Reflexão de um raio incidente . . . . . . . . . . . . . . . . 24
2.2.2 Cálculo da refração e da transmissão de um raio incidente 25
2.2.3 Modelo para a luminosidade . . . . . . . . . . . . . . . . 27
3 Técnicas 29
3.1 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Hipóteses simplificadoras . . . . . . . . . . . . . . . . . . 31
3.1.3 Otimização com uma árvore k-d . . . . . . . . . . . . . . 31
3.1.4 Configuração das entradas e saídas . . . . . . . . . . . . 38
3.2 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Metodologia de projeto . . . . . . . . . . . . . . . . . . . 39
3.2.2 Recursos Utilizados . . . . . . . . . . . . . . . . . . . . . 44
3.2.2.1 Ferramentas de desenvolvimento para os mo-
delos de aplicação . . . . . . . . . . . . . . . . . 44
3.2.2.2 Plataforma de desenvolvimento . . . . . . . . . 46
3.2.2.3 Ferramentas de desenvolvimento para os mo-
delos de arquitetura . . . . . . . . . . . . . . . . 46
3.2.3 Particionamento em hardware e software . . . . . . . . . 51
3.2.4 Especificação e dimensionamento da arquitetura . . . . . 53
3.2.4.1 Visão geral . . . . . . . . . . . . . . . . . . . . . 53
3.2.4.2 Processador . . . . . . . . . . . . . . . . . . . . 54
3.2.4.3 Coprocessador . . . . . . . . . . . . . . . . . . . 56
3.2.4.4 Vias de dados . . . . . . . . . . . . . . . . . . . 61
3.2.4.5 Controlador de vídeo . . . . . . . . . . . . . . . 64
3.2.4.6 Dimensionamento da memória DDR2 externa . 65
3.2.4.7 Considerações a respeito do número de copro-
cessadores em paralelo . . . . . . . . . . . . . . 66
4 Resultados 69
4.1 Imagens geradas . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2 Melhoria de desempenho causada pelo uso de uma árvore k -d . 71
4.3 Resultados do sistema sintetizado em hardware . . . . . . . . . 73
4.3.1 Sistema base . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3.2 Coprocessador . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Conclusões 76
5.1 Objetivos alcançados . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . 77
5.3 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.4 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . 80
Referências 81
Apêndice A -- Estimativas para o coprocessador 84
Apêndice B -- Estimativas para a árvore k-d 87
15
1 INTRODUÇÃO
A computação gráfica é a área de estudo a qual engloba o processamento
de imagens focando na síntese digital e na manipulação de informações ge-
ométricas e de conteúdo visual. Sua área de aplicação é diversa e engloba
a área artística, a área de design de produto, os jogos eletrônicos, as anima-
ções de cinema, a engenharia (sobretudo na simulação de eventos físicos e
químicos de materiais envolvidos nos projetos em desenvolvimento) e a me-
dicina. Dessa forma, há uma demanda crescente por meios que possibilitem
a elaboração de elementos visuais com alto nível de detalhe para atender os
requisitos destes vários setores profissionais.
As plataformas computacionais contemporâneas possuem alta capaci-
dade de processamento e conseguem sintetizar imagens realistas com re-
lativa facilidade, contudo tais plataformas muitas vezes não executam os algo-
ritmos de geração de imagens realistas com a desenvoltura almejada. Dessa
forma, o projeto de arquiteturas dedicadas combinadas com algoritmos otimi-
zados de geração de imagens tem sido visto como uma potencial alternativa
a este problema e são um campo de intensa pesquisa.
Este trabalho trata deste assunto e, para atender tais requisitos, combina
um algoritmo com o qual é possível gerar imagens com um alto nível de deta-
lhe com a elaboração de uma arquitetura dedicada em hardware. Além disso,
tal arquitetura também é acompanhada de métodos otimizados de busca e
16
acesso aos dados.
1.1 Motivação
Ray tracing é uma técnica utilizada em computação gráfica para sintetizar
imagens 3-D com alto grau de realismo. O método consiste em rastrear a partir
de uma cena pré-definida todos os fenômenos ópticos (reflexões e refrações)
a que são submetidos os raios de luz que chegam ao observador. A figura 1
apresenta um exemplo de imagem gerada por esse algoritmo.
Figura 1 – Exemplo de imagem sintetizada utilizando ray tracing. Extraído de (OYONALE,2009).
Embora o princípio subjacente não seja sofisticado, os resultados obtidos
por ray tracing são visualmente impressionantes e superiores quando com-
parados a imagens geradas por outros algoritmos, como a renderização por
rasterização (STRATTON, 2008), conforme ilustrado na figura 2. Contudo, o ray
tracing apresenta um alto custo computacional1, sendo indicado para situa-1Em uma implementação simples do algoritmo de ray tracing, para cada raio de luz lançado
é necessário executar uma verificação de interseção para cada primitiva da cena. Comopara cada pixel é lançado pelo menos um raio, a complexidade computacional do algoritmo
17
ções onde o tempo de geração das imagens não é crítico (como fotografias
sintetizadas ou efeitos especiais para filmes e programas de TV); o uso dessa
técnica em video games, por exemplo, é inviável no estado atual da tecnologia.
Figura 2 – Comparação entre imagens sintetizadas por rasterização e por ray tracing.Extraído de (HOWARD, 2007).
1.2 Trabalhos existentes
Existem no mercado diversas soluções em software que implementam a
renderização por ray tracing, tais como POV-Ray e mental ray. No entanto,
realizações em hardware são raras e na maior parte experimentais ((WOOP;
SCHMITTLER; SLUSALLEK, 2005), (HANIKA, 2007)). Recentemente, a empresa
coreana Siliconarts anunciou o lançamento do primeiro core IP para ray tra-
cing (SILICONARTS, 2011), o que pode significar o começo da entrada dessa
tecnologia no mercado de consumo em massa.
Vários centros de pesquisa ao redor do mundo ((HANIKA, 2007) e (PUR-
é O(p · n · r), onde p é o número de pixels da imagem; n, a quantidade de primitivas; e r, onúmero máximo de reflexões e refrações rastreadas pelo sistema.
18
CELL et al., 2002)) trabalham com o objetivo de produzir um protótipo para o
uso do ray tracing em tempo real com a finalidade de abrir as portas para o
uso desta tecnologia. Entretanto, nenhum desses trabalhos implementa uma
arquitetura completa para a execução do ray tracing em FPGAs; é nessa linha
de investigação que se insere o projeto h3dge.
1.3 Apresentação
O objetivo deste trabalho é propor e descrever um raytracer em hardware.
O projeto consiste na definição de uma cena composta de objetos modelados
por um número de triângulos por meio dos quais pode-se obter facilmente a
maioria das figuras em 3D.
Os parâmetros de entrada são compostos por uma lista de triângulos
acompanhados de suas coordenadas no espaço e das propriedades dos ma-
teriais que os compõem (transparente, opaco, translúcido) e por um número
de luzes acompanhadas de suas propriedades (posição no espaço e cor). A
partir destas entradas, o hardware emprega o algoritmo de ray tracing e gera
a imagem em 3D com os efeitos ópticos implementados.
1.4 Objetivos
O objetivo principal deste projeto é propor, implementar e testar uma ar-
quitetura para um raytracer em hardware.
Além disso, devem-se destacar objetivos secundários para a realização de
tal tarefa como:
• Desenvolver um módulo de interface de vídeo;
19
• Desenvolver um módulo para tratar os dados de entrada por meio de
uma porta serial;
• Desenvolver um módulo no qual serão definidos os fenômenos ópticos
do projeto, ou seja, as reflexões e refrações.
1.5 Organização
O restante deste documento está organizado da seguinte forma:
• No capítulo 2 são apresentados os conceitos teóricos essenciais ao en-
tendimento deste projeto, oriundos da Matemática e da Física;
• Em seguida, o capítulo 3 é o cerne do trabalho, apresentando toda a
metodologia e as técnicas utilizadas para implementar o raytracer ;
• O capítulo 4 apresenta os resultados obtidos por meio da aplicação dos
conceitos abordados no capítulo anterior;
• Enfim, as conclusões fecham o documento, com um olhar global sobre
os objetivos alcançados e as possibilidades futuras.
20
2 PRINCÍPIOS TEÓRICOS
Este capítulo trata das abordagens matemáticas para a realização dos
cálculos envolvidos no projeto. Há a seção de princípios matemáticos na qual
se discute os algoritmos utilizados no cálculo de raiz quadrada, na interseção
de um raio de luz com um plano e na interseção de um raio de luz com um
triângulo.
Após a seção de princípios matemáticos, a seção de princípios físicos dis-
cute as abordagens utilizadas para a modelagem dos fenômenos ópticos de
reflexão e refração e no cálculo da intensidade luminosa de um ponto obser-
vado.
2.1 Princípios Matemáticos
2.1.1 Cálculo de raiz quadrada
O emprego da operação de raiz quadrada é muito frequente na computa-
ção gráfica. Apesar de ser uma operação relativamente complexa, ela deve
ser empregada em fórmulas matemáticas (como, por exemplo, na refração) e
em frequentes operações de normalização de vetores. Neste trabalho optou-
se pelo emprego de um algoritmo que utilize operações matemáticas simples,
como deslocamentos e adições, e que já fosse implementado em hardware.
Por isso utilizou-se o Non-Restoring Algorithm já sintetizado em FPGA e des-
21
crito em (PIROMSOPA; APORNTEWAN; CHOGSATITVATAA, 2001). Dado um radi-
cando não negativo de 32 bits D[31 : 0], sua raiz quadrada é dada por Q[15 : 0]
e o resto R[16 : 0] é dado por R = D−Q2. O algoritmo 1 descreve o processo
de obtenção da raiz quadrada.
D[31 : 0] unsigned integerQ[15 : 0] unsigned integer {resultado}R[16 : 0] unsigned integer {resto}R← 0Q← 0for i = 15→ 0 do
if R ≥ 0 thenR← (R << 2)or(D >> (i+ i)and(3))R← R− ((Q << 2)or(1)
elseR← (R << 2)or(D >> (i+ i)and(3))R← R− ((Q << 2)or(3))
end ifif R ≥ 0 thenQ← (Q << 1)or(1)
elseQ← (Q << 1)or(0)
end ifi← i− 1
end forAlgoritmo 1 – Cálculo de raiz quadrada
2.1.2 Interseção de raio com plano
Em 3D, uma reta é paralela a um plano π, ou o intercepta em um ponto
individual, ou está totalmente incluída no plano. Seja a reta L dada pela equa-
ção paramétrica: P (s) = P0+s(P1−P0) = P +s.~u e o plano π dado pelo ponto
V0 e seu vetor normal ~n.
É necessário verificar se L é paralela ao plano π testando se ~n.~u = 0, o
que significa que a direção do vetor ~u da reta é perpendicular ao plano normal
~n. Se esse produto escalar é de fato nulo, então ou L e π são paralelos e não
se interceptam, ou L está totalmente no plano π. Para verificar se L ∈ π, basta
22
testar se um ponto de L (por exemplo. P0) está contido em π.
Figura 3 – Interseção raio - plano
Se a reta e o plano não são paralelos, então L e π se interceptam em um
ponto único P (sI) que é calculado (veja figura 3) a seguir.
No ponto de interseção o vetor P (s) − V0 = ~w + s.~u, onde ~w = P0 − V0, é
equivalente à condição: ~n.(~w+ s.~u) = 0. Por meio de manipulações é possível
obter:
sI =−~n.~w~n.~u
=~n(V0 − P0)
~n(P1 − P0)(2.1)
2.1.3 Interseção de raio com triângulo
O método de cálculo de interseção de raio com triângulo escolhido é o
de Möller e Trumbore (MÖLLER; TRUMBORE, 1997) que utiliza as coordenadas
baricêntricas com o propósito de escolher o ponto de interseção. Um ponto
T (u, v) de um triângulo é exprimido em coordenadas baricêntricas da seguinte
forma:
T (u, v) = (1− u− v).V0 + u.V1 + v.V2 (2.2)
23
onde
(u, v) são as coordenadas baricêntricas e
V0, V1 e V2 são os vértices do triângulo.
Para serem válidos, u e v devem atender às seguintes condições:
u ≥ 0, v ≥ 0, u+ v ≤ 1
Calcular a interseção entre o raio R(t) = O + t. ~D (O é o ponto de origem
e ~D é a direção e o sentido) e o triângulo, T (u, v), é equivalente à R(t) =
T (u, v). A partir da igualdade anterior e da representação em coordenadas
baricêntricas é possível obter:
O + t. ~D = (1− u− v).V0 + u.V1 + v.V2 (2.3)
Com algumas manipulações é possível expressar a representação como
um produto de vetores da seguinte forma:
(− ~D V1 − V0 V2 − V0
).
t
u
v
= O − V0 (2.4)
Nomeando ~E1 = V1 − V0, ~E2 = V2 − V0 e ~T = O − V0 a solução para a
equação anterior, aplicando a Regra de Cramer, é a seguinte:
t
u
v
=1
(( ~D × ~E2). ~E1).
((~T × ~E1). ~E2)
(( ~D × ~E2). ~T )
((~T × ~E1). ~D)
(2.5)
A partir da resolução do sistema anterior e se u e v atendem às condições
24
anteriores conclui-se que o ponto pertence ao triângulo e que t é o coeficiente
do vetor de direção.
2.2 Princípios Físicos
2.2.1 Reflexão de um raio incidente
A figura 4 ilustra a reflexão de um raio sobre um objeto.
Figura 4 – Reflexão de um raio incidente ~I = − ~Iop
Seja ~Iop o vetor oposto à direção de um raio incidente em um objeto, ~N é
a normal a este raio e ~V é o vetor do raio refletido pelo objeto. Cabe ressaltar
que ~Iop e ~N são vetores unitários. O raio refletido é calculado da seguinte
forma:
~V = ~N.( ~Iop. ~N) + ~a (2.6)
e
~Iop + ~a = ~N(Iop. ~N) (2.7)
25
logo:
~V = 2 ~N( ~Iop. ~N)− ~Iop (2.8)
Por meio da substituição de Iop por I, é possível obter:
~V = ~I − 2 ~N(~I. ~N) (2.9)
2.2.2 Cálculo da refração e da transmissão de um raio inci-dente
A figura 5 ilustra a situação na qual um raio de luz, cuja direção e sentido
são indicados pelo vetor i, é refletido e refratado nas direções e sentidos do
vetores r e t respectivamente. Um ângulo θv é o ângulo compreendido entre
o vetor v e a normal n. Com base nesta nomenclatura, o raio refratado é
calculado a seguir.
Figura 5 – Reflexão acompanhada de refração de um raio incidente~i - adaptado de (GREVE,2007)
A refração de um raio ocorre quando um raio incidente cruza uma super-
fície que delimita dois materiais com índices de refração diferentes n2 e n1 e
26
n2
n1≤ 1. Os ângulos de incidência, reflexão e refração são respectivamente θi,
θr e θt e, como os vetores de~i, ~r e ~t são unitários, é possível escrever:
sen(θv) =| ~vh|~|v|
= |~vh| (2.10)
cos(θv) =| ~vv|~|v|
= |~vv| (2.11)
ou
cos(θv) = ±~v.~n (2.12)
A partir da lei de Snell-Déscartes n1senθi = n2senθt e da equação anterior,
é possível escrever:
|~th| =n1
n2
|~ih| (2.13)
Como ~ih e ~th são paralelos e apontam na mesma direção:
~th =n1
n2
(~i− proj~n(~i)) =n1
n2
(~i− (~i.~n)~n) (2.14)
A partir de ~th + ~tv = ~t e do teorema de Pitágoras obtém-se a seguinte
equação:
t =n1
n2
~i−(n1
n2
(~i.~n) +√
1− |th|2)~n =
n1
n2
i−(n1
n2
(~i.~n) +√1− sen2θt
)~n (2.15)
Novamente empregando-se a lei de Snell:
27
~t =n1
n2
~i−
n1
n2
(~i.~n) +
√1−
(n1
n2
)2
(1− cos2θi)
~n⇔
~t =n1
n2
~i−
n1
n2
(~i.~n) +
√1−
(n1
n2
)2
(1− (~i.~n)2)
~n (2.16)
Vale a pena ressaltar que a equação anterior é valida se a condição(n1
n2
)2(1−(~i.~n)2) ≤ 1 for verdadeira. Caso tal condição não se satisfaça, tem-se
o fenômeno de reflexão total e não há raio refratado.
2.2.3 Modelo para a luminosidade
Após os cálculos dos vetores dos raios refletidos e refratados, inicia-se o
cálculo da intensidade luminosa para o pixel. Para tal cálculo o modelo de
iluminação de Whitted (WHITTED, 1980) é utilizado. Ele faz o relacionamento
da reflexão especular, da transmissão, da reflexão difusa e da iluminação glo-
bal com a intensidade total da luz em um ponto preciso por meio da seguinte
fórmula:
I = Ia + kd +
j=ls∑j=1
( ~N. ~Lj) + ksS + ktT (2.17)
Onde:
I: intensidade total
Ia: reflexão devido à luz ambiente
kd: coeficiente de reflexão difusa
N : normal unitária da superfície
Lj: vetor em direção a j-ésima fonte luminosa
28
ks: coeficiente de reflexão especular
S: intensidade da luz na direção do raio refletido
kt: coeficiente de transmissão
T : a intensidade da luz na direção do raio refratado
29
3 TÉCNICAS
Este capítulo aborda o algoritmo empregado e especifica todos os deta-
lhes técnicos envolvidos no desenvolvimento do raytracer em hardware. A
primeira seção aborda o princípio do ray tracing, as hipóteses simplificadoras
e o formato das entradas nas quais o projeto foi especificado.
A segunda seção aborda o desenvolvimento do projeto. Inicialmente são
descritos detalhes sobre o projeto em hardware, após isso inicia-se uma visão
geral das ferramentas e linguagens empregadas.
Na terceira seção documenta-se o processo de desenvolvimento e espe-
cificação da arquitetura do projeto e tem-se as primeiras estimativas sobre os
recursos que serão utilizados.
A quarta seção discute o particionamento entre hardware e software do
projeto e documenta detalhes sobre estas duas partes do desenvolvimento.
3.1 Algoritmo
3.1.1 Visão Geral
Após a descrição dos cálculos empregados no ray tracing, esta seção
apresenta o algoritmo implementado.
O princípio de funcionamento do algoritmo é bastante simples: define-se
30
uma janela de observação sobre a qual a imagem será projetada e posiciona-
se o observador a uma certa distância. Em seguida, para cada pixel da janela
um raio é lançado a partir do observador; calculam-se as interseções desse
raio com os objetos da cena, e para cada interseção são determinados os
raios derivados (refletidos, refratados, etc), que são por sua vez rastreados da
mesma forma, como ilustrado na figura 6. Enfim, a cor do pixel é determinada
pela composição das contribuições dos raios calculados, calculadas a partir
das características do material interceptado (cor, coeficientes de reflexão e
transmissão, etc) e da cor da fonte de luz.
Fonte de luz
Objeto da cena
ImagemObservador
Figura 6 – Funcionamento do algoritmo de ray tracing.
As primeiras soluções para ray tracing usaram lógica de ponto flutuante,
a qual requer mais superfície de hardware para sua realização, contudo a
utilização de lógica de ponto fixo permite a elaboração de soluções mais efi-
cientes e robustas (HANIKA, 2007). Com o objetivo de produzir uma solução
robusta, neste trabalho os cálculos serão feitos empregando-se uma lógica de
ponto fixo com possíveis enquadramentos (mudanças de escala) em cálculos
intermediários.
Além disso, no lugar de algoritmos recursivos (tipicamente utilizados na
31
construção de árvores) serão utilizados algoritmos iterativos para que a des-
crição implementada seja sintetizável em hardware.
3.1.2 Hipóteses simplificadoras
Em uma primeira abordagem, utilizar-se-ão algumas hipóteses simplifica-
doras na implementação do algoritmo de ray tracing:
• Todos os raios partirão paralelos ao plano de projeção. Tal simplificação
permite a obtenção de imagens sem implementar um modelo de câmera;
• Apenas os fenômenos de reflexão e refração serão considerados. Efei-
tos ópticos mais complexos não serão implementados;
• Cada raio partindo do plano de projeção só poderá receber até cinco
reflexões/refrações. Essa medida é essencial para limitar os recursos
utilizados.
3.1.3 Otimização com uma árvore k-d
Segundo (HAVRAN, 2000) existem diversas maneiras para se otimizar um
algoritmo de ray tracing. Entre os algoritmos mais comuns, o algoritmo de
otimização por árvore k-d revelou-se estatisticamente mais eficiente, isto é,
tal algoritmo encontra mais rapidamente o triângulo que um determinado raio
de luz intercepta. A abordagem detalhada destes algoritmos não faz parte
deste trabalho e recomenda-se a leitura de (HAVRAN, 2000) para um maior
aprofundamento em algoritmos de ray tracing.
No ray tracing, a imagem 3D é gerada a partir da verificação da busca
dos raios de luz incidentes, refletidos e refratados no conjunto de triângulos
da cena. Contudo, o processo de verificação tende a ser bem custoso se
32
o algoritmo percorrer a lista inteira de triângulos toda vez que a busca de
interseção do raio for necessária. Para evitar isto, utiliza-se um processo de
indexação espacial por meio de árvores k-d, que organiza os dados com o
objetivo de percorrer um número mínimo de triângulos e verificar a ocorrência
da interseção destes triângulos com um raio.
As árvores k-d são árvores binárias nas quais cada nó contém um ponto
em dimensão k. Cada nó não-terminal representa uma divisão do espaço por
um plano, e o caminho percorrido desde a raiz até um nó terminal descreve a
região do espaço determinada por ele delimitada. O nó terminal ainda arma-
zena referências para todos os triângulos contidos em sua região espacial. A
figura 7 mostra um exemplo de uma árvore k-d.
Figura 7 – Uma árvore k-d bidimensional. Nós internos são nomeados de acordo com osplanos divisores e nós folha são nomeados de acordo com a região que delimitam noespaço. À direita está a árvore k-d que representa a divisão espacial especificada à
esquerda. Extraído de: (FOLEY; SUGERMAN, 2005).
As divisões do espaço são sempre feitas por meio de planos paralelos aos
eixos coordenados, o que simplifica a geração dos filhos esquerdo e direito
de um nó. Por exemplo: se um nó N é dividido pelo plano x = x0, todos os
triângulos cujas coordenadas em x de, pelo menos, um de seus vértices sejam
menores do que x0 estarão referenciados em, pelo menos, um nó terminal
acessível pelo filho da esquerda; o raciocínio é análogo para o filho da direita.
Se um triângulo possuir vértices tanto à “esquerda” de x0 (com coordenada
x menor que x0) quanto à “direita”, ele será referenciado por nós terminais
33
acessíveis pelos dois filhos de N .
Durante a construção de uma árvore k-d, é necessário encontrar um crité-
rio que consiga resolver o problema de dividir um nó em duas sub-regiões do
espaço. Como o problema de divisão de planos na árvore k-d é relacionado
com os eixos que delimitam o espaço para que seja possível encontrar um
determinado triângulo mais rapidamente, seria vantajoso encontrar um mé-
todo que relacionasse os triângulos e sua posição no espaço com a posição
na qual um eixo será dividido. O eixo a ser dividido é o eixo que menos res-
tringe o número de triângulos dentro dele, pois a distância entre a coordenada
máxima e a coordenada mínima aceita é a maior entre os eixos de uma deter-
minada subdivisão espacial. Há vários métodos (HAVRAN, 2000) com os quais
é possível obter uma orientação de como dividir o espaço:
• mediana espacial - na construção da árvore, o plano de divisão sempre
divide o eixo com o maior intervalo no ponto médio da região delimitada
pelo eixo. Esta abordagem balanceia o espaço em cada lado do plano
de divisão;
Figura 8 – Divisão do espaço por mediana espacial.
• mediana de objetos - a coordenada do eixo de maior intervalo é dividida
de tal forma que o número de triângulos seja o mesmo em ambos os
lados das novas sub-regiões do espaço;
34
Figura 9 – Divisão do espaço por mediana de objetos.
• modelo de custos - consiste em determinar uma lista de possíveis posi-
ções candidatas para a divisão de um eixo e escolher aquela que possui
o menor custo de divisão. Isto pode ser feito por meio de probabilidade
geométrica.
Custo
Posição do plano divisor
Figura 10 – Divisão do espaço por um modelo de custos.
Segundo (HAVRAN, 2000), o modelo de custos é que possui melhor de-
sempenho entre os três supracitados e que será empregado neste trabalho.
O modelo de custos a partir da área superficial corresponde ao cálculo de
uma função heurística de custo para todas as possíveis posições do plano de
divisão e a seleção da posição que fornece o custo mais baixo. As posições
possíveis são limitadas pelas coordenadas no eixo no qual será feita a divisão
de cada vértice de todos os triângulos contidos em uma subdivisão do espaço.
Esse modelo, ilustrado pela figura 11, é denominado heurística de área super-
35
ficial (cuja sigla em inglês é SAH — Surface Area Heuristic), e a fórmula para
seu cálculo é a seguinte:
C =1
SA(Ncurr)[SA(LCNcurr)(Trigleft+Trigboth)+SA(RCNcurr)(Trigright+Trigboth)]
(3.1)
onde:
SA(Ncurr) área do nó atual
SA(LCNcurr) área do candidato a filho esquerdo do nó atual
SA(RCNcurr) área do candidato a filho direito do nó atual
Trigleft número de triângulos à esquerda do valor candidato a divisão
Trigright número de triângulos à direita do valor candidato a divisão
Trigboth número de triângulos que pertencem aos dois lados da possível di-
visão
Figura 11 – O valor de uma função de custo para quatro objetos (duas dimensões). Asposições limites dos objetos possuem grande influência na seleção do ponto de divisão com
o custo mínimo. Extraído de (HAVRAN, 2000).
O critério de parada das divisões dos eixos no modelo de heurística de
área superficial ocorre quando o menor custo de divisão de um eixo é maior
36
ou igual ao custo de divisão do nó pai da árvore ou quando a profundidade má-
xima é atingida. O algoritmo 2 descreve a construção da árvore k-d utilizando
o modelo de heurística de área superficial.
o algoritmo inicia com o tratamento da raiz a qual possui custo de divisão∞
while existirem nós a serem tratados and a profundidade máxima não foratingida do
dividir o eixo do espaço indexável que possui o maior tamanhocalcular o custo de todas as possíveis posições de corteescolher a posição de menor custoif custo for menor que o custo da divisão do nó-pai then
executar a divisãocriar dois novos nós para armazenar os triângulos compreendidos naparte esquerda e na parte direita da divisãoadicionar os nós criados ao fim da lista de nós a serem tratados
end iftratar próximo nó
end whileAlgoritmo 2 – Construção da árvore k-d
Após a construção da árvore k-d é necessário o uso de um algoritmo para
percorrê-la a fim de encontrar o triângulo que intercepta um determinado raio
de luz. Dado um raio de luz r, deve-se encontrar a interseção mais próxima
com o espaço indexável (isto é, o espaço que será subdivido dentro de uma
árvore k-d). Para isto foram utilizado os cálculos descritos na seção 2.1.2.
Uma vez que a primeira interseção é encontrada deve-se procurar o nó folha
da árvore-k-d no qual a interseção está contida. Esse processo é detalhado
no algoritmo 3.
Uma vez encontrado o nó-folha, deve-se testar cada triângulo referenciado
por ele (o conjunto destes triângulos é chamado pacote de triângulos). Uma
vez que a interseção é encontrada, calcula-se o raio refletido (seção 2.2.1) e,
se houver, o raio refratado (seção 2.2.2). Após isso, é necessário encontrar o
próximo pacote de triângulos para cada novo raio gerado, usando novamente
o algoritmo 3.
37
parâmetros:ray o raio de luz atualcurrentNode o nó sendo atravessado por ray atualmenteif ainda não foi calculado o primeiro nó atravessado thenpoint← ponto em que o raio entra no espaço indexadoif raio não intercepta o espaço indexado then
return nó nulo (não existe próximo nó)end ifnode← raiz da árvore k-d
elsepoint← ponto em que o raio deixa o nó atualnode← currentNodewhile node não é estritamente maior em todas as dimensões (x, y, z) quecurrentNode do
if node é a raiz thenreturn nó nulo (não existe próximo nó)
elsenode← pai de node
end ifend while
end ifwhile node não é um nó-folha dosplitAxis← eixo de divisão de nodesplitCoord← coordenada na qual splitAxis foi divididoif point[splitAxis] = splitCoord then
if rayDirection[splitAxis] > 0 thennode← filho direito de node
elsenode← filho esquerdo de node
end ifelse if point[splitAxis] > splitCoord thennode← filho direito de node
elsenode← filho esquerdo de node
end ifend whilereturn node
Algoritmo 3 – Busca de um próximo nó na árvore k-d
38
3.1.4 Configuração das entradas e saídas
Há dois arquivos responsáveis pelos parâmetros de entrada do h3dge. O
primeiro é um arquivo .dscx cuja estrutura é a seguinte :
• Primeira linha: a palavra "DSCX";
• Segunda Linha: width e height, a largura e a altura da janela de obser-
vação;
• Terceira linha: nMats, nMedia e nLights, o número de materiais presen-
tes na cena seguido pelo número de meios ópticos e de fontes lumino-
sas;
• nMats linhas seguintes: os materiais cujos atributos são especificados
na ordem: cor vermelha, cor verde, cor azul, coeficiente de reflexão,
coeficiente de transmissão;
• nMedia linhas seguintes: os meios ópticos presentes na cena, caracte-
rizados pelo seu índice de refração;
• nLights linhas seguintes: as fontes luminosas cujos atributos são espe-
cificados na ordem: coordenadas x, y e z; e intensidade da cor vermelha,
azul e verde;
• Linha seguinte: nTrigs, o número de triângulos;
• nTrigs linhas seguintes: o material de cada triângulo, seguido pelos nú-
meros identificadores dos dois meios ópticos por ele separados.
A cena que será processada é formada por triângulos e é armazenada em
um arquivo .off cuja estrutura é a seguinte :
• Primeira linha: a palavra "OFF";
39
• Segunda linha: nPoints, a quantidade de pontos; nTrigs, a de triângu-
los; e um zero;
• nPoints linhas seguintes: os pontos dos vértices dos triângulos;
• nTrigs linhas seguintes: o número de vértices de polígonos (sempre
igual a 3, pois a cena é composta sempre por triângulos) e o número
identificador dos pontos que compõem cada vértice.
Tais informações podem ser obtidas por meio de arquivos de formato pa-
dronizado, tais como os arquivos .off (Object File Format, definido em (SHI-
LANE et al., 2004)), utilizados para representar a geometria de um modelo com
base em polígonos.
A saída do algoritmo é uma sequência de valores RGB correspondentes a
cada um dos pixels da imagem calculada.
3.2 Desenvolvimento
3.2.1 Metodologia de projeto
Os modelos clássicos de projeto em hardware e software tipicamente co-
meçam de uma mesma especificação de sistema que é gradualmente refinada
e sintetizada em uma arquitetura a qual é composta por componentes progra-
máveis ou dedicados. Contudo a grande desvantagem desta abordagem é o
fato de ser necessário um particionamento prematuro entre o que irá ser pro-
gramado em hardware e software. Desta forma separa-se, desde o início da
concepção do projeto, o que será desenvolvido em software e em hardware e,
a partir desta separação, inicia-se o desenvolvimento do projeto. A parte em
software é feita geralmente usando uma linguagem de programação de alto
desempenho (linguagem C, por exemplo); a parte em hardware, por sua vez,
40
é feita utilizando-se simuladores de linguagens de descrição de hardware de
baixo nível como o VHDL ou o Verilog.
A grande desvantagem dessa metodologia é o risco do aumento de com-
plexidade do projeto resultante de um dimensionamento equivocado da di-
visão entre software e hardware. Por isso, para a execução deste trabalho
procurou-se adotar uma nova metodologia (ERBAS, 2006) na qual procura-se
melhorar o projeto do circuito por meio da eliminação da decisão prematura
do particionamento. A figura 12 ilustra esta metodologia em forma de Y a qual
reconhece uma clara separação entre um modelo de aplicação, um modelo de
arquitetura e um passo explícito para o mapeamento no qual se correlacionam
os dois modelos.
Figura 12 – Metodologia de projeto empregada. Adaptado de (ERBAS, 2006).
O modelo de aplicação descreve o comportamento funcional de uma apli-
cação independentemente de especificações arquiteturais como o particiona-
mento ou de características do desenvolvimento temporal do sistema. O mo-
delo de arquitetura define os recursos da arquitetura e captura suas caracte-
rísticas temporais sendo capaz de avaliar a desenvoltura para a execução das
arquiteturas em hardware e software. Logo ao invés de utilizar a abordagem
41
clássica na qual a simulação do hardware e do software são vistas como par-
tes cooperantes, a metodologia em Y distingue as simulações de aplicação
e arquitetura sendo que a última envolve aspectos das partes programáveis
como também das partes dedicadas.
O esquema geral de desenvolvimento é dado pela figura 12. O conjunto de
modelos de aplicação no canto superior direito da figura conduz o projeto da
arquitetura. O primeiro passo do projetista é estudar estas aplicações, fazer
alguns cálculos iniciais e propor uma plataforma candidata para o desenvol-
vimento da arquitetura. Os números resultantes podem inspirar o projetista a
melhorar a arquitetura, reestruturar a aplicação ou mudar o mapeamento. As
possíveis ações do projetista são ilustradas por meio das nuvens de cor cinza
na figura 12.
O desacoplamento dos modelos de arquitetura e aplicação permite utilizar
um mesmo modelo de aplicação para exercitar diferentes particionamentos
entre hardware e software e mapeá-los em um conjunto de modelos de arqui-
tetura. Esta capacidade demostra a eficiência do desacoplamento por meio
do reuso de ambas as partes do modelo.
Após encontrar uma alternativa que atenda aos requisitos do projeto, é
necessária a transição para a abordagens de baixo nível visando à síntese do
circuito. Para isto recorre-se a modelos Register Transfer Level (RTL) sinteti-
záveis com os quais é possível obter modelos mais precisos e que atendam
aos requisitos de projeto. Para tal tarefa é necessário um conjunto de ambi-
entes de desenvolvimento nos quais existam diferentes níveis de abstração
para um mesmo projeto. Assim enquanto modelos executáveis abstratos de
aplicação exploram eficientemente as abordagens de projeto, modelos mais
detalhados agregam mais detalhes de desenvolvimento e consequentemente
trazem uma maior precisão e permitem um projeto eficiente em hardware.
42
O fluxo de desenvolvimento da plataforma de arquitetura (parte esquerda
da metodologia em Y da figura 12) começa com uma descrição RTL do cir-
cuito. Tal descrição pode ser acompanhada por um conjunto de detalhes
específicos de execução da plataforma de desenvolvimento. Um arquivo se-
parado conhecido como testbench (bancada de testes) provê uma bancada
virtual para a simulação e verificação do circuito. Ela incorpora o código para
gerar os estímulos de entrada e monitorar as respostas de saída. Uma vez
que estes arquivos são criados, o circuito pode ser construído e verificado
de uma maneira eficiente. Os passos do desenvolvimento da plataforma de
arquitetura, segundo (CHU, 2006), são descritos abaixo:
• Desenvolver o arquivo de projeto da arquitetura e a bancada de testes;
• Utilizar o arquivo de projeto da arquitetura como a descrição do circuito
e executar a simulação para verificar se as funções do projeto funcionam
de maneira adequada;
• Executar a síntese do circuito;
• Utilizar o arquivo netlist de saída do sintetizador, que especifica as ins-
tâncias e as interconexões das diversas células do projeto, como descri-
ção do circuito e realizar uma simulação e análise de tempo para verificar
a regularidade da síntese e checar se o tempo de execução é adequado;
• Executar o place-and-route (posicionamento e interligação de células);
• Anotar as informações precisas de tempo para o netlist, realizar a simu-
lação e análise de tempo para verificar a correção do place-and-route e
verificar se o circuito atende as restrições de tempo;
• Gerar o arquivo de configuração e programar a plataforma de desenvol-
vimento;
43
• Verificar o funcionamento da parte física.
O fluxo descrito acima representa um processo ideal, pois assume que a
descrição do projeto inicial siga a especificação funcional e atenda as restri-
ções de tempo. Na realidade, o fluxo de desenvolvimento pode acarretar em
várias iterações para corrigir os erros funcionais ou problemas de tempo. É
possível que haja necessidade de rever os arquivos de projeto de arquitetura
originais para ajustar parâmetros da síntese e no place-and-route. A figura 13
ilustra todos os passos descritos acima.
Figura 13 – Passos para o projeto da plataforma de arquitetura. Adaptado de (CHU, 2006)
44
3.2.2 Recursos Utilizados
Esta seção descreve todas as ferramentas e recursos utilizados no pro-
cesso de desenvolvimento do raytracer segundo a metodologia descrita na
seção 3.2.1 .
3.2.2.1 Ferramentas de desenvolvimento para os modelos de aplicação
Neste trabalho para a execução dos modelos de aplicação foi utilizada
a interface Eclipse CDT configurada para executar a biblioteca SystemC. A
figura 14 mostra o ambiente de desenvolvimento do modelo de aplicação.
Figura 14 – O ambiente de desenvolvimento do modelo de aplicação.
Um dos objetivos principais da linguagem SystemC é possibilitar a mode-
lagem de sistemas em um nível de abstração acima das descrições RTL, in-
cluindo sistemas que podem ser desenvolvidos em hardware, software ou uma
combinação dessas abordagens. A camada de base do SystemC proporciona
um kernel de simulação orientado a eventos. Com ele é possível realizar ope-
rações com eventos e processá-las de maneira abstrata, sem conhecer o que
os eventos realmente representam ou o que os processos fazem. Isto é bem
45
interessante para proporcionar uma linguagem de projeto de sistemas diante
de uma ampla variedade de modelos de computação e comunicação.
Outros elementos do SystemC incluem módulos e portas para representar
informações estruturais, interfaces e canais que podem ser utilizados em abs-
trações para a comunicação. O kernel e estes elementos abstratos compõem
a linguagem núcleo. No topo desta linguagem é possível adicionar modelos
mais específicos de computação, bibliotecas e metodologias de projetos que
são úteis para o projeto de sistemas.
Figura 15 – Arquitetura da linguagem SystemC. Adaptado de (GROTKER, 2002)
A figura 15 expõe as diferentes camadas do systemC. A camada de base
mostra que SystemC é construída inteiramente em C++. Isto significa que um
programa escrito em SystemC pode ser executado por meio de um compila-
dor C++. Junto com a linguagem de núcleo, há os tipos de dados que são
úteis para a modelagem de hardware e para certos tipos de programação em
software (como os tipos em ponto fixo). Os canais primários da camada su-
perior incluem modelos que são amplamente utilizados como sinais, timers
e buffers FIFO. As camadas do topo não fazem parte do SystemC padrão,
contudo pode-se escolher usá-los ou mesmo desenvolver componentes para
46
novos modelos computacionais.
3.2.2.2 Plataforma de desenvolvimento
Para o desenvolvimento da arquitetura foi utilizada a plataforma de desen-
volvimento ML507 (figura 16), da Xilinx. Essa placa é construída ao redor da
FPGA Virtex-5 XC5VFX70T e possui uma série de periféricos, dentre os quais
destacam-se (XILINX, 2011b):
• Memória DDR2 SODIMM de 256 MB;
• Memória flash de 32 MB;
• SRAM de 9 MB com barramento de dados de 32 bits e 4 bits de paridade;
• Saída de vídeo DVI, e adaptador para VGA incluso;
• Conector DB9 para porta serial RS232;
• Interface JTAG;
• LEDs, botões e switches para debug.
A Xilinx também fornece as ferramentas de software para utilização da
placa, notadamente o Embedded Development Kit, parte da suíte de desen-
volvimento ISE, que contém diversos IPs para a utilização dos periféricos dis-
poníveis.
3.2.2.3 Ferramentas de desenvolvimento para os modelos de arquite-tura
A linguagem SystemVerilog foi utilizada para o desenvolvimento dos mo-
delos de arquitetura (notadamente o coprocessador) e seu uso justifica-se em
sua praticidade. Trata-se de uma extensão da linguagem Verilog a qual busca
47
Figura 16 – Plataforma de desenvolvimento ML507 da Xilinx
maior produtividade no projeto de grandes chips com um elevado número de
portas e de IPs. Uma grande vantagem desta linguagem é seu maior grau de
abstração que permite uma transição mais suave na concepção dos modelos
de arquitetura a partir dos modelos de aplicação.
SystemVerilog (SYSTEMVERILOG, 2011) é capaz de suportar a modelagem
e verificação no nível de abstração de transação. Ela permite a invocação
direta de funções em C/C++ e é a primeira linguagem baseada em Verilog que
permite uma cossimulação eficiente entre blocos em SystemC. Isto é muito
interessante para estabelecer ligações entre o design em uma abstração de
sistema para uma implementação em hardware.
A linguagem também é dotada de um conjunto de extensões que atendem
requisitos avançados de projeto. Alguns exemplos são a modelagem de inter-
faces que permitem maior produtividade no desenvolvimento de projetos nos
quais o uso dos barramentos é intensivo; o fim das restrições no número de
conexões nas portas dos módulos, permitindo qualquer tipo de dado em cada
lado da porta; tipos de dados estendidos que permitem modelagem similar
48
aos tipos de dados do C (estruturas, por exemplo) e melhorias na proteção
das IPs. As melhorias no suporte a verificação dos módulos são bastantes
significativas. Novas metodologias permitem o aumento da precisão nos tes-
tes, simplificam as bancadas e facilitam o reúso de código, diminuindo drasti-
camente o tempo dispendido na eliminação de erros.
SystemVerilog também possui novas características para suportar mode-
los de hardware e bancadas de testes que utilizam técnicas de orientação a
objeto que são inteiramente reutilizáveis. A combinação de um método de
interface em SystemVerilog com as técnicas de criação de uma bancada de
testes orientada a objeto permite o desenvolvimento simplificado de metodo-
logias de testes baseadas em requisitos exigentes de projeto.
Para a descrição dos modelos de arquitetura em SystemVerilog e a sua
posterior simulação e verificação utiliza-se a ferramenta ActiveHDL. A ferra-
menta possui um ambiente gráfico para o desenvolvimento em HDLs permi-
tindo testes integrados de diversos módulos com uma relativa flexibilidade. Ela
suporta FPGAs dos principais fabricantes, incluindo a plataforma Xilinx que é
empregada neste trabalho (ALDEC, 2011). A figura 17 ilustra a interface do
ActiveHDL.
Após a especificação de todos os módulos do coprocessador utilizando
SystemVerilog, incia-se o processo de síntese. Neste passo, as representa-
ções e descrições dos módulos são convertidas em representações geométri-
cas as quais serão dispostas fisicamente dentro da FPGA. Na síntese leva-se
em conta as propriedades da plataforma de desenvolvimento utilizada, as cé-
lulas padrão, as regras de disposição das células e suas limitações temporais
e é o primeiro passo da transformação de uma descrição em hardware de
nível abstrato em um dispositivo físico. Todas as informações, regras e limita-
ções da FPGA na qual uma descrição em hardware será sintetizada estão em
49
Figura 17 – O ambiente de desenvolvimento e de simulação em SystemVerilog do modelo dearquitetura.
bibliotecas disponibilizadas pelo fabricante.
Para a síntese a ferramenta Synplify Premier with Design Planner é em-
pregada. Segundo (SYNOPSYS, 2011) tal ferramenta é o ambiente de verifi-
cação e desenvolvimento em FPGAs mais produtivo no meio industrial. Além
disso, inclui um conjunto de ferramentas de síntese compreensivo, de alta ve-
locidade, com correlação temporal precisa, previsão de consumo e tecnologia
de otimização. A figura 18 ilustra a interface do Synplify Premier.
Após a síntese é necessário executar o posicionamento e interligação de
células. No projeto de hardware usando FPGA, esta etapa geralmente não é
feita por uma pessoa pois geralmente usa-se uma ferramenta disponibilizada
pelo fabricante da FPGA ou outro fabricante de software. A necessidade de
um software é estimulada pela complexidade interna de uma FPGA e pelas
características do projeto a ser inserido neste dispositivo. O primeiro passo, o
posicionamento, envolve decidir em quais partes da FPGA que serão coloca-
dos os subcomponentes eletrônicos e dispositivos lógicos. Após isso, segue-
se a fase de interligação (roteamento) na qual é decidido a maneira como
50
Figura 18 – O ambiente de síntese
todos estes dispositivos serão interligados, levando-se em conta as regras e
as limitações do dispositivo em geral especificadas no software responsável
por esta etapa. Neste projeto o posicionamento e interligação de células foi
feito por meio do ISE Design Suite disponível para a plataforma de desenvol-
vimento da Xilinx empregada na síntese dos modelos de arquitetura (seção
3.2.4). A figura 19 ilustra a interface do ISE Design Suite da Xilinx.
Figura 19 – Interface do ISE Design Suite, software utilizado para o posicionamento einterligação de células.
51
3.2.3 Particionamento em hardware e software
O particionamento entre hardware e software levou em conta a frequência
das operações que ocorrem no processo de geração de uma imagem em 3D.
O processo inicia-se com a leitura dos arquivos de entrada especificados na
seção 3.1.4 a partir de um disco rígido de um PC e o envio destes dados para
a plataforma de desenvolvimento ML507 por meio da porta serial. Estes dados
são armazenados na memória DDR2. Após a transferência dos dados, incia-
se o trabalho do processador, responsável pela execução de um software que
indexará os triângulos enviados pela porta serial por meio da construção de
uma árvore k -d.
Após a construção da árvore k -d, inicia-se o trabalho dos coprocessado-
res, descritos em hardware, os quais executam o algoritmo de ray tracing,
calculando as reflexões e refrações dos raios de luz no conjunto de triângulos.
A partir destas reflexões e refrações, pode-se calcular a intensidade luminosa
(seção 2.2.3) em um ponto da janela de observação (seção 3.1.1), o que tam-
bém é feito em hardware. No fim de todo o processo, utilizando a interface
disponível na plataforma de desenvolvimento ML507, é possível exibir a ima-
gem 3D gerada pelo algoritmo.
Para cada imagem gerada, é necessária a construção de uma árvore de
indexação espacial antes da execução do algoritmo de ray tracing. Dessa
forma não haverá sobrecarga de nenhum barramento presente o que viabiliza
tal divisão. A divisão permitirá uma implementação mais facilitada sem pre-
judicar as vantagens de se possuir um hardware dedicado para a execução
do algoritmo de ray tracing, justificando sua construção por meio do software.
Além disso, poupa-se superfície em hardware a qual pode ser usada para es-
pecificar outros fenômenos ópticos, por exemplo. A lista a seguir e a figura 20
52
resumem o particionamento em hardware e software de todas as atividades
envolvidas na geração de uma imagem em 3D usando ray tracing:
• Entrada e construção da árvore de indexação espacial - software;
• Interseção, reflexões e refrações - hardware;
• Cálculo da intensidade luminosa - hardware;
• Saída dos dados - hardware (utilizando recursos disponíveis na plata-
forma embarcada).
Figura 20 – Fluxograma do particionamento em hardware e software do raytracer
Uma vez o sistema base definido, foi possível a adaptação dos modelos
de aplicação para seu uso como software embarcado. Tal implementação
iniciou-se com a adaptação do port do sistema operacional FreeRTOS para a
versão 13.1 da ferramenta de desenvolvimento da Xilinx, que modificava em
53
alguns pontos a API utilizada. Após modificações nas camadas de abstra-
ção do hardware, o sistema pôde ser executado com sucesso na FPGA. Em
seguida, tendo em vista o particionamento software/hardware, modificou-se o
software em SystemC para a execução no sistema embarcado. Visto que não
foi possível compilar toda a biblioteca SystemC para a plataforma PPC440,
confeccionou-se uma biblioteca C++ que implementasse os tipos de dados
necessários ao correto funcionamento do software existente (notadamente os
números em ponto fixo).
3.2.4 Especificação e dimensionamento da arquitetura
A partir do desenvolvimento dos modelos de aplicação (seções 3.2.1 e
3.2.2.1) é possível especificar e dimensionar a arquitetura do projeto, que será
discutida nessa seção.
3.2.4.1 Visão geral
De uma maneira geral e simplificada, a arquitetura de hardware do sistema
h3dge é a exposta na figura 21.
Figura 21 – Arquitetura simplificada do sistema h3dge
54
Conforme discutido na seção (3.2.3), cada um dos componentes do sis-
tema tem uma função bem determinada, a saber:
• O processador é responsável pela indexação espacial e o coprocessa-
dor é responsável pelo algoritmo de ray tracing e pelo cálculo da intensi-
dade luminosa;
• O controlador de memória oferece acesso à memória DDR2 presente
na placa de desenvolvimento;
• O controlador UART fornece uma interface de comunicação serial com
um PC;
• O controlador de vídeo possibilita a saída da imagem gerada em uma
interface DVI;
• E todos os componentes se comunicam por meio de vias de dados
internas.
As próximas seções detalham o funcionamento da parte majoritária dos
elementos dessa estrutura.
3.2.4.2 Processador
Inicialmente, foi proposta a utilização do processador PicoBlaze para co-
mandar as atividades do circuito. O PicoBlaze é um soft core altamente otimi-
zado para as FPGAs da Xilinx, que permite sintetizar em um pequeno número
de slices uma unidade de processamento funcional e flexível. Suas principais
características são (CHU, 2008):
• Palavra de dados de 8 bits;
55
• 16 registradores de 8 bits;
• Memória de dados de 64 bytes;
• Instruções de 18 bits de largura;
• Endereços de instrução de 10 bits de largura, suportando um programa
de até 1024 instruções;
• 256 portas de entrada e 256 portas de saída;
• 2 ciclos de relógio por instrução;
• 5 ciclos de relógio para tratamento de uma interrupção.
O PicoBlaze é uma boa alternativa para executar programas que fazem
essencialmente E/S. Entretanto, após estudo aprofundado de suas caracte-
rísticas, é possível perceber que ele não é apropriado às necessidades de
processamento do h3dge, pelas seguintes razões:
• O algoritmo de criação da árvore k -d será executado em software, visto
que essa etapa do processo não pode ser paralelizada. Como o Pi-
coBlaze só pode ser programado em linguagem assembly, a escrita do
algoritmo seria dificultada;
• Mesmo se a decisão de implementar o algoritmo em assembly fosse
tomada, a realização seria trabalhosa, visto o tamanho dos registradores
e da unidade lógica e aritmética (ULA) - uma operação de adição de dois
números de 32 bits necessitaria da metade dos registradores;
• Mesmo se o algoritmo fosse implementado com sucesso, ele dificilmente
caberia na memória de programa de 1024 instruções;
56
• O PicoBlaze não tem um controlador de memória externa embutido. As-
sim, seria necessário adicioná-lo como uma IP, e escrever o driver para
utilizá-lo - driver este que, por sua vez, ocuparia espaço na já escassa
memória de programa.
Tendo em vista essas limitações, optou-se pelo uso do core PowerPC 440
embutido na FPGA. Tal processador possui funcionalidades muito mais favo-
ráveis às necessidades deste projeto, tais como (XILINX, 2010a):
• Arquitetura RISC 32 bits;
• 32 registradores de 32 bits;
• Caches de instrução e de dados de 32 KB cada;
• Interfaces PLB (Processor Local Bus) para conexão de processadores
adicionais;
• Interface JTAG;
• Suporte à programação em C/C++ via gcc.
Além das funcionalidades superiores, um outro argumento a favor da utili-
zação desse core é seu "custo zero", visto que o bloco está presente em silício
(sua utilização não necessita de slices adicionais).
3.2.4.3 Coprocessador
Conforme dito na seção 3.2.3 o coprocessador engloba todas as funções
necessárias para o cálculo em ponto fixo e pela execução do algoritmo de ray
tracing. Esta seção dedica-se a especificar a arquitetura do coprocessador.
57
O primeiro passo no projeto do coprocessador consistiu no desenvolvi-
mento de uma estimativa do tamanho de sua memória por meio da implemen-
tação dos modelos de aplicação (seção 3.2.1). O propósito da memória do
coprocessador é acelerar o processo de cálculo dos raios refletidos e refrata-
dos, evitando-se um número exagerado de requisições à memória DDR2 para
conseguir os dados necessários para tais cálculos.
A partir da especificação das estruturas de dados necessárias para o al-
goritmo de ray tracing, foi possível calcular o tamanho dos tipos de dados rela-
cionados com o funcionamento do coprocessador. Estes cálculos detalhados
encontram-se no apêndice A.
Após estes primeiros cálculos, estipulou-se que a quantidade máxima de
triângulos que podem ser referenciados por um único nó folha de uma árvore
k -d é 1024. Em outras palavras, convencionou-se que um pacote de triângulos
pode no máximo possuir 1024 elementos; um pouco mais que 1% da quantia
máxima de triângulos que pode ser armazenada. Tal número mostrou-se sa-
tisfatório para todos os testes realizados na plataforma de desenvolvimento.
Caso o número de triângulos seja maior que o estipulado, uma nova requisi-
ção à memória deve ser feita para para carregar os próximos 1024 triângu-
los. Cabe destacar que, embora seja possível, é improvável que exista um
nó folha com mais que 1024 triângulos, pois o propósito de uma árvore k -d é
justamente dividir os triângulos entre seus nós folhas para diminuir o número
de objetos com os quais o teste de interseção será feito. No caso de imagens
com um número muito alto de triângulos, será necessário aumentar a quantia
máxima de triângulos que podem estar referenciados em um nó folha.
Além disso, estimou-se a quantidade de espaço necessária para arma-
zenar um conjunto de raios refletidos e refratados, considerando um número
máximo de reflexões de cada raio igual a cinco (seção 3.1.2). Como cada raio
58
pode refletir-se e, se possível, refratar-se então, no caso em que a quantidade
de raios é máxima, há a possibilidade de obtenção de um conjunto de raios or-
ganizados em uma estrutura similar a uma árvore binária de busca na qual os
filhos à esquerda são os raios gerados após uma reflexão e os filhos a direita
são os raios gerados após uma refração. O tamanho máximo desta árvore é
dado por uma árvore binária de busca balanceada de altura cinco cujo cálculo
está disponível no apêndice A. Deve-se ressaltar que o número máximo de
materiais, meios e luzes é igual a dezesseis conforme já discutido na seção
3.1.2.
A lista a seguir enumera todos as estruturas que serão armazenadas na
memória do coprocessador e seu respectivo tamanho, de acordo com os cál-
culos disponíveis no apêndice A:
• nó da árvore em processamento - 56 bytes;
• vetor para 1024 triângulos - 49152 bytes;
• vetor para os materiais - 320 bytes;
• vetor para as luzes - 384 bytes;
• vetor para os meios - 64 bytes;
• variável para a cor do pixel - 12 bytes;
• tamanho da pilha a qual armazena os raios refletidos e refratados - 4032
bytes;
A partir dos dados anteriores conclui-se que o tamanho da memória do
coprocessador é de 52.76 kbytes. Após o dimensionamento da memória,
elaborou-se para o processador a arquitetura descrita na figura 22.
59
Figura 22 – Arquitetura do coprocessador
O bloco de Direct Memory Access (DMA) é composto por uma interface
disponível na plataforma de desenvolvimento com a qual é possível acessar
a memória DDR2 externa e assim carregar os dados necessários para o fun-
cionamento do coprocessador em sua memória local. A unidade de cálculo
em ponto fixo concentra as rotinas matemáticas para os cálculos executados
pelo algoritmo de ray tracing. O módulo responsável pela execução do algo-
ritmo contém as descrições dos fenômenos ópticos de reflexão e refração e
as estruturas para o preparo da execução destas descrições.
Cabe ressaltar que devido a restrições temporais (prazo de entrega) e às
dificuldades envolvidas na execução deste projeto (seção 5.2), não foi possível
descrever em hardware a arquitetura supracitada. Após uma série de simpli-
ficações, decidiu-se descrever em hardware a operação de interseção de um
raio com um triângulo, pois trata-se de uma operação frequente no algoritmo
60
e que proporciona ganho de desempenho se descrita em hardware. Os cálcu-
los empregados na interseção são descritos na seção 2.1.2 e a arquitetura do
fluxo de dados descrito em hardware é ilustrada na figura 23.
Figura 23 – Fluxo de dados do módulo de interseção de um raio com um triângulo.
A unidade de controle deste módulo possui quatro estados. No primeiro
calcula-se o determinante, o qual é necessário para o cálculo dos parâmetros
u e v, respectivamente obtidos no segundo e terceiro estados. Após isso é
possível calcular, no quarto estado, o resultado t e obter o ponto de interseção
61
por meio da equação R(t) = O + t. ~D (seção 2.1.2).
3.2.4.4 Vias de dados
Embora a arquitetura exposta na figura 21 seja adequada para um enten-
dimento global do funcionamento do hardware, ela não é exata do ponto de
vista das vias de dados. Isso porque o bus de interconexão nela indicado é na
verdade implementado por duas vias de dados organizados em uma estrutura
hierárquica: a crossbar e um bus PLB v4.6.
A crossbar é uma via de dados extremamente simples, localizada no inte-
rior do bloco de processamento no qual encontra-se o processador PowerPC
440. Como pode-se observar na figura 24, ela, representada por um “X”, age
como unidade central de arbitragem entre todos os elementos mestres e es-
cravos do bloco, funcionando basicamente como um switch.
Embedded Processor Block Reference Guide www.xilinx.com 29UG200 (v1.8) February 24, 2010
R
Chapter 2
Embedded Processor Block Overview
The embedded processor block in Virtex-5 FXT devices contains several additional modules along with the PowerPC 440 processor. These additional modules allow system designers to improve the performance and reduce the cost of their designs. This chapter provides an overview of the embedded processor block in Virtex-5 FPGAs and briefly describes each of the additional modules and interfaces.
Embedded Processor Block ComponentsThe main components of the embedded processor block in Virtex-5 FXT FPGAs are the processor, the crossbar and its interfaces, the Auxiliary Processing Unit (APU) controller, and the control (clock and reset) module. Figure 2-1 shows the embedded processor block and its components.
The processor is described in detail in Chapter 1, “PowerPC 440 Embedded Processor.” The processor has three PLB interfaces: one for instruction reads, one for data reads, and one for data writes. Typically, all three interfaces access a single large external memory. Peripheral access in PowerPC 440 systems is memory mapped, and the data PLB interfaces typically connect to various peripherals directly or via bridges. Some of these peripherals
Figure 2-1: Embedded Processor Block in Virtex-5 FPGAs
Virtex-5 FXT PlatformEmbedded Processor Block
PowerPC 440Processor
ICURDAPUControl
FCMInterface
LocalLink0
LocalLink1
LocalLink2
LocalLink3
SPLB0
SPLB1
MPLB
MemoryControllerInterface
ControlInterface
DCRInterface
DMA
DMA
DMA
DMA
CPM/Control
DCR
DCURD
DCUWR
UG200_c2_01_010708
Figura 24 – Estrutura interna do bloco de processamento das FPGAs Virtex-5. Extraído de(XILINX, 2010a).
A crossbar localiza-se entre as cinco interfaces escravas do bloco de
62
processamento (três vindo diretamente do processador e duas, SPLB01 e
SPLB12, fazendo a conexão com um bus PLB externo) e as duas interfaces
mestras (MPLB3, ligada ao bus PLB externo, e MCI4, conectada ao controlador
de memória). Somente comunicações entre mestre e escravo, e vice-versa,
são permitidas; assim, não é possível enviar dados de um periférico conec-
tado à interface SPLB0 a um outro presente na interface SPLB1.
As principais funcionalidades da crossbar são:
• Pipeline de até 5 transações para as interfaces MPLB e MCI;
• Transmissões em ciclo único ou em modo burst ;
• Arbitragem independente para MPLB e MCI;
• Fases de arbitragem e de dados independentes;
• Suporte a palavras de 128, 64 ou 32 bits;
• Espaço de endereçamento de 64 Gb (34 bits de endereço), a ser dividido
entre os dispositivos escravos.
Tipicamente, a crossbar funciona a uma frequência mais alta que a do bus
externo e dos escravos/mestres sintetizados na FPGA, e um mecanismo de
prioridades round-robin é utilizado para a arbitragem. A descrição em detalhes
do funcionamento dessa via de dados está além do escopo deste trabalho;
para mais detalhes, aconselha-se a leitura de (XILINX, 2010a).
O Processor Local Bus (PLB), por sua vez, é a via de dados utilizada para
a conexão do bloco de processamento com os periféricos. Trata-se de um bus1Slave PLB 02Slave PLB 13Master PLB4Memory Controller Interface
63
padronizado, parte da arquitetura CoreConect proposta pela IBM para vias de
dados em Systems-on-Chip (SoC).
DS531 September 21, 2010 www.xilinx.com 2Product Specification
LogiCORE IP Processor Local Bus (PLB) v4.6 (v1.05a)
Functional DescriptionThe Xilinx PLB consists of a central bus arbiter, the necessary bus control and gating logic, and all necessary busOR/MUX structures. The Xilinx PLB provides the entire PLB bus structure and allows for direct connection with aconfiguration number of masters and slaves. Figure 1 provides an example of the PLB connections for a system withthree masters and three slaves.
Basic Operation
The Xilinx PLB has three-cycle arbitration during the address phase of the transaction as shown in Figure 2. Thereis a two-cycle delay from Mn_request to PLB_PAValid. If the slave can respond combinatorially in the samecycle—the optimistic assumption shown and theoretically possible for a write transaction—the whole transactiontakes three cycles.
The two-cycle delay from Mn_request to PLB_PAValid holds for the case where there are two or more attachedmasters and allows one cycle for a priority arbitration to occur and one cycle to route the selected master’stransaction data and qualifiers to the slaves. If there is a single master, arbitration is not necessary and transactiondata and qualifiers can be driven to the slaves without multiplexing. This allows PLB_PAValid to be driven afterone clock, saving a cycle of latency.
X-Ref Target - Figure 1
Figure 1: PLB Interconnect Diagram
Central Bus Arbiter
PLB Masters PLB Core PLB Slaves
R ead Data B u s
S t a t us & C o nt r o l
Bu s Co n t r o l & Gat i ng Log i c
Re a d Da ta Bu s
S t a t us & C ont rol
DS531_01_061608
Shared Bus
Arbitration
Address and Transfer Qualifiers
Write Data Bus
Control
Address and Transfer Qualifiers
Write Data Bus
Control
Figura 25 – Arquitetura do bus PLB v4.6. Extraído de (XILINX, 2010b).
A estrutura de uma via de dados PLB v4.6, conforme ilustrado na figura 25,
consiste em uma unidade de arbitragem centralizada e toda a lógica necessá-
ria para o controle da via compartilhada. A implementação utilizada, descrita
em (XILINX, 2010b), possibilita a conexão de até 16 mestres e escravos, e
possui como funções principais:
• Árbitro com número configurável de mestres;
• Suporte a palavras de 128, 64 e 32 bits para mestres e escravos;
• Pipeline de endereçamento;
• Quatro níveis de prioridade para os mestres;
64
• Esquema de prioridades configurável (round-robin ou prioridades fixas);
• Temporizador watchdog;
• Circuito de reset dedicado.
3.2.4.5 Controlador de vídeo
O controlador de vídeo utilizado foi o XPS Thin Film Transistor (TFT) Con-
troller (XILINX, 2009). Esse controlador é uma IP capaz de exibir até 256 mil
cores em uma resolução de 640 por 480 pixels. A saída pode ser feita via uma
uma interface VGA ou DVI, mas visto que no kit de desenvolvimento utilizado
há somente uma porta DVI, a opção VGA não foi utilizada5.
De um ponto de vista pragmático, o XPS TFT Controller exibe em um moni-
tor o conteúdo de um frame buffer armazenado em memória. Tal buffer deve
estar organizado em 1024 colunas e 512 linhas de pixels de 32 bits (totali-
zando 2 MB), das quais somente as primeiras 640 colunas e 480 linhas serão
realmente exibidas na tela. Como usual, cada pixel é uma composição de três
cores: vermelho, verde e azul; cada cor tem um valor de 6 bits, e o pixel é
organizado como mostrado na tabela 1 (bits em ordem big endian).
Tabela 1 – Organização de um pixel na memória. Adaptado de (XILINX, 2009).
Bits Descrição
[31 : 24] Não definido[23 : 18] Vermelho: 0b000000 (mais escuro)→ 0b111111 (mais claro)[17 : 16] Não definido[15 : 10] Verde: 0b000000 (mais escuro)→ 0b111111 (mais claro)[9 : 8] Não definido[7 : 2] Azul: 0b000000 (mais escuro)→ 0b111111 (mais claro)[1 : 0] Não definido
O Embedded Development Kit (EDK) fornece ainda uma API para a utili-
zação dessa IP em software. Por meio dessa biblioteca, é possível configurar5Entretanto, o mesmo kit inclui um adaptador DVI-VGA para paliar essa limitação.
65
e iniciar facilmente o periférico, efetuar algumas operações de renderização
básicas (e.g. limpar tela, desenhar um retângulo preenchido com uma cor),
assim como escrever alguns caracteres na tela usando as funções básicas de
renderização de texto inclusas.
3.2.4.6 Dimensionamento da memória DDR2 externa
As principais estruturas que são armazenadas na memória externa e que
ocupam uma quantia significativa de espaço são a lista de triângulos e a árvore
k -d. Esta seção mostra a metodologia adotada para estimar o tamanho da
memoria necessária para executar o algoritmo de ray tracing do h3dge.
No projeto considera-se um máximo de 70000 triângulos os quais são su-
ficientes para executar o h3dge com as duas imagens testes utilizadas (seção
4.1) e para construir árvores k -d com um tamanho razoável, o que garante a
estabilidade do sistema. Maiores árvores geram cenários mais específicos de
divisão de planos e de interseção de triângulos, os quais são muito interessan-
tes para encontrar possíveis erros no código. Outro aspecto importante a ser
ressaltado é que a árvore k -d possui profundidade máxima igual a dezesseis.
A profundidade máxima é necessária para se evitar árvores muito profundas
as quais diminuem drasticamente o rendimento da indexação espacial (para
maiores informações consultar as seções 3.1.3 e 4.2).
Além disso, deve-se ressaltar que na árvore k -d as referências dos triân-
gulos indexados em cada pacote são alocadas apenas nos nós folha por meio
de listas ligadas. Dessa forma, para poupar espaço em disco, é interessante
que as listas ligadas sejam compostas por referências (ou ponteiros) para os
triângulos alocados inicialmente em outro intervalo da memória, evitando-se
repetições desnecessárias de triângulos nos nós da árvore. O espaço alo-
cado na memória para as referências deve ser suficiente para alocar mais que
66
70000 triângulos, pois no momento da divisão de uma região do espaço, o
plano frequentemente cruza alguns triângulos. Inicialmente adotou-se alocar
espaço suficiente para alocar 140000 referências de triângulos, ilustrando o
caso no qual o plano intercepta todos os triângulos que devem ser repetidos
em ambos os lados dos filhos originados pelo plano divisor. Esta abordagem
funciona para figuras menores e mais simples, contudo, para figuras mais
complexas são necessárias 280000 referências de triângulos para referenciá-
los de maneira segura (sem estouros) na árvore k -d. O aumento do número de
referências decorre justamente do fato da imagem ser mais complexa, o que
aumenta os casos de triângulos interceptados pelo plano divisor nos vários
níveis da árvore.
A partir de todas estas considerações tornou-se possível estimar o espaço
em memória ocupado pelos triângulos, pela árvore k -d e pelas listas ligadas
de referências de triângulos alocadas em seus nós folhas. O total de espaço
em memória necessário é de 12.34 Megabytes. Para maiores detalhes sobre
os cálculos realizados, consultar o apêndice B.
3.2.4.7 Considerações a respeito do número de coprocessadores emparalelo
O número de coprocessadores depende diretamente da capacidade do
barramento de transferência de dados entre a memória e a FPGA. Os ganhos
de desempenho na execução paralela existem até o momento em que o barra-
mento atinge sua capacidade máxima de transferência de dados. Após esse
momento, a adição de novos coprocessadores torna-se inadequada, pois a la-
tência para o acesso ao barramento crescerá de tal forma que anulará os ga-
nhos de performance obtidos com a maior capacidade de coprocessamento.
No momento em que um coprocessador está acessando a memória, outro
67
coprocessador pode estar calculando a intensidade luminosa de seu respec-
tivo ponto. A situação limite ocorre quando a frequência conjunta dos acessos
à memória de todos os processadores se iguala à capacidade do barramento
de acesso à memória. É importante ressaltar que no projeto há o controlador
de vídeo que também utiliza o barramento para acessar a memória, logo seu
uso também deve ser considerado para a estimativa de quantos coprocessa-
dores podem ser acoplados ao barramento. De acordo com (XILINX, 2009), a
frequência dos acessos a memória do controlador de vídeo é de 25MHz e, de
acordo com (XILINX, 2010a), o barramento PLB funciona a 100MHz, portanto
sobram 75MHz para os coprocessadores acessarem a memória.
Segundo (XILINX, 2011a), o clock de funcionamento da memoria DDR2 da
plataforma de desenvolvimento é de 267MHz e seu tempo de latência (latência
CAS) é de cinco ciclos de relógio (XILINX, 2010c). Dessa forma, o tempo de
resposta da memória é de 53MHz, sendo menor que os 75MHz resultantes da
atuação do controlador de vídeo. Assim conclui-se que são necessários dois
ciclos de relógio do barramento para ler um dado da memória.
Após a síntese do módulo de execução do algoritmo de ray tracing, foi pos-
sível obter sua análise temporal e seu ciclo de máquina que é de 210ns, logo
sua frequência é de 4.5MHz. Assim conclui-se que são necessários 23 ciclos
de clock para calcular um raio refletido e, se existir, um raio refratado. Para
que estes raios sejam calculados, é necessário saber quais são os triângulos
contidos dentro da sub-região na qual o raio está imerso, logo necessitam-se
de acessos à memória. A execução do cálculo de um raio leva dez vezes mais
vezes que a de um acesso a memória, assim nota-se que o o barramento
PLB não estará muito ocupado durante o cálculo dos fenômenos ópticos ne-
cessários para determinar as intensidades luminosas nos pontos da janela de
observação, o que abre espaço para o paralelismo.
68
Nota-se que o grau de paralelismo depende da quantidade média de tri-
ângulos por pacote pois, para conseguir cada triângulo, é necessário acessar
a memória. Se houver até 10 triângulos por nó folha da árvore k -d, o copro-
cessador não precisará esperar pelo barramento para obter os dados neces-
sários para os cálculos de interseção. Desta forma, o paralelismo é possível
para figuras pouco complexas e se resume a 2 processadores por conta da
limitação do barramento único e da latência da memória. Para acelerar o pro-
cesso, podem ser utilizado outros barramentos e módulos para DMA e assim
possibilitar o acesso a memória com mais frequência. Neste trabalho não foi
possível devido a limitação do barramento único disponível na plataforma de
desenvolvmento da Xilinx.
69
4 RESULTADOS
Este capítulo dedica-se ao detalhamento de todos os resultados consegui-
dos na elaboração do projeto do raytracer h3dge. Na primeira seção exibe-se
as imagens geradas a partir da execução do algoritmo. Após isso, inicia-se o
detalhamento de como as árvores de indexação espacial melhoram a execu-
ção do algoritmo por meio da drástica redução dos testes de interseção entre
um raio e um triângulo. Enfim, são apresentados os resultados obtidos por
meio da sintetização da arquitetura proposta em hardware.
4.1 Imagens geradas
As imagens geradas pelo algoritmo de ray tracing do h3dge foram três:
• A primeira delas é o poliedro (figura 26), o qual contém oitenta faces.
• A segunda e terceira imagens são do célebre Stanford bunny, composto
por setenta mil triângulos. A seguir há duas imagens do coelho: a pri-
meira (figura 27) com a visão frontal e a segunda (figura 28) com a visão
traseira, respectivamente.
70
Figura 26 – O poliedro, uma das figuras geradas pelo algoritmo de ray tracing utilizado noh3dge. Nota-se os efeitos de transparência causados pela refração dos raios de luz.
Figura 27 – Stanford bunny, uma das figuras geradas pelo algoritmo de ray tracing utilizadono h3dge: visão frontal.
71
Figura 28 – Stanford bunny, uma das figuras geradas pelo algoritmo de ray tracing utilizadono h3dge: visão traseira.
4.2 Melhoria de desempenho causada pelo usode uma árvore k -d
Para verificar a influência da árvore k-d no desempenho do sistema, foi
executado um experimento em software. Tal experimento consistiu em variar
a altura máxima permitida à arvore (que pode ser diferente da altura real, visto
que a construção da árvore pode parar antes da atingir a altura máxima se o
custo de divisão dos nós aumentar demasiadamente) e verificar o tempo de
execução do algoritmo de ray tracing. Os resultados obtidos para o poliedro
(figura 26) são apresentados na tabela 2 e na figura 29.
A interpretação desses resultados mostra que a SAH, apesar de levar a ár-
vores k-d de qualidade, não garante o menor tempo de execução global. Isso
porque ela só visa a minimizar o tempo gasto percorrendo a árvore e o pa-
cote de triângulos, e não o tempo de construção da árvore; assim, vemos que
uma árvore k-d de altura máxima 5 tem performance superior à uma árvore
de altura máxima 16.
72
Tabela 2 – Influência da árvore k-d no desempenho
Altura máxima da árvore k-d Tempo de execução (s)
0 13,9851 11,2572 8,2403 6,2414 5,7765 5,3476 5,5657 6,0898 6,3299 6,472
10 6,53811 6,57412 6,50113 6,52714 6,62015 6,54716 6,588
5
6
7
8
9
10
11
12
13
14
15
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Tem
po d
e ex
ecuç
ão (s
)!
Altura máxima da árvore k-d!
Figura 29 – Influência da árvore k-d no desempenho
73
Mesmo com essa limitação, vemos que o uso da árvore k-d permite a
obtenção de ganhos de performance significativos. Com uma árvore de altura
3 o ganho ultrapassa 55%, e no melhor caso temos um ganho de mais de
61%. Assim, a validade desse método para a aceleração do algoritmo de ray
tracing fica atestada.
4.3 Resultados do sistema sintetizado em hard-ware
Esta seção discute os resultados obtidos na sintetização da arquitetura
proposta na seção 3.2.4 em hardware. Primeiramente são apresentados os
dados referentes ao sistema-base; em seguida, são detalhados os resultados
da sintetização do coprocessador.
4.3.1 Sistema base
O sistema base é constituído pelo processador, controlador de memória,
controlador UART, controlador de vídeo, bus PLB e outros periféricos essen-
ciais e de debug. Após a síntese, a ocupação da FPGA reportada pela ferra-
menta Xilinx Platform Studio é a apresentada na tabela 3.
Tabela 3 – Ocupação da FPGA para o sistema-base
Elemento Utilização (absoluta) Utilização (%)
Número de slices 4545 de 11200 40Número de registradores nas slices 7243 de 44800 16
Número usado como Flip Flop 7243Número usado como Latch 0Número usado como LatchThru 0
Número de LUTs nas slices 8151 de 44800 18Número de pares LUT-Flip Flop nas slices 10916 de 44800 24
Observando os dados de ocupação, podemos notar que o sistema-base
corresponde a uma grande parcela da área total da FPGA, tomando 40% dos
74
slices disponíveis. Tal ocupação poderia ser diminuída por meio da exclusão
dos componentes adicionados para facilitar a depuração, tais como botões e
LEDs.
Do ponto de vista de performance, o sistema satisfaz a todas as condições
para operar a 100 MHz, velocidade atribuída ao bus PLB — com a exceção
do controlador de vídeo, que funciona a 25 MHz. Para testar a velocidade
do sistema “puro”, sem a aceleração em hardware, foi executada a síntese
dos modelos da seção 4.1 somente em software, utilizando o algoritmo em
C++ com cálculos em ponto flutuante (acelerados graças à presença de uma
FPU). Os resultados desse experimento são exibidos na tabela 4.
Tabela 4 – Desempenho do algoritmo de ray tracing em software no sistema base
Modelo Tempo de execução
Poliedro 9min20sStanford bunny > 60min
4.3.2 Coprocessador
Esta seção dedica-se a mostrar os dados da síntese dos módulos imple-
mentados no coprocessador. A princípio tentou-se sintetizar os módulos de in-
terseção raio-triângulo, reflexão e refração de maneira combinatória utilizando
o comando assign do SistemVerilog. Apesar do ganho de velocidade que
seria obtido com tal estratégia, ela revelou-se inadequada, pois a superfície
ocupada seria de 916% das LUTs da FPGA do kit de desenvolvimento. Dessa
forma, foi necessário modificar esta implementação inicial visando à redução
da área ocupada.
A princípio alterou-se o módulo de interseção de um raio com um triângulo,
já que esta é uma operação bem frequente no algoritmo de ray tracing. Para a
redução da área ocupada foi adotada uma arquitetura de unidade de controle
75
e fluxo de dados, documentada na seção 3.2.4.3. Após a síntese utilizando o
ISE Project Navigator, os dados exibidos na tabela 5 foram obtidos.
Tabela 5 – Ocupação da FPGA para o módulo de interseção
Elemento Utilização (absoluta) Utilização (%)
Número de slices 2049 de 11200 18Número de registradores nas slices 572 de 44800 1
Número usado como Flip Flop 326Número usado como Latch 192Número usado como LatchThru 54
Número de LUTs nas slices 7457 de 44800 16Número de pares LUT-Flip Flop nas slices 7592 de 44800 16
A partir destes dados foi possível executar a síntese do módulo de inter-
seção em hardware conforme descrito na seção 3.2.4.3. Após isso tentou-se
sintetizar o módulo de cálculo da normal, abrindo caminho para a posterior
síntese dos módulos de reflexão e refração, adotando-se a estratégia de pro-
jeto composto por uma unidade de controle e por um fluxo de dados. Apesar
dos esforços para a redução de superfície, a síntese no Synplify mostrou que
os módulos de interseção e cálculo de normal ocupariam juntos 108% da área
da FPGA, impossibilitando o processo de posicionamento e interligação de
células.
É importante ressaltar que a redução de superfície ainda é possível, pois
na arquitetura testada para o módulo da normal havia três módulos de divisão
(os quais ocupam muita superfície em hardware) operando em paralelo. Pode-
se reduzir este número para um módulo, contudo isto adicionaria mais dois
estados para a unidade de controle o que demandaria mais tempo para que
o cálculo da normal fosse efetuado. A proximidade da data de entrega deste
projeto impossibilitou que o módulo de cálculo da normal fosse implementado
de uma maneira apropriada, logo sua execução será deixada neste trabalho
como uma atividade em aberto.
76
5 CONCLUSÕES
Os capítulos anteriores dedicaram-se cada um a introduzir os assuntos
abordados neste trabalho, ou a descrever uma parte específica de sua reali-
zação. Esta seção, por sua vez, discute os resultados globais do projeto, bem
como suas contribuições acadêmicas e suas perspectivas futuras.
5.1 Objetivos alcançados
Este trabalho teve como objetivo propor, implementar e testar uma arquite-
tura em hardware para a execução do algoritmo de ray tracing. Tal arquitetura
deveria, a partir de informações fornecidas por meio de um arquivo de en-
trada, gerar a imagem sintetizada correspondente e exibi-la em um terminal
de vídeo.
Nesse escopo, pode-se dizer que o projeto foi concluído com sucesso. A
partir do estudo aprofundado do algoritmo de ray tracing, foi proposta uma
arquitetura para sua realização em hardware, que evoluiu conforme o avanço
do projeto para se adequar a novos requisitos, impostos tanto pela própria
natureza do projeto (tempo e recursos disponíveis) quanto pela complexidade
do problema em si. Finalmente, como resultado desse processo, a descrição
em SystemVerilog de módulos de um coprocessador que pudesse executar
o algoritmo e um protótipo atendendo aos requisitos funcionais puderam ser
finalizados.
77
Entretanto, alguns pontos do projeto permanecem como objetivos para
projetos futuros; em especial, a integração entre o coprocessador e o sistema
base para a realização efetiva da aceleração em hardware. Outras perspecti-
vas futuras serão apresentadas na seção 5.4.
5.2 Dificuldades encontradas
Apesar dos êxitos, as dificuldades encontradas no decorrer do projeto fo-
ram numerosas. Tais dificuldades tiveram grande impacto sobre o cronograma
do projeto, limitando, às vezes severamente, o avanço dos trabalhos. Dentre
os principais obstáculos que surgiram, destacam-se:
• A dificuldade na depuração: a depuração de um algoritmo de ray tra-
cing é uma tarefa árdua. Embora a observação dos resultados não seja
difícil — a apresentação gráfica da saída, característica comum a pro-
jetos da área da computação gráfica, facilita a verificação do correto
funcionamento do algoritmo —, encontrar a origem de um defeito não
é trivial, principalmente se considerado que o algoritmo em alto nível foi
descrito em C++/SystemC. Muitas vezes foi necessário executar o pro-
grama passo a passo com um debugger, repetidamente, acompanhando
as mudanças em grande parte das variáveis, somente para encontrar a
causa de um erro em um único pixel. E em alguns casos, a interação
entre as várias partes do programa era tão complexa que a única solu-
ção viável era reescrever completamente as funções afetadas — durante
meses, por exemplo, tentou-se lidar com um “buraco” que se formava na
frente do poliedro (figura 26) sem sucesso, até que se decidiu pela rees-
crita do algoritmo de construção e percurso da árvore k-d1;1A causa de tal “buraco” era a forma como o percurso da árvore k-d era implementado.
Inicialmente, o algoritmo percorria a árvore sempre a partir da raiz, o que pode acarretar a
78
• Problemas com as ferramentas: a manipulação do ambiente de desen-
volvimento mostrou-se outra fonte de atrasos no cronograma. Primeira-
mente, a ferramenta de síntese da Xilinx surpreendeu negativamente
ao não suportar a linguagem SystemVerilog, que contudo era extre-
mamente necessária, haja vista a complexidade das estruturas de da-
dos envolvidas. Dessa forma, foi necessário optar por um arranjo mal-
coordenado de três ferramentas (Active-HDL, Synplify e Xilinx ISE) para
obter um suporte a essa linguagem (ainda que incompleto, visto que vá-
rias funcionalidades importantes, como as arrays de duas dimensões,
não estavam implementadas). Em segundo lugar, a documentação in-
cipiente fornecida com o Xilinx XPS, bem como os bugs inesperados e
a política de não suportar arquivos de versões anteriores da ferramenta,
apresentaram-se como um obstáculo à realização do sistema base —
uma tarefa que em princípio não deveria apresentar grandes dificulda-
des.
• As mudanças excessivas na arquitetura: embora a metodologia ado-
tada previsse uma evolução gradual dos requisitos e do particionamento
hardware-software do sistema, a presença dos problemas acima men-
cionados afetou negativamente a organização do projeto, visto que al-
gumas vezes foi necessário tomar decisões baseadas mais no crono-
grama que em critérios técnicos. Um exemplo desse tipo de situação
foi a tradução do código em SystemC para C++ visando à execução no
processador embarcado. Embora importante para acelerar o desenvol-
vimento do protótipo, ela acabou introduzindo ainda mais dificuldades,
visto que, uma vez que não era possível compilar a biblioteca para o am-
biente PowerPC utilizado, foi necessário reescrever uma boa parte do
código para realizar as operações em ponto fixo.
perda de pacotes de triângulos por conta de imprecisões nos cálculos.
79
5.3 Contribuições
A grande contribuição deste trabalho está na proposição de uma arquite-
tura completa para a execução do algoritmo de ray tracing em FPGAs, assim
como na realização do protótipo correspondente.
Focando-se na realização de um ray tracer embarcado, o projeto h3dge
se insere em uma categoria alternativa aos atuais esforços para a realização
de ray tracing em tempo real — notadamente a execução do algoritmo para-
lelizado em clusters com grande capacidade de processamento. Entretanto,
seus fundamentos, notadamente a otimização por meio de árvores k-d e a
paralelização dos cálculos por meio de processadores dedicados, podem ser
aproveitados em sistema de qualquer escala.
5.4 Trabalhos futuros
Ao mesmo tempo em que contribui ao esforço de desenvolvimento de ray
tracers mais rápidos e eficientes, este trabalho fornece muitos pontos para
evolução futura, dentre os quais destacam-se:
• Melhorar a integração entre o coprocessador e o sistema base;
• Acelerar a construção da árvore k-d em hardware, por meio da utilização
de algoritmos mais eficientes e paralelizados;
• Aumentar o grau de realismo das imagens geradas pela incorporação
de mais efeitos ópticos ao algoritmo, tais como dispersão ou aberração
cromática;
• Melhorar a interface do sistema com o PC por meio da utilização de um
barramento mais eficiente, como o bus PCI express, que permitiria a
80
efetiva utilização da FPGA como uma “placa de vídeo”;
5.5 Considerações finais
De um modo geral, este projeto foi uma ocasião frutífera, possibilitando o
estudo de um problema complexo e a investigação de possíveis soluções. A
combinação de duas áreas completamente distintas — a saber, computação
gráfica e arquitetura de computadores — possibilitou uma oportunidade única
de aprendizado e de utilização de todos os conceitos apreendidos durante o
curso de Engenharia Elétrica com Ênfase em Computação na Escola Politéc-
nica da Universidade de São Paulo, desde álgebra linear e cálculo vetorial até
os métodos de gerenciamento de projetos. Assim, na opinião do grupo, este
trabalho pode ser chamado com justeza de “trabalho de formatura”, síntese e
apogeu de seis anos de dedicação ao estudo da engenharia.
81
REFERÊNCIAS
ALDEC. Active-HDL 9.1. 2011. Disponível em: <http://www.aldec.com/activehdl/>. Acesso em: 24 nov. 2011.
CHU, P. FPGA prototyping by VHDL examples: Xilinx Spartan-3 version. [S.l.]:Wiley-Interscience, 2008. ISBN 9780470185315.
CHU, P. P. RTL hardware design using VHDL: coding for efficiency, portability,and scalability. [S.l.]: Wiley-IEEE Press, 2006. ISBN 0471720925.
ERBAS, C. System-level modeling and design space exploration formultiprocessor embedded System-on-Chip architectures. Tese (Doutorado)— Informatics Institute, Univ. of Amsterdam, Nov. 2006.
FOLEY, T.; SUGERMAN, J. Kd-tree acceleration structures for a GPUraytracer. In: Proceedings of the ACM SIGGRAPH/EUROGRAPHICSconference on Graphics hardware. New York, NY, USA: ACM, 2005. (HWWS’05), p. 15–22.
GREVE, B. de. Reflections and refractions in ray tracing. 2007. Disponível em:<http://www.flipcode.com/archives/reflection_transmission.pdf>.Acesso em: 4 out. 2011.
GROTKER, T. System design with SystemC. Norwell, MA, USA: KluwerAcademic Publishers, 2002. ISBN 1402070721.
HANIKA, J. Fixed point hardware ray tracing. Tese (Doutorado) — UniversitatUlm, 2007.
HAVRAN, V. Heuristic ray shooting algorithms. Tese (Doutorado) — CzechTechnical University, 2000.
HOWARD, J. Real time ray-tracing: the end of rasterization? 2007. Disponívelem: <http://blogs.intel.com/research/2007/10/real_time_raytracing_the_end_o.php>. Acesso em: 12 dez. 2011.
MÖLLER, T.; TRUMBORE, B. Fast, minimum storage ray-triangle intersection.Journal of graphics tools, v. 2, n. 1, p. 21–28, 1997.
OYONALE. Oyonale - 3D art and graphic experiments. 2009. Disponível em:<http://www.oyonale.com/modeles.php?lang=en&page=40>. Acesso em:12 nov. 2011.
82
PIROMSOPA, K.; APORNTEWAN, C.; CHOGSATITVATAA, P. An FPGAimplementation of a fixed-point square root operation. In: Proceedings of theInternational Symposium on Communications and Information Technology.Thailand: [s.n.], 2001. v. 14–16, p. 587–589. ISSN 0730-0301.
PURCELL, T. J. et al. Ray tracing on programmable graphics hardware. ACMTrans. Graph., ACM, New York, NY, USA, v. 21, p. 703–712, July 2002. ISSN0730-0301. Disponível em: <http://doi.acm.org/10.1145/566654.566640>.
SHILANE, P. et al. The Princeton shape benchmark. In: Shape modelinginternational. [S.l.: s.n.], 2004.
SILICONARTS. Siliconarts launches RayCore R© IP Core. Julho 2011.Disponível em: <http://www.siliconarts.co.kr/recent-announcements/siliconartslaunchesraycoreipcore>. Acesso em: 4 ago. 2011.
STRATTON, J. State of ray tracing (in games). 2008. Disponível em:<http://www.cs.utah.edu/~jstratto/state_of_ray_tracing/>. Acessoem: 12 nov. 2011.
SYNOPSYS. Synplify Premier. 2011. Disponível em: <http://www.synopsys.com/Tools/Implementation/FPGAImplementation/FPGASynthesis/Pages/SynplifyPremier.aspx>. Acesso em: 24 nov. 2011.
SYSTEMVERILOG. System Verilog overview. 2011. Disponível em:<http://www.systemverilog.org/overview/overview.htm>. Acesso em:24 nov. 2011.
WHITTED, T. An improved illumination model for shaded display.Communications of the ACM, v. 23, n. 6, p. 343–349, 1980.
WOOP, S.; SCHMITTLER, J.; SLUSALLEK, P. RPU: a programmable rayprocessing unit for realtime ray tracing. ACM Trans. Graph., ACM, New York,NY, USA, v. 24, p. 434–444, July 2005. ISSN 0730-0301. Disponível em:<http://doi.acm.org/10.1145/1073204.1073211>.
XILINX. XPS Thin Film Transistor (TFT) Controller. setembro 2009. Disponívelem: <http://www.xilinx.com/support/documentation/ip_documentation/xps_tft.pdf>. Acesso em: 28 nov. 2011.
. Embedded Processor Block in Virtex-5 FPGAs. fevereiro 2010.Disponível em: <http://www.xilinx.com/support/documentation/user_guides/ug200.pdf>. Acesso em: 15 nov. 2011.
. LogiCORE IP Processor Local Bus (PLB) v4.6 (v1.05a). setembro2010. Disponível em: <http://www.xilinx.com/support/documentation/ip_documentation/plb_v46.pdf>. Acesso em: 28 nov. 2011.
. Virtex-5 FPGA Data Sheet: DC and Switching Characteristics. maio2010. Disponível em: <http://www.xilinx.com/support/documentation/data_sheets/ds202.pdf>. Acesso em: 28 nov. 2011.
83
. LogiCORE IP DDR2 Memory Controller for PowerPC 440 Processors.março 2011. Disponível em: <http://www.xilinx.com/support/documentation/ip_documentation/ppc440mc_ddr2.pdf>. Acesso em: 28nov. 2011.
. ML505/ML506/ML507 Evaluation Platform User Guide. maio 2011.Disponível em: <http://www.xilinx.com/support/documentation/boards_and_kits/ug347.pdf>. Acesso em: 15 nov. 2011.
84
APÊNDICE A -- ESTIMATIVAS PARA OCOPROCESSADOR
Tabela 6 – Dimensionamento da memória do coprocessador
Estrutura Elemento Total
Triângulo v1 96
v2 96
v3 96
materialId 32
medium1 32
medium2 32
Total (bits) 384
Total (bytes) 48
Raio point start 96
vector direction 96
Ray* next 32
Int depth 32
RayType type 32
KdTreeNode* currentNode 32
currentNRefraction 32
amplitude 32
Triangle* triangleHit 32
85
Tabela 6 – Dimensionamento da memória do coprocessador (continuação)
Estrutura Elemento Total
point intersection 96
Total (bits) 512
Total (bytes) 64
Material cor RGB 96
coeff reflection 32
coeff transmission 32
Total (bits) 160
Total (bytes) 20
Meio indiceRefracao 32
Total (bits) 32
Total (bytes) 4
Luz point posicao 96
point color 96
Total (bits) 192
Total (bytes) 24
Memória nó em processamento da árvore (bytes) 56
coprocessador vetor para 1024 triangulos (bytes) 49152
vetor para os materiais (bytes) 320
vetor para as luzes (bytes) 384
vetor para os meios (bytes) 64
variavel para cor do pixel - RGB (bytes) 12
máximo de reflexões 5
Total pilha de reflexões e refrações (bytes) 4032
86
Tabela 6 – Dimensionamento da memória do coprocessador (continuação)
Estrutura Elemento Total
Total (kbytes) 52,76
87
APÊNDICE B -- ESTIMATIVAS PARA AÁRVORE K-D
Tabela 7 – Dimensionamento da memória DDR2 necessária para a alocação de uma árvorek -d de 70000 triângulos
Estrutura Elemento Eixo Total
Triângulo v1 32 96
v2 32 96
v3 32 96
materialId 32
medium1 32
medium2 32
Total (bits) 384
Total (bytes) 48
Total triângulos (MB) 3,20
Nó da árvore left* 32
right* 32
parent* 32
next1* 32
trig* 32
nbTriangles 32
minbounds 32 96
88
Tabela 7 – Dimensionamento da memória DDR2 necessária para a alocação de uma árvorek -d de 70000 triângulos (continuação)
Estrutura Elemento Eixo Total
maxbounds 32 96
splitAxis 32
depth 32
Total (bits) 448
Total (bytes) 56
Total nós da árvore (MB) - profund. 16 7,00
Ref. triângulo triangle* 32
next* 32
Total (bits) 64
Total (bytes) 8
Total referências (MB) 2,14
Total árvore k-d (MB) 12,341
