HL2GLSL

Source code checked in, #94877

Project Collection Service Accounts — Mon, 01 Oct 2012 22:38:35 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #94876

Project Collection Service Accounts — Mon, 01 Oct 2012 22:31:06 GMT

Checked in by server upgrade

Source code checked in, #57274

_TFSSERVICE — Wed, 28 Jul 2010 22:13:23 GMT

Checked in by server upgrade

Updated Wiki: Blog

chatain — Wed, 06 Jan 2010 18:05:23 GMT

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:

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:

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:

A troca da função "mul" pelo "*"
A inversão de parâmetros na função "cross"
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.

Updated Wiki: Home

chatain — Wed, 06 Jan 2010 17:22:20 GMT

HL2GLSL is a sub project of NDOS Project

Video presentation: http://br.youtube.com/watch?v=46Tf8M-h2Y8

Descrição do Projeto

HL2GLSL é um aplicativo para converter código da linguagem High Level Shading Language para a linguagem OpenGL Shading Language, auxiliando o porte de jogos e aplicativos gráficos construídos para executarem em ambientes Windows para ambientes Linux/MacOS. Ambas as linguagens são também utilizadas para processamento paralelo, pois executam diretamente nas placas gráficas. O projeto esta sendo construído utilizando a linguagem C#, a IDE MonoDevelop e o framework para geração de compiladores Grammatica.

Para maiores informações sobre Shaders, leia: http://www.vvvv.org/tiki-index.php?page=User+Shaders

Project Description

HL2GLSL is a translator between High Level Shading Language and OpenGL Shading Language. Since the HLSL shaders runs only in Microsoft Windows OS, the project aims to help game developers port their games to the Linux and MacOS systems. Both languages are also used to parallel processing in general purpose applications. The project uses C#, the Grammatica compiler compiler and the MonoDevelop IDE.

For more information about Shaders, see: http://www.vvvv.org/tiki-index.php?page=User+Shaders

See Also: Blog, HLSL BNF, Parsing Shaders, Development Tips, Differences Between HLSL and GLSL,GLSL Debugger,Work Plan,OpenCL Tutorials

Updated Wiki: Blog

chatain — Thu, 12 Nov 2009 18:26:35 GMT

Blog do Projeto

Unfortunately this page exists only in portuguese.

12/11/09

03/11/09

05/10/09

02/10/09

30/09/09

23/09/09

14/09/09

28/08/09

Até mais,

Leonardo Chatain

23/07/09

08/07/09

int IVsRunningDocTableEvents.OnAfterAttributeChange
int IVsRunningDocTableEvents.OnAfterDocumentWindowHide
int IVsRunningDocTableEvents.OnAfterFirstDocumentLock
int IVsRunningDocTableEvents.OnAfterSave
int IVsRunningDocTableEvents.OnBeforeDocumentWindowShow
int IVsRunningDocTableEvents.OnBeforeLastDocumentUnlock

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

26/05/09

12/05/09

using EnvDTE;

DTE dte;

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

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

      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

06/05/09

23/04/09

Melhorias na estruturação e organização do código;
Remoção de alguns bugs;
Melhor organização visual;

20/04/09

10/04/09

01/04/09

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;

25/03/09 - Hello World

        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:

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));
        }

17/03/09

08/03/2009

24/02/2009

18/02/2009

18/01/2009

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

30/10/2008 - Finishing the Debugger

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.

30/09/2008 - GLSL Debugger

18/08/2008

04/08/2008

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++;  }

  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

04/07/2008

18/06/2008

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

15/05/2008

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

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

07/03/2008

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
) {..}

22/02/2008

A troca da função "mul" pelo "*"
A inversão de parâmetros na função "cross"
A remoção de parâmetros na função "main"

Updated Wiki: OpenCL Tutorials

chatain — Thu, 12 Nov 2009 18:14:09 GMT

Olá,
estes são os tutorials disponíveis até agora:

OpenCL Tutorials - 1 (quickstart)
- versão em pdf: OpenCL Tutorials1.pdf

Até,

Leonardo Chatain

Updated Wiki: OpenCL Tutorials

chatain — Tue, 10 Nov 2009 18:43:03 GMT

Olá,
estes são os tutorials disponíveis até agora:

OpenCL Tutorials - 1 (quickstart)
- versão em pdf: OpenCL Tutorials1.pdf

Até,

Leonardo Chatain

Updated Wiki: OpenCl Tutorials - 1

chatain — Mon, 09 Nov 2009 19:51:04 GMT

Olá a todos,
este é meu primeiro tutorial sobre OpenCL, e espero que seja útil.
Não falarei aqui sobre OpenCL em si, já que há por aí suficientes introduções a OpenCL. Começarei o tutorial falando um pouco sobre o modelo de execução de OpenCL, mas será algo breve. Teremos tempo mais tarde para isso.
Neste tutorial, o que eu gostaria de providenciar é um quickstart para que fique mais tranquilo começar a usar e a fazer testes em OpenCL.

Os códigos deste tutorial encontram-se aqui:

Um programa OpenCL se divide em duas partes: a execução do host, que é a execução na CPU, como já a conhecemos. Nesta etapa apenas são adicionadas algumas instruções para preparar a execução do device.
A outra parte, a parte do device, refere-se à computação que ocorrerá, no nosso caso, na GPU. Para esta deveremos nos acostumar com alguns conceitos básicos. O primeiro deles é o de kernel. Um kernel, como já foi citado no blog, é uma função que executa no device. Uma característica importante do modelo é que temos uma execução SIMT (Single Instruction Multiple Thread), ou seja, o mesmo kernel é executado simultaneamente com dados diferentes.
Aceita essa idéia, passamos agora para alguns conceitos auxiliares:

work-item: sempre que um kernel é lançado, cada instancia em execução desse kernel torna-se um work-item. Work-items são identificados por um índice que pode ser acessado de dentro do kernel;

Na arquitetura NVIDIA, cada work-item é mapeado para uma CUDA thread;

work-group: é como os work-items são agrupados. É importante ressaltar que esse agrupamento é muito mais importante do que pode parecer a primeira vista, dado que todos os work-items pertencentes a um work-group são executados na mesma Compute Unit (que são mapeados, na arquitetura NVIDIA, para Scalar Processors (SPs)), o que lhes permite interagir entre si de forma muito mais eficiente. Work-groups são mapeados, em CUDA, para thread blocks;

Work-groups possuem, assim como os work-items, IDs únicos que podem ser acessados de dentro do kernel;

NDRange: um NDRange é um grid N-dimensional (com N = 1, 2 ou 3) de work-groups. Eles também são acessados por um ID;

Este é um exemplo de NDRange (retirado da especificação liberada pelo Khronos Group).

OK. Acho que é o suficiente por hoje. Mais tarde teremos a oportunidade de estudar mais a fundo essas características da linguagem e da arquitetura. Por hora é tudo com o qual devemos nos preocupar.
Agora gostaria de desenvolver aqui um primeiro exemplo prático. Trata-se de um programa muito simples, que computa a soma de dois vetores.
Este exemplo é fortemente baseado no exemplo análogo da NVIDIA, que vem junto com o SDK do OpenCl.

Kernel

Certo, vamos começar com a parte fácil da história: programando o kernel.
Suponhamos que estivéssemos interessados em fazer uma função comum para calcular a soma entre dois vetores. Ela seria mais ou menos assim:

void vector_add_golden (const float * const srcA,
                                     const float * const srcB,
                                     float * const golden) {
	for (int i = 0; i < iNumElements; i++)
		golden[i] = srcA[i] + srcB[i];
}

O que temos aí é um laço que itera por todos os elementos do vetor e soma seus valores, colocando o resultado no terceiro vetor.
Se quiséssemos fazer isso em OpenCL, escreveríamos uma função que somasse dois vetores, escreveriamos a função que soma um elemento do vetor, e esse elemento seria o indice da instancia do kernel em execução. Complicado? Vamos ver um exemplo:

__kernel void vector_add (__global const float * const v1,
			 __global const float * const v2,
			 __global float * const res,
			 __global const int n) {
	int idx = get_global_id(0);

	if (idx < n)
		 res[idx] = v1[idx] + v2[idx];
}

Percebam que utilizamos a palavra reservada __kernel__ para especificar que trata-se de um kernel.
Outro detalhe está em

	int idx = get_global_id(0);

essa instrução coloca em 'idx' o ID da instancia do kernel em execução.

Em seguida o que fazemos é o seguinte: O kernel se pergunta: "Meu ID está dentro dos limites do vetor?". Caso afirmativo, ele computa a soma desse elemento, e caso negativo nada é feito.

alguns detalhes adicionais:

Esse kernel deve estar obrigatóriamente em um arquivo com extensão ".cl", que deve ser separado dos arquivos ".cpp" ou ".c" que contiverem código a ser compilado.
Nos arquivos ".cl" deve constar apenas código OpenCL, visto que o código OpenCL é compilado em tempo de execução e deve ser 'invocado' de algum lugar.

Inicializando...

Ok, alta agora apenas a preparação para o lançamento do kernel.
Mas não sejamos tão apressados. Vamos entrar agora na parte mais chata deste tutorial.
OpenCL é uma linguagem de baixo nível, portanto nos cabe o trabalho de fazer grande parte das coisas que, por exemplo, CUDA faz por nós.
Mas vamos por partes. Precisaremos, inicialmente, dos headers necessários. Isso é facil:

#include <oclUtils.h>

