GLSL Debugger

unfortunatelly, so far, this page is available only in portuguese

Introdução

Nos últimos anos a tecnologia das placas tem evoluído significativamente. A arquitetura das placas atuais apresenta alto grau de paralelismo e flexibilidade de programação [GPU04]. Esta flexibilidade foi obtida através da substituição de alguns módulos fixos por programáveis em alguns pontos do pipeline de renderização [ROS04]. Esta evolução permite que novos algoritmos sejam implementados. Os programas escritos para esta classe de hardware programável são comumente chamados de shaders.

Inicialmente, a maioria dos programas para GPUs eram escritos em linguagem Assembly, contudo, sabe-se que desenvolvedores fazem um uso mais efetivo de hardware programáveis quando eles têm a oportunidade de programar em uma linguagem de alto nível [FER03]. Surgiram então, linguagens de mais alto nível para programação de shaders. Entre elas, podemos citar Cg, HLSL e GLSL. A base sintática e semântica destas linguagens é a linguagem de propósito geral C. Porém, as linguagens de programação de shaders apresentam alguns recursos característicos, não presentes em linguagens de propósitos gerais, em virtude de serem voltadas para a implementação de algoritmos gráficos. Estes recursos visam facilitar a codificação e um maior aproveitamento do paralelismo presente nas placas gráficas. Entre eles, pode-se citar a definição de matrizes e vetores como tipos de dados básicos.

Cg é uma linguagem muito especializada que visa permitir ao desenvolvedor controlar através de programação a forma, a aparência e movimentos do objeto renderizado [FER03]. Foi desenvolvida através de parceria entre NVIDIA e Microsoft. Cg e HLSL são a mesma linguagem com nomes diferentes. Esta diferença é utilizada pelas empresas para identificar a tecnologia base, enquanto HLSL depende do framework utilizado, Cg é independente da interface de programação 3D utilizada e é completamente integrada tanto com Direct3D quanto com OpenGL [FER03]. Por fim, GLSL, cujo nome oficial é OpenGL Shading Language, é uma
extensão da linguagem OpenGL [ROS04]. GLSL apresenta algumas vantagens em relação à CG (e consequentemente, à HLSL devido à similaridade de ambas). Entre estas vantagens estão:
  • o uso de uma linguagem padrão que muda mais lentamente mas que mantém a compatibilidade com as versões anteriores frente à uma linguagem proprietária;
  • foi projetada de tal forma que uma aplicação OpenGL existente e funcional, pode ser facilmente adaptada para utilizá-la;
  • apesar de ambas serem independentes de plataforma, apenas GLSL é independente de hardware;
  • GLSL é compilada em tempo de execução pelo prórpio hardware gráfico, permitindo a geração de código de máquina mais otimizado para o hardware que está sendo utilizado. CG é compilada durante o desenvolvimento sendo traduzida para uma linguagem de máquina padrão, não necessariamente a mais otimizada para o hardware utilizado.

O alto poder computacional das placas gráficas modernas combinado com a facilidade destas linguagens de programação de alto nível permitem que algoritmos cada vez mais complexos sejam implementados em GPUs [SKE07]. Apesar das vantagens apresentadas pela GLSL, as ferramentas de depuração e análise de código não seguiram a mesma evolução da linguagem e ainda requerem aprimoramento para que a linguagem possua as mesmas facilidades de programação das linguagens de propósitos gerais ou mesmo de outras linguagens de programação de shaders. Ferramentas como o FXComposer 2.5 [NVI08] fornecem um poderoso ambiente para desenvolvimento e depuração de shaders em CG, HLSL, entre outras. Programas como spyGlass [MAG02], BuGLe [MER04] e gDEBugger [GRA04] permitem a depuração da máquina de estados do OpenGL, mas não do shader. Por outro lado, existem ferramentas especificas para a depuração de shaders, como, por exemplo, a Apple OpenGL Shader Builder [APP02] que não considera a aplicação alvo, e a Shadesmith [PS03] que considera a aplicação alvo, porém, é necessário que o código fonte da aplicação seja levemente alterado [SKE07].

Como resultado, desenvolvedores geralmente gastam uma grande quantidade de tempo localizando e depurando erros de programação. Fazendo uma analogia com a programação para CPUs, basta pensar no ganho em produtividade que se obteve quando deixou de ser necessário que o desenvolvedor para acompanhar o valor de uma variável, tivesse que imprimir seu conteúdo na tela, que facilmente se percebe os benefícios que o desenvolvimento de ferramentas
de depuração mais eficientes traria para a programação de shaders.

