Blog do Projeto

Unfortunately this page exists only in portuguese.

06/01/10

Olá,
criei um projeto exclusivo para o OpenCL, e estarei postando lá as informações relativas a essa etapa do projeto. Por favor, visitem http://opencl.codeplex.com/ para maiores informações.

Att,

Leonardo

12/11/09

Olá,
estou trabalhando no segundo tutorial sobre OpenCL, que acredito que deva estar pronto em breve. Nele pretendo discutir um pouco melhor OpenCL e a arquitetura sobre a qual ele deve executar. Pretendo nesse tutorial avançar mais também nas técnicas e possibilidades de programação, abordando um pouco os diferentes tipos de memória e sua relação com a eficiência geral do programa.
Estou também estudando uma forma de acelerar a execução do trabalho de um doutorando aqui do grupo de computação gráfica. Ainda estou em uma fase bastante preliminar, mas em breve deverei estar publicando aqui mais informações relacionadas a isso.

Até,

Leonardo Chatain

03/11/09

Olá a todos,
estive bastante envolvido com as tarefas da faculdade nos últimos dias, assim que não tenho tido muito tempo de postar aqui os resultados do meu trabalho.
Encontrei um material muito bom sobre OpenCl aqui: http://www.macresearch.org/opencl. Nelas são apresentados desde questões gerais sobre opencl até otimizações diversas. Vale a pena conferir.

Até,

Leonardo Chatain

05/10/09

Olá a todos,
gostaria de fazer aqui um pequeno post apenas para comentar sobre um benchmark que foi feito pela SiSoftware (os responsáveis pelo famoso Sandra).
O benchmark levou em consideração as versões 2.2 e 2.3 do driver da NVidia, comparando CUDA e Opencl. Os resultados completos podem ser conferidos aqui: http://sisoftware.co.uk/index.html?dir=qa&location=gpu_opencl&langx=en&a=.
A idéia central é que o OpenCl está praticamente à altura do CUDA (tendo em vista os testes desse benchmark) em termos de desempenho, o que responde a uma grande crítica ao OpenCL.

Att,

Leonardo Chatain

02/10/09

Bom dia,
estou postando aqui hoje meu primeiro tutorial sobre OpenCL. Esse primeiro tutorial pretende ser uma iniciação, um hello world detalhado de como funciona uma aplicação OpenCl.
Futuros tutoriais aprofundar-se-ão em outros temas;
O tutorial pode ser encontrado aqui: OpenCl Tutorials - 1;

Até mais,

Leonardo Chatain

30/09/09

Olá a todos,
queria avisar que a nvidia liberou para a comunidade em geral o driver da versão 1.0 do OpenCL nesta segunda feira.
A página com informações para download tanto de windows, linux e mac pode ser encontrada aqui: http://www.nvidia.com/object/cuda_opencl.html

Até mais,

Leonardo Chatain

23/09/09

Bom dia,
Nessa última semana fiz uma pequena apresentação sobre o projeto, apresentando todas as suas fases. Disponibilizo aqui apresentação com áudio http://www.inf.ufrgs.br/~lpchatain/apresentacao_chatain.pptx(~14mb) (o Microsoft Office 2007 é necessário para abrir a apresentação, um plugin de compatibilidade para versões anteriores do Office pode ser encontrada aqui: http://www.microsoft.com/downloads/details.aspx?familyid=941b3470-3ae9-4aee-8f43-c6bb74cd1466&displaylang=en);

Até mais,

Leonardo Chatain

14/09/09

Olá a todos,
nesta última semana estive tentando fazer um benchmark do Cuda. Trata-se de um programa que resolve o problema das n-rainhas*, desenvolvido em Cuda e C++. O trabalho em questão foi feito pelo Vitor, e pode ser conferido em http://vitorpamplona.com/wiki/An%C3%A1lise%20de%20Performance:%20C%20vs%20Cuda.
Nesse trabalho foi concluido que a implementação em C++ estava mais eficiente que a em Cuda. Entretanto fora utilizada a versão 1.0 do Cuda, e minha intenção era fazer um novo teste com a nova versão do compilador, para verificar eventuais melhorias de performance. Também gostaria de fazer os testes com diferentes configurações de hardware.
Entretanto estive com bastantes dificuldades em fazer os testes funcionarem. Eles apresentaram um comportamento anômalo (leia-se imprevisível) na máquina em que iniciei os testes, e atribui o problema à arquitetura 64bits da nova máquina. Mudando para um processador 32 bits não tenho problemas com a compilação, entretanto estou tendo problemas com os kernels, que falham em sua execuçao. Acredito ser um pequeno problema com a mudança do compilador (1.0 -> 2.2), mas ainda não consegui identificá-lo.
Estarei postando aqui em breve um relatório de meus testes.

Fora isso continuo estudando OpenCl, o que é bastante parecido com Cuda, assim que vou 'com as duas ao mesmo tempo'.

Até mais,

Leonardo Chatain

28/08/09

Olá a todos,
estive estudando uma maneira de gerenciar automaticamente a inclusão da DLL (como citado no post anterior). Postei algumas perguntas no blog da MSDN e obtive algumas respostas interessantes, que devem ser testadas nos proximos dias.

