1 Padrões de Implementação em Processamento de Imagens. 2 Resumo. 4 Computação paralela. 1.1 Relátório final para PIBIC/CNPq

Transcrição

1 1 Padrões de Implementação em Processamento de Imagens 1.1 Relátório final para PIBIC/CNPq Victor M. de A. Oliveira, Rubens Campos Machado Centro de Tecnologia da Informação Renato Archer CTI Divisão de Robótica e Visão Computacional Rod. Pedro I, km 143, Campinas SP rubens.campos.machado@gmail.com; victormatheus@gmail.com 2 Resumo Neste trabalho implementamos alguns filtros de processamento de imagens de modo a explorar o potencial de novas arquiteturas paralelas como multi-core e GPU. Fazemos uma análise comparativa de algoritmos de acordo com 3 categorias: Pontual, Local e Global. No fim, criamos uma biblioteca open-source com os algoritmos. 3 Introdução Nas últimas décadas acostumamo-nos a tirar proveito de um aumento constante na velocidade de processamento dos computadores. A cada novo modelo de processador, os programas se tornavam automaticamente mais rápidos, viabilizando a incorporação de novas funcionalidades. Nos dias atuais, porém, assistimos a uma saturação desse crescimento. O poder computacional passou a crescer através da utilização de dois ou mais processadores (ou núcleos de processamento). O efeito no desempenho dos programas, contudo, não é mais automático. Os programas precisam ser projetados para tirar proveito dos múltiplos elementos de processamento. Nesse contexto, o nosso trabalho consistiu em paralelizar e otimizar 2 filtros de processamento de imagens muito utilizados e cujos resultados podem ser estendidos para uma ampla classe de outros filtros: Filtro pontual: Threshold Filtro global: Abertura de área com a Max-Tree 4 Computação paralela Computação paralela é uma forma de computação em que várias operações são realizadas simultaneamente. A vantagem desse tipo de computação sobre a computação serial (aquela em que apenas uma operação é executada por vez) é que é possível diminuir o tempo de execução de alguns algoritmos permitindo que partes independentes dele sejam executadas ao mesmo tempo, por outro lado, qualquer computação paralela pode ser simulada em um 1

2 modelo serial, uma vez que é possível intercalar todas as operações paralelas e executá-las sequencialmente. O aumento de desempenho de um algoritmo executado paralelamente em relação à sua versão sequencial é limitado superiormente pela Lei de Amdahl, que diz: 1 A = (1 P ) + P S (1) Em que P é a proporção da computação que é se beneficia do paralelismo e S, a quantidade de paralelismo. Temos a melhor situação quando P = 1, isto é, a computação é completamente paralela (também chamada de embarrassingly parallel na literatura). Algoritmos com essa propriedade são facilmente paralelizáveis, como veremos adiante neste trabalho. Figure 1: Previsão com P = 30% - Podemos ver que em determinado momento, não vale mais a pena aumentar a quantidade de paralelismo do algoritmo, pois o custo da parte sequencial dele se sobrepõe ao resto. 5 Arquiteturas paralelas Devido à exaustão do modelo tradicional de computação sequencial, tem surgido diversas arquiteturas paralelas e distribuidas, podemos citar dentre elas: Processadores Multi-core. ex: Intel Dual/Quad Core, AMD Opteron/Phenom GPGPU (Unidade de processamento gráfico de propósito geral). ex: NVidia Geforce/Tesla, AMD Firestream Cluster. ex: Beowulf Computação em grade (grid computing). ex: Rede BOINC Neste trabalho só fizemos experimentos com as arquiteturas multi-core e gpgpu. 2