Este é um arquivo disponibilizado juntamente com os exemplos da NVIDIA, e que nos dá algumas funções interessantes, mas que não é necessário.
Ele inclui sozinho o arquivo CL/cl.h, que é, esse sim, o verdadeiro necessário.

Faremos também algumas declarações adicionais:

#include <iostream>

#define NUM 11444777

using namespace std;

/* Estes são, em ordem, o nome do arquivo em que se encontra nosso kernel,
 * o número de elementos da computação e um inteiro que será utilizado para
 * verificação de erros;
 */
const char* cSourceFile = "vector_add.cl";
cl_int iNumElements = NUM;
cl_int error = 0;

Ok, mais uma tarefa fácil agora: alocar a memória do host, inicializá-la e computar no host para futura verificação:

        /* Aqui são alocadas as variáveis que residem na CPU. São elas os dois vetores a serem somados,
	 * e os dois vetores com os resultados da computação no host e no device;
	 */
	cl_float * const srcA = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const srcB = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const golden = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const res = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	
	/* Fazemos a devida inicialização dos vetores a serem somados.
	 */
	for (int i = 0; i < iNumElements; ++i) {
		srcA[i] = srcB[i] = i;
	}
	
	/* Aqui fazemos o cálculo da soma na CPU, para fins de verificação.
	 */
	vector_add_golden(srcA, srcB, golden);

Contexto e Command-queue

Muito bem, a esta altura já estamos com tudo pronto para criar nosso contexto e nossa command-queue.
Um contexto engloba todas as variaveis e os registradores, ou seja, o estado de uma computação. A command-queue, por outro lado, é a fila de comandos que devem ser efetuados no programa.
Para criar o contexto, utilizaremos a seguinte função:

	 cl_context clCreateContextFromType5 (cl_context_properties *properties,
						cl_device_type device_type,
						void (*pfn_notify)(const char *errinfo,
						const void *private_info, size_t cb,
						void *user_data),
						void *user_data,
						cl_int *errcode_ret)

Onde:

properties é um vetor de propriedades co contexto, que por hora será passado como NULL;
cldevicetype especifica o tipo do device. A tabela completa encontra-se na especificação, utilizaremos CLDEVICETYPE_GPU, pois estamos criando o contexto na GPU;
As proximas duas informações tampouco serão importantes por hora, e serão passadas como NULL;
errcoderet_ é o inteiro, que declaramos lá encima, que conterá o código de um eventual erro;

Se tudo der certo, será retornado CL_SUCCESS.

Nosso código fica então:

        cl_context context = clCreateContextFromType (NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando contexto" << endl;
		exit (error);
	}

Para criar a command-queue, precisaremos primeiramente da lista de devices de nosso sistema. Para fazer isto, utilizaremos a função clGetContextInfo, como pode ser visto abaixo:

        // Estes são, respectivamente, o vetor de devices a ser preenchido e o tamanho em memória desse vetor;
        cl_device_id *devices;
	size_t devices_size;
        // Chamamos a função uma primeira vez, para conseguir o tamanho em memória que deve ser alocado a devices;
	error = clGetContextInfo (context, CL_CONTEXT_DEVICES, 0, NULL, &devices_size);
        // Alocamos o espaco necessario
	devices = (cl_device_id*) malloc (devices_size);
        // E chamamos novamente a funcao para efetivamente colocar em 'devices' a informacao de todos os devices (no meu caso apenas uma GPU)
	error |= clGetContextInfo (context, CL_CONTEXT_DEVICES, devices_size, devices, 0);
	if (error != CL_SUCCESS) {
		cout << "Erro pegando informacoes do contexto;" << endl;
		exit (error);
	}

Muito bem, já estamos prontos para a criação da command_queue:

        cl_command_queue queue = clCreateCommandQueue (context, *devices, 0, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando command_queue" << endl;
		exit (error);
	}

Alocando memória no device

Ok, já criamos as estruturas necessárias para gerenciar a execução OpenCL. Vamos agora alocar os vetores para serem somados na GPU, e em seguida invocar o kernel.
Em OpenCl, temos que alocar um buffer, que é um espaço de memória a ser alocado em um contexto.
A alocação tem a seguinte assinatura:

	 cl_mem clCreateBuffer (cl_context context,
			cl_mem_flags flags,
			size_t size,
			void *host_ptr,
			cl_int *errcode_ret)

As flags podem ser:
- CL_MEM_READ_WRITE
- CL_MEM_WRITE_ONLY
- CL_MEM_READ_ONLY
- CL_MEM_USE_HOST_PTR
- CL_MEM_ALLOC_HOST_PTR
- CL_MEM_COPY_HOST_PTR

E devem ser combinadas usando |

Nosso código fica da seguinte forma:

	cl_int error2 = 0, error3 = 0;
	cl_mem srcA_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcA, &error);
	cl_mem srcB_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcB, &error2);
	cl_mem res_d = clCreateBuffer (context, CL_MEM_WRITE_ONLY, sizeof(cl_float) * iNumElements, NULL, &error3);
	if ((error | error2 | error3) != CL_SUCCESS) {
		cout << "Erro alocando memoria no host" << endl;
		exit (error|error2|error3);
	}

"Criando" um programa e um kernel

Ok, criamos os Buffers, agora precisamos "criar" um programa e compilá-lo. Na verdade o que precisamos é informar quais são nossos códigos OpenCl para que possam ser compilados.
Faremos isso usando:

	 cl_program clCreateProgramWithSource (cl_context context,
						cl_uint count,
						const char **strings,
						const size_t *lengths,	
						cl_int *errcode_ret)

para criar o programa, e:

	 cl_int clBuildProgram (cl_program program,
				cl_uint num_devices,
				const cl_device_id *device_list,
				const char *options,
				void (*pfn_notify)(cl_program, void *user_data),
				void *user_data)

para compila-lo;

Segue o código fonte desta parte:

	// Estas três linhas apenas conseguem o endereço do kernel
	size_t kernelLength;
        const char* cPathAndName = shrFindFilePath(cSourceFile, argv[0]);
        const char* cSourceCL = oclLoadProgSource(cPathAndName, "", &kernelLength);
	cl_program program = clCreateProgramWithSource (context, 1, (const char**)&cSourceCL, &kernelLength, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o programa" << endl;
		exit (error);
	}
	error = clBuildProgram (program, 0, NULL, NULL, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro buildando o programa" << endl;
		exit (error);
	}

A seguir precisamos agora criar um 'kernel object', que deve ser associado ao programa que acabamos de criar. Isso pode ser feito utilizando:

	 cl_kernel clCreateKernel (cl_program program,
				     const char *kernel_name,
				     cl_int *errcode_ret)

Ficando o código da seguinte maneira:

	cl_kernel vector_add_kernel = clCreateKernel (program, "vector_add", &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o kernel" << endl;
		exit (error);
	}

Invocando o Kernel

Ok, já criamos um contexto, descobrimos os devices, criamos um command_queue, alocamos a memória, criamos um programa e associamos os kernels.
Basta agora chamar os kernels para que esteja tudo concluído. Para fazer isso, devemos primeiramente empilhar os argumentos. Isso pode ser feito usando:

	 cl_int clSetKernelArg (cl_kernel kernel,
				cl_uint arg_index,
				size_t arg_size,
				const void *arg_value)
Onde:
* _kernel_ é o kernel ao qual deve ser empilhado o parametro;
* _{"arg_index"}_ é o índice do parâmetro a ser empilhado (primeiro parametro, segundo parametro...);
* _{"arg_size"}_ é o tamanho do parametro;
* _{"*arg_value"}_ é o valor do argumento;

Nosso código de empilhamento de parametros fica da seguinte forma:

	error = clSetKernelArg (vector_add_kernel, 0, sizeof(cl_mem), (const void*)&srcA_d);
	error |= clSetKernelArg (vector_add_kernel, 1, sizeof(cl_mem), (const void*)&srcB_d);
	error |= clSetKernelArg (vector_add_kernel, 2, sizeof(cl_mem), (const void*)&res_d);
	error |= clSetKernelArg (vector_add_kernel, 3, sizeof(cl_int), (const void*)&iNumElements);
	if (error != CL_SUCCESS) {
		cout << "Error empilhando os parametros" << endl;
		exit (error);
	}

Agora chegou o tão esperado momento de chamar o kernel. Para tanto utilizaremos a seguinte função:

       cl_int clEnqueueNDRangeKernel (cl_command_queue command_queue,
						cl_kernel kernel,
						cl_uint work_dim,
						const size_t *global_work_offset,
						const size_t *global_work_size,
						const size_t *local_work_size,
						cl_uint num_events_in_wait_list,
						const cl_event *event_wait_list,
						cl_event *event)

Onde:

