Edison Gustavo Muenz. Estudo e implementação de um algoritmo de processamento de imagens com técnicas GPGPU

Transcrição

1 Edison Gustavo Muenz Estudo e implementação de um algoritmo de processamento de imagens com técnicas GPGPU Florianópolis SC Agosto / 2008

2 Edison Gustavo Muenz Estudo e implementação de um algoritmo de processamento de imagens com técnicas GPGPU Orientador: Dr. rer.nat. Aldo von Wangenheim BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO INE CENTRO TECNOLÓGICO UNIVERSIDADE FEDERAL DE SANTA CATARINA Florianópolis SC Agosto / 2008

3 Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação Prof. Dr. rer.nat. Aldo von Wangenheim Departamento de Informática e Estatística - INE - UFSC Orientador

4 Resumo Algoritmos de processamento de imagens muitas vezes caracterizam-se por tomarem uma considerável quantidade de tempo para serem executados. Isto os torna possíveis elementos computacionais carentes de otimização e de uma melhoria em seu tempo de execução, tornandoos aptos a atender exigências de certas aplicações, como as de tempo real. As alternativas tomadas até então consistiam em utilizar clusters de alto desempenho, no entanto, o alto custo destes inviabliza a utilização destes algoritmos em máquinas disponíveis comercialmente, como os PCs. Com a evolução da computação gráfica e a demanda por placas gráficas mais poderosas, ocorreu uma evolução destas mesmas, onde características úteis apareceram, viabilidando o seu uso para propósitos além da pura síntese de gráficos, mas também para propósitos gerais. Este trabalho de conclusão de curso consiste em implementar um algoritmo de processamento digital de imagens utilizando as placas gráficas (GPUs) de forma a melhorar o desempenho dos mesmos.

5 Sumário Introdução p. 5 1 Objetivos p Objetivos gerais p Objetivos específicos p. 7 2 Fundamentação teórica p GPU p Stream processing p Aplicações GPGPU p Framework CUDA p Motivação p Arquitetura de execução p Uma extensão da linguagem C p Ponteiros p Texturas p. 16 Apêndices p. 19

6 5 Introdução Processamento digital de imagens é o processo de a partir de uma imagem de entrada processar cada pixel desta, gerando resultados, o que em geral é uma imagem de saída. Este processo pode gerar imagens de diferentes formatos, aumentar e/ou diminuir a imagem. No entanto, uma característica marcante de alguns destes algoritmos, principalmente os de segmentação de imagens é a alta exigência computacional para execução. Isto pode impedir o seu uso em algumas aplicações como biometria, reconhecimento de padrões, processamento de vídeo, etc. Os clusters são uma das soluções que a comunidade científica adotou para resolver tais problemas, aumentando o poder computacional disponível, no entanto, estes são caros e impraticáveis para muitas aplicações e usos que poderiam ser dados a este campo. A evolução das GPUs com o seu poder computacional e programabilidade pode ser uma solução barata e eficiente para este problema computacional. Elas conseguem obter tempos de resposta muitas vezes superior às CPUs atuais graças à sua arquitetura, tendo em vista um modelo de execução em paralelo. As GPUs possuem uma grande quantidade de núcleos, com um grande número de ALUs e pequenas caches. Esta arquitetura diferenciada exige das aplicações que utilizam a GPU algumas premissas para executarem os algoritmos de forma eficiente, sendo a principal delas: independência dos dados. Alguns algoritmos de processamento de imagens estão aptos de forma direta para serem executados na GPU (ou seja, são em essência paralelos), já outros necessitam de uma adaptação para serem traduzidos para a GPU. Esta tradução é um grande problema para alguns algoritmos, pois estes devem ser modelados de forma diferente para garantir uma independência dos dados, sendo algumas vezes impraticável ou impossível (até a data presente) obter um modelo que consiga executar de forma eficiente o algoritmo. Algumas técnicas para evitar algumas insuficiências das GPUs estão descritas em (??). Como apontado por (??) e (??) uma das carências das GPUs era a ausência de linguagens de alto nível para a criação de programas para a GPU. Estes estavam restritos às linguagens