Trabalhos neste sentido já estão sendo realizados. Entre eles, pode-se citar, o glslDevil [SKE072], o qual serviu de inspiração para o trabalho aqui descrito. O glslDevil é um sistema de depuração para programas em linguagem GLSL. Permite a depuração sem a necessidade de recompilar ou mesmo de ter o código fonte do programa alvo. Para isto, recupera os dados modificando a biblioteca de OpenGL para executar as novas funções instrumentadas com o código de depuração. Estes dados podem então ser utilizados para depuração dos shaders ou análise do programa [SKE07a].

Visual Studio provê um depurador para HLSL integrado ao DirectX SDK mas não para GLSL. Um plugin para o Visual Studio permitiria que o desenvolvedor não precisasse trocar de ambiente ao desenvolver um aplicativo OpenGL com shaders GLSL.

A linguagem GLSL

OpenGL é uma API (Application Programming Interface) multi-plataforma padrão. É um dos principais ambientes para desenvolvimento de aplicações gráficas 2D e 3D interativas. Sua especificação foi finalizada em 1992 e desde então, se tornou a API mais amplamente suportada e utilizada pela indústria. Sua intenção é prover acesso às funcionalidades do hardware gráfico no mais baixo nível possível que ainda mantenha a independência de hardware [OPE08].

Alterações e testes de conformidade com a especificação da OpenGL são controlados pela ARB (Architecture Review Board), um grupo formado por representantes de empresas como 3Dlabs, Apple, ATI, Dell, IBM, Intel, NVIDIA, SGI, and Sun Microsystems. Em 2006, a ARB passou a ser o grupo responsável pela OpenGL no consórcio Khronos Group [OPE08]. Khronos Group é um consórcio focado na criação de padrões abertos de APIs para possibilitar a criação e execução de mídias dinâmicas em uma ampla variedade de plataformas e dispositivos. Qualquer pessoa ou empresa pode fazer parte deste grupo participando do desenvolvimento das especificações mediante o pagamento de anuidade [KHR08].

Desde o lançamento da versão 1.0, oito revisões da especificação foram lançadas, cada uma delas adicionando novas funcionalidades. Atualmente está na versão 2.1. A especificação da versão 3.0 já está em discussão desde meados de 2007, não há ainda previsão para o lançamento [OPE08]. Todas versões anteriores à 2.0 eram baseadas em um pipeline fixo. O usuário podia controlar vários parâmetros, mas a funcionalidade intrínsica e a ordem de processamento eram
fixas. A OpenGL 2.0 mudou isto. Foram acrescentadas funções à especificação 2.0 que permitiam a programação dos processadores de vértices e de fragmentos, através do uso de uma linguagem de alto nível específicas para este fim. Com esta versão, os desenvolvedores passaram a ter maior controle do pipeline de processamento e a desenvolver seus próprios algoritmos de renderização [ROS04]. Uma explicação mais detalhada sobre este pipeline pode ser encontrada
na sessão, “O Pipeline Gráfico”.

Devido ao fato de ter sido projetada como uma máquina de estados de função fixa, antes da OpenGL 2.0 a única forma de modificar a OpenGL era definir extensões para ela. Atualmente existem mais de 400 extensões [OPE08]. Extensões suportadas por apenas um fabricante, possuem um grupo de letras que o identifica (ex: APP para extensões suportadas apenas pela Apple, Inc, SGI para aquelas suportadas apenas pela Silycon Graphics, Inc, etc). Extensões suportadas por mais de um fabricante recebem o prefixo EXT e aquelas que foram revisadas pelo ARB recebem o prefixo ARB e são candidatas a fazerem parte da OpenGL padrão. GLSL, cujo nome oficial é OpenGL Shading Language, é uma extensão da OpenGL. Esta linguagem foi introduzida ao padrão OpenGL na especificação 2.0 e é utilizada para o desenvolvimento de shaders. Shader é como são chamados os programas desenvolvidos para hardware gráficos que apresentam alguns módulos programáveis no pipeline de renderização. Ou seja, com GLSL é possível programar os processadores de vértices e de fragmentos. Vertex Shader é o shader para o processamento de vértices e envolve as operações que ocorrem a cada vértice, como transformações e iluminação. Fragment Shader é o shader para processamento de fragmentos e consiste nas operações realizadas à cada fragmento, como ler um valor de textura da memória e aplicar a cada fragmento. Fragmento é uma estrutura de dados que contém todas as informações sobre um pixel após a renderização, ou seja, um fragmento é um candidato à pixel.
Para maiores explicações sobre o que é e como utilizar uma textura em OpenGL, vide [WOO99].