work_dim é o número de dimensões dos work-items (1,2 ou 3);
*global_work_offset deve ser mantido NULL (pelo menos nesta versão do driver opencl da NVIDIA;
*global_work_size é um vetor que descreve as dimensões dos work-items;
*local_work_size é o número de work-items por work-group (em uma analogia a CUDA, é o número de threads per block;
O retorno é o código de erro;
os outros parametros não importam por hora;

Aqui declaramos o numero de work-items por work-group e o número de work-items total, e em seguida chamamos o kernel;
shrRoundUp arredonda o numero de elementos para o maior multiplo do numero de work-items por work-group;

	size_t work_groups = 256;
        size_t work_items = shrRoundUp((int)work_groups, iNumElements);

	error = clEnqueueNDRangeKernel (queue, vector_add_kernel, 1, NULL, &work_items, &work_groups, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro empilhando os kernels" << endl;
		exit (error);
	}

Recuperando os valores e fazendo o check:

Chamamos o kernel! Maraviha! Não foi tão difícil.
Agora temos que conseguir de volta o resultado. Para isso, devemos enfileirar uma requisição de leitura de buffer. Isso pode ser feito da seguinte maneira:

	 cl_int clEnqueueReadBuffer (cl_command_queue command_queue,
					cl_mem buffer,
					cl_bool blocking_read,
					size_t offset,
					size_t cb,
					void *ptr,
					cl_uint num_events_in_wait_list,
					const cl_event *event_wait_list,
					cl_event *event)

onde:

buffer é o buffer alocado no device que queremos ler;
blocking_read é um booleano que indica se a leitura será bloqueante ou não. Isso não é importante agora;
cb é o tamanho dessa memória;
*ptr é um ponteiro para um espaço de memória (que ja deve estar com cb bytes alocados) de destino, no HOST;
O retorno é o código de erro;

Nosso código fica entõa da seguinte maneira:

	error = clEnqueueReadBuffer (queue, res_d, CL_TRUE, 0, sizeof(cl_float)*iNumElements, (void *)res, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro lendo o buffer" << endl;
		exit (error);
	}

Faremos agora o check com a computação no host:

       for (int i = 0; i < iNumElements; ++i) {
		if (golden[i] != res[i]) {
			cout << "Nao fecha a computacao" << endl;
			exit (1);
		}
	}
	cout << "Passou no TESTE!!!" << endl;

E pronto, nosso programa está concluído!
Pode parecer que é um esforço demasiado, mas a questão é que essas etapas apenas serão desenvolvidas uma vez. Todos os códigos utilizarão basicamente a mesma estrutura, e não acredito que leve muito tempo para alguem fazer algum wrapper.

Limpeza

Feito o trabalho, se quisermos ser programadores responsáveis, devemos limpar a memória que utilizamos. Toda inicialização com clCreate deve ser desalocada usando clRelease
Assim temos, para nosso exemplo:

    clReleaseKernel(vector_add_kernel);  
    clReleaseProgram(program);
    clReleaseCommandQueue(queue);
    clReleaseContext(context);
    clReleaseMemObject(srcA_d);
    clReleaseMemObject(srcB_d);
    clReleaseMemObject(res_d);

Chegamos assim ao fim deste tutorial.
Muito obrigado pela atenção. Quaisquer dúvidas podem me contatar.
Abraços

Leonardo Chatain

Updated Wiki: OpenCL Tutorials

chatain — Mon, 09 Nov 2009 19:45:33 GMT

Olá,
estes são os tutorials disponíveis até agora:

OpenCL Tutorials - 1 (quickstart)
- versão em pdf: OpenCL Tutorials1.pdf

Até,

Leonardo Chatain

Updated Wiki: OpenCL Tutorials

chatain — Mon, 09 Nov 2009 19:44:53 GMT

Olá,
estes são os tutorials disponíveis até agora:

OpenCL Tutorials - 1 (quickstart)
- versão em pdf: OpenCL Tutorials1.pdf

Até,

Leonardo Chatain

Updated Wiki: OpenCl Tutorials - 1

chatain — Mon, 09 Nov 2009 19:43:02 GMT

work-item: sempre que um kernel é lançado, cada instancia em execução desse kernel torna-se um work-item. Work-items são identificados por um índice que pode ser acessado de dentro do kernel;

Na arquitetura NVIDIA, cada work-item é mapeado para uma CUDA thread;

work-group: é como os work-items são agrupados. É importante ressaltar que esse agrupamento é muito mais importante do que pode parecer a primeira vista, dado que todos os work-items pertencentes a um work-group são executados na mesma Compute Unit (que são mapeados, na arquitetura NVIDIA, para Scalar Processors (SPs)), o que lhes permite interagir entre si de forma muito mais eficiente. Work-groups são mapeados, em CUDA, para thread blocks;

Work-groups possuem, assim como os work-items, IDs únicos que podem ser acessados de dentro do kernel;

NDRange: um NDRange é um grid N-dimensional (com N = 1, 2 ou 3) de work-groups. Eles também são acessados por um ID;

Este é um exemplo de NDRange (retirado da especificação liberada pelo Khronos Group).

OK. Acho que é o suficiente por hoje de parafernália teórica. Mais tarde teremos a oportunidade de estudar mais a fundo essas características da linguagem. Por hora é tudo com o qual devemos nos preocupar.
Agora gostaria de desenvolver aqui um primeiro exemplo prático. Trata-se de um programa muito simples, que computa a soma de dois vetores.
Este exemplo é fortemente baseado no exemplo análogo da NVIDIA, que vem junto com o SDK do OpenCl.

Kernel

void vector_add_golden (const float * const srcA,
                                     const float * const srcB,
                                     float * const golden) {
	for (int i = 0; i < iNumElements; i++)
		golden[i] = srcA[i] + srcB[i];
}

__kernel void vector_add (__global const float * const v1,
			 __global const float * const v2,
			 __global float * const res,
			 __global const int n) {
	int idx = get_global_id(0);

	if (idx < n)
		 res[idx] = v1[idx] + v2[idx];
}

Percebam que utilizamos a palavra reservada __kernel__ para especificar que trata-se de um kernel.
Outro detalhe está em

	int idx = get_global_id(0);

alguns detalhes adicionais:

Inicializando...

#include <oclUtils.h>

#include <iostream>

#define NUM 11444777

using namespace std;

/* Estes são, em ordem, o nome do arquivo em que se encontra nosso kernel,
 * o número de elementos da computação e um inteiro que será utilizado para
 * verificação de erros;
 */
const char* cSourceFile = "vector_add.cl";
cl_int iNumElements = NUM;
cl_int error = 0;

Ok, mais uma tarefa fácil agora: alocar a memória do host, inicializá-la e computar no host para futura verificação:

        /* Aqui são alocadas as variáveis que residem na CPU. São elas os dois vetores a serem somados,
	 * e os dois vetores com os resultados da computação no host e no device;
	 */
	cl_float * const srcA = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const srcB = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const golden = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const res = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	
	/* Fazemos a devida inicialização dos vetores a serem somados.
	 */
	for (int i = 0; i < iNumElements; ++i) {
		srcA[i] = srcB[i] = i;
	}
	
	/* Aqui fazemos o cálculo da soma na CPU, para fins de verificação.
	 */
	vector_add_golden(srcA, srcB, golden);

Contexto e Command-queue

	 cl_context clCreateContextFromType5 (cl_context_properties *properties,
						cl_device_type device_type,
						void (*pfn_notify)(const char *errinfo,
						const void *private_info, size_t cb,
						void *user_data),
						void *user_data,
						cl_int *errcode_ret)

Onde:

properties é um vetor de propriedades co contexto, que por hora será passado como NULL;
cldevicetype especifica o tipo do device. A tabela completa encontra-se na especificação, utilizaremos CLDEVICETYPE_GPU, pois estamos criando o contexto na GPU;
As proximas duas informações tampouco serão importantes por hora, e serão passadas como NULL;
errcoderet_ é o inteiro, que declaramos lá encima, que conterá o código de um eventual erro;

Se tudo der certo, será retornado CL_SUCCESS.

Nosso código fica então:

        cl_context context = clCreateContextFromType (NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando contexto" << endl;
		exit (error);
	}

Para criar a command-queue, precisaremos primeiramente da lista de devices de nosso sistema. Para fazer isto, utilizaremos a função clGetContextInfo, como pode ser visto abaixo:

        // Estes são, respectivamente, o vetor de devices a ser preenchido e o tamanho em memória desse vetor;
        cl_device_id *devices;
	size_t devices_size;
        // Chamamos a função uma primeira vez, para conseguir o tamanho em memória que deve ser alocado a devices;
	error = clGetContextInfo (context, CL_CONTEXT_DEVICES, 0, NULL, &devices_size);
        // Alocamos o espaco necessario
	devices = (cl_device_id*) malloc (devices_size);
        // E chamamos novamente a funcao para efetivamente colocar em 'devices' a informacao de todos os devices (no meu caso apenas uma GPU)
	error |= clGetContextInfo (context, CL_CONTEXT_DEVICES, devices_size, devices, 0);
	if (error != CL_SUCCESS) {
		cout << "Erro pegando informacoes do contexto;" << endl;
		exit (error);
	}

Muito bem, já estamos prontos para a criação da command_queue:

        cl_command_queue queue = clCreateCommandQueue (context, *devices, 0, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando command_queue" << endl;
		exit (error);
	}

Alocando memória no device

	 cl_mem clCreateBuffer (cl_context context,
			cl_mem_flags flags,
			size_t size,
			void *host_ptr,
			cl_int *errcode_ret)

As flags podem ser:
- CL_MEM_READ_WRITE
- CL_MEM_WRITE_ONLY
- CL_MEM_READ_ONLY
- CL_MEM_USE_HOST_PTR
- CL_MEM_ALLOC_HOST_PTR
- CL_MEM_COPY_HOST_PTR

E devem ser combinadas usando |

Nosso código fica da seguinte forma:

	cl_int error2 = 0, error3 = 0;
	cl_mem srcA_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcA, &error);
	cl_mem srcB_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcB, &error2);
	cl_mem res_d = clCreateBuffer (context, CL_MEM_WRITE_ONLY, sizeof(cl_float) * iNumElements, NULL, &error3);
	if ((error | error2 | error3) != CL_SUCCESS) {
		cout << "Erro alocando memoria no host" << endl;
		exit (error|error2|error3);
	}

