ANÁLISE COMPARATIVA DO DESEMPENHO DE UNIDADES DE PROCESSAMENTO GRÁFICO

Transcrição

1 UNIVERSIDADE DO ESTADO DO AMAZONAS - UEA ESCOLA SUPERIOR DE TECNOLOGIA ENGENHARIA DE COMPUTAÇÃO DARLISSON MARINHO DE JESUS ANÁLISE COMPARATIVA DO DESEMPENHO DE UNIDADES DE PROCESSAMENTO GRÁFICO Manaus 2013

2 DARLISSON MARINHO DE JESUS ANÁLISE COMPARATIVA DO DESEMPENHO DE UNIDADES DE PROCESSAMENTO GRÁFICO Trabalho de Conclusão de Curso apresentado à banca avaliadora do Curso de Engenharia de Computação, da Escola Superior de Tecnologia, da Universidade do Estado do Amazonas, como pré-requisito para obtenção do título de Engenheiro de Computação. Orientador: Prof. Dr. Raimundo Corrêa de Oliveira Manaus 2013

3 ii Universidade do Estado do Amazonas - UEA Escola Superior de Tecnologia - EST Reitor: Cleinaldo de Almeida Costa Vice-Reitor: Raimundo de Jesus Teixeira Barradas Diretor da Escola Superior de Tecnologia: Cleto Cavalcante de Souza Leal Coordenador do Curso de Engenharia de Computação: Raimundo Corrêa de Oliveira Coordenador da Disciplina Projeto Final: Tiago Eugênio de Melo Banca Avaliadora composta por: Data da Defesa: / /2013. Prof. Dr. Raimundo Corrêa de Oliveira (Orientador) Prof. Dr. Jucimar Maia da Silva Júnior Prof. Dr. Ernande Ferreira de Melo CIP - Catalogação na Publicação J58a JESUS, Darlisson Análise Comparativa do Desempenho de Unidades de Processamento Gráfico/ Darlisson Jesus; [orientado por] Prof. Dr Raimundo Corrêa de Oliveira - Manaus: UEA, p.: il.; 30cm Inclui Bibliografia Trabalho de Conclusão de Curso (Graduação em Engenharia de Computação). Universidade do Estado do Amazonas, CDU:

4 iii DARLISSON MARINHO DE JESUS ANÁLISE COMPARATIVA DO DESEMPENHO DE UNIDADES DE PROCESSAMENTO GRÁFICO Trabalho de Conclusão de Curso apresentado à banca avaliadora do Curso de Engenharia de Computação, da Escola Superior de Tecnologia, da Universidade do Estado do Amazonas, como pré-requisito para obtenção do título de Engenheiro de Computação. BANCA EXAMINADORA Aprovado em: / /2013 Prof. Raimundo Corrêa de Oliveira, Doutor UNIVERSIDADE DO ESTADO DO AMAZONAS Prof. Jucimar Maia da Silva Júnior, Doutor UNIVERSIDADE DO ESTADO DO AMAZONAS Prof. Ernande Ferreira de Melo, Doutor UNIVERSIDADE DO ESTADO DO AMAZONAS

5 iv Agradecimentos Agradeço à minha família por estar sempre ao meu lado e ter me apoiado durante todos esses anos de estudo. Agradeço também ao professor Raimundo Corrêa, pelos seus ensinamentos, compreensão e acima de tudo por compartilhar suas experiências de vida. Obrigado aos professores do curso, seus ensinamentos serviram de base e instrumento para o término desse trabalho. Por último, obrigado aos amigos que fiz durante os anos, tanto dentro quanto fora da Universidade e a todos aqueles que de alguma forma estiveram e estão próximos de mim, fazendo esta vida valer cada vez mais a pena.

6 v Resumo Muitos pesquisadores, cientistas e desenvolvedores já começaram a perceber que os sistemas computacionais heterogêneos baseado em unidades de processamento gráfico podem proporcionar aumentos significativos no desempenho de uma gama de aplicações. As unidades de processamento gráfico ou GPU (do inglês, Graphics Processing Unit) são co-processadores destinados inicialmente a melhorar ou prover de capacidade gráfica um computador. Porém, as aplicações para GPUs tem sido expandida à outras áreas, principalmente onde as aplicações requerem processamento pesado e possuam componentes que podem ser paralelizados, como a área de processamento digital de imagens. No entanto, os desenvolvedores precisam das unidades de processamento gráfico adequadas para projetar soluções de alto desempenho aliado ao menor custo das tecnologias com o passar do tempo. Neste trabalho, foi comparado o desempenho de alguns modelos de GPU dos fabricantes Nvidia e ATI, através da implementação do filtro de detecção de borda Sobel e o filtro Passa baixa na linguagem OpenCL(do inglês, Open Computing Language). Dentro do contexto de processamento digital de imagens com os filtros Sobel e Passa baixa, os resultados mostram que as unidades de processamento gráfico da fabricante Nvidia possuem o melhor desempenho de tempo de execução, mas são as GPUs da fabricante ATI que possuem as melhores taxas de transferência de memória, quando se considera imagens com dimensões superiores a dezesseis megapixels. Palavras Chave: GPU, OpenCL, comparação

7 vi Abstract Many researchers, scientists and developers have begun to realize that heterogeneous computing systems based on graphics processing units can provide significant increases in performance to a range of applications. The graphics processing unit (GPU) are coprocessors intended, originally, to improve the use and quality of computer graphics applications. However, the GPU applications has been extended to other fields to general purpose, especially where applications require high performance and have components that can be parallelized, such as digital image processing. However, developers need the graphics processing units suitable for designing high performance solutions along with smaller cost of technology over time. In this study, we compared the performance of some models of GPU from Nvidia and ATI manufacturers, through the implementation of the Sobel filter to edge detection and lowpass filter with the OpenCL language. Within the context of digital image processing with Sobel and low pass filters, the results show that the graphics processing units from Nvidia manufacturer having the best performance in run time, but are the GPUs from ATI manufacturer that have the best data transfer rates of memory, when considering images larger than sixteen megapixels. Key-words : GPU, OpenCL, comparison

8 vii Sumário Lista de Tabelas Lista de Figuras Lista de Códigos xi xii xiii 1 Introdução Descrição do Problema Justificativa Objetivos Objetivo Geral Objetivos Específicos Metodologia Organização Fundamentação Teórica Processamento Digital de Imagens Imagem digital Filtragem digital Filtragem no domínio espacial Filtro Sobel para detecção de borda Filtragem no domínio da frequência Visão geral da Transformada de Fourier Filtro Passa-baixa Computação Paralela Taxonomia de Flynn OpenCL Breve Histórico

9 viii Fundamentos do OpenCL Modelo de Plataforma Modelo de Execução Modelo de Memória Modelo de Programação Desenvolvimento com OpenCL Fluxo de trabalho Unidades de Processamento Gráfico Diferenças entre uma GPU e uma CPU Arquitetura Nvidia Tesla Arquitetura Nvidia Fermi Arquitetura ATI Caicos Metodologia e Implementações Detalhes da plataforma Especificações de hardware e software Informações dos dispositivos OpenCL Visão geral dos programas Filtro Sobel para detecção de borda Implementação em C Filtro Passa-baixa Criar fatores Twiddles FFT Principal Transpor Matriz Reversão de bits Operação Borboleta Normalizar Filtro Passa baixa em OpenCL Filtro Passa baixa em C Bibliotecas auxiliares em C Biblioteca utils.h Biblioteca cl utils.h Biblioteca pgm.h Resultados Experimentais Visão geral da execução do experimento Amostras

10 ix 4.3 Resultados da aplicação dos filtros Filtro Sobel para Detecção de Borda Filtro Passa-baixa Tempos de execução Filtro Sobel Tempo médio de execução Desvio padrão do tempo de execução Comparação entre GPU e CPU Filtro Passa baixa Tempo médio de execução Desvio padrão do tempo de execução Comparação entre GPU e CPU Taxas de transferência Filtro Sobel Taxa média de transferência na escrita Desvio padrão da taxa de transferência na escrita Taxa média de transferência na leitura Desvio padrão da taxa de transferência na leitura Filtro Passa baixa Taxa média de transferência na escrita Desvio padrão da taxa de transferência na escrita Taxa média de transferência na leitura Desvio padrão da taxa de transferência na leitura Discussão dos resultados Tempos de execução Taxas de transferências Conclusão Considerações finais Trabalhos futuros Referências Bibliográficas 72 A Detalhes dos dispositivos OpenCL 76 A.1 Informações técnicas dos dispositivos OpenCL

11 B Lista de Códigos 78 B.1 Filtro Sobel B.1.1 Programa host B.1.2 Programa kernel B.2 Filtro Passa-baixa B.2.1 Programa host B.2.2 Programa kernel B.3 Bibliotecas auxiliares em C B.3.1 utils.h B.3.2 cl utils.h B.3.3 pgm.h x

12 xi Lista de Tabelas 3.1 Resumo das especificações das GPUs Nvidia e ATI

13 xii Lista de Figuras 1.1 Fabricante dos co-processadores de Supercomputadores (Fonte: [Top ]) Uma imagem monocromática com a convenção para par de eixos (x, y) Resultado da aplicação do filtro Sobel para detecção de borda Procedimentos da filtragem no domínio da frequência com Fourier FFT - fluxo da Operação Borboleta Resultado da aplicação do filtro passa baixa ideal Ilustração das diferentes arquiteturas proposta na Taxonomia de Flyn O modelo de plataforma da OpenCL Execução de kernels - Work-groups e Work-Itens Modelo de memória do OpenCL Fluxograma de um programa em OpenCL Arquitetura de alto nível CPUs e GPUs Arquitetura da Nvidia Tesla Componentes da arquitetura da Nvidia Tesla Visão geral da arquitetura Nvidia Fermi Detalhes de um multiprocessador de stream na Nvidia Fermi Visão geral da arquitetura ATI Caicos Detalhes da arquitetura ATI Caicos Filtro Sobel - máscara de convolução aplicada à imagem Fluxograma do programa que computa a FFT Diagrama de sequência da execução do experimento Resultado da aplicação do filtro Sobel com a Nvidia Geforce GT Resultado da aplicação do filtro Sobel com a Nvidia Geforce Resultado da aplicação do filtro Sobel com a ATI Radeon HD Resultado da aplicação do filtro Passa baixa com Nvidia Geforce GT