A GLSL possuí suas raízes na linguagem C, desta forma, a estrutura básica dos programas desenvolvidos em ambas é a mesma, assim, a primeira função executada em um shader é a função void main(), ou seja, ela é obrigatória. Com o intuíto de facilitar operações gráficas mais freqüentes, a linguagem apresenta um conjunto de tipos de dados que incluí o tipo matrix e o tipo vetor, o que resulta em um código mais conciso, pois é possível realizar operações sobre estes tipos da mesma forma que se faria utilizando um escalar [OPE05]. Também foi adicionado um conjunto de tipos básicos chamado Samplers para criar um
mecanismo no qual shaders acessam a memória de textura e os qualificadores attribute, uniform e varying para especificar a entrada e saída de uma variável. Variáveis do tipo attribute indicam uma troca freqüente de valores entre a aplicação e o vertex shader, as do tipo uniform indicam uma troca pouco freqüente entre a aplicação e qualquer um dos shaders e as do tipo varying indicam interpolação entre os valores de um vertex shader para um fragment shader . A linguagem permite sobrecarga de funções e declaração de variáveis em qualquer parte do código e incluí suporte para laços, chamadas de subrotinas e expressões condicionais. A linguagem não suporta ponteiros, strings ou caracters e nem nenhuma operação baseada nestes tipos. Não há limite para o tamanho do código de um shader [ROS04]. Atualmente, a GLSL encontra-se na versão 1.2, a versão 1.3.1 é parte da especificação da OpenGL 3.0, e, entre outras modificações, apresenta suporte para a diretiva #include[OPE08].

Os principais benefícios da linguagem são os seguintes [ROS04, WIK08b]:
  • Foi projetada de tal forma que uma aplicação OpenGL existente e funcional, pode ser facilmente adaptada para utilizá-la;
  • A compilação é em tempo de execução, assim, não requer alteração do código fonte para uso em plataformas diferentes;
  • É uma linguagem de alto nível, então, não depende da linguagem assembly de cada fabricante;
  • É verdadeiramente um padrão aberto multiplataforma;
  • Permite a implementação de vários shaders mais simples ao invés de um único shader mais complexo;
  • Tanto a linguagem quanto os demais requisitos necessários para a criação de um shader são parte da OpenGL, desta forma, não é preciso utilizar nenhuma
biblioteca ou executável adicional.
A descrição completa e detalhada da OpenGL Shading Language pode ser encontrada em [ROS04].

O Pipeline Gráfico

Como as operações da OpenGL são definidas para serem aplicadas em uma determinada ordem, podemos ver a OpenGL como um pipeline de processamento gráfico. A figura 3.1 representa um diagrama lógico simplicado da OpenGL 2.0. Antes desta versão, a programabilidade dos hardware gráficos estava oculta e só era acessível através do uso de extensões. Porém, a arquitetura básica da OpenGL não mudou desde a versão 1.1. Então, se fizessemos o diagrama da versão 1.1, a única diferença seria que os processadores de vértices e de fragmentos seriam módulos fixos e não mais programáveis como na figura 3.1.
DiagramaOpenGL.jpg
Figura 3.1 – Diagrama lógico da arquitetura básica da OpenGL 2.0 [ROS05]

As descrições resumidas de cada um dos estágios foram baseadas em [ROS04, WOO99]. Memória da Aplicação - As formas primitivas de geometria suportadas pela OpenGL são pontos, linhas, polígonos, etc. Os dados sobre estas primitivas estão inicialmente armazenados em uma memória à qual a aplicação tem acesso.