"Criando" um programa e um kernel

	 cl_program clCreateProgramWithSource (cl_context context,
						cl_uint count,
						const char **strings,
						const size_t *lengths,	
						cl_int *errcode_ret)

para criar o programa, e:

	 cl_int clBuildProgram (cl_program program,
				cl_uint num_devices,
				const cl_device_id *device_list,
				const char *options,
				void (*pfn_notify)(cl_program, void *user_data),
				void *user_data)

para compila-lo;

Segue o código fonte desta parte:

	// Estas três linhas apenas conseguem o endereço do kernel
	size_t kernelLength;
        const char* cPathAndName = shrFindFilePath(cSourceFile, argv[0]);
        const char* cSourceCL = oclLoadProgSource(cPathAndName, "", &kernelLength);
	cl_program program = clCreateProgramWithSource (context, 1, (const char**)&cSourceCL, &kernelLength, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o programa" << endl;
		exit (error);
	}
	error = clBuildProgram (program, 0, NULL, NULL, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro buildando o programa" << endl;
		exit (error);
	}

A seguir precisamos agora criar um 'kernel object', que deve ser associado ao programa que acabamos de criar. Isso pode ser feito utilizando:

	 cl_kernel clCreateKernel (cl_program program,
				     const char *kernel_name,
				     cl_int *errcode_ret)

Ficando o código da seguinte maneira:

	cl_kernel vector_add_kernel = clCreateKernel (program, "vector_add", &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o kernel" << endl;
		exit (error);
	}

Invocando o Kernel

	 cl_int clSetKernelArg (cl_kernel kernel,
				cl_uint arg_index,
				size_t arg_size,
				const void *arg_value)
Onde:
* _kernel_ é o kernel ao qual deve ser empilhado o parametro;
* _{"arg_index"}_ é o índice do parâmetro a ser empilhado (primeiro parametro, segundo parametro...);
* _{"arg_size"}_ é o tamanho do parametro;
* _{"*arg_value"}_ é o valor do argumento;

Nosso código de empilhamento de parametros fica da seguinte forma:

	error = clSetKernelArg (vector_add_kernel, 0, sizeof(cl_mem), (const void*)&srcA_d);
	error |= clSetKernelArg (vector_add_kernel, 1, sizeof(cl_mem), (const void*)&srcB_d);
	error |= clSetKernelArg (vector_add_kernel, 2, sizeof(cl_mem), (const void*)&res_d);
	error |= clSetKernelArg (vector_add_kernel, 3, sizeof(cl_int), (const void*)&iNumElements);
	if (error != CL_SUCCESS) {
		cout << "Error empilhando os parametros" << endl;
		exit (error);
	}

Agora chegou o tão esperado momento de chamar o kernel. Para tanto utilizaremos a seguinte função:

       cl_int clEnqueueNDRangeKernel (cl_command_queue command_queue,
						cl_kernel kernel,
						cl_uint work_dim,
						const size_t *global_work_offset,
						const size_t *global_work_size,
						const size_t *local_work_size,
						cl_uint num_events_in_wait_list,
						const cl_event *event_wait_list,
						cl_event *event)

Onde:

work_dim é o número de dimensões dos work-items (1,2 ou 3);
*global_work_offset deve ser mantido NULL (pelo menos nesta versão do driver opencl da NVIDIA;
*global_work_size é um vetor que descreve as dimensões dos work-items;
*local_work_size é o número de work-items por work-group (em uma analogia a CUDA, é o número de threads per block;
O retorno é o código de erro;
os outros parametros não importam por hora;

	size_t work_groups = 256;
        size_t work_items = shrRoundUp((int)work_groups, iNumElements);

	error = clEnqueueNDRangeKernel (queue, vector_add_kernel, 1, NULL, &work_items, &work_groups, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro empilhando os kernels" << endl;
		exit (error);
	}

Recuperando os valores e fazendo o check:

	 cl_int clEnqueueReadBuffer (cl_command_queue command_queue,
					cl_mem buffer,
					cl_bool blocking_read,
					size_t offset,
					size_t cb,
					void *ptr,
					cl_uint num_events_in_wait_list,
					const cl_event *event_wait_list,
					cl_event *event)

onde:

buffer é o buffer alocado no device que queremos ler;
blocking_read é um booleano que indica se a leitura será bloqueante ou não. Isso não é importante agora;
cb é o tamanho dessa memória;
*ptr é um ponteiro para um espaço de memória (que ja deve estar com cb bytes alocados) de destino, no HOST;
O retorno é o código de erro;

Nosso código fica entõa da seguinte maneira:

	error = clEnqueueReadBuffer (queue, res_d, CL_TRUE, 0, sizeof(cl_float)*iNumElements, (void *)res, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro lendo o buffer" << endl;
		exit (error);
	}

Faremos agora o check com a computação no host:

       for (int i = 0; i < iNumElements; ++i) {
		if (golden[i] != res[i]) {
			cout << "Nao fecha a computacao" << endl;
			exit (1);
		}
	}
	cout << "Passou no TESTE!!!" << endl;

Limpeza

    clReleaseKernel(vector_add_kernel);  
    clReleaseProgram(program);
    clReleaseCommandQueue(queue);
    clReleaseContext(context);
    clReleaseMemObject(srcA_d);
    clReleaseMemObject(srcB_d);
    clReleaseMemObject(res_d);

Chegamos assim ao fim deste tutorial.
Muito obrigado pela atenção. Quaisquer dúvidas podem me contatar.
Abraços

Leonardo Chatain

Updated Wiki: OpenCl Tutorials - 1

chatain — Mon, 09 Nov 2009 19:41:03 GMT

work-item: sempre que um kernel é lançado, cada instancia em execução desse kernel torna-se um work-item. Work-items são identificados por um índice que pode ser acessado de dentro do kernel;

Na arquitetura nVidia, cada work-item é mapeado para uma CUDA thread;

work-group: é como os work-items são agrupados. É importante ressaltar que esse agrupamento é muito mais importante do que pode parecer a primeira vista, dado que todos os work-items pertencentes a um work-group são executados na mesma Compute Unit (que são mapeados, na arquitetura nVidia, para Scalar Processors (SPs)), o que lhes permite interagir entre si de forma muito mais eficiente. Work-groups são mapeados, em CUDA, para thread blocks;

Work-groups possuem, assim como os work-items, IDs únicos que podem ser acessados de dentro do kernel;

NDRange: um NDRange é um grid N-dimensional (com N = 1, 2 ou 3) de work-groups. Eles também são acessados por um ID;

Kernel

void vector_add_golden (const float * const srcA,
                                     const float * const srcB,
                                     float * const golden) {
	for (int i = 0; i < iNumElements; i++)
		golden[i] = srcA[i] + srcB[i];
}

__kernel void vector_add (__global const float * const v1,
			 __global const float * const v2,
			 __global float * const res,
			 __global const int n) {
	int idx = get_global_id(0);

	if (idx < n)
		 res[idx] = v1[idx] + v2[idx];
}

Percebam que utilizamos a palavra reservada __kernel__ para especificar que trata-se de um kernel.
Outro detalhe está em

	int idx = get_global_id(0);

alguns detalhes adicionais:

Inicializando...

#include <oclUtils.h>

Este é um arquivo disponibilizado juntamente com os exemplos da nVidia, e que nos dá algumas funções interessantes, mas que não é necessário.
Ele inclui sozinho o arquivo CL/cl.h, que é, esse sim, o verdadeiro necessário.

Faremos também algumas declarações adicionais:

#include <iostream>

#define NUM 11444777

using namespace std;

/* Estes são, em ordem, o nome do arquivo em que se encontra nosso kernel,
 * o número de elementos da computação e um inteiro que será utilizado para
 * verificação de erros;
 */
const char* cSourceFile = "vector_add.cl";
cl_int iNumElements = NUM;
cl_int error = 0;

Ok, mais uma tarefa fácil agora: alocar a memória do host, inicializá-la e computar no host para futura verificação:

        /* Aqui são alocadas as variáveis que residem na CPU. São elas os dois vetores a serem somados,
	 * e os dois vetores com os resultados da computação no host e no device;
	 */
	cl_float * const srcA = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const srcB = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const golden = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const res = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	
	/* Fazemos a devida inicialização dos vetores a serem somados.
	 */
	for (int i = 0; i < iNumElements; ++i) {
		srcA[i] = srcB[i] = i;
	}
	
	/* Aqui fazemos o cálculo da soma na CPU, para fins de verificação.
	 */
	vector_add_golden(srcA, srcB, golden);

Contexto e Command-queue

	 cl_context clCreateContextFromType5 (cl_context_properties *properties,
						cl_device_type device_type,
						void (*pfn_notify)(const char *errinfo,
						const void *private_info, size_t cb,
						void *user_data),
						void *user_data,
						cl_int *errcode_ret)

Onde:

properties é um vetor de propriedades co contexto, que por hora será passado como NULL;
cldevicetype especifica o tipo do device. A tabela completa encontra-se na especificação, utilizaremos CLDEVICETYPE_GPU, pois estamos criando o contexto na GPU;
As proximas duas informações tampouco serão importantes por hora, e serão passadas como NULL;
errcoderet_ é o inteiro, que declaramos lá encima, que conterá o código de um eventual erro;

Se tudo der certo, será retornado CL_SUCCESS.

Nosso código fica então:

        cl_context context = clCreateContextFromType (NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando contexto" << endl;
		exit (error);
	}

Para criar a command-queue, precisaremos primeiramente da lista de devices de nosso sistema. Para fazer isto, utilizaremos a função clGetContextInfo, como pode ser visto abaixo:

        // Estes são, respectivamente, o vetor de devices a ser preenchido e o tamanho em memória desse vetor;
        cl_device_id *devices;
	size_t devices_size;
        // Chamamos a função uma primeira vez, para conseguir o tamanho em memória que deve ser alocado a devices;
	error = clGetContextInfo (context, CL_CONTEXT_DEVICES, 0, NULL, &devices_size);
        // Alocamos o espaco necessario
	devices = (cl_device_id*) malloc (devices_size);
        // E chamamos novamente a funcao para efetivamente colocar em 'devices' a informacao de todos os devices (no meu caso apenas uma GPU)
	error |= clGetContextInfo (context, CL_CONTEXT_DEVICES, devices_size, devices, 0);
	if (error != CL_SUCCESS) {
		cout << "Erro pegando informacoes do contexto;" << endl;
		exit (error);
	}

Muito bem, já estamos prontos para a criação da command_queue:

        cl_command_queue queue = clCreateCommandQueue (context, *devices, 0, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando command_queue" << endl;
		exit (error);
	}

Alocando memória no device

	 cl_mem clCreateBuffer (cl_context context,
			cl_mem_flags flags,
			size_t size,
			void *host_ptr,
			cl_int *errcode_ret)

As flags podem ser:
- CL_MEM_READ_WRITE
- CL_MEM_WRITE_ONLY
- CL_MEM_READ_ONLY
- CL_MEM_USE_HOST_PTR
- CL_MEM_ALLOC_HOST_PTR
- CL_MEM_COPY_HOST_PTR

E devem ser combinadas usando |

Nosso código fica da seguinte forma:

	cl_int error2 = 0, error3 = 0;
	cl_mem srcA_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcA, &error);
	cl_mem srcB_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcB, &error2);
	cl_mem res_d = clCreateBuffer (context, CL_MEM_WRITE_ONLY, sizeof(cl_float) * iNumElements, NULL, &error3);
	if ((error | error2 | error3) != CL_SUCCESS) {
		cout << "Erro alocando memoria no host" << endl;
		exit (error|error2|error3);
	}