3 Figure 2: Esquema de alguns processadores multi-core da intel, além do cache dentro de cada core, existe um segundo nível de cache ligando os núcleos entre si. 5.1 Multi-core Processadores multi-core são aqueles que possuem mais de uma unidade de processamento (CPU), portanto, são capazes de realizar computação paralela, pois as tarefas atribuidas a cada núcleo (core) do sistema serão executadas em paralelo. A maioria dos sistemas multi-core encontrados atualmente se baseia em uma arquitetura SMP (multiprocessamento simétrico). Assim, são um conjunto de processadores idênticos se comunicam através de uma memória compartilhada, atualmente existem no mercado processadores com até 8 núcleos, mas já existem protótipos com até 80 núcleos ( que devem se tornar comuns em pouco tempo. Na taxonomia de Flynn ( os sistemas multi-core se encaixam na categoria MIMD (multiple instruction, multiple data), uma vez que cada núcleo pode executar suas instruções independentemente das dos outros e operar sobre conjuntos de dados distintos (veremos que no caso da GPU, isso não acontece). 5.2 GPGPU GPGPU significa Unidade de Processamento Gráfico de Propósito Geral, ou seja, hardware dedicado ao processamento gráfico, como renderização, mas que pode ser utilizado para realizar computação genérica. As GPG- PUs tem sido utilizadas com sucesso em diversas áreas como: Bioinformática, criptografia, visão computacional, entre outros. O poder computacional das GPUs vem aumentando drasticamente, por outro lado, são mais complexas de programar, como veremos adiante. Um outro problema é a falta de padrões no mercado, um código escrito para um modelo de GPU não funciona em modelos de outra empresa e nem pode ser executado em uma CPU. No momento em que esse artigo é escrito, existe uma iniciativa de se criar uma linguagem padrão para programação das diferentes GPUs chamada OpenCL ( mas os drivers e compiladores não estavam ainda disponíveis ao público geral. 3

4 6 Threshold O Threshold (Limiarização) é uma técnica muito simples de segmentação de imagens, os pixels são classificados como objeto ou como fundo baseado na comparação da sua intensidade de brilho com um determinado valor limiar. A definição de threshold que usaremos nesse trabalho é: 0, se Î(P ) > Limiar Ĵ(P ) = 1, caso contrario (2) A entrada é uma imagem nível de cinza Î e a saída será uma imagem binária Ĵ. O algoritmo para realizar essa operação em paralelo é simples: Threshold: entrada: Î = (D, Vi) - imagem nível de cinza saída: Ĵ = (D, Vj) - imagem binária Para todo P em D faça em paralelo: se Vi(P) > Limiar: Vj(P) = 0 senão: Vj(P) = 1 Claramente, esse algoritmo se aproveita de todo o paralelismo disponível no sistema (i.e. embarrassingly parallel ). Por exemplo, se duplicarmos a capacidade de paralelismo do sistema, dobrando o número de processadores, teremos teoricamente a metade do tempo de execução em relação ao tempo anterior. 6.1 Implementação - Multicore Fizemos a implementação desse algoritmo em um ambiente multi-core e em GPU. Na versão multi-core utlizamos a biblioteca pthreads em um processador Intel Xeon X3220 de 4 núcleos, cada um 2.4Ghz, e 64 bits. typedef unsigned char uchar; #include <stdlib.h> #include <pthread.h> typedef struct _threshold_arg { uchar* in; uchar* out; uchar t; int start; int end; threshold_arg; static void* threshold_func(void *arg) { const threshold_arg* t = (threshold_arg*)arg; const int s = t->start; const int e = t->end; const uchar threshold = t->t; uchar* in = t->in; 4

5 uchar* out = t->out; uint i; for(i=s; i < e; i++) { out[i] = (in[i] > threshold)? 0 : 1; return NULL; void threshold_(int DIM1, int DIM2, uchar* in, uchar threshold, int n) { pthread_t* thread = (pthread_t*)malloc(sizeof(pthread_t)*n); threshold_arg* arg = (threshold_arg*)malloc(sizeof(threshold_arg)*n); int size = DIM1*DIM2; int load = size/n; int i; for(i=0; i<n; i++) { arg[i].start = load*i; arg[i].end = load*(i+1); arg[i].in = in; arg[i].out = in; arg[i].t = threshold; arg[i-1].end += size % n; for(i=0; i<n; i++) { pthread_create(&thread[i], NULL, threshold_func, &arg[i]); for(i=0; i<n; i++) { pthread_join(thread[i], NULL); free(thread); free(arg); 6.2 Implementação - GPU Neste trabalho utilizamos uma GPU NVidia Geforce 8400GS através da linguagem CUDA, que é uma linguagem C com algumas primitivas de paralelismo adicionadas na sintaxe, e os drivers, bibliotecas e o compilador distribuidos pelo fabricante. Embora a linguagem CUDA seja parecida com a linguagem C, a arquitetura de uma GPU é bastante diferente da arquitetura de uma CPU. Enquanto que as CPUs multi-core possuem uma arquitetura MIMD, a GPU se aproxima mais de uma arquitetura SIMD (Single Instruction, Multiple Data), ou seja, uma única operação é realizada sobre um conjunto extenso de dados em paralelo. Na implementação multi-core, aplicamos uma função threshold em um conjunto de dados. Para realizar o paralelismo, criamos novas funções que possuem como domínio partes dos dados de entrada e criamos threads com o objetivo de executar cada função, ou seja, pensamos na função no momento em que exploramos o paralelismo, isso é chamado de paralelismo nas taferas (task paralellism). Na GPU, ocorre algo diferente, como existe um número grande de processadores de baixa capacidade, nesse ambiente é mais natural definir o paralelismo em torno dos dados, ou seja, é definida uma operação que será executada em pedaços dos dados de entrada. Essa função é aplicada em paralelo nos dados pelos diversos 5

6 processadores existentes. Não nos importamos com o número de processadores, apenas com o que é feito nos dados, isso é chamado de paralelismo nos dados (data paralellism). As GPUs NVidia possuem um conjunto de multiprocessadores, cada um deles com vários cores. A computação é divida pelo programador em Blocos, cada bloco possui de 128 a 512 threads, um multiprocessador carrega um bloco e o executa em paralelo com seus núcleos de uma forma SIMD, portanto, existe uma mistura de 2 tipos de arquitetura, dentro de um bloco, que é SIMD e entre blocos, que é MIMD, uma vez que diferentes processadores não precisam executar a mesma instrução no mesmo instante. No entanto, uma análise interessante é que dentro de um mesmo bloco, se algumas threads tentam escrever em uma mesma posição de memória ao mesmo tempo, a arquitetura garante que qualquer uma delas vai conseguir escrever com sucesso, além disso, existe uma instrução de sincronização entre as threads em um bloco. Com esses dados, podemos dizer que dentro do bloco, a GPU segue uma modelo PRAM Arbitrário Assíncrono (Syntesis of parallel algorithms), porém, entre blocos não há um modo trivial de garantir a sincronização. As funções que são executadas em paralelo são chamadas Kernels, aqui está nossa primeira tentativa de kernel para o algoritmo de threshold: global void threshold1(uchar* in, uchar* out, uchar threshold, int width, int height) { const int x = blockdim.x * blockidx.x + threadidx.x; const int y = blockdim.y * blockidx.y + threadidx.y; if (x < width && y < height) { out[width*y+x] = (in[width*y+x] > threshold)? 0 : 1; Veja que existe um modo de indexação entre os threads e os blocos. Como estamos lidando com imagens, é mais natural usar uma indexação bidimensional, assim cada thread com índice (x,y) processa o pixel (x,y). Entretanto, esse kernel é ineficiente pois a GPU possui modos de endereçamento de 32,64 e 128 bits. Mas nossa imagem é composta de 8 bits (tamanho de um char), estamos desperdiçando acessos a memória, uma vez que utilizando endereçamento 32 bits poderíamos conseguir 4 pixels em um único acesso à memória principal. Portanto, a partir de agora utilizaremos uma imagem com 4 canais: global void threshold2(rgba8* in, RGBA8* out, uchar threshold, int width, int height) { const int x = blockdim.x * blockidx.x + threadidx.x; const int y = blockdim.y * blockidx.y + threadidx.y; const int off = width*y+x; if (x < width && y < height) { RGBA8 k = in[off]; RGBA8 o; o.r = (k.r > threshold)? 0 : 1; o.g = (k.g > threshold)? 0 : 1; o.b = (k.b > threshold)? 0 : 1; o.a = (k.a > threshold)? 0 : 1; out[off] = o; A terceira otimização que fizemos é alinhar cada linha da imagem na memória, assim a GPU consegue fazer vários acessos à memória simultaneamente. Para isso, utilizamos as funções cudamallocpitch e cudamemcpy2d para a alocação da imagem e transferência dos dados para a placa. 6.3 Resultados e comparações Temos os seguintes resultados (em milisegundos) para o programa multi-core: 1024KB 4096KB 16384KB 40000KB 65536KB 1 thread(s) continued on next page 6

7 1024KB 4096KB 16384KB 40000KB 65536KB 2 thread(s) thread(s) thread(s) thread(s) Podemos ver na figura 2.a que o tempo de execução do algoritmo de threshold para multi-core diminui conforme o número de threads aumenta e vai ocupando os núcleos disponíveis, até chegar a algo entre 2 e 3 vezes mais rápido que a versão sequencial (i.e. aquela com apenas uma thread). A pergunta que ocorre é por que não se chega a uma performance 4 vezes maior, que seria o limite teórico previsto pelo Lei de Amdahl, uma vez que existem 4 núcleos disponíveis na máquina. Isso ocorre porque a divisão de trabalho em threads tem um custo (overhead). O gerenciamento de threads pelo sistema operacional consome ciclos de processamento, podemos ver na figura 2.b que se o número de threads aumenta muito, o custo de gerenciamento chega a ultrapassar o próprio custo de processamento do algoritmo. Além disso, há outros fatores como: A arquitetura multi-core às vezes possui gargalos no acesso à memória principal por mais de um processador ao mesmo tempo; o sistema operacional pode não balencear equilibradamente os threads nos núcleos fazendo com que processadores fiquem ociosos, entre outras causas. Na nossa implementação para GPU comparamos os tempos (em milisegundos) das otimizações feitas: KB 900KB 1024KB 4096KB 15625KB 40000KB versão versão versão Podemos ver que há um grande impacto na performance da versão 1 para a versão 2 quando alinhamos o tipo dos dados em 32 bits. Da versão 2 para a 3 vemos que houve uma grande melhora nas imagens cujas dimensões não atendiam às condições para o alinhamento de memória. Uma preocupação inicial com o uso da GPU era o quanto a transferência de dados da memória principal para a memória do dispositivo iria influenciar no tempo de execução. Na nossa implementação não houve muitos problemas quanto a isso, no caso de 40000KB a transferência custou 0.63ms, o que corresponde a 1% do tempo de processamento do kernel. Mesmo com as otimizações feitas aqui vemos que a GPU não conseguiu superar os resultados da versão multicore. Isso, em parte, pode ser explicado porque a GPU que utilizamos tem apenas 2 multiprocessadores, enquanto que há modelos mais atuais no mercado que chegam às centenas. No entanto, um aspecto positivo é que enquanto a GPU está realizando trabalho a CPU fica ociosa, podendo ser utilizada para outros propósitos, o que é uma vantagem em aplicações interativas, em que a velocidade de resposta ao usuário (e não de processamento) é o fator mais importante. 7 Max-Tree A abertura de área faz parte de uma classe de filtros morfológicos chamados filtros conexos. São chamados assim porque tem a propriedade de nunca inserir novas arestas nas imagens. Nesse contexto, a Max-tree é uma estrutura de dados que agiliza a aplicação de alguns filtros conexos sobre uma imagem, sendo muito útil em visualização, onde é comum se aplicar vários filtros até se obter as características desejadas de uma imagem. 7

8 image original imagem com abertura de área - as regiões da imagem marcadas tinham área in Nesse trabalho procuramos criar um algoritmo para construção da Max-Tree que fosse eficiente nas arquiteturas multi-core disponíveis. Nos baseamos no algoritmo de Salembier (CITAÇÃO) e de Meijster (CITAÇÃO) para criar uma versão híbrida dos dois que se aproveita tanto da capacidade de paralelismo do ambiente multi-core do algoritmo de Meijster quanto da localidade no cache, presente no algoritmo de Salembier. 7.1 Algoritmo de Salembier A construção da Max-Tree consiste em estabelecer uma relação de inclusão entre as regiões da imagem com mesmo brilho (componente conexa). O algoritmo de Salembier funciona utilizando uma fila hieráquica de pixels. Essa fila tem como objetivo permitir a inundação de áreas de mesmo nível de cinza, durante a inundação de uma área podem acontecer as seguintes situações: Encontra-se um pixel na região de vizinhança que possui nível de cinza menor que o pixel que está sendo avaliado Encontra-se um pixel na região de vizinhança que possui nível de cinza maior que o pixel que está sendo avaliado Na primeira situação, não há nada de diferente a fazer, basta inserir o pixel na fila ordenada, ele será o próximo a ser avaliado na fila. Na segunda, o pixel é inserido na fila e é feita uma chamada recursiva de inundação para o pixel com nível de cinza maior; ao fim, é estabelecidade a relação de antecessor entre as regiões (maior -> menor). O processo começa com o pixel de menor valor, assim é garantido que todas as regiões serão inundadas e farão parte da Max-Tree A = (3)

9 Exemplo de Max-Tree gerada pelo algoritmo de salembier a partir da imagem A. Cada nó representa uma componente conexa. 7.2 Algoritmo de Meijster O algoritmo de Meijster funciona utilizando um estrutura de conjuntos disjuntos (em oposição a uma fila, como o método de Salembier). Cada pixel (nó da estrutura) aponta para um antecessor que ou pertence a mesma componente conexa que ele, ou à componente do nível de cinza imediatamente inferior. Esses nós que apontam para uma outra componente correspondem a um nó da Max-Tree, pois guardam as informações (ex: área) da componente conexa de que fazem parte. O algoritmo funciona unindo um pixel com os da sua vizinhança, mas respeitando as componentes conexas, ou seja, quando há um merge em duas estruturas de conjuntos, em vez de simplesmente unir as raízes, como acontece no algoritmo original de Tarjan, a união é feita nível a nível. 9

10 Exemplo de Max-Tree gerada pelo algoritmo de meijster a partir da imagem A. Os nós de nível (que correspondem aos nós da Ma 7.3 Algoritmo Híbrido Nossa versão do algoritmo é uma implementação paralela (multithreaded) da construção de uma MaxTree. A idéia básica é dividir a imagem em determinado número de fatias e processar cada fatia em uma thread. Os resultados são, então, costurados dois a dois. Para o processamento inicial de cada fatia utilizamos um algoritmo de inundação baseado no de Salembier. Para a costura das árvores resultantes do processamento anterior utilizamos um algoritmo de Union-Find. O desenvolvimento desse algoritmo é motivado pelo fato de que o algoritmo de Salembier é bastante rápido em um ambiente sequencial, pois a sua fila hierárquica percorre a memória de uma maneira linear, o que faz um bom aproveitamento da memória cache, diferente do algoritmo de Union-Find, cuja estrutura de apontadores faz com que o acesso seja muito mais aleatório. No entanto, o algoritmo de Salembier não permite o paralelismo. Nossa abordagem foi alterar o algoritmo de Salembier para criar uma estrutura de apontadores utilizável pelo algoritmo de Union-Find. Assim, cada thread executa o algoritmo de Salembier em uma fatia da imagem, e em seguida, as fatias são unidas por Union-Find. A figura seguinte ilustra o processo para o caso em que dividimos a imagem em 4 fatias. 10

11 7.4 Implementação e resultados Todas as nossas implementações paralelas foram feitas em C++ utilizando a biblioteca pthreads, os testes foram feitos em computador com um processador Intel Xeon X3220 de 4 núcleos, cada um 2.4Ghz de 64 bits. Caso de teste 1 min média max Salembier Meijster Union-Find+Salembier Caso de teste 2 min média max Salembier Meijster Union-Find+Salembier

12 Caso de teste 1 Caso de teste Conclusão Vemos que a nossa abordagem tem bons resultados. Mesmo no caso binário, em que o algoritmo de Salembier tem vantagem pois utiliza inundação, nosso algoritmo tem resultado equivalente. Como usa threads, o algoritmo é capaz de utilizar o poder de processamento paralelo dessas novas arquiteturas. 8 Biblioteca de processamento de imagens Nome da biblioteca algoritmos que estão implementados nela local onde encontrar o source 9 Referências References [1] E. Dougherty and R. Lotufo. Hands-on Morphological Image Processing. SPIE, [2] A. Meijster and M. H. F. Wilkinson, A comparison of algorithms for connected set openings and closings, IEEE Trans. Patt. Anal. Mach. Intell., 24 (4), pp , 2002 [3] P. Salembier and A. Oliveras and L. Garrido. Anti-extensive Connected Operators for Image and Sequence Processing. IEEE Transactions on Image Processing; 7: , [4] Compute Unified Device Architecture (CUDA) Programming Guide. NVIDIA, [5] Reif, J. H Synthesis of Parallel Algorithms. 1st. Morgan Kaufmann Publishers Inc. 12