Estive também estudando nessas últimas semanas OpenCl.
OpenCl é uma linguagem inicialmente criada pela Apple - e que teve como colaboradores a Intel, a nVidia e a AMD - para escrever programas que executem em ambientes heterogeneos, compostos de GPUs e CPUs.
A linguagem foi 'abraçada' pelo Kronos Group, que disponibilizou recentemente a especificação da versão 1.0.
Atualmente existem apenas versões beta dos drivers (visto que o kronos group somente disponibiliza a especificação, cabe às fabricantes de hardware gráfico implementarem essa especificação e fornecerem um compilador e um driver/sdk.

Eu estou aqui testando com o driver beta da nvidia (apenas para desenvolvedores registrados). A implementação da nVidia nada mais é que um 'mapeamento' da arquitetura CUDA para o OpenCl (creio que isso seja próximo ao que a AMD/ATI está fazendo, mapeando não para o CUDA mas para o Stream).

Em CUDA, as funções que se utilizam do paralelismo da GPU são conhecidas como kernels.
Kernels são executados por Streaming Multiprocessors (SMs). Cada SM, por sua vez, é composto por 8 Scalar Processors (SPs), os quais podem, cada um, executar simultaneamente até 4 threads. Assim temos que um Streaming Multiprocessor pode executar simultaneamente até 32 threads, o que chamaremos de warp.
Sempre que invocamos um kernel, especificamos para ele quantos thread blocks e quantas threads per block queremos que esse kernel utilize. Cada SM encarrega-se da execução de 1 thread block.
Teoricamente, assim, se tivermos menos que 32 threads em um thread block estaremos 'perdendo processamento', pois não teremos preenchido o warp do SM. Se tivermos mais que 32 threads per block, entretanto, nossa situação dependerá da quantidade de memória e de registradores que estarão sendo utilizados. Funciona da seguinte forma: a CPU utiliza cache para esconder a latencia de memória, i.e. para não termos que esperar sempre que os dados cheguem, nós armazenamos-nos em uma cache. Na GPU escondemos a latência da memória com computações. Temos que a troca de contexto entre threads é muito veloz, assim ao invés de armazenarmos a memória em uma grande cache, simplesmente mandamos outra thread executar enquanto esperamos, contanto que haja registradores livres no banco de registradores do SM.

Em OpenCl temos a noção de work-items, que são mapeados para CUDA Threads, temos a noção de work-groups, que são mapeados para thread blocks e por fim temos um NDRange, que é mapeado para um grid de thread blocks.
O mapeamento é feito compilando OpenCl para o mesmo "bytecode": PTX.

Em breve estarei postando aqui trechos iniciais de código em OpenCl, e espero estar fazendo alguns benchmarks com CUDA/OpenCl/CPU.

Para maiores informações a respeito das duas linguagens:
Até mais,

Leonardo Chatain

23/07/09

Olá a todos,
Nesta semana estive com alguns problemas relativos à compatibilidade do debugger quando o projeto é levado a outros computadores. Esses problemas se deveram não à falta de compatibilidade do programa, mas sim do Package. Corrigi o problema, mas pretendo investigar a sua causa.
Estou agora precisando ter acesso ao executavel gerado após a compilação, estive dando uma olhada nisso nesta semana, sem muito sucesso. Além disso, preciso encontrar uma forma de manter sempre a DLL modificada como a acessivel pelo programa, ou seja, preciso de alguma forma manter a dll nas pastas do Visual Studio, no local onde o Package é instalado, e fazer com que tudo isso se ajeite na hora da instalação do pacote.
Além desses pequenos problemas, continuo trabalhando na parte gráfica (infelizmente não sou muito proficiente na criação de interfaces amigáveis e bonitas) para integrá-la bem ao ambiente do Visual Studio. Ainda estou pensando em uma boa forma de dispor os compontentes, e em como melhorar a usabilidade do debugger.
Fora isso ele se encontra bem integrado. É preciso fazer alguns testes, nos quais me dedicarei na próxima semana.

Até la,

Leonardo

08/07/09

Olá a todos,
Estou fazendo atualmente alguns ajustes automatizar mais o debugger, utilizando para isso as interface IVsRunningDocTableEvents, que implementa alguns métodos para obter as notificações sobre modificações na IDE.
Para poder passar a receber os eventos da IDE (que serão tratados pelos handlers da interface, a saber:
  • int IVsRunningDocTableEvents.OnAfterAttributeChange
  • int IVsRunningDocTableEvents.OnAfterDocumentWindowHide
  • int IVsRunningDocTableEvents.OnAfterFirstDocumentLock
  • int IVsRunningDocTableEvents.OnAfterSave
  • int IVsRunningDocTableEvents.OnBeforeDocumentWindowShow
  • int IVsRunningDocTableEvents.OnBeforeLastDocumentUnlock
)

Esses eventos são importantes para que possamos ser notificados de modificações importantes, como por exemplo saber quais são os documentos que estão abertos.

Para poder receber os eventos, devemos nos inscrever da seguinte forma:
Declaramos inicialmente um cookie:
  • uint cookie;
E logo após devemos declarar uma interface IVsRunningDocumentTable, e solicitar que ela avise sobre os eventos
  • IVsRunningDocumentTable rdt =
(IVsRunningDocumentTable)Package.GetGlobalService(typeof(SVsRunningDocumentTable));
  • rdt.AdviseRunningDocTableEvents(this, out dwCookie);

Em breve, novas novidades.
Até,

Leonardo Chatain

11/06/09

Olá a todos,
infelizemente, após algum tempo de estudo em cima do debugger de exemplo, feito por Jackson Davis, disponível em http://code.msdn.microsoft.com/debugenginesample, e após uma troca de e-mails com o mesmo, constatei que o desenvolvimento de uma debug engine para o VS, ou seja, o objetivo inicial de integrar totalmente o debugger de GLSL com o debugger do Visual Studio é demasiado complexa, visto que há um grande número de interfaces a implementar e que aparentemente o debugger de GLSL não é compatível com o modelo de debug engine que o Visual Studio espera. Com certeza ha uma maneira de realizar essa integraçao, fazendo as devidas modificações no debugger e implementando as interfaces requeridas pelo VS, mas esse trabalho levará muito tempo.
Portanto, dadas as condições, optamos por desenvolver o depurador de forma externa ao depurador do Visual Studio, como já vinha sendo feito em paralelo. Existe uma quantidade consideravel de melhorias que se podem fazer e é esse o atual objetivo.
Tendo em vista o atual foco do trabalho, em pouco tempo espero estar postando alguns print screens e releases do debugger 'integrado'.

Obrigado,

Leonardo

26/05/09

Olá a todos,
estou utilizando os objetos DTE e DTE2 para alguns testes. Ainda tive alguns problemas após o último post para conseguir o objeto, mas agora essa já é uma questão do passado.
Estive nessas semanas estudando os objetos DTE e DTE2 e também estudando um projeto de exemplo de um depurador C++ integrado ao Visual Studio. Os resultados desse estudo ainda não são visíveis no depurador GLSL.
Quanto a alteraçoes no depurador, coloquei uma lista com os shaders sendo editados no projeto, de forma que o usuário possa escolher mais facilmente qual o shader a ser escolhido. Vou seguir com algumas alterações visuais desse estilo para deixar o debugger mais amigável.

Até

12/05/09

Olá a todos,
ontem descobri uma solução interessante para um pequeno problema que me atormentou por bastante tempo e que pelo visto atormenta bastante gente ainda.
Para solucionar uma série de questões ao desenvolver VSPackages, podemos utilizar o "automation object" DTE, que representa o objeto de mais alta hierarquia no ambiente EnvDTE, que possui referencias a todos os elementos da automação do núcleo do VS. Para tanto declaramos uma interface DTE, pertencente ao namespace EnvDTE (é necessário adicionar uma Reference ao projeto: EnvDTE), e utilizamos o método GetService para recuperar o objeto DTE (ele será referenciado pela interface DTE que declaramos).
Pretendo colocar mais explicações sobre o objeto DTE nos proximos post, mas agora quero me concentrar na explicação e solução do problema que me atormentou.
Eis que o seguinte código é o responsável por declarar e recuperar o objeto DTE:
using EnvDTE;

DTE dte;

protected override void Initialize() {
//Inicializações

this.dte = GetService(typeof(SDTE)) as DTE;
}

Entretanto, após a execução do trecho, dte continuava sempre com valor null, o que acabava gerando exceções e obviamente não era o que deveria estar acontecendo.
Buscando na internet, encontrei no VSX Team Blog (o blog do pessoal do VSX (Visual Studio Extensibility)) a solução para meu problema.
O fato é que caso o ambiente não esteja totalmente carregado (em "zombie state"), a solicitação da referencia do objeto DTE retorna null. Como eu queria que o package fosse carregado juntamente com o VS (no startup), a inicialização do package ocorria antes de o ambiente estar totalmente carregado, e dte continha sempre o valor null.
Assim, a solução proposta pelo pessoal do blog é a seguinte: utilizar a interface IVsShellPropertyEvents, implementando o handler OnShellPropertyChange, o qual faz o tracking do estado da IDE. A propriedade que diz se o VS está zombie é a VSPROPID_Zombie.
Segue abaixo a implementação do blog do pessoal do VSX:

      DTE dte;
      uint cookie;
      protected override void Initialize()
      {
           base.Initialize();
           IVsShell shellService = GetService(typeof(SVsShell)) as IVsShell;
           if (shellService != null)
                ErrorHandler.ThrowOnFailure(shellService.AdviseShellPropertyChanges(this,out cookie));
           ...
        }

        #region IVsShellPropertyEvents Members

        public int OnShellPropertyChange(int propid, object var)
        {
            // when zombie state changes to false, finish package initialization
            if ((int)__VSSPROPID.VSSPROPID_Zombie == propid)
            {
                if ((bool)var == false)
                {
                    // zombie state dependent code
                    this.dte = GetService(typeof(SDTE)) as DTE;
                    // eventlistener no longer needed
                    IVsShell shellService = GetService(typeof(SVsShell)) as IVsShell;
                    if (shellService != null)
                        ErrorHandler.ThrowOnFailure(shellService.UnadviseShellPropertyChanges(this.cookie));
                    this.cookie = 0;
                }
            }

            return VSConstants.S_OK;

        }

        #endregion

Esse artigo pode ser encontrado em http://blogs.msdn.com/vsxteam/archive/2008/06/09/dr-ex-why-does-getservice-typeof-envdte-dte-return-null.aspx.

Nos proximos posts estarei descrevendo mais a fundo a parte técnica do VS que estudei até agora, e introduzirei alguns dos problemas futuros que pretendo estar resolvendo.
Até lá,

Leonardo Chatain

06/05/09

Olá,
nestas ultimas semanas estive um pouco sobrecarregado, e não tive muito tempo para escrever no blog. A primeira etapa da depuração já esta concluida, entretanto restam alguns bugs relativos ao depurador que devem ser resolvidos antes de ser lançado um release do plug-in.
Venho trabalhando na parte mais profunda da integração.
Além da mera questão de mapear as funcionalidades do depurador para a IDE (que não é trivial), restam alguns problemas que surgem do fato de que algumas features existentes no VS não se encontram atualmente no depurador (como por exemplo a utilização de breakpoints). Essas funcionalidades deverão ser implementadas em breve.

Leonardo Chatain

23/04/09

Oi,
nesta semana finalizei uma primeira integração. Neste primeiro estágio temos, como já foi dito, o depurador da Bárbara executando sobre o Visual Studio.
Há ainda uma série de melhorias que devem ser feitas sobre esta integração:
  • Melhorias na estruturação e organização do código;
  • Remoção de alguns bugs;
  • Melhor organização visual;
Até o fim desta semana planejo ter uma versão utilizavel do depurador, melhor organizada visualmente, com algumas funcionalidades a mais (no que toca à integração, por exemplo que o depurador saiba qual o shader que deve ser depurado automaticamente, assim como o programa opengl.
Até lá,

Leonardo Chatain

20/04/09

Olá a todos,
estou tendo alguns problemas na integração, que derivam diretamente de dúvidas com relação ao depurador desenvolvido pela Barbara.
A idéia desta primeira integração é bastante simples, uma simples adição do depurador da barbara sobre o VS. A idéia é que após essa etapa seja construido incrementalmente o depurador integrado. Nesse ponto temos algumas dificuldades, como por exemplo que o depurador não suporta a colocação de breakpoints, mas executa sempre passo a passo, de forma que não se pode definir de forma mais flexivel o fluxo do programa.

Leonardo Chatain

10/04/09

Olá,
nesta semana estive trabalhando na efetiva integração do Depurador GLSL para o VS2008. A idéia inicial inserir apenas o depurador de forma externa ao depurador do Visual Studio, o que é uma tarefa mais simples e deve ser terminada até o final da semana. Nos proximos posts estarei publicando screenshots e maiores explicações sobre essa integração. Esse trabalho tem a vantagem de que o depurador estará rapidamente pronto para ser utilizado, entretanto ele não estara integrado com o depurador do Visual Studio. Para acessá-lo haverão menus e janelas exclusivas que se encarregarão de realizar todo o processo.
Após terminar essa primeira etapa de integração, pretendo construir uma Debug Engine que se comunique com a SDM e torne o processo de depuração transparente ao usuário.

Até lá,
Leonardo Chatain

01/04/09

Olá a todos,
nas semanas anteriores eu estive estudando o desenvolvimento de VSPackages genéricos, como uma forma de me familiarizar com eles. Nesta semana, e nas que virão, me voltei efetivamente para o VSDebugger e como extendê-lo.

Basicamente o debugger do visual studio é composto de três partes:
  • Interface com o usuário (UI), que permite, por exemplo, que sejam colocados breakpoints, que o codigo seja executado instrução a instrução, etc.
  • SDM (Session Debug Manager), que é basicamente quem gerencia as Debug Engines. Pode ser visto como um multiplexador de Debug Engines, além de fazer a comunicação com a UI. A SDM é implementada pelo VS e não será alterada.
  • Debug Engine (DE), que é o elemento que efetivamente faz a depuração do programa, e se comunica com a SDM. É aqui que será introduzido o depurador de GLSL.

Assim, teremos que construir uma DE que incorpore o depurador desenvolvido pela Bárbara. Para construir uma DE, são necessários alguns passos:
  • Primeiro devemos registrar nossa DE no Visual Studio, permitindo que ele a reconheça e utilize;
  • Nossa DE deve, quando solicitado pela SDM, "conectar-se" ao programa a ser depurado. Isso ocorre quando o usuário escolhe depurar o programa. Ocorre então uma troca de mensagens entre a SDM e as DEs;
  • Agora que nossa DE está "conectada" ao programa efetivamente podemos nos concentrar em depurar o programa. Esta etapa consiste em:
    • Controlar o fluxo de execução, respeitando breakpoints e execução step-by-step;
    • Comunicar-se com a SDM, fazendo com que tanto o VS quanto o usuário tenham um feedback da depuração;
    • Além disso temos que permitir:
      • A criação/deleção de breakpoints;
      • A inserção de watches;
      • A visualização da pilha de chamadas;
      • etc.
  • A seguir devemos nos desconectar do programa e solicitar à SDM para que o mesmo seja terminado;

Neste momento estou estudando um pouco mais o trabalho da Bárbara. Minhas dúvidas se concentram em como exatamente integrar todo o sistema de debugging do Visual Studio ao depurador que já foi desenvolvido. Nos próximos posts procurarei explicar um pouco melhor o funcionamento do mecanismo de depuração do VS, além de tentar aproximar um pouco mais os dois debuggers.

Até lá,
Leonardo Chatain

25/03/09 - Hello World

Nesta semana continuei a estudar o desenvolvimento de um Package para o VS2008. O estudo foi dirigido basicamente aos procedimentos de criação e ao funcionamento dos recursos gerados pelo wizard.

Para iniciar o desenvolvimento de um VSPackage, após baixar o SDK do Visual Studio, é utilizar o wizard de criação de package, que se encarrega de gerar o código base, deixando para nós apenas o desenvolvimento do Package.
Assim, após definir o nome de nosso Package, somos perguntados a respeito de algumas coisas sobre o ele: a linguagem em que o desenvolveremos, se queremos uma Tool Window, um Menu Tool, etc.
Para construir o Hello World utilizei C# e criei tanto uma Tool Window quanto um Menu Tool.
Os resultados foram os seguintes:

Window Tool:

windowTool.bmp

windowTool2.bmp

Código Fonte

        private void okButton_Click(object sender, System.EventArgs e)
        {
            MessageBox.Show("Seu nome é " + nameBox.Text.ToString(), "Seu nome", MessageBoxButtons.OK);
        }

        private void limparButton_Click(object sender, System.EventArgs e)
        {
            nameBox.Text = "";
        }


Command Tool:

cmdTool.bmp

Código fonte do command:

        private void MenuItemCallback(object sender, EventArgs e)
        {
            // Show a Message Box to prove we were here
            IVsUIShell uiShell = (IVsUIShell)GetService(typeof(SVsUIShell));
            Guid clsid = Guid.Empty;
            int result;
            Microsoft.VisualStudio.ErrorHandler.ThrowOnFailure(uiShell.ShowMessageBox(
                       0,
                       ref clsid,
                       "Hello World",
                       string.Format(CultureInfo.CurrentCulture, "Hello World - Este é um menuTool"),
                       string.Empty,
                       0,
                       OLEMSGBUTTON.OLEMSGBUTTON_OK,
                       OLEMSGDEFBUTTON.OLEMSGDEFBUTTON_FIRST,
                       OLEMSGICON.OLEMSGICON_INFO,
                       0,        // false
                       out result));
        }

Nos proximos posts estarei explicando com mais detalhes o funcionamento desses elementos. Atualmente estou buscando algo mais proximo do debugger, assim que possivelmente nos proximos posts não estarei mais lidando com exemplos genéricos, mas com algo mais focado no debugger em si.
Uma ótima referência (em ingles) é http://learnvsxnow.codeplex.com/


Leonardo Chatain

17/03/09

Oi pessoal,
sou o Leonardo e este é meu primeiro post aqui.
Atualmente, como a Barbara comentou, estou estudando o desenvolvimento de um "plug-in" para o Visual Studio, que permita a integração do trabalho dela com o ambiente de desenvolvimento, facilitando assim o trabalho de depuração.
A idéia é tornar o depurador natural ao usuário do VS.

O desenvolvimento se fará a partir de VSPackages, que são a ferramenta de extensibilidade mas completa que a Microsoft provê para o Visual Studio.

Mais informações sobre Visual Studio Extensibility, além do download dos SDKs do VS2005 e VS208, podem ser encontradas aqui: http://msdn.microsoft.com/en-us/vsx/default.aspx (Visual Studio Extensibility Developer Center).

Leonardo Chatain

08/03/2009

Nesta semana trabalhei corrigindo problemas na interface e procurei deixar o código do depurador menos "duro". Como por exemplo, poder abrir os arquivos em qualquer ordem e não primeiro um tipo de shader e depois o outro.

24/02/2009

Em virtude da troca de bolsistas, optamos por focar no desenvolvimento do plugin para o Visual Studio. Desta forma, o Leonardo está estudando o desenvolvimento de plugins, enquanto eu estou arrumando o código para que esta integração possa ser feita.

18/02/2009

Fui aprovada para o Mestrado em Ciência da Computação - UFRGS, desta forma, a partir de março estarei afastada do projeto. Quem irá dar continuidade ao projeto é o aluno no quinto semestre de graduação do curso de
Ciência da Computação - UFRGS, Leonardo Chatain. Seja bem vindo, Leonardo!

18/01/2009

Como disse no último post, comecei a trabalhar na integração da ferramenta com outras.
A ferramenta com a qual estou fazendo integração é a Shader Designer. A principal dificuldade encontrada até o momento está sendo portar o projeto da Shader Designer do Microsoft Visual Studio 2003 para o 2008 (ambiente em que foi desenvolvido o depurador). Estou tendo que re-escrever praticamente todo o código. Além de que, o Shader Designer utiliza uma série de códigos fontes e de bibliotecas de terceiros (vide abaixo) que também estão sendo portados.

Códigos Fontes de terceiros

a) 3DLabs GLSL Open Source Compiler

b) Algumas funções da "Matrix and Quaternion fAQ"