Processador de Vértices – é um módulo programável onde ocorrem as operações sobre cada um dos vértices, como transformações, aplicação de cor e iluminação. Os shaders que rodam neste módulo são chamados Vertex Shaders. O código do shader deve conter a especificação para executar todas as funções desejadas pelo desenvolvedor, não é possível, por exemplo, se o desenvolvedor desejar efetuar normalização e iluminação que o shader contenha o código de apenas uma delas e utilizar uma função fixa para executar a outra. A figura 3.2 representa as entradas e saídas possíveis do processador de vértices.
SaidaProcessadorVertices.jpg
Figure 3.2. Entradas e saídas do Processador de Vértices [ROS04]

Junção de primitivas – estágio onde os vértices são agrupados de acordo com o tipo primitivo da geometria.

Processamento de primitivas – consiste nos processos de clipping, projeção perspectiva, geração das coordenadas de janela e culling.
Rasterização – as primitivas são decompostas em partes menores correspondentes à um pixel no frame buffer. Cada uma destas partes é chamada de fragmento. Por exemplo, se uma linha (definida por dois vértices) cobre cinco pixels na tela, o processo de rasterização vai convertê-la em cinco fragmentos.

Processador de Fragmentos – é um módulo programável. Depois dos fragmentos serem gerados na rasterização, uma série de operações pode ser realizada nos fragmentos, sendo que a mais importante provavelmente é o mapeamento de textura. Nesta operação, a coordenada de textura associada ao fragmento é utilizada para acessar uma região da memória chamada memória de textura. Os shaders que rodam neste módulo são chamados Fragment Shaders. Um
shader não pode modificar as coordenadas (x,y) de um fragmento. O processador de fragmentos não substituí funcionalidades fixas que ocorrem “por baixo” do pipeline de processamento de pixel da OpenGL, como por exemplo testes de profundidade e operações lógicas. A figura 3.3 apresenta os valores de entrada e saída do processador de fragmentos.
SaidaProcessadorFragmentos.jpg
Figure 3.3. Entradas e saídas do Processador de Fragmentos [ROS04]

Operações por fragmento – depois de processados, os fragmentos passam por uma série de operações simples, como por exemplo teste de profundidade, para determinar a visibilidade do pixel de destino.

Operações do Frame Buffer – operações realizadas para controlar em quais regiões do frame buffer as primitivas serão desenhadas.

A OpenGL suporta tanto o desenho de geometria 3D (como visto até agora) como de imagens. Estas imagens são chamadas de retângulos de pixels. Seus valores iniciais estão na memória controlada pela aplicação. Imagens que serão utilizadas como textura são enviadas para a memória de textura e as demais para o frame buffer.

Trabalhos Relacionados

Existe uma série de software voltados para a depuração e/ou edição de programas OpenGL e de shaders GLSL. Por possuírem características diferenciadas, podem ser divididos basicamente em três grupos:
  • Depuradores de programas OpenGL;
  • Depuradores e/ou editores de shaders GLSL que não consideram o programa OpenGL hospedeiro;
  • Depuradores e/ou editores de shaders GLSL que consideram o programa OpenGL hospedeiro.

Neste trabalho serão descritos e comparados alguns destes softwares.

Depuradores de programas OpenGL

Com o crescimento da utilização de shaders, são poucas ferramentas que se limitam apenas ao programa OpenGL. Como pode-se perceber através da descrição de algumas delas abaixo, são ferramentas simples que fornecem ao usuário poucas funcionalidades. A gDEBugger [GRA04] era uma ferramenta mais sofisticada que em versões passadas se encaixava nesta categoria, porém, em sua versão atual também passou a oferecer suporte para a edição de shaders
e assim, será descrita posteriormente.
  • GLTrace [HAW05] é o mais simples deles. Ele intercepta e gera um log em um arquivo texto das chamadas OpenGL. Suporta apenas a versão 1.1 da especificação OpenGL .
  • SpyGlass [MAG02] desenvolvido para sistemas Unix, assim como o GLTrace, intercepta as chamadas OpenGL. A principal diferença é que este apresenta uma interface gráfica e permite ao usuário não apenas gerar um log das chamadas, mas também depurar o programa. Não é um depurador sofisticado, permite apenas execução passo à passo e inserção de breakpoints.
  • BuGLe [MER04], também desenvolvido para sitemas Unix, é um depurador que permite visualizar as chamadas OpenGL, tirar um screenshot ou capturar um vídeo do programa em execução, verificar erros a cada chamada de forma transparente ao programa, exibir estatísticas da execução (por exemplo, frame rate), forçar a renderização em modo wireframe e setar breakpoints. Uma interface gráfica está em desenvolvimento.