7 6 de Shaders, que eram basicamente utilizados em computação gráfica para obter efeitos gráficos mais realistas, mas para propósitos gerais, eram deficientes por incluirem um overhead das APIs gráficas, como OpenGL e Directx. Isto torna o código sujo e difícil de depurar, debugar e sempre é necessário trabalhar diretamente com texturas. Além disso, há também as limitações dos Shaders. A NVIDIA então disponibilizou o framework CUDA para permitir a criação de programas para suas placas de vídeo da série Esta possui muitas características úteis para a criação de aplicativos GPGPU, sem necessitar do overhead das apis gráficas, facilitando a escrita dos algoritmos.

8 7 1 Objetivos 1.1 Objetivos gerais Estudar e implementar sob o paradigma de programação paralela, que é imposto pela programação GPGPU, algoritmos de processamento de imagens, elaborando estratégias e resolvendo os problemas encontrados neste novo ambiente. 1.2 Objetivos específicos Estudar abordagens disponíveis para a programação de algoritmos sob o paradigma de programação paralela em GPUs Modelar e implementar o algoritmo de filtro de difusão anisotrópico e segmentação por funcional de Mumford&Shah Verificar particularidades nos modelos CPU e GPU dos algoritmos descritos Efetuar um estudo comparativo de performance e qualidade de resultados nos ambientes especificados

9 8 2 Fundamentação teórica 2.1 GPU A GPU (graphical processing unit) é o processador que das placas gráficas. Estas placas são compostas de diversos componentes, no entanto, assim como nos pcs (onde a CPU é o componente principal ), a GPU é o componente principal destas mesmas, onde ocorre o processamento de todas as instruções enviadas à placa de vídeo. O poder de processamento das GPUs atuais é imenso, se comparado ao processamento das CPUs modernas. Este poder chamou a atenção dos desenvolvedores e permitiu que os efeitos gráficos nunca vistos antes. Também fez com que olhássemos para a GPU com olhos não somente voltados ao processamento de gráficos, mas como um processador de propósito geral. As GPUs passaram a obter atenção dos desenvolvedores para propósito geral porque passaram a possuir estágios programáveis (atualmente com 2 estágios). Estes estágios permitem que sejam inseridos algoritmos que irão rodar dentro da GPU tratando os dados da forma que for necessário, tendo como objetivo efeitos gráfico e/ou algum outro propósito. Os 2 estágios programáveis da GPU são também chamados de shaders, estes são: vertex shader e pixel shader Stream processing Este é o modelo de programação que deve ser seguido quando escrevem-se algoritmos para a GPU. Isto ocorre porque a GPU possui processadores que funcionam desta forma. Este é um modelo de programação que incentiva o paralelismo, pois ele estabelece o modelo de execução SIMD (nos modelos da GPU atuais, embora existam outros modelos para Stream processing(??)). Este modelo é a sigla para Same instruction, multiple data, ditando que o mesmo código é executado sobre diferentes dados. Este modelo define o termo kernel, que é o código que será executado em cada trecho dos dados. Este kernel executando sobre este setor de dados define um stream.