c) AVI exporter

d) GLEW Extensions manager.

e) MeshMender da Nvidia

f) DEV-IL

Bibliotecas de terceiros

a) Compona's SyntaxBox.

b) Flexporter

15/12/2008

Nestas últimas semanas escrevi e apresentei um trabalho acadêmico sobre o assunto. A apresentação pode ser obtida aqui.

Também foram acrescentadas novas funcionalidades:
  • Permite ao usuário optar por depurar:
    • Apenas o shader;
    • Apenas o programa OpenGL hospedeiro;
    • Ambos.
  • Permite visualizar o valor atualizado das variáveis que já foram depuradas

Nas próximas semanas, vou iniciar o estudo sobre desenvolvimento de plugins e começar a integração da ferramenta.

30/11/2008

Como dito no post anterior, foram muitas as dificuldades encontradas na utilização de extensões para captura de dados da placa gráfica.
Para que outras pessoas que necessitem utilizar estas extensões não enfrentem o mesmo problema (principalmente pela falta de documentação e de exemplos de uso), coloquei na página Capturing Data From Graphics Hardware, uma explicação das extensões utilizadas com exemplos.

O depurador foi aprimorado. Agora é possível não apenas ver o resultado da variável que está sendo depurada, mas também das funções pré-definidas da OpenGL Além disto, foi escrito um trabalho acadêmico sobre o assunto, que após sua apresentação, também estará disponível aqui no CodePlex.