14 4.6 Resultado da aplicação do filtro Passa-baixa com Nvidia Geforce Resultado da aplicação do filtro Passa-baixa com ATI Radeon HD Filtro Sobel - Tempo médio de execução nas GPUs Filtro Sobel - Desvio padrão do tempo de execução nas GPUs Filtro Sobel - Tempo médio de execução nas GPUs e CPU Filtro Passa baixa - Tempo médio de execução nas GPUs Filtro Passa baixa - desvio padrão do tempo de execução nas GPUs Filtro Passa baixa - tempo médio de execução nas GPUs e CPU Filtro Sobel - taxa de transferência média de escrita Filtro Sobel - desvio padrão da taxa de transferência de escrita Filtro Sobel - taxa de transferência média de leitura Filtro Sobel - desvio padrão da taxa de transferência de leitura Filtro Passa baixa - taxa de transferência média de escrita Filtro Passa baixa - desvio padrão da taxa de transferência de escrita Filtro Passa baixa - taxa de transferência média de leitura Filtro Passa baixa - desvio padrão da taxa de transferência de leitura xiii

15 xiv Lista de Códigos Kernel do filtro Sobel em OpenCL Código do filtro Sobel em C Kernel do filtro Passa-baixa em OpenCL Código do filtro Passa-baixa na linguagem C A.1.1Informações técnicas dos dispositivos OpenCL B.1.1Código fonte da programa host do filtro sobel B.1.2Código fonte do filtro sobel em OpenCL B.2.1Código fonte do programa host do filtro passa baixa B.2.2Código fonte do filtro passa baixa em OpenCL B.3.1Código fonte da biblioteca utils.h B.3.2Código fonte da biblioteca cl utils.h B.3.3Código fonte da biblioteca pgm.h

16 Capítulo 1 Introdução Microprocessadores baseados em uma única unidade central de processamento ou CPU (do inglês, Central Processing Unit), como aqueles da família Intel R Pentium R, impulsionaram aumentos de desempenho e redução de custo nas aplicações de computador por mais de duas décadas [David B. Kirk2011]. Cada vez mais surgem novas aplicações que exigem processadores com alto poder de processamento, principalmente aplicações científicas, como simulações climáticas. No entanto, para continuar aumentando o poder de processamento desses microprocessadores, a maioria dos fabricantes de microprocessadores passaram a fabricar modelos em que múltiplas unidades de processamento, conhecidas como núcleos, são usadas em cada chip. Isso se deu, principalmente, devido a questões de consumo de energia e dissipação de calor, que limitaram o aumento da frequência de clock e o nível de tarefas que podiam ser realizadas em cada período de clock dentro de uma única CPU. Uma outra solução é a utilização de modernas Unidades de Processamento Gráfico ou GPU (do inglês, Graphics Processing Unit), que ao contrário desse modelo baseado em múltiplos núcleos (multicore), a fabricação da GPU segue um projeto baseado em muitos núcleos (manycore). Por possuírem processadores com muitos núcleos e uma arquitetura favorável à programação paralela, essas modernas unidades de processamento gráfico têm sido amplamente adotadas em áreas de computação de alto desempenho na solução de problemas de cálculo em grande escala [Zhang et al.2011].

17 Descrição do Problema Descrição do Problema Além disso, como resultado da recente evolução das ferramentas para programação das GPUs, pesquisadores, cientistas e desenvolvedores, tornaram-se os maiores interessados em usufruir do poder destes processadores, principalmente no contexto da computação científica. Contudo, surge a necessidade de comparar o desempenho computacional das GPUs dos diferentes fabricantes, identificando a GPU com o melhor desempenho e, também, conhecer o quanto o desempenho da GPU pode ser superior ao de uma CPU. Essas informações podem auxiliar engenheiros e cientistas no projeto de soluções de alto desempenho, aliado ao menor custo das tecnologias com o passar do tempo. 1.2 Justificativa O uso das GPUs como os principais co-processadores utilizados nos supercomputadores é crescente, de forma que, explorar esse recurso computacional se torna bastante relevante, uma vez que ele pode fornecer alto poder de processamento. Na figura 1.1 é apresentado um gráfico que mostra a presença dos co-processadores na construção dos supercomputadores, de acordo com a [Top ]. As GPUs da fabricante Nvidia estão sendo utilizadas em mais de 60% dos supercomputadores. Isso, mostra que as GPUs de fato estão sendo adotadas como o principal recurso computacional para o processamento científico. Além disso, a linguagem OpenCL [Khronos OpenCL Working Group2008] é um padrão aberto para programação paralela de propósito geral em CPUs, GPUs e outros processadores. Ela consiste de uma API para coordenar a computação paralela entre processadores heterogêneos e uma linguagem de programação multi-plataforma baseada na linguagem C. De forma que, a área de Processamento de Digital de Imagem pode obter grandes benefícios da programação paralela com GPU, uma vez que, a maioria algoritmos usados nessa área são computacionalmente custosos, mas paralelizáveis [Gonzalez and Woods2006]. Além disso, os métodos tradicionais de processamento não conseguem satisfazer a exigência de tempo real para o processamento de imagem com grandes dimensões.

18 Objetivos 3 Figura 1.1: Fabricante dos co-processadores de Supercomputadores (Fonte: [Top ]) 1.3 Objetivos Objetivo Geral O objetivo do presente trabalho de Graduação é comparar o desempenho das Unidades de Processamento Gráfico das fabricantes NVIDIA e ATI, através do Processamento Digital de Imagens com os filtros Passa-baixa e o filtro Sobel para detecção de borda, implementados na linguagem OpenCL. E também, avaliar o quanto o desempenho das GPUs desses fabricantes é superior em relação as CPU da fabricante Intel Objetivos Específicos Determinar os indicadores de desempenho que permitam avaliar as rotinas destes filtros no contexto das GPUs e CPUs; Avaliar a arquitetura das GPUs da Nvidia e ATI, buscando identificar as diferenças que podem afetar no desempenho das implementações;

19 Metodologia 4 Implementar o algoritmo do filtro Passa-Baixa na linguagem OpenCL e obter os dados de desempenho das GPUs Nvidia e ATI; Implementar o algoritmo do filtro Passa-Baixa na linguagem C e obter os dados de desempenho das CPUs Intel; Implementar o algoritmo do filtro para detecção de borda Sobel na linguagem OpenCL e obter dados de desempenho das GPU Nvidia e ATI; Implementar o algoritmo do filtro para detecção de borda Sobel na linguagem C e obter dados de desempenho das CPUs Intel; Comparar o desempenho das GPUs dos fabricantes Nvidia e ATI; Comparar o desempenho das GPUs Nvidia e ATI com a CPU Intel; 1.4 Metodologia A pesquisa, quanto aos objetivos, conduz a uma experimentação, desta forma, caracterizando-se como pesquisa experimental, assim, foi realizado um estudo da especificação do OpenCL 1.1 [Khronos OpenCL Working Group2008] e dos principais conceitos de filtragem digital, tanto no domínio do tempo, quanto no domínio da frequência. Os filtros implementados neste trabalho, o filtro Passa-baixa, o filtro Sobel para detecção de borda e a rotina da Transformada Rápida de Fourier, foram embasados, principalmente, no livro do Rafael Gonzalez [Gonzalez and Woods2006]. A etapa seguinte, consistiu em montar o hardware necessário, sobre o qual foram realizados os testes de desempenho. Foram utilizados 3 computadores, com as mesmas configurações de processador, memória, placa-mãe, etc; e cada um, desses computadores, foi equipado com as placas gráficas: Nvidia Geforce GT 520, Nvidia Geforce 210 e ATI Radeon HD As aplicações foram implementados na linguagem C e OpenCL, com o Microsoft Visual Studio 2010 professional e as ferramentas de desenvolvimento disponibilizadas por cada um dos fabricantes das GPUs. Para a avaliação de desempenho, foi considerado as seguintes métricas:

20 Organização 5 Tempo médio de execução total, que corresponde ao tempo total da execução do programa, medida usada para GPU e CPU. Trata-se do tempo, em segundos, do ciclo de vida do programa do filtro. O tempo médio de execução foi calculado aplicando-se o cálculo da média aritmética sobre o conjunto de dados de tempo de execução. Taxa Média de Transferência Dados da Memória - corresponde ao número de bytes por unidade de tempo transmitidos entre a memória do computador e a memória da placa gráfica, na escrita e leitura, porém é uma métrica usada somente para as GPUs. A amostra com o maior tamanho, possui 64.0 MB (67,108,904 bytes), e a menor, cerca de 64.0 KB (65,551 bytes). Em resumo, a metodologia adotada é composta dos seguintes passos: Revisão bibliográfica; Análise e experimentação da linguagem OpenCL; Desenvolvimento dos Filtros Digitais (Sobel e Passa-baixa); Coleta das imagens para serem processadas; Coleta e análise dos dados; 1.5 Organização O restante desta dissertação está organizado da seguinte forma. O capítulo 2 apresenta os fundamentos teóricos necessários para o entendimento do texto. O capítulo 3 apresenta a metodologia utilizada neste trabalho e as implementações com a linguagem OpenCL dos filtros Sobel e Passa-baixa. No capítulo 4 são apresentados os resultados experimentais. Finalmente, o capítulo 5 apresenta a conclusão e as sugestões de trabalhos futuros.

21 Capítulo 2 Fundamentação Teórica Este capítulo tem por objetivo apresentar os principais conceitos necessários para entendimento deste trabalho. A primeira seção trata dos conceitos de imagens digitais e filtros digitais espaciais e no domínio da frequência. A seção 2 descreve o uso da linguagem OpenCL para programação de sistemas heterogêneos. Finalmente, a seção 3 aborda as Unidades de processamento gráfico do ponto de vista histórico e descreve as arquiteturas das GPUs utilizadas neste trabalho. 2.1 Processamento Digital de Imagens Segundo [Gonzalez and Woods2006], o Processamento Digital de Imagens (PDI) engloba o processo de manipulação de uma imagem por computador digital de forma que a entrada e a saída sejam imagens. O principal objetivo de se usar processamento digital de imagens é fornecer subsídios para facilitar a interpretação das informações de uma imagem para o analista humano e melhorar a imagem para que possa ser posteriormente submetida a outros processamentos. Dentre as áreas de aplicação do processamento de imagens podemos citar: Realce de imagens - No realce de imagens os detalhes como contornos são evidenciados, podendo ser aplicado na análise de impressões digitais para contornar as papilas dos dedos e remover borrões que dificultam o processo de leitura por equipamentos