10 9 Um código executando em CPU sobre um conjunto de dados data é o seguinte: void kernel() {... } int result; for (int i = 0; i < DATA_SIZE; ++i) { kernel(data[i], result); } No caso dessa execução ser feita no modelo Stream processing este código seria o seguinte: void kernel() {... } result = apply_kernel(kernel, data, DATA_SIZE); Ou seja, o método kernel() será aplicado a cada elemento do array data Aplicações GPGPU Existem várias particularidades ao escrevermos algortimos para a GPU, pois a arquitetura desta é diferente da arquitetura da CPU, introduzindo algumas dificuldades e limites. Por isto sempre que estes forem escritos, deve-se ter sempre em mente o funcionamento do pipeline gráfico, seus limites e particularidades. Algumas destas características são: Latência do barramento entre CPU e GPU - Existe uma latência para a troca de informações entre a CPU e a GPU que é limitado pelo slot AGP ou PCI-Express. Este tempo pode ser crítico quando há muita comunicação entre estes dois componentes. Portanto deve-se ter sempre em mente que é recomendável enviar instruções e dados suficientes, ou então que ocupem um tempo que justifique o processamento ser feito na GPU. Caso contrário, uma situação onde o resultado já poderia ter sido calculado pela CPU, mas a instrução ainda está trafegando pelo barramento até a GPU pode ocorrer. Dificuldades de programação - Como a GPU possui uma arquitetura altamente especializada, alguns comandos não são possíveis de serem executados em alguns estágios do pipeline, tornando alguns algoritmos de implementação trivial em CPU, difíceis de se

11 10 implementar em GPU. O algoritmo quicksort é um exemplo claro desta limitação, pois a operação scatter (escrita em algum endereço de memória) é limitado no vertex shader e desabilitado no pixel shader. Soluções para estas dificuldades existem, através da busca de algoritmos alternativos e/ou uma implementação diferenciada, que aproveita melhor o paralelismo e consegue rodar sobre as limitações do hardware da GPU. Gather Uma das maiores dificuldades com a maneira clássica de escrever algoritmos GPGPU (através de Shaders) são as limitações de gather e scatter. A operação Gather é o ato de obter dados a partir de um endereço de memória aleatório. Por exemplo: int dados = data[10]; Neste caso, estamos obtendo o dado a partir do endereço 10 do conjunto de dados data. Esta operação possui suporte total no Pixel Shader, mas é limitada no Vertex Shader. Scatter A operação Scatter é o ato de escrever dados em um endereço de memória. Por exemplo: data[10] = 5; Aqui está se escrevendo o valor 5 no conjunto de dados data. Esta operação não é suportada no Pixel Shader e pode ser feita no Vertex Shader. Isto apresenta limitações claras porque muitos algoritmos necessitam escrever em endereços de memória, tornando algumas vezes impossível alguns algoritmos serem escritos pela maneira clássica de GPGPU (shaders). 2.2 Framework CUDA O CUDA é um framework desenvolvido pela NVIDIA com o objetivo de facilitar a criação de aplicações para a GPU.

12 11 Ele pode ser interpretado como uma API com funções e formas de escrever código diretamente na GPU. Esta API é uma extensão do C, onde o compilador da NVIDIA (nvcc) compila o código relativo ao CUDA e deixa o compilador padrão da máquina (gcc, msvc) compilar o código C Motivação A forma (clássica) de se escrever código para a GPU é através da programação dos shaders, rodando no vertex shader, pixel shader ou geometry shader (a partir do Shader model 4.0). Este tipo de código é eficiente (no quesito praticidade) caso a aplicação não tenha o intuito de utilizar código GPGPU. No entanto, caso o código tenha um propósito geral (não diretamente relacionado ao uso de uma API 3D), há muito esforço desnecessário, como: Necessidade da utilização de APIs gráficas (como opengl e direct3d) Dificuldade em traduzir problemas computacionais para a GPU ausência de scatter/gather Este esforço diminui com o CUDA, pois o código não é mais escrito em linguagem de shaders, a necessidade de utilização de APIs gráficas desaparece, há suporte para scatter/gather em qualquer parte do código Arquitetura de execução Kernels, Grids e Blocos de threads O CUDA não foge ao modelo de programação de Streams(??) como há na programação de Shaders, pois a GPU é uma máquina com múltiplos processadores em paralelo, e é isto que a torna tão eficiente computacionalmente. Isto implica que há kernels, e estes irão rodar em paralelo sobre um conjunto de dados, mas cada instância deste kernel (thread) irá processar um dado diferente. Threads São a menor unidade de execução do kernel, onde cada uma executa parte do código do kernel. Estas estão organizadas em blocos, podendo estas compartilharem informações entre si através de uma memória de rápido acesso e sincronizarem sua execução para coordenar o acesso à memória.