Em breve também estarei disponibilizando um realease do depurador.

30/10/2008 - Finishing the Debugger

Durante este mês me foquei em terminar o depurador GLSL.
Foram muitas as dificuldades encontradas, principalmente na utilização de extensões para capturar a saída dos processadores de vértices e de fragmentos.
Foram implementados 3 módulos:
  • Wrapper OpenGL -> responsável por capturar as operações OpenGL realizadas pelo programa OpenGL hospedeiro e inserir os códigos necessários para depuração;
  • Parser GLSL -> responsável por re-escrever o código do shader GLSL de modo a inserir as variáveis de depuração necessárias
  • Interfce Gráfica -> responsável por interligar e utilizar os resultados obtidos nos demais módulos, além de, é claro, ser a interface com o usuário.

Este trabalho foi apresentado no XX Salão de IC - UFRGS. A apresentação pode ser baixada aqui.

Para as próximas semanas pretendo continuar trabalhando no aprimoramento da ferramenta e escrever um documento mais detalhado sobre seu desenvolvimento.

30/09/2008 - GLSL Debugger

Passei algum tempo sem postar no blog. Durante este tempo estava trabalhando em uma nova etapa do projeto, o desenvolvimento de um plugin de depuração de GLSL para o Visual Studio. Maiores detalhes do andamento e da descrição desta etapa podem ser encontrados em GLSL Debugger.