22 Processamento Digital de Imagens 7 biométricos [Marques Filho and Vieira Neto1999]; Detecção de padrões - A detecção de padrões pode ser aplicada em sistemas de reconhecimento de face em imagens ou vídeos ou na identificação de veículos em situação irregular através do reconhecimento de placas [Pedrini and Schwartz2007]; Segmentação de imagens - A segmentação é usada para dividir a imagem em estruturas com as características relevantes para a aplicação em questão, bem como para destacar a localização, topologia e forma de objetos [Pedrini and Schwartz2007] Imagem digital Uma imagem monocromática pode ser descrita matematicamente por uma função f(x, y) da intensidade luminosa ou nível de cinza, sendo seu valor, em qualquer ponto de coordenadas espaciais (x, y), proporcional ao brilho da imagem naquele ponto [Marques Filho and Vieira Neto1999]. A figura 2.1 mostra uma imagem monocromática e a convenção utilizada para o par de eixos (x, y). Figura 2.1: Uma imagem monocromática com a convenção para par de eixos (x, y). Os filtros digitais implementados neste trabalho, foram projetados para trabalharem com imagens monocromáticas, bidimensionais e estáticas. Na secção 4.2, é possível obter maiores detalhes do formato das imagens utilizadas.

23 Processamento Digital de Imagens Filtragem digital O processo de filtragem tem como objetivo extrair informações como as bordas da imagem ou corrigir algumas degradações na imagem, de modo que, a imagem resultante seja mais adequada que a imagem original para uma aplicação específica. Basicamente, as técnicas de filtragem são transformações da imagem pixel a pixel, que dependem da intensidade luminosa (nível de cinza) de um determinado pixel e do valor dos níveis de cinza dos pixel vizinhos, na imagem original, ou seja, cada o pixel filtrado da imagem, tem um valor que depende do contexto em que ele se encontra na imagem original. Os filtros são divididos em duas categorias: filtros no domínio do espaço e filtros no domínio da frequência Filtragem no domínio espacial Uma imagem digitalizada pode ser representada como uma matriz de pixels, dessa forma, os procedimentos de filtragem no domínio espacial manipulam diretamente os pixels da imagem. Então, pode-se expressar as funções de processamento de imagens no domínio espacial como: g(x, y) = T [f(x, y)] (2.1) onde: g(x, y) é a imagem processada, f(x, y) é a imagem original e T é um operador em f, definido em uma certa vizinhança de (x, y) Filtro Sobel para detecção de borda O filtro Sobel é uma operação utilizada em processamento de imagem, aplicada sobretudo em algoritmos de detecção de borda, e foi proposto por Irwin Sobel em [Sobel1970]. Em termos técnicos, consiste num operador que calcula diferenças finitas, dando uma aproximação do gradiente da intensidade dos pixels da imagem. O filtro Sobel calcula o gradiente da intensidade da imagem em cada ponto, dando a direção da maior variação de claro para escuro e a quantidade de variação nessa direção.

24 Processamento Digital de Imagens 9 Assim, obtém-se uma noção de como varia a luminosidade em cada ponto, de forma mais suave ou abrupta. Com isto consegue-se estimar a presença de uma transição claro-escuro e de qual a orientação desta. Como as variações claro-escuro intensas correspondem a fronteiras bem definidas entre objetos, consegue-se fazer a detecção de borda [Gonzalez and Woods2006]. Na figura 2.2 é possível observar o resultado da aplicação do filtro Sobel para detecção de borda. (a) Imagem original (b) Imagem após a aplicação do filtro Sobel Figura 2.2: Resultado da aplicação do filtro Sobel para detecção de borda Em termos matemáticos, este filtro utiliza duas matrizes 3x3 que são convoluídas com a imagem original para calcular aproximações das derivadas - uma para as variações horizontais Gx e uma para as verticais Gy. Sendo A a imagem de entrada então, Gx e Gy serão duas imagens que em cada ponto contêm uma aproximação às derivadas horizontal e vertical de A. Gx = A Gy = A A magnitude do gradiente é dado por: G = Gx 2 + Gy 2 (2.2)

25 Processamento Digital de Imagens Filtragem no domínio da frequência As técnicas de filtragem no domínio da frequência se baseiam, matematicamente, no teorema da convolução. Seja g(x, y) a imagem formada pela convolução (denotada pelo simbolo *) da imagem f(x, y) com um operador linear h(x, y), ou seja, g(x, y) = f(x, y) h(x, y) (2.3) Considerando o teorema da convolução, a seguinte relação no domínio da frequência também é valida: G(u, v) = F (u, v)h(u, v) (2.4) onde G, F e H são os resultados obtidos pela aplicação da Transformada de Fourier nas imagens g, f e h, respectivamente. Associando aos sistemas lineares, a transformada H(u, v) é denominada função de transferência do filtro [Lathi2007]. Em uma aplicação de suavização de imagens, por exemplo, dada uma imagem f(x, y), o problema consiste em selecionar H(u, v) de tal maneira que conduza a imagem desejada G(u, v). A transformada inversa de Fourier, define a imagem filtrada no domínio espacial, como ilustrado na equação 2.5. f(x, y) = I 1 [F (u, v)h(u, v)] (2.5) Esse fluxo de operação dos filtros no domínio da frequência é ilustrado na figura 2.3. Imagem f(x,y) DFT (FFT) F(u,v)H(u,v) Filtro H(u,v) X (DFT) -1 Imagem processada f (x,y) Figura 2.3: Procedimentos da filtragem no domínio da frequência com Fourier

26 Processamento Digital de Imagens 11 Algumas considerações sobre o domínio da frequência: A frequência é diretamente relacionada a taxas espaciais de variação da intensidade luminosa da imagem; As baixas frequências da imagem correspondem aos componentes de intensidade de variação lenta em uma imagem, à medida que se distancia da origem da transformada. As frequências mais altas correspondem a variações de intensidade mais rápidas, como por exemplo, bordas de objetos e outros elementos que fazem mudanças abruptas de intensidade Visão geral da Transformada de Fourier A Transformada de Fourier é uma transformada integral que expressa uma função em termos de funções de base sinusoidal, por exemplo, como soma ou integral de funções sinusoidais multiplicadas por coeficientes ( amplitudes ) [Lathi2007]. Em geral, a transformada de Fourier é tipicamente utilizada para decompor um sinal nas suas componentes em frequência e suas amplitudes. Geralmente, a denominação Transformada de Fourier é referente à Transformada de Fourier para funções contínuas, que representa qualquer função integrável x(t) como a soma de exponenciais complexas com frequência angular ω, medida em radianos/s, e amplitude complexa X(ω). A fórmula para o cálculo da transformada contínua de Fourier é mostrada na equação 2.6. X(ω) = x(t)e iωt dt (2.6) A saída da Transformada de Fourier contém todos os elementos de sua entrada, de forma que pode ser usado um processo conhecido como a Transformada Inversa de Fourier para recuperar o sinal original, a fórmula para esse cálculo é mostrada na equação 2.7. x(t) = I 1 (X(ω)) = 1 X(ω)e iωt dω (2.7) 2π

27 Processamento Digital de Imagens 12 Onde i é um número imaginário. Pela equação 2.6, foi possível observar que a Transformada de Fourier opera em dados contínuos. No entanto, dados contínuos contém números infinitos de amostras e com precisão infinita. Para que este processamento seja prático, a Transformada de Fourier deve ser capaz de processar um conjunto de dados que contém um número finito de elementos. Portanto, um processo conhecido como a Transformada de Fourier Discreta ou DFT (do inglês, Discrete Fourier Tranform), foi desenvolvido para estimar a Transformada de Fourier, e que opera sobre um conjunto de dados finitos [Lathi2007]. A fórmula matemática é mostrada abaixo. X k = N 1 n=0 x n e i2πk n N k = 0, 1,..., N 1 (2.8) A Transformada Discreta Inversa de Fourier é definida pela equação 2.9 x n = 1 N N 1 k=0 X k e i2πk n N n = 0, 1,..., N 1 (2.9) Pela equação 2.8 o processamento da DFT é realizado com um número finito de amostras. No entanto, o problema com este método está em sua complexidade computacional que é O(n 2 ), ou seja à medida que o número de amostras é aumenta, o tempo de processamento aumenta exponencialmente. Transformada Rápida de Fourier - FFT Existe um algoritmo eficiente para se calcular a DFT e a sua inversa, chamado Transformada Rápida de Fourier ou FFT (do inlgês, Fast Fourier Transform). Existem várias implementações diferentes da FFT, esse trabalho implementa o algoritmo de Cooley- Tukey [Cooley and Tukey1965]. A explicação completa desse algoritmo não é foco desse trabalho, uma explicação detalhada pode ser encontrada em [Rao et al.2011]. O algoritmo Cooley-Tukey aproveita a natureza cíclica da Transformada de Fourier e computa em O(nlogn), dividindo a DFT em DFTs menores. A limitação deste algoritmo é que o número de amostras de entrada deve ser uma potência de 2. Todas as amostras usadas nesse experimento satisfazem essa exigência, como pode ser visto na seção 4.2. A principal operação no cálculo desse algoritmo da FFT é conhecido como Operação

28 Processamento Digital de Imagens 13 borboleta. Essa operação é realizada em um par de amostras de cada vez, cujo fluxo de operações é mostrado na figura 2.4 [Rao et al.2011]. Figura 2.4: FFT - fluxo da Operação Borboleta O W visto na figura 2.4 é um coeficiente trigonométrico conhecido como Twiddle factor e definido como: W = e i 2π N (2.10) Nota-se na figura 2.4 que os índices de entrada são reordenados, essa mudança é feita por questões de otimizações e os detalhes do por que isso é feito pode ser encontrado em [Rao et al.2011] Filtro Passa-baixa Um filtro do tipo passa-baixa é aquele que deixa passar as baixas frequências, eliminando os valores relacionados às altas frequências. Portanto, o efeito deste filtro é o de suavizar a imagem, uma vez que as altas frequências que correspondem às transições abruptas são atenuadas. A suavização tende pelo mesmo motivo, diminuir o ruído em imagens. [Gonzalez and Woods2006] Neste trabalho foi implementado o filtro passa-baixa ideal que opera no domínio da frequência. E para isso, foi necessário implementar o algoritmo que computa a Transfor-