13 12 Blocos Consiste em um agrupamento de threads que irão executar em um dos multiprocessadores disponíveis na GPU. Estes blocos são indepependentes entre si, ou seja, podem executar em uma ordem aleatória e não previamente conhecida. Um grande número de blocos garante um grande paralelismo (mantendo os multiprocessadores ocupados). Grids É o conjunto de todos os blocos que está executando um kernel. Quando um grid termina de executar significa que o kernel terminou sua execução. Memória A comunicação entre a CPU e a GPU é feita através de métodos da api, como cudamalloc() (aloca memória na GPU) e cudamemcpy() (transfere dados entre CPU e GPU). Estes métodos são otimizados pelo compilador para utilizar o chip DMA (Direct Memory Access) aumentando a velocidade de acesso. Uma thread possui acesso à memória da GPU através dos seguintes padrões: Read-write per-thread registers, Read-write per-thread local memory, Read-write per-block shared memory, Read-write per-grid global memory, Read-only per-grid constant memory, Read-only per-grid texture memory. Registradores Cada multiprocessador possui uma quantidade definida de registradores. Portanto, o número de threads por bloco é limitado ao hardware onde o programa está sendo executado. Memória compartilhada O CUDA disponibiliza uma memória compartilhada de alta velocidade de acesso ao programador. Esta memória pode ser utilizada para sincronia das threads entre os blocos, diminuindo o número de loads feitos da memória principal da GPU, aumentando a velocidade de execução do kernel. O tamanho desta memória é limitado a 16kb por bloco.

14 Uma extensão da linguagem C O CUDA faz uma extensão da linguagem C, adicionando alguns tipos e conceitos. Por ser uma extensão do C, a curva de aprendizado é menor devido às similaridades com o C, que é uma linguagem conhecida. Há a introdução de alguns conceitos básicos: Host - Executa o código compilado e controla os dispositivos (devices). Seria a CPU. Device - Executa código escrito especificamente para o dispositivo, a GPU. Funções e tipos que caracterizam vetores como já parte da linguagem (como float2). Este código é suportado tanto no host quanto no device. Qualificadores para métodos device Implica que um método será executado apenas no device. Chamado apenas pelo próprio device global Implica no ponto de entrada para um kernel Executado no device Chamado apenas pelo host host Executado no host Chamado apenas pelo host É equivalente declarar um método com este modificador e não declará-lo sem nenhum dos modificadores listados. No entanto, é possível declarar um método com ambos os modificadores device e host que dizem que um método será compilado para ser executado em ambos os ambientes.

15 14 Qualificadores para variáveis device Especifica que uma variável será armazenada no device. Os modificadores a seguir definem onde a variável será alocada. constant Uma variável declarada com este modificador possui as seguintes características Reside no espaço de memória de constantes Tem um tempo de vida igual à vida da aplicação É acessível a todas as threads do grid através da biblioteca runtime. shared Uma variável declarada com este modificador possui as seguintes características Reside no espaço de compartilhado de thread de um bloco (memória veloz mas pequena) Tem um tempo de vida igual à vida do bloco É acessível a todas as threads do bloco Este tipo de variável é suscetível à sincronia de threads, portanto, para sincronizar os reads e writes utiliza-se o comando syncthreads(), garantindo que as escritas de outras threads serão visíveis. Se nenhum destes modificadores for especificado, a variável terá a seguinte característica: Reside no espaço de memória global Tem um tempo de vida igual à vida da aplicação É acessível a todas as threads do grid através da biblioteca runtime. Chamando um kernel Quando declaramos um método com o modificador global e queremos chamá-lo para poder executar um kernel, este deve possuir um tipo de chamada especial, onde é especificado a dimensão do grid que irá executar aquele kernel. O formato desses parâmetros segue a forma <<< Dg, Db, Ns >>>, onde:

16 15 Dg é do tipo dim3 e especifica a dimensão e o tamanho do grid. Sendo Dg.x * Dg.y igual ao número de blocos. Db é do tipo dim3 e especifica a dimensão e o tamanho de cada bloco. Sendo Db.x * Db.y * Db.z igual ao número de threads por bloco. Ns é do tipo size t e especifica o número de bytes que serão alocados dinamicamente além dos bytes estáticos. Esta memória é utilizada por arrays declarados com o modificador extern. Este argumento é opcional e o seu valor padrão é 0. Por exemplo, se queremos chamar um kernel com 10 blocos, sendo 5 threads por bloco, podemos utilizar o seguinte programa C: global void kernel() {... } void main() { kernel<<<10, 5>>>(); } É válido lembrar que uma chamada de um kernel a partir do host é assíncrono, ou seja, o kernel pode não terminar sua execução antes que a próxima instrução do código do host seja chamado. Para que haja uma sincronização deste kernel é possível chamar o método cudathreadsynchronize() que garante o término de execução de todas as threads. O compilador nvcc Este é o compilador disponibilizado para poder compilar o código do CUDA. A diferença, é que este não é um compilador completo, ou seja, ele não se responsabiliza por código C, e sim apenas pelo código escrito em CUDA. Isto permite que o compilador utilizado para compilar o código C seja customizado, ou seja, pode ser o gcc, visual c++ compiler, etc. Modo de emulação O nvcc permite que o código escrito em cuda (os kernels) sejam executados em modo de emulação (na CPU) para debugar o código, permitindo chamadas a qualquer método de CPU dentro do kernel em si para debugação. Métodos como printf() podem ser chamados dentro do kernel apenas em modo de emulação. Para compilar em modo de emulação é passada a flag -deviceemu para o nvcc.

17 Ponteiros Ponteiros no CUDA são muito similares a ponteiros em C. Há algumas fórmulas básicas para utilizá-los, sendo o que os distingue dos ponteiros em C. É preciso diferenciar se um ponteiro está sendo alocado no host ou no device. Sendo os ponteiros do host os ponteiros C e os ponteiros device os ponteiros CUDA. Os ponteiros em C são alocados através de malloc(), os ponteiros em CUDA são alocados com cudamalloc(). Para popular os dados de cada ponteiro, em C geralmente utiliza-se um for sobre os dados populando conforme necessário. Em CUDA, os ponteiros possuem seus dados populados através de cudamemcpy() que copia os dados de um ponteiro C para um ponteiro CUDA (o método cudamemcpy() é análogo ao método memcpy()). Um trecho de código para alocar um ponteiro CUDA e popular seus dados: int * data = (int*)malloc(sizeof(int) * 10); for (int i = 0; i < 10; ++i) data[i] = 5; int * d_data; cudamalloc((void**)&d_data, sizeof(int) * 10); cudamemcpy(d_data, data, sizeof(int) * 10, cudamemcpyhosttodevice); Texturas O CUDA possui o tipo textura. Este tipo permite acesso à memória de texturas, que possui rápido acesso e é otimizada para armazenar estes tipos de dados. Para poder alocar memória para as texturas, utiliza-se o comando cudamallocarray() que irá alocar a imagem na memória para texturas. É possível também utilizar a memória global para alocar a textura, no entanto, isso geralmente implica em perda de desempenho. Além disso, o CUDA não oferece suporte a algumas operações com as texturas (como filtros) quando utiliza-se este modo. Uma textura alocada na memória global sofre das seguintes características: Pode ter apenas uma dimensão Não suporta filtro para as texturas