18/08/2008

GLSL não possui suporte à cast implícito (ex: vec4 color = 0.5;) assim, acrescentei o cast explicito (ex: vec4 color = vec4(0.5); )

Continuei com os testes do programa. A principal dificuldade encontrada nos testes é a validação. Por enquanto, o método utilizado para os testes consiste em pegar um código HLSL válido, converter e testar em um compilador GLSL se o código gerado é válido ou não. Se não for, o programa é corrigido. Ou seja, por falta de uma BNF oficial da HLSL, nossos testes são baseados em exemplos. O que não é o ideal. A idéia é que a próxima etapa de testes seja realizada comparando as imagens geradas. Ou seja, serão obtidas imagens executando o shader HLSL e estas serão comparadas com as imagens obtidas através da execução do shader GLSL. A diferença entre estas imagens nos dirá o percentual de erro obtido na conversão. É mais uma forma de validar o programa, porém, o fato dos testes serem baseados em exemplos persiste. Para que este fator não seja tão relevante, estamos utilizando uma gama variada de exemplos.

04/08/2008

Como o programa estava disponível apenas em versões de linha de comando, desenvolvi uma versão que apresenta uma interface gráfica simplificada. Com esta interface, basta o usuário carregar o código HLSL e clicar em converter. Os códigos são exibidos lado à lado, facilitando a visualização pelo usuário.