Depuradores e/ou editores de shaders que não consideram o programa OpenGL hospedeiro

O grupo de ferramentas descrito anteriormente estava focado no programa OpenGL e não levava em consideração a existência ou não de shaders. Este grupo é o inverso. Está focado no desenvolvimento do shader e nem sequer necessita de um programa OpenGL hospedeiro. O shader é executado dentro da própria ferramenta, permitindo ao usuário se ater primeiramente a obter o efeito desejado, para só depois então, se preocupar com o desenvolvimento do programa
onde o shader será efetivamente executado.
  • Shader Designer [TYP07] teve sua produção descontinuada pela TyphoonLabs, porém, ainda está disponível para download gratuitamente [WIK08b]. Desenvolvida para sistemas Windows e Linux, foi projetada com o objetivo de facilitar o desenvolvimento de shaders utilizando GLSL. Apresenta uma IDE (Integrated Development Environment) com renderização em tempo real do shader, acesso à estados relevantes da OpenGL, compilação offline e validação
do shader, multiplos formatos de textura, entre outras características. Não apresenta suporte para depuração do shader.
  • OpenGL Shader Builder [APP02] desenvolvida para o sistema Mac OS, provê uma IDE para o desenvolvimento e depuração de shaders GLSL. A janela principal engloba um editor, um depurador que permite visualizar o conteúdo das variáveis, execução passo à passo e reiniciar a execução e um gerenciador de recursos ( informações sobre texturas, variáveis temporárias, etc utilizadas) e de desempenho. Assim como o anterior, permite a renderização e visualização em tempo real do resultado dos efeitos desenvolvidos aplicados à um objeto.
  • RenderMonkey [AMD08] desenvolvida para o sistema Windows, sua principal diferença frente as anteriores é que ela não suporta apenas GLSL mas também outras linguagens de programação de shaders, como HLSL. Outra diferença é a presença de interfaces diferenciadas para programadores e artistas. A interface de desenvolvimento voltada para artistas procura ocultar muito da complexidade da programação de shaders.

Depuradores e/ou editores de shaders GLSL que consideram o programa OpenGL hospedeiro

Apesar deste grupo considerar tanto o programa OpenGL hospedeiro quanto o shader GLSL, o que se percebe é que ainda há uma divisão entre ferramentas voltadas para a edição do shader e ferramentas para a depuração. O que demonstra ainda a deficiência de uma ferramenta realmente poderosa que integre o desenvolvimento e a depuração de shaders GLSL, não apenas de forma textual, mas também apresentando recursos de renderização e visualização em tempo real.
  • GLIntercept [TRE05] desenvolvida para o sistema Windows, intercepta e produz um log das chamadas de funções OpenGL. Seu diferencial em relação as demais ferramentas que também apresentam esta funcionalidade é o suporte à plugins. Através da utilização dos plugins disponíveis é possível, por exemplo, exibir o código de um shader e editá-lo em tempo real.
  • gDEBugger [GRA04] é uma ferramenta comercial, multiplataforma em constante atualização. É um dos mais completos depurador de programas OpenGL hospedeiros existente. Permite execução passo à passo, inserção de breakpoints, visualização de threads, localiza o gargalo da aplicação, entre várias outras funcionalidades. Em versões anteriores não apresentava suporte à GLSL, porém, em sua versão atual permite visualizar e editar shaders em tempo real.
  • Shadesmith [PS03] desenvolvida para Windows, provê uma forma automática de depurar shaders. Suas funcionalidades são bastante limitadas, permitindo ao usuário apenas visualizar o valor das variáveis durante a execução e editar o shader em tempo de execução. Requer alterações no código fonte do programa OpenGL hospedeiro.
  • GLSL Devil [SKE07a] ferramenta multiplataforma que serviu de inspiração para a realização do trabalho aqui descrito. Permite a depuração sem a necessidade de recompilar ou mesmo de ter o código fonte do programa alvo. Para isto, recupera os dados modificando a biblioteca de OpenGL para executar as novas funções instrumentadas com o código de depuração. Estes dados podem então ser utilizados para depuração dos shaders ou análise do programa. Possibilita ao usuário, entre outras funcionalidades:
    • a execução passo à passo tanto do programa OpenGL hospedeiro quanto do shader;
    • selecionar quais funções OpenGL serão exibidas no log de execução;
    • visualizar o conteúdo das variáveis e acompanhar as alterações dos valores;
    • oferece suporte para Geometry Shaders [WIK08].