"Criando" um programa e um kernel

	 cl_program clCreateProgramWithSource (cl_context context,
						cl_uint count,
						const char **strings,
						const size_t *lengths,	
						cl_int *errcode_ret)

para criar o programa, e:

	 cl_int clBuildProgram (cl_program program,
				cl_uint num_devices,
				const cl_device_id *device_list,
				const char *options,
				void (*pfn_notify)(cl_program, void *user_data),
				void *user_data)

para compila-lo;

Segue o código fonte desta parte:

	// Estas três linhas apenas conseguem o endereço do kernel
	size_t kernelLength;
        const char* cPathAndName = shrFindFilePath(cSourceFile, argv[0]);
        const char* cSourceCL = oclLoadProgSource(cPathAndName, "", &kernelLength);
	cl_program program = clCreateProgramWithSource (context, 1, (const char**)&cSourceCL, &kernelLength, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o programa" << endl;
		exit (error);
	}
	error = clBuildProgram (program, 0, NULL, NULL, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro buildando o programa" << endl;
		exit (error);
	}

A seguir precisamos agora criar um 'kernel object', que deve ser associado ao programa que acabamos de criar. Isso pode ser feito utilizando:

	 cl_kernel clCreateKernel (cl_program program,
				     const char *kernel_name,
				     cl_int *errcode_ret)

Ficando o código da seguinte maneira:

	cl_kernel vector_add_kernel = clCreateKernel (program, "vector_add", &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o kernel" << endl;
		exit (error);
	}

Invocando o Kernel

	 cl_int clSetKernelArg (cl_kernel kernel,
				cl_uint arg_index,
				size_t arg_size,
				const void *arg_value)
Onde:
* _kernel_ é o kernel ao qual deve ser empilhado o parametro;
* _{"arg_index"}_ é o índice do parâmetro a ser empilhado (primeiro parametro, segundo parametro...);
* _{"arg_size"}_ é o tamanho do parametro;
* _{"*arg_value"}_ é o valor do argumento;

Nosso código de empilhamento de parametros fica da seguinte forma:

	error = clSetKernelArg (vector_add_kernel, 0, sizeof(cl_mem), (const void*)&srcA_d);
	error |= clSetKernelArg (vector_add_kernel, 1, sizeof(cl_mem), (const void*)&srcB_d);
	error |= clSetKernelArg (vector_add_kernel, 2, sizeof(cl_mem), (const void*)&res_d);
	error |= clSetKernelArg (vector_add_kernel, 3, sizeof(cl_int), (const void*)&iNumElements);
	if (error != CL_SUCCESS) {
		cout << "Error empilhando os parametros" << endl;
		exit (error);
	}

Agora chegou o tão esperado momento de chamar o kernel. Para tanto utilizaremos a seguinte função:

       cl_int clEnqueueNDRangeKernel (cl_command_queue command_queue,
						cl_kernel kernel,
						cl_uint work_dim,
						const size_t *global_work_offset,
						const size_t *global_work_size,
						const size_t *local_work_size,
						cl_uint num_events_in_wait_list,
						const cl_event *event_wait_list,
						cl_event *event)

Onde:

work_dim é o número de dimensões dos work-items (1,2 ou 3);
*global_work_offset deve ser mantido NULL (pelo menos nesta versão do driver opencl da Nvidia;
*global_work_size é um vetor que descreve as dimensões dos work-items;
*local_work_size é o número de work-items por work-group (em uma analogia a CUDA, é o número de threads per block;
O retorno é o código de erro;
os outros parametros não importam por hora;

	size_t work_groups = 256;
        size_t work_items = shrRoundUp((int)work_groups, iNumElements);

	error = clEnqueueNDRangeKernel (queue, vector_add_kernel, 1, NULL, &work_items, &work_groups, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro empilhando os kernels" << endl;
		exit (error);
	}

Recuperando os valores e fazendo o check:

	 cl_int clEnqueueReadBuffer (cl_command_queue command_queue,
					cl_mem buffer,
					cl_bool blocking_read,
					size_t offset,
					size_t cb,
					void *ptr,
					cl_uint num_events_in_wait_list,
					const cl_event *event_wait_list,
					cl_event *event)

onde:

buffer é o buffer alocado no device que queremos ler;
blocking_read é um booleano que indica se a leitura será bloqueante ou não. Isso não é importante agora;
cb é o tamanho dessa memória;
*ptr é um ponteiro para um espaço de memória (que ja deve estar com cb bytes alocados) de destino, no HOST;
O retorno é o código de erro;

Nosso código fica entõa da seguinte maneira:

	error = clEnqueueReadBuffer (queue, res_d, CL_TRUE, 0, sizeof(cl_float)*iNumElements, (void *)res, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro lendo o buffer" << endl;
		exit (error);
	}

Faremos agora o check com a computação no host:

       for (int i = 0; i < iNumElements; ++i) {
		if (golden[i] != res[i]) {
			cout << "Nao fecha a computacao" << endl;
			exit (1);
		}
	}
	cout << "Passou no TESTE!!!" << endl;

Limpeza

    clReleaseKernel(vector_add_kernel);  
    clReleaseProgram(program);
    clReleaseCommandQueue(queue);
    clReleaseContext(context);
    clReleaseMemObject(srcA_d);
    clReleaseMemObject(srcB_d);
    clReleaseMemObject(res_d);

Chegamos assim ao fim deste tutorial.
Muito obrigado pela atenção. Quaisquer dúvidas podem me contatar.
Abraços

Leonardo Chatain

Updated Wiki: OpenCl Tutorials - 1

chatain — Mon, 09 Nov 2009 19:38:12 GMT

work-item: sempre que um kernel é lançado, cada instancia em execução desse kernel torna-se um work-item. Work-items são identificados por um índice que pode ser acessado de dentro do kernel;

Na arquitetura nVidia, cada work-item é mapeado para uma CUDA thread;

work-group: é como os work-items são agrupados. É importante ressaltar que esse agrupamento é muito mais importante do que pode parecer a primeira vista, dado que todos os work-items pertencentes a um work-group são executados na mesma Compute Unit (que são mapeados, na arquitetura nVidia, para Scalar Processors (SPs)), o que lhes permite interagir entre si de forma muito mais eficiente. Work-groups são mapeados, em CUDA, para thread blocks;

Work-groups possuem, assim como os work-items, IDs únicos que podem ser acessados de dentro do kernel;

NDRange: um NDRange é um grid N-dimensional (com N = 1, 2 ou 3) de work-groups. Eles também são acessados por um ID;

Kernel

void vector_add_golden (const float * const srcA,
                                     const float * const srcB,
                                     float * const golden) {
	for (int i = 0; i < iNumElements; i++)
		golden[i] = srcA[i] + srcB[i];
}

__kernel void vector_add (__global const float * const v1,
			 __global const float * const v2,
			 __global float * const res,
			 __global const int n) {
	int idx = get_global_id(0);

	if (idx < n)
		 res[idx] = v1[idx] + v2[idx];
}

Percebam que utilizamos a palavra reservada __kernel__ para especificar que trata-se de um kernel :)
Outro detalhe está em

	int idx = get_global_id(0);

alguns detalhes adicionais:

Inicializando...

#include <oclUtils.h>

#include <iostream>

#define NUM 11444777

using namespace std;

/* Estes são, em ordem, o nome do arquivo em que se encontra nosso kernel,
 * o número de elementos da computação e um inteiro que será utilizado para
 * verificação de erros;
 */
const char* cSourceFile = "vector_add.cl";
cl_int iNumElements = NUM;
cl_int error = 0;

Ok, mais uma tarefa fácil agora: alocar a memória do host, inicializá-la e computar no host para futura verificação:

        /* Aqui são alocadas as variáveis que residem na CPU. São elas os dois vetores a serem somados,
	 * e os dois vetores com os resultados da computação no host e no device;
	 */
	cl_float * const srcA = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const srcB = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const golden = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const res = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	
	/* Fazemos a devida inicialização dos vetores a serem somados.
	 */
	for (int i = 0; i < iNumElements; ++i) {
		srcA[i] = srcB[i] = i;
	}
	
	/* Aqui fazemos o cálculo da soma na CPU, para fins de verificação.
	 */
	vector_add_golden(srcA, srcB, golden);

Contexto e Command-queue

	 cl_context clCreateContextFromType5 (cl_context_properties *properties,
						cl_device_type device_type,
						void (*pfn_notify)(const char *errinfo,
						const void *private_info, size_t cb,
						void *user_data),
						void *user_data,
						cl_int *errcode_ret)

Onde:

properties é um vetor de propriedades co contexto, que por hora será passado como NULL;
cldevicetype especifica o tipo do device. A tabela completa encontra-se na especificação, utilizaremos CLDEVICETYPE_GPU, pois estamos criando o contexto na GPU;
As proximas duas informações tampouco serão importantes por hora, e serão passadas como NULL;
errcoderet_ é o inteiro, que declaramos lá encima, que conterá o código de um eventual erro;

Se tudo der certo, será retornado CL_SUCCESS.

Nosso código fica então:

        cl_context context = clCreateContextFromType (NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando contexto" << endl;
		exit (error);
	}

Para criar a command-queue, precisaremos primeiramente da lista de devices de nosso sistema. Para fazer isto, utilizaremos a função clGetContextInfo, como pode ser visto abaixo:

        // Estes são, respectivamente, o vetor de devices a ser preenchido e o tamanho em memória desse vetor;
        cl_device_id *devices;
	size_t devices_size;
        // Chamamos a função uma primeira vez, para conseguir o tamanho em memória que deve ser alocado a devices;
	error = clGetContextInfo (context, CL_CONTEXT_DEVICES, 0, NULL, &devices_size);
        // Alocamos o espaco necessario
	devices = (cl_device_id*) malloc (devices_size);
        // E chamamos novamente a funcao para efetivamente colocar em 'devices' a informacao de todos os devices (no meu caso apenas uma GPU)
	error |= clGetContextInfo (context, CL_CONTEXT_DEVICES, devices_size, devices, 0);
	if (error != CL_SUCCESS) {
		cout << "Erro pegando informacoes do contexto;" << endl;
		exit (error);
	}

Muito bem, já estamos prontos para a criação da command_queue:

        cl_command_queue queue = clCreateCommandQueue (context, *devices, 0, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando command_queue" << endl;
		exit (error);
	}

Alocando memória no device

	 cl_mem clCreateBuffer (cl_context context,
			cl_mem_flags flags,
			size_t size,
			void *host_ptr,
			cl_int *errcode_ret)

As flags podem ser:
- CL_MEM_READ_WRITE
- CL_MEM_WRITE_ONLY
- CL_MEM_READ_ONLY
- CL_MEM_USE_HOST_PTR
- CL_MEM_ALLOC_HOST_PTR
- CL_MEM_COPY_HOST_PTR

E devem ser combinadas usando |

Nosso código fica da seguinte forma:

	cl_int error2 = 0, error3 = 0;
	cl_mem srcA_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcA, &error);
	cl_mem srcB_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcB, &error2);
	cl_mem res_d = clCreateBuffer (context, CL_MEM_WRITE_ONLY, sizeof(cl_float) * iNumElements, NULL, &error3);
	if ((error | error2 | error3) != CL_SUCCESS) {
		cout << "Erro alocando memoria no host" << endl;
		exit (error|error2|error3);
	}