Esta interface apresenta um limitante, que é o fato de ser compatível apenas com sistemas Windows. Porém, em breve, pretendo desenvolver uma versão compatível com outros sistemas.

24/07/2008

GLSL não apresenta suporte ao comando "Switch". Desta forma, fiz uma função que substitui este comando por "If..else".

Exemplo: Código HLSL
        switch ( teste ) {
    			case 0: k++; return teste; 
    			case 1: return teste; 
    			case 2: t++; return teste; 
    			default: { 
    				teste++;
       			} 


Exemplo: Código GLSL
      if (teste == 0) { k++; return teste; }
      else if (teste == 1) { return teste;}
      else if (teste == 2) { t++; return teste; }
      else { teste++;  }


GLSL não permite atribuições para elementos dos vetores, se estes vetores forem variáveis to tipo "varying". Então, fiz uma função que cria uma variável temporária, efetua a atribuição e então atribui o valor à variável original.

Exemplo: Código HLSL
  float4 MyShader( float2 Tex : TEXCOORD0 ) : COLOR0
{
    float4 Color;
    
    Color = float4(1.0,1.0,1.0,1.0);
    Color.a;
    Color.a = 0.1;
    Color.rgb = float3(0.5f);

    Tex.y = Tex.y + (sin(timeraslow)*0.01);
    Tex.x = Tex.x + (cos(timeraslow)*0.01);
    Color = tex2D( g_samSrcColor, Tex.xy);

    Color -= tex2D( g_samSrcColor, Tex.xy-0.001)*2.0f;
    Color += tex2D( g_samSrcColor, Tex.xy+0.001)*2.0f;
    Color.rgb = float3((Color.r+Color.g+Color.b)/3.0f);   	
   	
    return Color;
}


Exemplo: Código GLSL
 varying vec2 Tex;

void main( )
{
    vec4 Color;
    
    Color = vec4(1.0,1.0,1.0,1.0);
    Color.a;
    Color.a = 0.1;
    Color.rgb = vec3(0.5); //não necessita de variável temporária pois não é varying

    vec2 tempTex = Tex; //como Tex era varying foi criada uma variável temporária 

    tempTex.y = Tex.y + (sin(timeraslow)*0.01);
    Tex=tempTex;
    tempTex.x = Tex.x + (cos(timeraslow)*0.01);
    Tex=tempTex;
    Color = tex2D( g_samSrcColor, Tex.xy);

    Color -= tex2D( g_samSrcColor, Tex.xy-0.001)*2.0;
    Color += tex2D( g_samSrcColor, Tex.xy+0.001)*2.0;
    Color.rgb = vec3((Color.r+Color.g+Color.b)/3.0));   	
   	
    gl_FragColor = Color;
}