Implementação

Como mencionado anteriormente, os requisitos para um depurador de GPUs são, resumidamente:
  • Permitir a execução passo à passo do programa;
  • Permitir a inserção de breakpoints;
  • Permitir o acompanhamento dos valores das variáveis;
  • Interferir o mínimo possível no programa original;
  • Executar o código na GPU e não via simulação por software;
  • Suportar extensões da maioria dos fabricantes;
  • Exibir os dados de um conjunto de pixel sob a forma de imagem.
Também já foi mencionado anteriormente que o trabalho aqui descrito segue como base [SKE07]. Assim, a partir de [SKE07] verificamos que as etapas necessárias para a implementação de ferramenta desejada consistem do desenvolvimento dos itens a seguir:
  • Uma biblioteca de funções para interceptar todas as chamadas OpenGL durante a execução do programa;
  • Um parser de GLSL para criar uma representação intermediária que permita a identificação da ordem de execução do programa, determinação do escopo de
variáveis e manipulação correta do código do shader;
  • Definir a representação intermediária;
  • Tratar condicionais, loops e chamadas de funções;
  • Uma interface gráfica que permita controlar a execução tanto da aplicação quanto do shader alvo.

Bliblioteca de funções

Como visto, é necessário uma biblioteca de funções para interceptar todas as chamadas OpenGL. Uma versão modificada da ferramenta GLTrace [HAW05] está sendo utilizada. A GLTrace consiste em um arquivo opengl32.dll próprio que ( desde que salvo na mesma pasta do programa OpenGL do qual se quer obter informação) é executado ao invés da dll original do sistema. Ao final da execução é gerado um arquivo texto com o log das funções OpenGL chamadas. Porém, oferece suporte apenas para a versão 1.1 da OpenGL. Para que esta dll pudesse ser utilizada no depurador referente ao trabalho aqui descrito, foram necessárias uma série de modificações. Entre elas, as principais são:
  • inclusão das funções necessárias para permitir o suporte à versão 2.1 da OpenGL e suas extensões;
  • inclusão de funções para exibição das funções chamadas e seus parâmetros na tela;
  • alteração para que a função OpenGL seguinte só seja executada mediante interação do usuário, permitindo a execução passo à passo.

Assim como na GLTrace, a biblioteca gerada é uma versão modificada da biblioteca de sistema opengl32.dll. Mantém o mesmo nome da original e deve estar na mesma pasta que o programa a ser depurado. No momento da execução do programa, a biblioteca opengl32.dll modificada é chamada e é ela que irá chamar a biblioteca do sistema que irá então executar as funções OpenGL. A linguagem de desenvolvimento utilizada foi a C e o ambiente Microsoft Visual Studio 2008.

A seguir, uma descrição mais detalhada do funcionamento da biblioteca:
  • o programa a ser depurado é executado;
  • ele chama a biblioteca modificada que encontra-se na mesma pasta;
  • a bliblioteca recebe a chamada de função e seus parâmetros;
  • ao invés de executar a função propriamente dita, a biblioteca executa a sua própria versão;
  • esta função modificada então:
    • recupera as informações sobre a localização da biblioteca OpenGL original do sistema;
    • carrega esta biblioteca;
    • cria uma variável do tipo function que recebe a função da biblioteca original;
    • atribui esta variável para um ponteiro de função;
    • executa este ponteiro. Ou seja, não está executando a sua própria função, mas sim a função apontada que é a pertencente à biblioteca do sistema;
  • imprime na tela as informações sobre a função OpenGL chamada;
  • coloca o sistema em modo de espera de uma interação do usuário;
  • quando o usuário interage, executa a próxima função.

Referências