"Criando" um programa e um kernel

	 cl_program clCreateProgramWithSource (cl_context context,
						cl_uint count,
						const char **strings,
						const size_t *lengths,	
						cl_int *errcode_ret)

para criar o programa, e:

	 cl_int clBuildProgram (cl_program program,
				cl_uint num_devices,
				const cl_device_id *device_list,
				const char *options,
				void (*pfn_notify)(cl_program, void *user_data),
				void *user_data)

para compila-lo;

Segue o código fonte desta parte:

	// Estas três linhas apenas conseguem o endereço do kernel
	size_t kernelLength;
        const char* cPathAndName = shrFindFilePath(cSourceFile, argv[0]);
        const char* cSourceCL = oclLoadProgSource(cPathAndName, "", &kernelLength);
	cl_program program = clCreateProgramWithSource (context, 1, (const char**)&cSourceCL, &kernelLength, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o programa" << endl;
		exit (error);
	}
	error = clBuildProgram (program, 0, NULL, NULL, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro buildando o programa" << endl;
		exit (error);
	}

A seguir precisamos agora criar um 'kernel object', que deve ser associado ao programa que acabamos de criar. Isso pode ser feito utilizando:

	 cl_kernel clCreateKernel (cl_program program,
				     const char *kernel_name,
				     cl_int *errcode_ret)

Ficando o código da seguinte maneira:

	cl_kernel vector_add_kernel = clCreateKernel (program, "vector_add", &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o kernel" << endl;
		exit (error);
	}

Invocando o Kernel

	 cl_int clSetKernelArg (cl_kernel kernel,
				cl_uint arg_index,
				size_t arg_size,
				const void *arg_value)
Onde:
* _kernel_ é o kernel ao qual deve ser empilhado o parametro;
* _{"arg_index"}_ é o índice do parâmetro a ser empilhado (primeiro parametro, segundo parametro...);
* _{"arg_size"}_ é o tamanho do parametro;
* _{"*arg_value"}_ é o valor do argumento;

Nosso código de empilhamento de parametros fica da seguinte forma:

	error = clSetKernelArg (vector_add_kernel, 0, sizeof(cl_mem), (const void*)&srcA_d);
	error |= clSetKernelArg (vector_add_kernel, 1, sizeof(cl_mem), (const void*)&srcB_d);
	error |= clSetKernelArg (vector_add_kernel, 2, sizeof(cl_mem), (const void*)&res_d);
	error |= clSetKernelArg (vector_add_kernel, 3, sizeof(cl_int), (const void*)&iNumElements);
	if (error != CL_SUCCESS) {
		cout << "Error empilhando os parametros" << endl;
		exit (error);
	}

Agora chegou o tão esperado momento de chamar o kernel. Para tanto utilizaremos a seguinte função:

       cl_int clEnqueueNDRangeKernel (cl_command_queue command_queue,
						cl_kernel kernel,
						cl_uint work_dim,
						const size_t *global_work_offset,
						const size_t *global_work_size,
						const size_t *local_work_size,
						cl_uint num_events_in_wait_list,
						const cl_event *event_wait_list,
						cl_event *event)

Onde:

work_dim é o número de dimensões dos work-items (1,2 ou 3);
*global_work_offset deve ser mantido NULL (pelo menos nesta versão do driver opencl da Nvidia;
*global_work_size é um vetor que descreve as dimensões dos work-items;
*local_work_size é o número de work-items por work-group (em uma analogia a CUDA, é o número de threads per block;
O retorno é o código de erro;
os outros parametros não importam por hora;

	size_t work_groups = 256;
        size_t work_items = shrRoundUp((int)work_groups, iNumElements);

	error = clEnqueueNDRangeKernel (queue, vector_add_kernel, 1, NULL, &work_items, &work_groups, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro empilhando os kernels" << endl;
		exit (error);
	}

Recuperando os valores e fazendo o check:

	 cl_int clEnqueueReadBuffer (cl_command_queue command_queue,
					cl_mem buffer,
					cl_bool blocking_read,
					size_t offset,
					size_t cb,
					void *ptr,
					cl_uint num_events_in_wait_list,
					const cl_event *event_wait_list,
					cl_event *event)

onde:

buffer é o buffer alocado no device que queremos ler;
blocking_read é um booleano que indica se a leitura será bloqueante ou não. Isso não é importante agora;
cb é o tamanho dessa memória;
*ptr é um ponteiro para um espaço de memória (que ja deve estar com cb bytes alocados) de destino, no HOST;
O retorno é o código de erro;

Nosso código fica entõa da seguinte maneira:

	error = clEnqueueReadBuffer (queue, res_d, CL_TRUE, 0, sizeof(cl_float)*iNumElements, (void *)res, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro lendo o buffer" << endl;
		exit (error);
	}

Faremos agora o check com a computação no host:

       for (int i = 0; i < iNumElements; ++i) {
		if (golden[i] != res[i]) {
			cout << "Nao fecha a computacao" << endl;
			exit (1);
		}
	}
	cout << "Passou no TESTE!!!" << endl;

Limpeza

    clReleaseKernel(vector_add_kernel);  
    clReleaseProgram(program);
    clReleaseCommandQueue(queue);
    clReleaseContext(context);
    clReleaseMemObject(srcA_d);
    clReleaseMemObject(srcB_d);
    clReleaseMemObject(res_d);

Chegamos assim ao fim deste tutorial.
Muito obrigado pela atenção. Quaisquer dúvidas podem me contatar.
Abraços

Leonardo Chatain

Updated Wiki: OpenCl Tutorials - 1

chatain — Mon, 09 Nov 2009 19:36:44 GMT

Olá a todos,
este é meu primeiro tutorial sobre OpenCL, e espero que seja útil.
Não falarei aqui sobre OpenCL em si, já que há por ai suficientes introduções a OpenCL. Começarei o tutorial falando um pouco sobre o modelo de execução de OpenCL, mas será algo breve. Teremos tempo mais tarde para isso.
Neste tutorial, o que eu gostaria de providenciar é um quickstart para que fique mais tranquilo começar a usar e a fazer testes em OpenCL.

Os códigos deste tutorial encontram-se aqui:

work-item: sempre que um kernel é lançado, cada instancia em execução desse kernel torna-se um work-item. Work-items são identificados por um índice que pode ser acessado de dentro do kernel;

Na arquitetura nVidia, cada work-item é mapeado para uma CUDA thread;

work-group: é como os work-items são agrupados. É importante ressaltar que esse agrupamento é muito mais importante do que pode parecer a primeira vista, dado que todos os work-items pertencentes a um work-group são executados na mesma Compute Unit (que são mapeados, na arquitetura nVidia, para Scalar Processors (SPs)), o que lhes permite interagir entre si de forma muito mais eficiente. Work-groups são mapeados, em CUDA, para thread blocks;

Work-groups possuem, assim como os work-items, IDs únicos que podem ser acessados de dentro do kernel;

NDRange: um NDRange é um grid N-dimensional (com N = 1, 2 ou 3) de work-groups. Eles também são acessados por um ID;

Kernel

void vector_add_golden (const float * const srcA,
                                     const float * const srcB,
                                     float * const golden) {
	for (int i = 0; i < iNumElements; i++)
		golden[i] = srcA[i] + srcB[i];
}

__kernel void vector_add (__global const float * const v1,
			 __global const float * const v2,
			 __global float * const res,
			 __global const int n) {
	int idx = get_global_id(0);

	if (idx < n)
		 res[idx] = v1[idx] + v2[idx];
}

Percebam que utilizamos a palavra reservada __kernel__ para especificar que trata-se de um kernel :)
Outro detalhe está em

	int idx = get_global_id(0);

alguns detalhes adicionais:

Inicializando...

#include <oclUtils.h>

#include <iostream>

#define NUM 11444777

using namespace std;

/* Estes são, em ordem, o nome do arquivo em que se encontra nosso kernel,
 * o número de elementos da computação e um inteiro que será utilizado para
 * verificação de erros;
 */
const char* cSourceFile = "vector_add.cl";
cl_int iNumElements = NUM;
cl_int error = 0;

Ok, mais uma tarefa fácil agora: alocar a memória do host, inicializá-la e computar no host para futura verificação:

        /* Aqui são alocadas as variáveis que residem na CPU. São elas os dois vetores a serem somados,
	 * e os dois vetores com os resultados da computação no host e no device;
	 */
	cl_float * const srcA = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const srcB = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const golden = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	cl_float * const res = (cl_float*) malloc(sizeof(cl_float)*iNumElements);
	
	/* Fazemos a devida inicialização dos vetores a serem somados.
	 */
	for (int i = 0; i < iNumElements; ++i) {
		srcA[i] = srcB[i] = i;
	}
	
	/* Aqui fazemos o cálculo da soma na CPU, para fins de verificação.
	 */
	vector_add_golden(srcA, srcB, golden);

Contexto e Command-queue

	 cl_context clCreateContextFromType5 (cl_context_properties *properties,
						cl_device_type device_type,
						void (*pfn_notify)(const char *errinfo,
						const void *private_info, size_t cb,
						void *user_data),
						void *user_data,
						cl_int *errcode_ret)

Onde:

properties é um vetor de propriedades co contexto, que por hora será passado como NULL;
cldevicetype especifica o tipo do device. A tabela completa encontra-se na especificação, utilizaremos CLDEVICETYPE_GPU, pois estamos criando o contexto na GPU;
As proximas duas informações tampouco serão importantes por hora, e serão passadas como NULL;
errcoderet_ é o inteiro, que declaramos lá encima, que conterá o código de um eventual erro;

Se tudo der certo, será retornado CL_SUCCESS.

Nosso código fica então:

        cl_context context = clCreateContextFromType (NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando contexto" << endl;
		exit (error);
	}

Para criar a command-queue, precisaremos primeiramente da lista de devices de nosso sistema. Para fazer isto, utilizaremos a função clGetContextInfo, como pode ser visto abaixo:

        // Estes são, respectivamente, o vetor de devices a ser preenchido e o tamanho em memória desse vetor;
        cl_device_id *devices;
	size_t devices_size;
        // Chamamos a função uma primeira vez, para conseguir o tamanho em memória que deve ser alocado a devices;
	error = clGetContextInfo (context, CL_CONTEXT_DEVICES, 0, NULL, &devices_size);
        // Alocamos o espaco necessario
	devices = (cl_device_id*) malloc (devices_size);
        // E chamamos novamente a funcao para efetivamente colocar em 'devices' a informacao de todos os devices (no meu caso apenas uma GPU)
	error |= clGetContextInfo (context, CL_CONTEXT_DEVICES, devices_size, devices, 0);
	if (error != CL_SUCCESS) {
		cout << "Erro pegando informacoes do contexto;" << endl;
		exit (error);
	}

Muito bem, já estamos prontos para a criação da command_queue:

        cl_command_queue queue = clCreateCommandQueue (context, *devices, 0, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando command_queue" << endl;
		exit (error);
	}

Alocando memória no device

	 cl_mem clCreateBuffer (cl_context context,
			cl_mem_flags flags,
			size_t size,
			void *host_ptr,
			cl_int *errcode_ret)

As flags podem ser:
- CL_MEM_READ_WRITE
- CL_MEM_WRITE_ONLY
- CL_MEM_READ_ONLY
- CL_MEM_USE_HOST_PTR
- CL_MEM_ALLOC_HOST_PTR
- CL_MEM_COPY_HOST_PTR

E devem ser combinadas usando |

Nosso código fica da seguinte forma:

	cl_int error2 = 0, error3 = 0;
	cl_mem srcA_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcA, &error);
	cl_mem srcB_d = clCreateBuffer (context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(cl_float) * iNumElements,
		(void*)srcB, &error2);
	cl_mem res_d = clCreateBuffer (context, CL_MEM_WRITE_ONLY, sizeof(cl_float) * iNumElements, NULL, &error3);
	if ((error | error2 | error3) != CL_SUCCESS) {
		cout << "Erro alocando memoria no host" << endl;
		exit (error|error2|error3);
	}

"Criando" um programa e um kernel

	 cl_program clCreateProgramWithSource (cl_context context,
						cl_uint count,
						const char **strings,
						const size_t *lengths,	
						cl_int *errcode_ret)

para criar o programa, e:

	 cl_int clBuildProgram (cl_program program,
				cl_uint num_devices,
				const cl_device_id *device_list,
				const char *options,
				void (*pfn_notify)(cl_program, void *user_data),
				void *user_data)

para compila-lo;

Segue o código fonte desta parte:

	// Estas três linhas apenas conseguem o endereço do kernel
	size_t kernelLength;
        const char* cPathAndName = shrFindFilePath(cSourceFile, argv[0]);
        const char* cSourceCL = oclLoadProgSource(cPathAndName, "", &kernelLength);
	cl_program program = clCreateProgramWithSource (context, 1, (const char**)&cSourceCL, &kernelLength, &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o programa" << endl;
		exit (error);
	}
	error = clBuildProgram (program, 0, NULL, NULL, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro buildando o programa" << endl;
		exit (error);
	}

A seguir precisamos agora criar um 'kernel object', que deve ser associado ao programa que acabamos de criar. Isso pode ser feito utilizando:

	 cl_kernel clCreateKernel (cl_program program,
				     const char *kernel_name,
				     cl_int *errcode_ret)

Ficando o código da seguinte maneira:

	cl_kernel vector_add_kernel = clCreateKernel (program, "vector_add", &error);
	if (error != CL_SUCCESS) {
		cout << "Erro criando o kernel" << endl;
		exit (error);
	}

Invocando o Kernel

	 cl_int clSetKernelArg (cl_kernel kernel,
				cl_uint arg_index,
				size_t arg_size,
				const void *arg_value)
Onde:
* _kernel_ é o kernel ao qual deve ser empilhado o parametro;
* _{"arg_index"}_ é o índice do parâmetro a ser empilhado (primeiro parametro, segundo parametro...);
* _{"arg_size"}_ é o tamanho do parametro;
* _{"*arg_value"}_ é o valor do argumento;

Nosso código de empilhamento de parametros fica da seguinte forma:

	error = clSetKernelArg (vector_add_kernel, 0, sizeof(cl_mem), (const void*)&srcA_d);
	error |= clSetKernelArg (vector_add_kernel, 1, sizeof(cl_mem), (const void*)&srcB_d);
	error |= clSetKernelArg (vector_add_kernel, 2, sizeof(cl_mem), (const void*)&res_d);
	error |= clSetKernelArg (vector_add_kernel, 3, sizeof(cl_int), (const void*)&iNumElements);
	if (error != CL_SUCCESS) {
		cout << "Error empilhando os parametros" << endl;
		exit (error);
	}

Agora chegou o tão esperado momento de chamar o kernel. Para tanto utilizaremos a seguinte função:

       cl_int clEnqueueNDRangeKernel (cl_command_queue command_queue,
						cl_kernel kernel,
						cl_uint work_dim,
						const size_t *global_work_offset,
						const size_t *global_work_size,
						const size_t *local_work_size,
						cl_uint num_events_in_wait_list,
						const cl_event *event_wait_list,
						cl_event *event)