09/07/2008

Acrescentei a conversão das funções intrínsicas. Para as funções intrínsicas de HLSL que não são suportadas pela GLSL (vide Differences Between HLSL and GLSL), é emitida uma mensagem de aviso ao usuário. GLSL também não suporta a letra 'f' após um número do tipo float (ex: 1.0f), então, inseri uma função que remove este 'f' do número.

Iniciei também a fase de testes do programa. Para isto estou utilizando os shaders Parsing Shaders. Após converter, executo o arquivo gerado no software Shader Designer. Este software é um editor/compilador de GLSL. Assim, através de sua saída, posso verificar se o código GLSL gerado é válido ou não e corrigir os problemas encontrados.

A versão mais atual dos fontes do projeto encontra-se disponível.

04/07/2008

Fiz algumas alterações na gramática e acrescentei novas funções para tratar estas alterações.

Alterações na gramática:
*Reconhecimento do parâmetro ": Register";
*Reconhecimento do parâmetro ": Packoffset";
*Reconhecimento do operador unário "!";
*Reconhecimento do tipo "uint".

GLSL não apresenta suporte para acesso à registradores. Assim, os parâmetros "register" e "packoffset" não podem ser utilizados. A medida adotada para solucionar este problema é avisar ao usuário deste fato e perguntar se ele deseja remover estes parâmetros. Caso ele opte por não remover, um aviso de que o código gerado será inconsistente é emitido.

O caso do tipo "uint" é similar, pois também não é suportado pela GLSL. Só que ao invés de remover a variável, a opção dada ao usuário é a de trocá-lo pelo tipo int.

18/06/2008

Passei a utilizar o Source Code Client do CodePlex para disponibilizar o código fonte.

Acrescentei as funções para tratar "return" e o tipo da função "main".

Em GLSL é necessário uma função void main() que é de onde iniciará a execução. Em HLSL, isto não é necessário.
Assim, é preciso substituir o nome da função em HLSL por "main" e o tipo da função por void. O tipo da função deve ser salvo pois ele será utilizado na saída da função.

Como a função em GLSL é do tipo void, ela não tem mais o "return". Sua saída vai ser determinada de acordo com o tipo e os parâmetros semânticos da função original,

Ex: Código HLSL

float4 pixelShader( float4 color):COLOR
{
          float4 teste =float4(0,1,0,0);
          float4 tes   = color + teste;

          return tes;
} 


Código GLSL

varying vec4 color;

void main() { 

	vec4 teste = vec4(0,1,0,0);
	vec4 tes   = color + teste;
	
	gl_FragColor = vec4(tes) ;  
} 


02/06/2008

Disponibilizei os fontes em desenvolvimento do projeto na sessão Releases nas versões de projeto para Mono e Visual Studio.

30/05/2008