3DL05 3DLABS CORPORATION: OpenGL Shading Language Compiler Front-end, 2005.
http://www.3dlabs.com/downloads/glslcompiler
ALL07 ALLINEA SOFTWARE: The Distributed Debugging Tool, 2007.
http://www.allinea.com
AMD08 AMD INC.: RenderMonkey, 2008.
http://developer.amd.com/gpu/rendermonkey/Pages/default.aspx
APP02 APPLE INC.: OpenGL Shader Builder, 2002.
http://developer.apple.com
FER06 FERNANDES, Antônio R.: GLSL Tutorial, 2006
www.lighthouse3d.com/opengl/glsl
FER03 FERNANDO, Randima. The Cg Tutorial.
Boston: Addison-Wesley, 2003.
GPU04 GPUGems: programming techniques, tips, and tricks for real-time graphics. Boston:
Addison-Wesley, c2004.
GRA04 GRAPHIC REMEDY: gDEBugger, 2004.
http://www.gremedy.com
HAR08 HARDWARE SECRETS: GeForce GTX 200 Series Architecture, 2008.
http://www.hardwaresecrets.com/article/569/2
HAW05 HAWK SOFTWARE: GLTrace Programming Utility, 2005
http://www.hawksoft.com/gltrace
HIL06 HILGART, Mark: Step-Through Debugging of GLSL Shaders, 2006.
http://facweb.cs.depaul.edu/research
KHR08 KHRONOS GROUP, 2008
http://www.khronos.org
LUM07 LUMINA PROJECT, 2007
http://lumina.sourceforge.net/Home.html
MAG02 MAGALLÓN M. E.: spyglass, 2002.
http://spyglass.sourceforge.net
MER04 MERRY B.: BuGLe, 2004
http://bugle.sf.net
MIC08 MICROSOFT CORPORATION: Debugging Terminology, 2008
http://msdn.microsoft.com/en-us/library/ms679306(VS.85).aspx
NVI08 NVIDIA CORPORATION.: FX Composer 2.5 Beta 2, 2008.
http://developer.nvidia.com/object/fxcomposerhome.html
OLG07 OWENS J. D., LUEBKE D., GOVINDARAJU N., HARRIS M., KRÜGER J.,
LEFOHN A. E., PURCELL T. J.: A survey of general-purpose computation on graphics
hardware. Computer Graphics Forum 26, 1 (2007), 80.113.
OPE05 OPENGL ORGANIZATION: OpenGL Shading Language, 2005.
http://www.opengl.org/documentation/glsl
OPE08 OPENGL ORGANIZATION, 2008.
http://www.opengl.org
PS03 PURCELL T. J., SEN P.: Shadesmith, 2003.
http://graphics.stanford.edu/projects/shadesmith
ROS04 ROST, Randi J.: OpenGL Shading Language.
Boston: Addison-Wesley, c2004.
ROS05 ROST, Randi J.: Introduction To OpenGL Shading Language, 2005
http://www.ecse.rpi.edu/~wrf/wiki/AdvancedComputerGraphicsSpring2008/GLSLOverview200
5.pdf
RUS05 RUSSEL, Charlie: Parallel Debugging Using Visual Studio 2005
http://go.microsoft.com/fwlink/?LinkId=55932
SKE07 STRENGERT, M., KLEIN, T., ERTL, T.: A Hardware-Aware Debugger for the
OpenGL Shading Language. In Proceedings of the ACM SIGGRAPH/EUROGRAPHICS
symposium on Graphics hardware (2007), pages: 81 – 88.
SKE07a STRENGERT, M., KLEIN, T., ERTL, T.: glslDevil, 2007.
http://www.vis.uni-stuttgart.de/glsldevil
TRE05 TREBILCO, Damian Trebilco: GLIntercept, 2005
http://glintercept.nutty.org
TYP07 TYPHOONLABS: Shader Designer, 2007.
http://www.opengl.org/sdk/tools/ShaderDesigner
WIK08 WIKIPEDIA, THE FREE ENCYCLOPEDIA: Debugger, 2008
http://en.wikipedia.org/wiki/Debugger
WIK08a WIKIPEDIA, THE FREE ENCYCLOPEDIA: Geometry Shader, 2008
http://en.wikipedia.org/wiki/Geometry_shader
WIK08b WIKIPEDIA, THE FREE ENCYCLOPEDIA: GLSL, 2008
http://en.wikipedia.org/wiki/GLSL
WOO99 WOO, Mason: OpenGL programming guide: the official guide to learning OpenGL,
Version 1.2. 3rd ed. Addison-Wesley, c1999. 730 p
XBI08 X – BIT LABS: ATI Radeon HD 4800 Graphics Architecture: Long Anticipated
Revenge?
http://www.xbitlabs.com/articles/video/display/ati-radeon-hd4850_4.html#sect0

Last edited Oct 30, 2008 at 4:18 AM by bellaver, version 8

Comments

No comments yet.