18 17 Pode ser acessada apenas por valores inteiros e não normalizados (não estando no intervalo [0,1)) Não suporta os variados modos de acesso disponíveis Utilizando texturas a partir de CUDA Arrays Deve-se declarar 5 variáveis, sendo 2 destas apenas descritores da textura em si, e não conterão dados pertinentes ao conteúdo da textura, as variáveis descritoras são: texture<type, Dim, ReadMode> texref; - Utilizada para declarar como a textura está sendo armazenada (tipo da variável), os filtros sendo aplicados, etc. cudachannelformatdesc - Contém uma descrição sobre a textura, em geral é criado com o método cudacreatechanneldesc<type>(); onde Type é o tipo da variável que irá conter cada pixel da textura (ex.: float, char, etc.) Então, na utilização das texturas, é necessário criar uma variável que irá conter a informação de cada pixel da textura e ser armazenada no lado do host. Como por exemplo: float * h texture; Esta variável é utilizada da mesma forma que utiliza-se para carregar texturas com OpenGL. A outra variável, é a correspondente à variável anterior, mas irá ser alocada no lado do device, ou seja, será enviada à GPU. É declarada da mesma forma, no entanto, sua alocação é dada pelo método cudamalloc(). Por exemplo: float * d_texture; cudamalloc( (void**) &d_texture, imagew * imageh * sizeof(float)); A próxima variável é do tipo cudaarray e será ela que irá transportar a informação para a GPU através da memória dedicada a texturas. O código abaixo mostra como ela deve ser usada: cudaarray * cu_array; cudamallocarray( &cu_array, &channeldesc, imagew, imageh ); cudamemcpytoarray( cu_array, 0, 0, h_data, imagew * imageh * sizeof(float), cudamemcpyhosttodevice); cudabindtexturetoarray( teximage, cu_array, channeldesc); Note que as variáveis teximage e channeldesc são os descritores citados anteriormente.

19 18 Invocação do kernel com texturas Para invocar um kernel que utiliza texturas, os passos da seção anterior são necessários para a declaração das variáveis para a utilização das texturas. O kernel deve então possuir um parâmetro onde ele poderá escrever o resultado do seu processamento. Ela terá o mesmo tipo que a textura que armazena a textura no lado do host, mas o ponteiro passado para o kernel será o da variável que é armazenada no lado do device. Veja o código abaixo: float * d_data; cudamalloc( (void**) &d_texture, imagew * imageh * sizeof(float));... global void grayscale(float * textura, int w, int h); //declaraç~ao do kernel... grayscale<<<grid, threads>>>(d_data, imagew, imageh); //invocaç~ao do kernel Obtenção dos resultados Para obter os resultados da invocação do kernel, é necessário copiar o resultado para uma variável local (no lado do host), isto é feito da seguinte forma: float * resultado = (image_t *)malloc(sizeof(float) * imageh * imagew); cudamemcpy( resultado, cu_array, sizeof(float) * imageh * imagew, cudamemcpydevicetohost); O resultado da computação feita pelo kernel pode ser manipulada da forma desejada através da variável resultado. Saída para várias texturas Foram feitos experimentos com a escrita do kernel em mais de uma textura, isto pode ser feito utilizando: Um cudaarray para cada textura Uma variável armazenada no dispositivo (sendo alocada com cudamalloc()) para cada textura Utilização dos mesmo descritores da textura (se a saída desejada for do mesmo tipo que a textura de entrada)

20 19 Apêndices Listing 2.1: Grayscale em CUDA 1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <cutil.h> 4 #include <cuda runtime.h> 5 #include <FreeImagePlus.h> 6 7 typedef uint4 image t; 8 9 / Kernel para rodar na GPU / 10 texture <image t, 2, cudareadmodeelementtype> teximage; 11 cudachannelformatdesc channeldesc = cudacreatechanneldesc<image t>(); global void grayscale (image t textura, int w, int h) 14 { 15 const int ix = blockdim.x blockidx.x + threadidx.x; 16 const int iy = blockdim.y blockidx.y + threadidx.y; 17 // Add half of a texel to always address exact texel centers 18 const float x = ( float )ix + 0.5f ; 19 const float y = ( float )iy + 0.5f ; if (ix < w && iy < h){ 22 image t fresult = tex2d(teximage, x, y); 23 uint color = fresult.x fresult.y fresult. z 0.11; 24 textura [w iy + ix] = make uint4( color, color, color, fresult.w); 25 } 26 } 27 28