Comecei a entender mais a fundo o projeto. Para isto, estudei HLSL e aprendi as principais diferenças entre as duas linguagens.
Portei o projeto para o Visual Studio 2008. E fiz uma análise do que já foi feito e do que ainda faltava fazer.
Acrescentei as "System-value semantics" à gramatica. Estas semânticas estão disponíveis apenas no Direct 3D 10.

15/05/2008

O projeto é desenvolvido em C#. Como não conhecia a linguagem, aproveitei para aprender em um curso.

Este curso faz parte do programa Students2Business, criado pela Microsoft e desenvolvido pelos Centros de Inovação e instituições de ensino parceiras. Resumidamente: o programa é gratuíto, o aluno pode escolher entre aulas de desenvolvimento ou de infra-estrutura de TI e é divido em 3 etapas. Ao final de cada etapa há uma prova classificatória para a etapa seguinte. As etapas 2 e 3 possuem duração de 40hs. Ao final da terceira etapa, os alunos que apresentarem os melhores projetos finais podem realizar gratuitamente provas de certificação Microsoft e todos os alunos que concluirem as 3 etapas terão direito a participar do evento de formatura. Maiores informações sobre o programa em http://proform.msdnbrasil.tempsite.ws/public/Default.aspx

30/04/2008

Olá!

Me chamo Bárbara e entrei no projeto para substituir o Vitor, que se afastou para fazer doutorado. Como ele, vou utilizar este espaço para periodicamente publicar os avanços do projeto.

21/03/2008

Nesta semana terminei a separação das funções em arquivos diferentes e iniciei algumas conversões de nomes de variáveis de acordo com um contexto semântico.

Por exemplo, enquanto em HLSL temos:

void main(
        float4 position   : POSITION, 
        float3 normal      : NORMAL, 
	float2 uv : TEXCOORD0,
	float3 lightDir : TEXCOORD1,
	float3 eyeDir : TEXCOORD2,
	float3 spotDir : TEXCOORD3,
	float3 lightDir1 : TEXCOORD4,
	float3 spotDir1 : TEXCOORD5,
	float4 shadowUV1 : TEXCOORD6,
	float4 shadowUV2 : TEXCOORD7)


Em GLSL teremos:

varying vec3 tangentEyeDir;
varying vec3 tangentLightDir[2];
varying vec3 tangentSpotDir[2];
varying vec4 shadowUV[2]; 
void main() { ... }


uv, position e normal no HLSL seriam as variáveis pré-definidas gl_TexCoord[0], gl_Vertex e gl_Normal no GLSL.

14/03/2008

Nesta semana comecei a construir o separador de funções. De um arquivo HLSL pode-se gerar vários GLSL. Para tal utilizo o grafo de dependências das funções declaradas no arquivo e em seus includes para separar as funções corretamente, levando para o arquivo correto a formatação desejada e os comentários pertinentes a ela.

07/03/2008

Enquanto o HLSL permite várias entradas de execução, ou seja, várias funções main, o GLSL só permite uma e exige o nome main. Desta forma, esta semana, trabalhei na criação de um grafo de chamadas de funções, para determinar quais funções estão sendo utilizadas para cada função de entrada no HLSL. Com esse grafo, poderei colocar cada função de entrada do HLSL em um arquivo diferente, levando também suas funções dependentes.

29/02/2008

Nesta semana trabalhei com a migração da declaração de variáveis uniform e varying, de uma função para o contexto do arquivo.

Do HLSL:

void funcao(
    // parameters 
    float4 position,
    uniform float4 lightPosition, // object space 
    uniform float4x4 texViewProj2) {..}


Para o GLSL
// parameters 
uniform float4 lightPosition; // object space 
uniform float4x4 texViewProj2;

void funcao(
     float4 position
) {..}


Migração simples, mas trabalhosa quando se tem uma árvore de Tokens sem ignorar espaços, comentários, novas linhas e tabulações. Acabei tento muita dificuldade em identificar os comentários relevantes que deveriam ser movidos juntamente com o parâmetro.

22/02/2008

Olá a todos.

Neste espaço vou publicar os avanços do projeto semanalmente.

Nesta última semana testei a http://www.ogre3d.org/ como arquitetura para os testes do projeto. Ao converter shaders de HLSL para GLSL, é necessário também converter o código fonte do programa que os usa, da API do DirectX para a da OpenGL. Esta parte não é coberta por este projeto, portanto é manual.

A OGRE é uma engine que permite o uso de shaders HLSL, Cg e GLSL de maneira unificada, removendo os links diretos ao DirectX ou ao OpenGL. Usando-a, não perderemos tempo migrando o código fonte dos testes, apenas com os testes dos shaders.

Também desenvolvi uma parte do conversor:
  1. A troca da função "mul" pelo "*"
  2. A inversão de parâmetros na função "cross"
  3. A remoção de parâmetros na função "main"

E estudei algumas propriedades da representação de matrizes das duas linguagens. Apesar dos elementos descritos na página Differences Between HLSL and GLSL, ainda tenho dúvidas sobre o modo de trabalho com as matrizes, especialmente se devo ou não transpô-las.

Last edited Jan 6, 2010 at 6:05 PM by chatain, version 66

Comments

No comments yet.