29 Processamento Digital de Imagens 14 mada Rápida de Fourier. De acordo com Vieira, [Marques Filho and Vieira Neto1999], sendo F (u, v) a transformada de Fourier da imagem a ser processada e sendo G(u, v) a transformada de Fourier da imagem que se deseja obter à saída (com os componentes de alta frequência atenuados), a filtragem passa-baixas consiste em encontrar um H(u, v) tal que: G(u, v) = F (u, v)h(u, v) (2.11) Filtro passa-baixas ideal - Segundo [Gonzalez and Woods2006], um filtro passabaixas 2-D ideal é aquele cuja função de transferência satisfaz a relação: 1, se D(u, v) Do, H(u, v) = 0, se D(u, v)x > Do. (2.12) onde Do é a frequência de corte medida a partir da origem e D(u, v) é a distância do ponto (u, v) até a origem do plano de frequência, que é obtido por: D(u, v) = (u P/2) 2 + (v Q/2) 2 (2.13) onde, P e Q são, respectivamente, a largura e a altura da imagem. Quanto menor o raio Do, menor a frequência de corte e, portanto, maior o grau de borramento da imagem resultante. Neste trabalho é definido Do como sendo Do = DimensoDaImagem/8, esse valor foi o que melhor evidenciou os efeitos do filtro. Na figura 2.5 é apresentado o resultado da aplicação do filtro passa baixa ideal em uma imagem.

30 Computação Paralela 15 (a) Imagem original (b) Imagem após a aplicação do filtro Sobel Figura 2.5: Resultado da aplicação do filtro passa baixa ideal O comportamento do filtro passa baixa é de causar uma suavização da imagem, uma vez que as transições abruptas (altas frequências) são atenuadas. Apesar desse filtro tender a minimizar o efeito de ruído, a nitidez da imagem também diminui. 2.2 Computação Paralela A computação paralela é uma forma de computação em que muitos cálculos são realizados simultaneamente, considerando o princípio de que os grandes problemas podem, frequentemente, ser divididos em partes menores, e então serem resolvidos simultaneamente ( em paralelo ) [Almasi and Gottlieb1989]. Quanto as formas de paralelismo, geralmente faz se uma distinção entre o chamado paralelismo em dados e paralelismo em tarefas. O paralelismo em dados é focado em distribuir o dado por diferentes nós (núcleos) computacionais para serem processados em paralelo. Enquanto que, o paralelismo em tarefa é a característica de um programa paralelo em que diferentes cálculos são realizados no mesmo ou em diferentes conjuntos de dados. A programação paralela tem sido utilizada por muitos anos, principalmente na computação de alto desempenho, de forma que a computação paralela se tornou o paradigma domi-