21 20 29 char arquivoentrada = entrada.bmp ; 30 char arquivosaida = saida.bmp ; int idivup(int a, int b) 33 { 34 return ((a % b)!= 0)? (a / b + 1) : (a / b); 35 } int main(int argc, char argv []) 38 { 39 if (argc > 1) { 40 arquivoentrada = argv [1]; 41 } 42 CUT DEVICE INIT(); fipimage img = new fipimage; 45 if (img >load(arquivoentrada) == 0) 46 { 47 printf ( [ERRO] Arquivo nao carregado!\n ); 48 return 1; 49 } if (img >convertto24bits() == 0) 52 { 53 printf ( [ERRO] Nao foi possivel converter a imagem para 24 bits ); 54 return 1; 55 } int width = img >getwidth(); 58 int height = img >getheight(); unsigned int memsize = sizeof(image t) width height ; image t h data = new image t[width height ]; 63

22 21 64 RGBQUAD pixelcolor; 65 for ( int i = 0; i < width; ++i) 66 { 67 for ( int j = 0; j < height ; ++j) 68 { 69 img >getpixelcolor(i,j, &pixelcolor); 70 h data [ i height + j ] = make uint4( 71 (unsigned int ) pixelcolor.rgbred, 72 (unsigned int ) pixelcolor.rgbgreen, 73 (unsigned int ) pixelcolor.rgbblue, 74 (unsigned int ) pixelcolor.rgbreserved 75 ); 76 } 77 } // agora a variavel h data possui os pixels da imagem, pode entao ser passada para a GPU pa 80 cudaarray cu array ; / Aloca memoria na GPU para o resultado / 83 image t d data = NULL; 84 CUDA SAFE CALL( cudamalloc( (void ) &d data, memsize) ); // transfere imagem para a GPU 87 cudachannelformatdesc channeldesc = cudacreatechanneldesc<image t>(); 88 CUDA SAFE CALL( cudamallocarray( &cu array, &channeldesc, width, height ) ); 89 CUDA SAFE CALL( cudamemcpytoarray( cu array, 0, 0, h data, memsize, cudamemcpyhosttode 90 CUDA SAFE CALL( cudabindtexturetoarray( teximage, cu array, channeldesc)); dim3 block(8, 8); 93 dim3 grid (idivup(width, block.x ), idivup(height, block.y ));; grayscale <<<grid, block>>>(d data, width, height ); 96 cudathreadsynchronize(); 97 CUT CHECK ERROR( Kernel execution failed ); 98

23 22 99 // allocate mem for the result on host side 100 image t resultado = new image t[memsize]; 101 // copy result from device to host 102 CUDA SAFE CALL( cudamemcpy( resultado, d data, memsize, cudamemcpydevicetohost) ); // cria uma nova imagem para poder salvar o resultado do kernel 105 fipimage outimg = new fipimage( img); for ( int i = 1; i < width 1; ++i) 108 { 109 for ( int j = 1; j < height 1; ++j) 110 { 111 int index = i height + j ; RGBQUAD pixel; 114 pixel.rgbreserved = (BYTE)resultado[index].w; 115 pixel.rgbred = (BYTE)resultado[index].x; 116 pixel.rgbgreen = (BYTE)resultado[index].y; 117 pixel.rgbblue = (BYTE)resultado[index].z; 118 if (outimg >setpixelcolor(i, j,&pixel ) == 0) 119 { 120 fprintf ( stderr, [ERRO] Problemas ao gravar as informacoes sobre a imagem de 121 return 1; 122 } 123 } 124 } 125 delete [] resultado ; if (outimg >save(arquivosaida) == 0) 128 { 129 fprintf ( stderr, [ERRO] Nao foi possivel gravar a imagem de saida em disco\n ); 130 return 1; 131 } CUDA SAFE CALL(cudaFree(d data));

24 CUDA SAFE CALL(cudaFreeArray(cu array)); 135 delete outimg; 136 delete img; 137 delete [] h data ; return 0; 140 }