Onde:

work_dim é o número de dimensões dos work-items (1,2 ou 3);
*global_work_offset deve ser mantido NULL (pelo menos nesta versão do driver opencl da Nvidia;
*global_work_size é um vetor que descreve as dimensões dos work-items;
*local_work_size é o número de work-items por work-group (em uma analogia a CUDA, é o número de threads per block;
O retorno é o código de erro;
os outros parametros não importam por hora;

	size_t work_groups = 256;
        size_t work_items = shrRoundUp((int)work_groups, iNumElements);

	error = clEnqueueNDRangeKernel (queue, vector_add_kernel, 1, NULL, &work_items, &work_groups, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro empilhando os kernels" << endl;
		exit (error);
	}

Recuperando os valores e fazendo o check:

	 cl_int clEnqueueReadBuffer (cl_command_queue command_queue,
					cl_mem buffer,
					cl_bool blocking_read,
					size_t offset,
					size_t cb,
					void *ptr,
					cl_uint num_events_in_wait_list,
					const cl_event *event_wait_list,
					cl_event *event)

onde:

buffer é o buffer alocado no device que queremos ler;
blocking_read é um booleano que indica se a leitura será bloqueante ou não. Isso não é importante agora;
cb é o tamanho dessa memória;
*ptr é um ponteiro para um espaço de memória (que ja deve estar com cb bytes alocados) de destino, no HOST;
O retorno é o código de erro;

Nosso código fica entõa da seguinte maneira:

	error = clEnqueueReadBuffer (queue, res_d, CL_TRUE, 0, sizeof(cl_float)*iNumElements, (void *)res, 0, NULL, NULL);
	if (error != CL_SUCCESS) {
		cout << "Erro lendo o buffer" << endl;
		exit (error);
	}

Faremos agora o check com a computação no host:

       for (int i = 0; i < iNumElements; ++i) {
		if (golden[i] != res[i]) {
			cout << "Nao fecha a computacao" << endl;
			exit (1);
		}
	}
	cout << "Passou no TESTE!!!" << endl;

Limpeza

    clReleaseKernel(vector_add_kernel);  
    clReleaseProgram(program);
    clReleaseCommandQueue(queue);
    clReleaseContext(context);
    clReleaseMemObject(srcA_d);
    clReleaseMemObject(srcB_d);
    clReleaseMemObject(res_d);

Chegamos assim ao fim deste tutorial.
Muito obrigado pela atenção. Quaisquer dúvidas podem me contatar.
Abraços

Leonardo Chatain

Updated Wiki: Blog

chatain — Fri, 06 Nov 2009 16:06:07 GMT

Blog do Projeto

Unfortunately this page exists only in portuguese.

03/11/09

05/10/09

02/10/09

30/09/09

23/09/09

14/09/09

28/08/09

Até mais,

Leonardo Chatain

23/07/09

08/07/09

int IVsRunningDocTableEvents.OnAfterAttributeChange
int IVsRunningDocTableEvents.OnAfterDocumentWindowHide
int IVsRunningDocTableEvents.OnAfterFirstDocumentLock
int IVsRunningDocTableEvents.OnAfterSave
int IVsRunningDocTableEvents.OnBeforeDocumentWindowShow
int IVsRunningDocTableEvents.OnBeforeLastDocumentUnlock

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

26/05/09

12/05/09

using EnvDTE;

DTE dte;

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

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

      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

06/05/09

23/04/09

Melhorias na estruturação e organização do código;
Remoção de alguns bugs;
Melhor organização visual;

20/04/09

10/04/09

01/04/09

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;

25/03/09 - Hello World

        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:

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));
        }

17/03/09

08/03/2009

24/02/2009

18/02/2009

18/01/2009

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

30/10/2008 - Finishing the Debugger

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.

30/09/2008 - GLSL Debugger

18/08/2008

04/08/2008

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++;  }

  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

04/07/2008

18/06/2008

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

15/05/2008

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

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

07/03/2008

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
) {..}

22/02/2008

A troca da função "mul" pelo "*"
A inversão de parâmetros na função "cross"
A remoção de parâmetros na função "main"

Updated Wiki: Blog

chatain — Thu, 05 Nov 2009 17:28:38 GMT

Blog do Projeto

Unfortunately this page exists only in portuguese.

03/11/09

Olá a todos,
estive bastante envolvido com as tarefas acadêmicas 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, e assisti a todas as apresentações. Nelas são apresentados desde questões gerais sobre opencl até otimizações diversas. Vale a pena conferir.
Até,
Leonardo Chatain

05/10/09

02/10/09

30/09/09

23/09/09

14/09/09

28/08/09

Até mais,

Leonardo Chatain

23/07/09

08/07/09

int IVsRunningDocTableEvents.OnAfterAttributeChange
int IVsRunningDocTableEvents.OnAfterDocumentWindowHide
int IVsRunningDocTableEvents.OnAfterFirstDocumentLock
int IVsRunningDocTableEvents.OnAfterSave
int IVsRunningDocTableEvents.OnBeforeDocumentWindowShow
int IVsRunningDocTableEvents.OnBeforeLastDocumentUnlock

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

26/05/09

12/05/09

using EnvDTE;

DTE dte;

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

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

      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

06/05/09

23/04/09

Melhorias na estruturação e organização do código;
Remoção de alguns bugs;
Melhor organização visual;

20/04/09

10/04/09

01/04/09

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;

25/03/09 - Hello World

        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:

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));
        }

17/03/09

08/03/2009

24/02/2009

18/02/2009

18/01/2009

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

30/10/2008 - Finishing the Debugger

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.

30/09/2008 - GLSL Debugger

18/08/2008

04/08/2008

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++;  }

  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

04/07/2008

18/06/2008

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

15/05/2008

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

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

07/03/2008

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
) {..}

22/02/2008

A troca da função "mul" pelo "*"
A inversão de parâmetros na função "cross"
A remoção de parâmetros na função "main"

Updated Wiki: Blog

chatain — Tue, 03 Nov 2009 18:57:21 GMT

Blog do Projeto

Unfortunately this page exists only in portuguese.

03/11/09

05/10/09

02/10/09

30/09/09

23/09/09

14/09/09

28/08/09

Até mais,

Leonardo Chatain

23/07/09

08/07/09

int IVsRunningDocTableEvents.OnAfterAttributeChange
int IVsRunningDocTableEvents.OnAfterDocumentWindowHide
int IVsRunningDocTableEvents.OnAfterFirstDocumentLock
int IVsRunningDocTableEvents.OnAfterSave
int IVsRunningDocTableEvents.OnBeforeDocumentWindowShow
int IVsRunningDocTableEvents.OnBeforeLastDocumentUnlock

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

26/05/09

12/05/09

using EnvDTE;

DTE dte;

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

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

      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

06/05/09

23/04/09

Melhorias na estruturação e organização do código;
Remoção de alguns bugs;
Melhor organização visual;

20/04/09

10/04/09

01/04/09

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;

25/03/09 - Hello World

        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:

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));
        }

17/03/09

08/03/2009

24/02/2009

18/02/2009

18/01/2009

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

30/10/2008 - Finishing the Debugger

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.

30/09/2008 - GLSL Debugger

18/08/2008

04/08/2008

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++;  }

  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

04/07/2008

18/06/2008

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

15/05/2008

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

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

07/03/2008

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
) {..}

22/02/2008

A troca da função "mul" pelo "*"
A inversão de parâmetros na função "cross"
A remoção de parâmetros na função "main"

Updated Wiki: Blog

chatain — Tue, 03 Nov 2009 18:52:14 GMT

Blog do Projeto

Unfortunately this page exists only in portuguese.

03/11/09

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 era uma grande crítica ao OpenCL.

Att,

Leonardo Chatain

02/10/09

30/09/09

23/09/09

14/09/09

28/08/09

Até mais,

Leonardo Chatain

23/07/09

08/07/09

int IVsRunningDocTableEvents.OnAfterAttributeChange
int IVsRunningDocTableEvents.OnAfterDocumentWindowHide
int IVsRunningDocTableEvents.OnAfterFirstDocumentLock
int IVsRunningDocTableEvents.OnAfterSave
int IVsRunningDocTableEvents.OnBeforeDocumentWindowShow
int IVsRunningDocTableEvents.OnBeforeLastDocumentUnlock

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

26/05/09

12/05/09

using EnvDTE;

DTE dte;

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

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

      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

06/05/09

23/04/09

Melhorias na estruturação e organização do código;
Remoção de alguns bugs;
Melhor organização visual;

20/04/09

10/04/09

01/04/09

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;

25/03/09 - Hello World

        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:

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));
        }

17/03/09

08/03/2009

24/02/2009

18/02/2009

18/01/2009

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

30/10/2008 - Finishing the Debugger

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.

30/09/2008 - GLSL Debugger

18/08/2008

04/08/2008

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++;  }

  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

04/07/2008

18/06/2008

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

15/05/2008

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

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

07/03/2008

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
) {..}

22/02/2008

A troca da função "mul" pelo "*"
A inversão de parâmetros na função "cross"
A remoção de parâmetros na função "main"

Updated Wiki: OpenCL Tutorials

chatain — Tue, 03 Nov 2009 17:30:05 GMT

Olá,
estes são os tutorials disponíveis até agora:

OpenCL Tutorials - 1 (quickstart)

Até,

Leonardo Chatain