31 Computação Paralela 16 nante na arquitetura de computadores, principalmente para processadores multicore [Asanovic et al.2009]. Para que se possa entender como programas paralelos podem ser projetados, é necessário definir como as arquiteturas de computadores são classificadas, uma das maneiras de se fazer isso é usando a taxonomia de Flynn Taxonomia de Flynn Existem diferentes maneiras de classificar arquiteturas de computadores, uma das mais clássicas é a Taxonomia de Flynn [Flynn1972], que distingue as arquiteturas de computadores de acordo com o fluxo de instruções e de dados. Cada um desses fluxos pode ser simples ou múltiplo. São definidas quatro classificações: SISD - Single Instruction Single Data: corresponde à arquitetura dos dispositivos com um único processador, onde apenas uma instrução ou um fluxo de dados é processado a cada momento. SIMD - Single Instruction Multiple Data: a mesma instrução é executada simultaneamente sobre diversos conjuntos de dados. MISD - Multiple Instruction Single Data: constituída por uma pipeline de unidades de processamento independentes que operam sobre um mesmo fluxo de dados enviando os resultados de uma unidade para a próxima. MIND - Multiple Instruction Multiple Data: Cada processador pode executar seu próprio fluxo de dados. Na figura 2.6 é apresentado a ilustração de cada classificação listada acima, onde cada PU (do inglês, processing unit é uma unidade de processamento central.

32 Computação Paralela 17 (a) Single instruction, single data (b) Multiple instruction, single data (c) Single instruction, multiple data (d) Multiple instruction, multiple data Figura 2.6: Ilustração das diferentes arquiteturas proposta na Taxonomia de Flyn. Estas quatro categorias principais já foram estendidas e existem variações, como SPMD (do inglês, Single Program, Multiple Data), proposta em [Darema et al.1988]. Esse modelo é similar ao SIMD, porém, cada unidade de processamento tem o seu próprio contador de programa permitindo-lhes trabalhar de forma independente, assim, colocando o SPMD na categoria MIMD.

33 Computação Paralela OpenCL O OpenCL (do inglê, Open Computing Language) é uma linguagem constituída de uma API (do inglês, Application Programming Interface) padrão para programação de computadores compostos de uma combinação de CPUs, GPUs e outros processadores. Esses sistemas computacionais são conhecidas como sistemas heterogêneos. O OpenCL é um padrão aberto mantido pelo Khronos group e voltado para o desenvolvimento paralelo em sistemas heterogêneos contendo CPUs, GPUs e outros aceleradores [Khronos OpenCL Working Group2008]. O OpenCL é baseada em um subconjunto estendido do padrão ISO C99 e, portanto, é muitas vezes referido como OpenCL C Breve Histórico A primeira especificação do OpenCL foi feita Apple Inc em 2007, mas foi aprimorada numa proposta de colaboração entre as equipes técnicas da AMD, IBM, Intel e Nvidia. Essa proposta foi então enviada para o Khronos Group, um consórcio com foco na criação de padrões abertos livres, como OpenGL R. Assim, em 2008 foi criado o Khronos Compute Working Group, com representantes de empresas de CPU, GPU, processadores embarcados e software. A versão preliminar 1.0 do OpenCL foi lançada cinco meses depois, sendo revisada e lançada oficialmente em dezembro de A versão mais atual do OpenCL é a 1.2, porém, somente a AMD e a Intel disponibilizam essa versão em seus kits de desenvolvimento. É importante notar aqui que OpenCL não é uma implementação real, mas sim uma especificação que fabricantes de hardware podem optar por apoiar. Em outras palavras, mesmo que uma aplicação possa rodar em hardware de dois fornecedores diferentes, o desempenho pode ser radicalmente diferente Fundamentos do OpenCL O OpenCL tem suporte para vários tipos de aplicações, porém, existe um conjunto de passos que as aplicações para plataforma heterogêneas devem seguir [Munshi et al.2011] : Descobrir os componentes que compõem o sistema heterogêneo;

34 Computação Paralela 19 Explorar as características desses componentes para que o software possa adaptar-se às características específicas dos diferentes elementos de hardware. Criar blocos de instrução (kernels) que irão ser executados na plataforma; Configurar e manipular os objetos de memória envolvidos; Executar os kernels na devida ordem assim como os componentes de sistema; Coletar os resultados. Para atingir esses passos é necessário usar a API dentro do OpenCL e o ambiente de programação dos kernels. Dessa forma, para entender a estratégia de programação dessas chamadas de API é preciso entender a arquitetura do Opencl, que é dividida em quatro modelos: Plataforma, Execução, Memória e Programação Modelo de Plataforma O modelo de plataforma do OpenCL é composto por um ou vários dispositivos computacionais ou (Devices. Um device pode ser uma GPU, por exemplo. Cada device possui diversas unidades computacionais (compute units), que possuem diversos elementos de processamento (processing elements)(alu, cache, memória compartilhada). Já um kernel é um programa escrito na linguagem OpenCL que é executado por todas as unidades computacionais ao mesmo tempo, que trata o fluxo de dados multiprocessado no modelo SIMD (do inglês, Single Instruction, Multiple Data). O sistema computacional responsável pela agregação, interações de entrada/saída, inicialização e submissão de tarefas a diferentes devices OpenCL é denominado de Host. Host, devices, compute units e processing elements compõem o modelo de plataforma da arquitetura OpenCL, como mostrado na figura 2.7. Esse modelo define as representações de alto nível da plataforma heterogênea que será usada com o OpenCL.

35 Computação Paralela 20 Figura 2.7: O modelo de plataforma da OpenCL com um host e outros dispositivos OpenCL. Cada dispositivo OpenCL tem uma ou mais unidades, cada qual com um ou mais elementos de processamento [Munshi et al.2011] Modelo de Execução O modelo de execução define que uma aplicação OpenCL é composta de duas partes diferentes: o host program e uma coleção de um ou mais kernels. O host program é executado no host (normalmente uma CPU) e os kernels são definidos no host e executados nos dispositivos OpenCL, e são eles os responsáveis pelos resultados de uma aplicação OpenCL. O programa host configura o contexto em que os kernels irão executar, incluindo a alocação de memória, transferência de dados entre os objetos de memória e criação de command-queues que são usadas para controlar a sequência em que os comandos são executados, incluindo os comandos que executam kernels. Para facilitar a execução paralela um espaço de índices é criado quando o kernel é submetido para ser computado no dispositivo opencl. Uma instância do kernel, chamado de item de trabalho ( work-item) é criado para cada índice e pode, posteriormente, ser identificado por esse índice. Os itens de trabalho são organizados, por sua vez, em grupos de trabalho work-groups. Assim como os itens de trabalho, cada grupo de trabalho possui um índice único, derivado do mesmo espaço de índice. Além de seus índices globais, os itens de trabalho possuem um índice local para identificar a sua localização dentro do seu grupo de trabalho.

36 Computação Paralela 21 Durante a execução, todos os itens de trabalho em um grupo de trabalho serão executados simultaneamente. O espaço de índices usados para dimensionar a quantidade de itens de trabalhos que serão usados no OpenCL é chamado de NDRange. O NDRange, como o nome sugere, suporta indexação multidimensional, no entanto, a versão mais atual do OpenCL (versão 1.2) só suporta a inclusão de até três dimensões. Na fígura 2.8 ilustra a relação entre kernels, work-itens e work-group. Figura 2.8: Execução de kernels - Work-groups e Work-Itens [Munshi et al.2011] Para que o host seja capaz de iniciar a execução de um kernel ele deve ser capaz de enfileirar alguns comandos. OpenCL consegue isso através do que ele chama de um contexto (context). O contexto contém os dispositivos a serem utilizados, os kernels e seus objetos de programa e objetos de memória. Usando este contexto, o host cria uma fila de comando (command-queue) usando a API do OpenCL. Os comandos quehost pode adicionar à fila de comandos, podem ser três categorias: comandos de execução do Kernel comandos de memória comandos de sincronização

37 Computação Paralela 22 A fila de comandos permite dois modos de execução de comandos enfileirados; Em ordem (In-order) e fora de ordem (In-order). Execução em ordem obriga a serialização dos comandos, enquanto que a fora de ordem permite que comandos iniciem a execução antes que os comandos anteriores tenham terminado a execução Modelo de Memória O OpenCL define dois tipos de objetos de memória: buffer objects e image objects. O primeiro, buffer object é um bloco de memória disponível para os kernels. É possível mapear estruturas de dados para este buffer e acessá-lo através de ponteiros. Por outro lado, os tipos image objects são restritos para a imagens digitais. Um formato de imagem pode ser otimizado de acordo com a necessidade de um dispositivo OpenCL específico. O modelo de memória da OpenCL define cinco tipos distintos de região de memória [Munshi et al.2011]: Host memory: essa região de memória é somente visível para o host. Global memory: essa região de memória permite acesso de leitura/escrita a todos os work-items em todos os work-groups. Constant memory: essa região de memória global permanece constante durante a execução de um kernel. O host aloca e inicializa os objetos de memória localizados na constant memory. Work-Items têm acesso de somente leitura a esse objetos. Local memory: essa região de memória é local ao work-group e pode ser usada para alocar variáveis que são compartilhadas a todos os work-items de um work-group. Private memory: essa região de memória é privada a um work-item. Variáveis definidas na memória privada de um work-item não são visíveis a outros work-items. Os work-itens são executados em elementos de processamento e tem suas próprias memórias privadas. Um work-group é executado em uma unidade de computação e compartilha uma região de memória local com os work-items no seu grupo. A memória do dispositivo OpenCL trabalha com o host para dar suporte à memória global como é apresentado figura 2.9.

38 Computação Paralela 23 Figura 2.9: Modelo de memória do OpenCL [The OpenCL Specification2010] A interação entre a memória do host e a do dispositivo OpenCL ocorre somente na transferência de dados entre as memórias, tanto de escrita quanto leitura. Essas memórias são, na maior parte das vezes, independentes uma da outra, uma vez que o host é definido fora do OpenCL Modelo de Programação O modelo de execução OpenCL suporta os modelos de programação de dados paralelos (Data-Parallel) e de tarefas paralelas (Task-Parallel), bem como suporta um híbrido desses dois modelos. O modelo principal que conduz o projeto OpenCL é o Data-Parallel. O modelo de programação Data-Parallel define uma sequência de instruções aplicadas a vários elementos de um objeto de memória. Como visto da seção Modelo de execução, O índice de espaço associado a um modelo de execução define os work-items e como os dados devem ser mapeados para os work-items. Em um modelo estrito de programação paralela de dados, existe um mapeamento de um-para-um do work-item e o elemento em um objeto de memória, através do qual um kernel pode ser executado em paralelo. O OpenCL define um modelo reduzido desse modelo

39 Computação Paralela 24 estrito, de forma que o mapeamento um-para-um não é requerido. Se o kernel não contém qualquer instrução condicional, cada work-items irá executar operações idênticas, mas em um subconjunto de itens de dados selecionados pelo seu ID global Desenvolvimento com OpenCL Fluxo de trabalho O fluxo de um programa básico em OpenCL possui o seguinte fluxo de trabalho [Munshi et al.2011]: 1. Inicialização Descobrir e escolher as plataformas e dispositivos; Criar o contexto de execução; Criar a fila de comandos para um dispositivo; Carregar o programa, compilá-lo e gerar o kernel; 2. Preparação da memória (leitura e escrita) Criar os objetos de memória que serão transferidos para o device; 3. Execução Transferência de dados para o dispositivo; Execução do kernel : definição dos argumentos e trabalho/particionamento; Espera pela finalização da execução do kernel; Transferência dos resultados para o hospedeiro; 4. Finalização Garanti a finalização do kernel; Desalocar objetos da memória do device;

40 Computação Paralela 25 O fluxo descrito acima é resumido na figura 2.10 através das chamadas de funções da API do OpenCL. É importante ressaltar que cada função é dependente da anterior e elas manipulam objetos próprios do OpenCL. Início clgetplatformids() clgetdeviceids() clcreatecontext() clcreatecommandqueue() clcreateprogramwithsource() clbuildprogram() clcreatekernel() clcreatebuffer() clenqueuewritebuffer() clsetkernelarg() clenqueuendrangekernel() clenqueuereadbuffer() clfinish() clrelease[kernel, Program..]() Preparar Inicialização Memória Execução Finalização Fim Figura 2.10: Fluxograma de um programa em OpenCL Durante a fase de inicialização do programa OpenCL, é criado um contexto (clcreate- Context()) no qual o dispositivo (devices) pode operar. Isto é alcançado através de uma

41 Unidades de Processamento Gráco 26 consulta à lista de dispositivos OpenCL disponíveis dentro do sistema (clgetdeviceids()) e criando esse contexto com referência a um dispositivo específico (device ID) dessa lista. Quando toda a configuração necessária é feita, uma fila deve ser especificada para coordenar os comandos que serão submetidos para o dispositivo a partir do host. A fila é criada (clcreatecommandqueue()) com referência a um contexto e um dispositivo específico, e permite que as operações sejam realizadas sobre os objetos de memória do OpenCL, kernels e programas [Khronos Group2010]. Com a fila de comandos especificada, é possível alocar memória para os dados de entrada e saída e para os kernels a serem executados. Em seguida, os programas dos kernels são criados, o que pode ser feito através de arquivos binários pré-compilados, ou a partir do código fonte (clcreateprogramwithsource()). Após o programa ser criado, ele pode ser construído (clbuildprogram()) para todos os dispositivos dentro de um contexto específico. Cada kernel que será executado, deve possuir um identificador único (clcreatekernel()), de forma que a máquina host possa se comunicar com ele. Além disso, é através do identificador do kernel que todos os argumentos necessários são passados (clsetkernelarg()), e então o kernel pode operar sobre os dados criados previamente (clcreatebuffer()) e escritos na memória do dispositivo (clenqueuewritebuffer()). Após o kernel ser executado (clenqueuendrangekernel()), todos os dados são lidos de volta da memória do dispositivo para o host (clenqueureadbuffer()) e todos os recursos utilizados anteriormente são liberados (clfinish(), clreleaseprogram(), clreleasekernel() e etc). Após esse fluxo, o programa host conclui sua execução. 2.3 Unidades de Processamento Gráfico Unidades de processamento gráfico (GPUs) é o nome dado a um tipo de microprocessador especializado em processar gráficos em computadores pessoais, estações de trabalho ou videogames e que hoje podem ser encontradas na maioria dos sistemas de computação convencionais [Owens et al.2008]. Como o nome sugere, GPUs têm suas origens no processamento de gráficos, mais especificamente na rasterização (tarefa de converter uma imagem descrita em um imagem vetorial em uma imagem raster (pixels ou pontos) para a saída em vídeo ou impressora). A rasterização é feita através de uma abordagem em pipeline onde cada elemento da imagem vetorial passa através de uma série de diferentes

42 Unidades de Processamento Gráco 27 estágios altamente especializados. As GPUs mais antigas possuíam o hardware especializado para cada uma dessas etapas, porém, os dispositivos gráficos modernos usam uma arquitetura unificada, onde cada um dos os processadores individuais do pipeline de rasterização é programável e capaz de processar o mesmo conjunto de instruções Diferenças entre uma GPU e uma CPU A CPU é projetada para executar uma thread por vez e para realizar cálculos muito complexos e em geral com uma grande quantidade de ramificações. Uma CPU com 4 processadores hexa-core pode executar apenas 24 threads simultaneamente (ou 48 se possuir suporte a Hyper-Threading) [David B. Kirk2011]. Para efeito de comparação, a menor unidade de paralelismo executável num dispositivo da Nvidia é capaz de executar 32 threads. As GPUs mais recentes da Nvidia possuem suporte para até threads ativas ao mesmo tempo por multiprocessador. Em GPUs com 16 multiprocessadores, isso equivale a mais de threads ativas simultaneamente. Figura 2.11: Arquitetura de alto nível CPUs e GPUs, fundamentalmente diferentes [David B. Kirk2011]. Na Figura 2.11, é apresentado as diferenças de alto nível de projeto nos dois tipos de processadores. A arquitetura da CPU é otimizada para o desempenho de código sequencial. Ela utiliza uma lógica sofisticada para permitir que instruções de uma única thread de execução sejam executadas em paralelo ou mesmo fora de sua ordem sequencial. Enquanto que, a filosofia de projeto das GPUs é modelada pela crescente indústria de videogames que exerce uma tremenda pressão econômica para a capacidade de realizar um número maciço de cálculos de ponto flutuante por quadro [David B. Kirk2011]. A solução que prevalece

43 Unidades de Processamento Gráco 28 até o momento é otimizar para a vazão de execução do número maciço de threads. Neste trabalho, foi utilizado três unidades de processamento gráfico, Nvidia Geforce GT 520, Nvidia Geforce 210 e ATI Radeon HD 6450, cada GPU dessas, foi concebida com uma arquitetura diferente. De forma que, é preciso conhecer os principais detalhes dessas arquiteturas para entender as diferenças entre elas, que podem influenciar no desempenho dessas unidades de processamento gráfico Arquitetura Nvidia Tesla A arquitetura Nvidia Tesla baseia-se em uma matriz de processadores escaláveis. A figura 2.12 apresenta a arquitetura da Nvidia GeForce 8800, GPU que introduziu a arquitetura Tesla em novembro de 2006, com 128 processadores de stream ou SP (do inglês, stream processors) organizados em 16 multiprocessadores de stream ou SM (do inglês, stream multiprocessor), e isso tudo, dentro de oito unidades de processamento independentes chamado TPC ( do inglês, texture/processors cluster). Cada SP tem uma unidade de multiplicaçãoadição ou MAD (do inglês Multiply Add) e uma unidade de multiplicação. Figura 2.12: Arquitetura da Nvidia Tesla ( [Lindholm et al.2008])

44 Unidades de Processamento Gráco 29 Na figura 2.13 é mostrado com mais detalhes o TPC, que contém um controlador de geometria, um controlador de SM (SMC), dois multiprocessadores de streaming (SMs), e uma unidade de textura. E cada SM tem oito núcleos SP, duas unidades de função especiais (SFUs), caches de instrução e caches constantes, uma unidade de ensino de vários segmentos e uma memória compartilhada. O SMC controla várias SMs, arbitrando a unidade compartilhada de textura. Figura 2.13: Componentes da arquitetura da Nvidia Tesla ( [Lindholm et al.2008]) A GPU Nvidia GeForce 210 foi construída com essa arquitetura e é usada neste trabalho. Ela possui 2 multiprocessadores de streamming com 8 SP cada, totalizando 16 processadores de streaming Arquitetura Nvidia Fermi Lançada em abril de 2010, esta arquitetura trouxe suporte para novas instruções para programas em C++, como alocação dinâmica de objeto e tratamento de exceções em operações de try e catch. Cada SM de um processador Fermi possui 32 CUDA cores. Até 16 operações de precisão dupla por SM podem ser executadas em cada ciclo de clock [Nvidia Corporation2010]. Além disso, cada SM possui: Dezesseis unidades de load e store, possibilitando que o endereço de fonte e destino possam ser calculados para dezesseis threads por clock.

45 Unidades de Processamento Gráco 30 Quatro Special Function Units (SFUs), que executam instruções transcendentais, como seno, cosseno, raiz quadrada, etc. Cada SFU executa uma instruções por thread por ciclo. O pipeline da SFU é desacoplado da dispatch unit, permitindo que esta possa realizar o issue (despacho) de outra instrução enquanto a SFU está ocupada. A Figura 2.14 apresenta a visão geral da arquitetura Fermi. É possível observar uma cache de segundo nível (L2) compartilhada por todos os SM. A cache de primeiro nível (L1) é compartilhada pelos 32 núcleos de cada SM. A memória compartilhada (shared memory) pode ser usada explicitamente pelo programador como uma memória de rascunho, que pode acelerar o processamento de uma aplicação, dependendo do seu padrão de acesso aos dados. Esta memória é dividida fisicamente com a cache de primeiro nível com um total de 64KB, cujo tamanho é configurável: 16 KB e 48KB para cache e memória compartilhada respectivamente ou ao contrário. Além dos dois níveis de cache e da memória compartilhada, a Fermi conta com uma memória global (DRAM) de até 6GB. Figura 2.14: Visão geral da arquitetura Nvidia Fermi [Nvidia Corporation2010] Na figura 2.15 é apresentado os principais componentes de um SM que compõe a arquitetura Fermi, apresentando seus núcleos simplificados, as unidades de escalonamento e

46 Unidades de Processamento Gráco 31 despacho de instruções, os registradores, a cache de nível 1, entre outros. Figura 2.15: Detalhes de um multiprocessador de stream na Nvidia Fermi [Nvidia Corporation2010] Cada SM é composto por quatro blocos de execução, que são controlados por duas unidades escalonamento, chamadas de warps (um grupo de 32 threads): dois blocos de 16 núcleos simples, capazes de executar em ordem uma instrução inteira ou de ponto flutuante, um bloco de 16 unidades load/store e um bloco de 4 unidades de processamento de instruções especiais (SFU - Special Function Units). Além disso, cada SM conta com uma memória cache L1/memória compartilhada de 64KB, já mencionada, e com 32KB de registradores, compartilhados entre todas as threads que executarão no SM. A GPU Nvidia GeForce GT 520, que é usada neste trabalho, é fabricada com a segunda geração dessa arquitetura e ela possui um total de 48 processadores de streammimg em um único multiprocessador de streaming SM.

47 Unidades de Processamento Gráco Arquitetura ATI Caicos De codinome Caicos, esta arquitetura foi lançada em 7 de fevereiro de 2011 com um único produto, a GPU Radeon HD Essa arquitetura é apresentada na figura Pode-se observar que a arquitetura da ATI Radeon 6450 é formada por 4 unidades de renderização de saída (ROPs), 2 unidades do mecanismo SIMD (parecido com os multiprocessadores de streaming (SM) da Nvidia), 2 unidades de textura (texture units), 1 bloco de cache L2 de 128KB e um controlador de memória de 64 bits ligados aos ROPs por um barramento de memória de 256-bit. Figura 2.16: Visão geral da arquitetura ATI Caicos Os mecanismos SIMD são encapsulados em unidades computacionais compute units e possuem 80 processadores de stream cada, assim, essa GPU possui 160 stream cores. O cache L1 de textura (L1TC) é de 8KB e o cache L1 de computação é 16 KB (LDS). Além disso, os streams cores usam a tecnologia VLIW (do inglês, Very Long Instruction Word), o que permite a execução de um grupo de instruções ao mesmo tempo.

48 Unidades de Processamento Gráco 33 Na figura 2.17, observa-se que cada processador de stream ou SP, possui cinco unidades lógica aritméticas ou ALU (do inglês Arithmetic Logic Unit), organizados em um projeto superescalar, ou seja, cada uma das ALUs pode executar uma instrução diferente, mas as instruções devem ser submetidas juntos de uma única vez. A primeira ALU, (da esquerda), é representada diferente das outras, pois possui instruções especiais, instruções transcendentais (como seno e cosseno) usadas para operações matemáticas específicas. Todos as outras quatro ALU têm as mesmas capacidades [Scott Wasson2007]. Figura 2.17: Detalhes da arquitetura ATI Caicos O processador Ultra-Threaded (Ultra threaded dispatch processor), apresentado na figura 2.17, é um dos principais componentes das GPUs ATI. Este processador gerencia um grande número de threads simultaneamente, de forma que ele é responsável em ordenar essas threads para serem processadas da melhor forma possível pelos mecanismos SIMD.

49 Capítulo 3 Metodologia e Implementações Neste capítulo é descrito a metodologia adotada nesse trabalho para a obtenção dos resultados de avaliação de desempenho das Unidades de Processamento Gráfico Nvidia e ATI. ë apresentado, também, a implementação dos filtros Sobel e Passa-baixa na linguagem OpenCL e na linguagem C. É descrito também os equipamentos e softwares utilizados e como o experimento foi executado. 3.1 Detalhes da plataforma Especificações de hardware e software Para implementar os filtros digitais de imagens em OpenCL e garantir as mesmas condições para a análise de desempenho, cada uma das três GPUs utilizadas nesse trabalho, foram instaladas em computadores com as mesmas configurações: PC/x64 com o processador Intel R Core TM 2 Duo E GHz, 4 GB de memória RAM DDR3 e com o barramento PCI-Express v2.0 x16 interfaceando a CPU e a GPU. Foram usadas três Unidades de processamento gráfico. A Nvidia Geforce GT 520, Nvidia Geforce 210 e ATI Radeon HD A escolha dessas GPUs foi motivada por serem de baixo custo financeiro e estarem disponíveis no comércio local. A Tabela 3.1 apresenta mais detalhes das especificações dessas GPUs.

50 Detalhes da plataforma 35 Tabela 3.1: Resumo das especificações das GPUs Nvidia e ATI Fabricante Nvidia AMD ATI Modelo Geforce GT 520 Geforce 210 Radeon HD 6450 Processadores de Stream Clock do processador 1620 MHz 1402 MHz 625 MHz Arquitetura da GPU Fermi Tesla Caicos Memória Clock da memória 900 MHz 500 MHz 533 MHz Tamanho da memória 1024 MB 512 MB 1024 MB Interface da memória 64-bit 64-bit 64-bit Largura de Banda (GB/sec) Tipo de memória DDR3 DDR3 DDR3 É importante que essas GPUs permaneçam com suas configurações de fábrica, sem nenhum tipo de overclocking 1 para melhorar o desempenho. O sistema operacional usado foi o Microsoft Windows 8 Professional 64 Bits, juntamente com a IDE Microsoft Visual Studio 2010 para a codificação. A versão do compilador usado foi o Microsoft C/C++ Optimizing Compiler Version for x64. Para o desenvolvimento com OpenCL é necessário realizar a instalação dos kits de desenvolvimento ou SDKs de cada fabricante. Para o computador com a GPU da fabricante ATI foi instalado o AMD APP SDK versão 2.8.1, obtido em [Avanced Micro Devices2013]. Já para os 2 dois computadores que possuíam GPUs da fabricante Nvidia, foi instalado o Nvidia Cuda Toolkit versão 5.0, obtido em [Nvidia Corporation2013]. O software R versão foi escolhido para fazer a análise e geração de gráficos a partir dos dados experimentais Informações dos dispositivos OpenCL Uma vez que os computadores são configurados corretamente com os SDKs de cada fabricante, é possível verificar as propriedades e recursos disponíveis nos dispositivos OpenCL 1 aumento da velocidade de clock de um componente e / ou a tensão do dispositivo, para permitir que eles ofereçam um desempenho além das especificações do fabricante

51 Detalhes da plataforma 36 (GPUs). Para consultar os detalhes dos dispositivos da Nvidia pode ser usado a ferramenta Nvidia Nsight v3.0 [NVIDIA Corporation2013]. Para os dispositivos da fabricante ATI a ferramenta pode se usar o AMD CodeXL v1.2 [AMD Developer Tools Team2013]. As seguintes informações 2 dos dispositivos foram obtidas: NVIDIA Geforce GT 520 GPU Local Mem Type : Local Local Mem Size (KB): 48 Global Mem Size(MB) : 1024 Global Mem Cache Size(KB) : 16 Max Mem Alloc Size (MB): 256 Max Work Group Size : NVIDIA Geforce 210 GPU Local Mem Type : Local Local Mem Size (KB): 16 Global Mem Size(MB) : 512 Global Mem Cache Size(Bytes) : 0 Max Mem Alloc Size (MB): 128 Max Work Group Size : ATI Radeon HD 6450 GPU Local Mem Type : Local Local Mem Size (KB): 32 Global Mem Size(MB) : 1024 Global Mem Cache Size(Bytes) : 0 Max Mem Alloc Size (MB): 512 Max Work Group Size : 256 Essas propriedades definem alguns recursos do dispositivo que podem ser utilizados pelo OpenCL e, também, determinar as possíveis limitações que podem ocorrer dentro do contexto da execução. Analisando as informações do dispositivo Nvidia Geforce 210, nota-se que o máximo de memória disponível, que pode ser utilizado pelo programa em 2 essas informações são apenas um subconjunto dos dados obtidos. Os detalhes completos dos dispositivos estão no Apêndice A.1

52 Visão geral dos programas 37 qualquer dado momento, é de 512 MB [Nvidia Corporation2009]. Esse dispositivo está em desvantagem, em termos de armazenamento disponível, pois esse valor é metade do valor de memória disponível para a Nvidia Geforce GT 520 e ATI Radeon HD 6450, ambas com 1024 MB de memória global disponível. As informações listadas acima mostram, também, diferenças no tamanho máximo de memória local disponível. Para a Nvidia Geforce 210 esse valor é de 16 KB, 48 KB para a Nvidia Geforce GT 520 e de 32 KB para ATI Radeon HD Dentro da especificação OpenCL, esta região de memória é usada como um bloco de memória de rascunho ou (scratch-pad), para o armazenamento e manipulação de dados temporários, sendo que a transferência de dados dentro da memória local é superior em relação a memória global [Khronos Group2010]. O tamanho máximo dos grupos de trabalho (workgroups), em cada dispositivo, corresponde ao máximo de itens de trabalho ou (workitems, que podem ser executado dentro de um único grupo de trabalho, a qualquer momento. O dispositivo Nvidia Geforce GT 520 suporta um total de 1024 workitems em um único workgroup, seguido pelo dispositivo Nvidia Geforce 210 com suporte a 512 workitems e por último está ATI Radeon HD 6450 workitems. O total de workitems que esses dispositivos irão criar, para o processamento dos pixels das imagens de entrada, serão iguais pra todos eles, essas diferenças no tamanho máximo de grupos de trabalho implicam somente na quantidade de workgroups que serão criados para dividir essa quantidade igual de workitems. 3.2 Visão geral dos programas Como foi apresentado na seção , para se usar o OpenCL é necessário implementar dois programas, o programa host e o kernel. O programa host é responsável por carregar a imagem de entrada, criar os objetos de memória, pela transferência de dados entre as memórias (CPU e GPU) e fazer as chamadas para execução do programa kernel dentro do dispositivo OpenCL. Esses dois programas foram implementados para cada um dos filtros. Para essas implemntações foi considerado um index space de 2 dimensões. Isso foi feito devido as imagens possuírem representação matricial, de forma que uma dimensão será responsável pelas li-

53 Filtro Sobel para detecção de borda 38 nhas e a outra dimensão será responsável pelas colunas. O total de work-items ou threads que serão criados, corresponde ao total de pixels que a imagem de entrada possuir. Ou seja, para uma imagem com a resolução de 512x512, serão criados work-items, um para cada pixel da imagem. A criação dos work-groups vai depender da capacidade de cada dispositivo. Como visto na seção anterior, a Nvidia Geforce GT 520 suporta no máximo 1024 work-items por work-group, distribuídos no total de dimensões criadas. Ou seja, ao processar uma imagem de 512x512 pixels, serão criados 256 work-groups (262144/1024=256). E cada unidade computacional da GPU processa um work-group por vez. 3.3 Filtro Sobel para detecção de borda A implementação do filtro Sobel foi feita aplicando-se diretamente a definição matemática do filtro, descrita na seção Na figura 3.1 é ilustrado a aplicação de uma máscara M sobre uma imagem A e como resultado uma imagem B. No domínio espacial, essa operação se resume em multiplicações ao longo de um conjunto de pixels da imagem de entrada com máscara. Figura 3.1: Filtro Sobel - máscara de convolução aplicada à imagem

54 Filtro Sobel para detecção de borda 39 De acordo com a figura, um elemento b 22 pode ser obtido da seguinte forma: b 22 = (a 11 m 11 ) + (a 12 m 12 ) + (a 13 m 13 ) +(a 21 m 21 ) + (a 22 m 22 ) + (a 23 m 23 ) +(a 31 m 31 ) + (a 32 m 32 ) + (a 33 m 33 ) Aplicando essa regra à imagem de entrada e as máscaras de sobel descritas em 2.2, o programa kernel é listado abaixo: Código 3.3.1: Kernel do filtro Sobel em OpenCL 1 kernel void sobel_kernel( global const char *inputimg, 2 global char *outputimg){ 3 int i = get_global_id(0); 4 int j = get_global_id(1); 5 int width = get_global_size(0); 6 int height = get_global_size(1); 7 char gx, gy; 8 char sum = 0; 9 outputimg[i * width + j] = (char) 0; 10 if (i > 0 && i < width - 1 && j > 0 && j < height - 1) { 11 gx = (inputimg[(i - 1) * width + (j + 1)] * inputimg[(i) * width + (j + 1)] 13 + inputimg[(i + 1) * width + (j + 1)]) 14 - (inputimg[(i - 1) * width + (j - 1)] * inputimg[(i) * width + (j - 1)] 16 + inputimg[(i + 1) * width + (j + 1)]); 17 gy = (inputimg[(i - 1) * width + (j - 1)] * inputimg[(i - 1) * width + j] 19 + inputimg[(i - 1) * width + (j + 1)]) 20 - (inputimg[(i + 1) * width + (j - 1)] * inputimg[(i + 1) * width + (j)] 22 + inputimg[(i + 1) * width + (j + 1)]); sum = (char) sqrt((float) gx * gx + gy * gy); 25 outputimg[i * width + j] = (sum > 255)? 255 : sum; 26 } 27 } No código listado acima, o identificador global indica que é da memória global que deve ser lido e armazenado os vetores das imagens de entrada e saída (inputimg[], outputimg[]), respectivamente. Já o método get_global_id(0 1) irá retornar um índice referente aos work-items criados para dimensão 0 ou 1. O total de work-items, que em em nossa estratégia de implementação corresponde a largura ou altura da imagem, é obtido pelo método get_global_size(0). Os tipos de dados manipulados pelo kernel são do tipo char, pois, as imagens em escala de cinza são por valores entre 0 e 255, que

55 Filtro Passa-baixa 40 são os mesmo valores aceitos por esse tipo. O programa host dessa implementação é listado no apêndice B Implementação em C Para avaliar o filtro Sobel na CPU, esse filtro foi implementado na Liguagem C, como pode ser visto no código abaixo: Código 3.3.2: Código do filtro Sobel em C 1 void filtro_sobel(pgm_t ipgm, pgm_t opgm, int image_width, 2 int image_height){ 3 int i, j, s, sum, sum_x, sum_y, m, n; 4 int dx[3][3] = { {1, 0, -1}, {2, 0, -2}, {1, 0, -1} }; 5 int dy[3][3] = { {1, 2, 1}, {0, 0, 0}, {-1, -2, -1} }; 6 7 for (i = 1; i < image_height - 1; i++){ 8 for (j = 1; j < image_width - 1; j++){ 9 sum_x = 0; 10 sum_y = 0; 11 for (m = -1; m <= 1; m++){ 12 for (n = -1; n <= 1; n++){ 13 s = ipgm.buf[(i + m) * image_width + j + n]; 14 sum_x += s * dx[m + 1][n + 1]; 15 sum_y += s * dy[m + 1][n + 1]; 16 } 17 } 18 sum = abs(sum_x) + abs(sum_y); 19 opgm.buf[i * image_width + j] = (sum > 255)? 255 : sum; 20 } 21 } 22 } Na implementação em C, também é aplicada a definição matemática do filtro Sobel. A diferença pro código kernel está na estrutura da máscara Gx e Gy. Enquanto que no código kernel essa estrutura é do tipo char no código em C é do tipo int. E na forma como as multiplicações ocorrem, em C é feita por laços de repetição, em OpenCL a iteração é feita pelo método get_global_size(0). 3.4 Filtro Passa-baixa Como visto na seção para o filtro passa baixa ser aplicado no domínio da frequência é necessário computar a Transformada Discreta de Fourier. Nesse trabalho, foi implementado o algoritmo clássico para computar a FFT [Cooley and Tukey1965] na versão

56 Filtro Passa-baixa 41 bidimensional, uma vez que as operações envolvem imagens digitais. Esse algoritmo foi implementado de forma híbrida, tanto na Linguagem C quanto na Linguagem OpenCL. Na figura 3.2 é mostrado o fluxograma que foi seguido para computar a Transformada Rápida de Fourier. Início Criar Fatores Twiddles FFT Principal (direta) Transpor Matriz FFT Principal (direta) Não FFT Principal Início Revesão de Bits Operação Borboleta Repetir < log²(n) Filtro Passa Baixa Sim FFT Principal (Inversa) FFT Inversa? Transpor Matriz FFT Principal (Inversa) Fim Não Sim Normalizar FFT Principal Fim Figura 3.2: Fluxograma do programa que computa a FFT

57 Filtro Passa-baixa 42 Cada processo é dependente do processo anterior, de modo que cada um dos passos devem ser seguidos em sequência. Um kernel foi escrito para cada um dos processos na figura 3.2, cada processo é resumido abaixo: Criar fatores Twiddles O objetivo desse kernel é pré-computar os valores dos fatores twiddle, que são necessário pelo kernel que computa a operação borboleta. Esse código é uma aplicação direta da equação 2.10 descrita na seção , porém a exponencial é aplicada em termos de cosseno, de acordo com a fórmula de Euler FFT Principal Essa função é escrita no programa host, e é responsável por calcular a FFT direta e inversa, coordenando as chamadas dos kernels da Reversão de bits, Operação borboleta e Normalizar Transpor Matriz Esse kernel é responsável por calcular a matriz transposta da imagem. Essa operação é feita para otimizar a aplicação da FFT 2D, conforme descrito em [Rao et al.2011] Reversão de bits Esse kernel é responsável por reordenar os índices do vetor da imagem, antes de ser aplicado o kernel da operação borboleta. Essa implementação foi adaptada do código apresentado em [Warren2003] Operação Borboleta Esse kernel é responsável por realizar operações borboleta, descrita na seção No fluxo da figura 2.4, observa-se que esse kernel precisa dos fatores twiddle e de duas entradas 3é uma fórmula matemática que mostra uma relação entre as funções trigonométricas e a função exponencial e ix = cos(x) + isen(x)

58 Filtro Passa-baixa 43 do vetor de dados com os índices reordenados. et al.2011]. Esse kernel executa log 2 (n vezes [Rao Normalizar Esse kernel é resonsável por dividir as entradas da imagem pelo total de posições do vetor da imagem. É chamado quando se aplica FFT inversa. Os programas kernels dos itens acima, encontram-se no Apêndice B Filtro Passa baixa em OpenCL A implementação do filtro passa baixa, segue a definição matemática descrita na seção Código 3.4.1: Kernel do filtro Passa-baixa em OpenCL 1 kernel void filtro_passabaixa( global float2* imagem, 2 int imgtam, int raio_d ){ 3 unsigned int u = get_global_id(0); 4 unsigned int v = get_global_id(1); 5 6 int2 imgtam_2 = (int2) (imgtam / 2, imgtam / 2); 7 int2 mask = (int2) (imgtam - 1, imgtam - 1); 8 int2 uv = ((int2) (u, v) + imgtam_2) & mask; 9 int2 diff = uv - imgtam_2; 10 int2 diff2 = diff * diff; 11 int dist2 = diff2.x + diff2.y; 12 int2 H_uv = (int2) (-1L, -1L); if (dist2 > raio_d) { 15 H_uv = (int2) (0L, 0L); 16 } 17 imagem[v*imgtam + u] = as_float2(as_int2( 18 imagem[v*imgtam + u]) & H_uv); 19 } No código as imagens são manipuladas como um tipo float2 que constitui a parte real e a parte imaginária da FFT. Esse tipo de dado é um tipo nativo do OpenCL e é uma estrutura definida por dois tipos primitivos float. O mesmo acontece para o tipo int2, uma estrutura formada por um tipo primitivo int. Uma variável com esses tipos, pode manipular diretamente as duas posições da estrutura. Como por exemplo, na linha 6 do código

59 Bibliotecas auxiliares em C Filtro Passa baixa em C Embora a implementação do filtro passa-baixa na linguagem C não fosse o foco desse trabalho, ela foi feita, seguindo a definição matemática descrita na seção Código 3.4.2: Código do filtro Passa-baixa na linguagem C 1 void filtro_passabaixa(float (*image)[2], int n){ 2 int u, v; 3 int p_2 = n / 2; 4 int q_2 = n / 2; 5 float diff_u, diff_v; 6 float dist = 0; 7 int d0 = n / 8; 8 for (u = 0; u < n; u++) { 9 for (v = 0; v < n; v++) { 10 dist = 0; 11 diff_u = (u < p_2)? u : u - n; 12 diff_v = (v < q_2)? v : v - n; 13 dist = (float) (diff_u * diff_u + diff_v * diff_v); 14 if (dist > d0) { 15 image[u * n + v][0] = 0; 16 image[u * n + v][1] = 0; 17 } 18 } 19 } 20 } Já a implementação do algoritmo que computa a Transformada Rápida de Fourier na linguagem C, que também não era foco nesse trabalho, não foi desenvolvida nesse trabalho. Invés disso, foi utilizado a implementação disponibilizada em [Breitenbach2004]. 3.5 Bibliotecas auxiliares em C Os códigos descritos nessa seção foram desenvolvidos ou adaptados para auxiliarem no desenvolvimento e execução dos experimentos Biblioteca utils.h As funções dessa biblioteca servem para a captura de tempo com a precisão de 64 bits e também, para a escrita formatada dos tempos de execução, taxas de transferência e outros dados da amostra. O código fonte é apresentado na sub-seção B.3.1 do Apêncice B.

60 Bibliotecas auxiliares em C Biblioteca cl utils.h As funções dessa biblioteca servem para mapear os códigos de erro numéricos da API do OpenCL para os códigos de erro em texto. O macro CL_CHECK foi adaptada do código disponibilizado em [Jiang2001]. O código fonte é apresentado na sub-seção B.3.2 do Apêncice B Biblioteca pgm.h As funções dessa biblioteca servem para a leitura e escrita de arquivos no formato pgm, essas implementação foi uma adaptação do código disponibilizado em [Wolf2009]. O código fonte é apresentado na sub-seção B.3.3 do Apêncice B.3.

61 Capítulo 4 Resultados Experimentais Nesse capítulo é apresentado os detalhes das métricas de avaliação de desempenho e assim como os resultados experimentais obtidos. A análise dos dados coletados dos experimentos é feita por meio de gráficos que comparam os tempos de execução e taxas de transferência para diferentes dimensões de imagens, entre as GPUs e também entre GPU e CPU. As métricas estatísticas de comparação são a média, desvio padrão, variância e intervalo de confiança. 4.1 Visão geral da execução do experimento A execução do experimento consistiu em submeter as amostras aos Filtros Sobel e Passabaixa, em cada uma das unidades de processamento gráfico utilizadas e também para o processamento na CPU. A figura 4.1 apresenta o diagrama de sequência com a visão geral dos passos da execução. O componente Script Shell é responsável por coordenar a execução do experimento criando arquivos de log, diretórios e submetendo as imagens para os testes. Como foi visto no capítulo anterior, os programas host foram implementados de forma que recebiam como único parâmetro o diretório completo da imagem a ser processada. A cada bateria de teste, os filtros processam 48 amostras, o que gera um total de 1152 execuções (48 amostras * 4 filtros ( 2 para GPU e 2 para CPU) * 3 computadores). Uma vez que várias baterias de testes são executadas, o gerenciamento dessas execuções se torna

62 Visão geral da execução do experimento 47 oneroso, por isso foi desenvolvido esse script para automatizar essa execução. O script foi desenvolvido em Shell Script e executado no sistema operacional Windows através de um emulador de shell chamado Git Bash. Usuário Script Shell Máquina Host Dispositivo OpenCL Executa script --platform, --app, --card Configura recursos para os testes loop [para cada imagem do total de amostras] main( imagem.pgm) Carrega imagem do disco Cria objetos de memória Inicializa dispositivo OpenCL Confirma inicialização Transfere objetos para memória Global Transferência finalizada Chama a execução do kernel do filtro digital Sinaliza que execução foi finalizada Executa kernel do filtro digital Armazena os resultados na memória global Requisita os dados da memória global Transfere os dados para memória do host Escreve as métricas em arquivo de log Libera memória dos dispositivo OpenCL Retorna sucesso Libera objetos de memória do Host Relatório com resultados Figura 4.1: Diagrama de sequência da execução do experimento O script recebe como argumentos a plataforma sobre teste (GPU ou CPU), o filtro a

63 Amostras 48 ser executado (Sobel, Passabaixa) e o dispositivo a ser testado (Nvidia Geforce GT 520, Nvidia Geforce 210 ou ATI Radeon HD 6450). 4.2 Amostras O total das amostras usadas nesse experimento foi de 48 imagens monocromáticas, em nível de cinza, no formato PGM ( do inglês, Portable Gray Map). Essas imagens foram divididas em 8 categorias com as seguintes dimensões (em pixels): 256x256, 512x512, 1024x1024, 2048x2048, 4096x4096 e 8192x8192, ou seja, 8 imagens para cada uma dessas dimensões. No formato PGM, o conteúdo da imagem pode ser representado por meio de caracteres ASCII ou em um formato binário. Quando o conteúdo da imagem é representado em ASCII os valores correspondentes aos pixels são apresentados em notação decimal e separados por espaços em branco, marcas de tabulação ou marcas de fim de linha. Enquanto que na representação binária, os valores correspondentes aos pixels das imagens são representados em caracteres (bytes) contíguos, sem qualquer separador entre valores consecutivos. O cabeçalho de imagens PGM possui a seguinte estrutura: P A primeira linha indica a codificação (P5 - binária ou P2 - ASCII). A segunda linha indica o tamanho horizontal e vertical da imagem, e a terceira linha representa o número máximo de níveis de cinza. As amostras usadas usam 255 como intensidade máxima. A partir da quarta linha seguem os brilhos dos pixels. Nas imagens P5, os brilhos estão no formato binário, e cada byte representa o brilho de um pixel, a codificação binária foi usada por deixar o arquivo da imagem mais compacto no disco.

64 Resultados da aplicação dos ltros Resultados da aplicação dos filtros Filtro Sobel para Detecção de Borda Após aplicar o filtro Sobel sobre as amostras, nota-se, por meio da análise visual das imagens, que não existiu diferença nos resultados gerados pelas diferentes GPUs, o que é um resultado esperado uma vez que o código fonte do programa kernel foi o mesmo para todas as GPUs. O resultado das imagens filtradas são apresentadas abaixo. (a) Imagem original (b) Imagem após a aplicação do filtro Sobel Figura 4.2: Resultado da aplicação do filtro Sobel com a Nvidia Geforce GT 520 Como esperado, a figura 4.2(a) mostra que o filtro Sobel aplicado pela Nvidia Geforce GT 520 detectou as bordas da imagem original, figura 4.2(b).

65 Resultados da aplicação dos ltros 50 (a) Imagem original (b) Imagem após a aplicação do filtro Sobel Figura 4.3: Resultado da aplicação do filtro Sobel com a Nvidia Geforce 210 (a) Imagem original (b) Imagem após a aplicação do filtro Sobel Figura 4.4: Resultado da aplicação do filtro Sobel com a ATI Radeon HD 6450 Pelas imagens acima, nota-se que tanto para Nvidia Geforce 210 quanto para a ATI Radeon HD 6450, o filtro Sobel consegui detectar as bordas das imagens originais (na direita). Esses resultados para as três unidades de processamento, deixam claro que a implementação do OpenCL por esses fabricantes, não possuem diferenças quando consideramos a qualidade das operações sobre um mesmo conjunto de dados.