Mapeamento dos Pesos - Interpola¸c˜ao de HRTFs com a Transformada Wavelet

4.3 Interpola¸c˜ao de HRTFs com a Transformada Wavelet

4.3.3 Mapeamento dos Pesos

O exemplo a seguir ilustra, na prática, como os componentes polifásicos são represen- tados. Considere um filtro H(z) = 1 + 2z−1_{+ 3z}−2_{+ 4z}−3_{. Seus componentes polifásicos}

desse filtro s˜ao: E0(z) = 1 + 3z−1 (pares) e E1(z) = 2 + 4z−1 (´ımpares).

4.3.3 Mapeamento dos Pesos

Conforme apresentado na Se¸cão 4.3, existe um valor de peso w que é multiplicado com seus respectivos filtros esparsos para cada sub-banda e posi¸cão no triângulo de interpola- ¸cão. O método utilizado para a obten¸cão dos pesos de cada sub-banda é o de otimiza¸cão linear através de m´ınimos quadrados em pontos em que os coeficientes são conhecidos. Entretanto, esta abordagem não contempla os pesos de posi¸cões desconhecidas. Assim, torna-se necessária a cria¸cão de uma fun¸cão de interpola¸cão destes pesos tendo como refe- rência os pesos obtidos nas dire¸cões conhecidas. Com isso, é poss´ıvel reconstruir as HRIRs das posi¸cões não conhecidas [13].

Escolheu-se o método de interpola¸cão polinomial cubic spline pois, dentre os testes realizados em [13], ele se mostrou mais eficiente. Este método consiste em gerar os pesos de todos os azimutes para cada sub-banda em um ângulo de eleva¸cão fixo. Em [14], o autor nomeia este procedimento de azimuth interpolation. Para o cálculo dos pesos em eleva¸cões intermediárias, que não são múltiplas de 10°, procedimento semelhante pode ser realizado. Para cada sub-banda e uma posi¸cão de azimute constante, podem ser calculados os pesos para diferentes ângulos de eleva¸cão. Isto é chamado de elevation interpolation.

Neste mecanismo de interpola¸cão de HRTFs no dom´ınio da transformada wavelet, a interpola¸cão na eleva¸cão acontece da seguinte maneira. Dado um azimute θ, calcula-se a média ponderada dos resultados da interpola¸cão na eleva¸cão para as duas eleva¸cões mais próximas.

w(θ, φ) = α ˆw(θ, φL) + (1− α) ˆw(θ, φH) (4.38)

onde ˆw é o resultado da interpola¸cão na eleva¸cão para o azimute θ e as eleva¸cões mais próxima da eleva¸cão de φ. φL e φH são, respectivamente, as eleva¸cões mais próximas

abaixo e acima da eleva¸cão de P. α é calculado conforme equa¸cão abaixo: α = φH− φ

φH − φL

Cap´ıtulo 5

Computa¸c˜ao Paralela com o uso de

Unidades de Processamento Gr´afico

Nos últimos anos, o interesse no desenvolvimento e utiliza¸cão de unidades de processamento gráfico, GPUs, em projetos que demandam alto poder de processamento cresceu bastante. O rápido aumento de performance juntamente com as melhorias em sua pro- gramabilidade associados ao baixo custo, quando comparadas a outras tecnologias, abriu caminhos para que esta se tornasse uma plataforma de pesquisa e desenvolvimento de aplica¸cões intensas computacionalmente, nos mais diversos dom´ınios de aplica¸cão.

O poder de processamento de placas gráficas cresce mais rapidamente que o poder de processamento das unidades centrais de processamento, CPUs, devido a diferen¸cas arquiteturais entre elas. A Figura 5.1 mostra este crescimento. Enquanto placas gráficas superam a marca de 1500 multiplicado por 106 _{opera¸cões em ponto flutuante por segundo,}

Giga Floating point Operations Per Second (GFLOPS)1_{, as CPUs ainda est˜ao abaixo de}

250 GFLOPS.

As CPUs são projetadas para alcan¸carem melhor performance na execu¸cão de códigos sequenciais, tendo que lidar também com caching de dados e controle de fluxo (branch predictions - previsão de desvios). Já as GPUs são especializadas em computa¸cão paralela e projetadas de tal forma que mais transistores são dedicados ao processamento de dados, ao invés de utilizá-los no controle de fluxo e caching de informa¸cões [54, 55]. A Figura 5.2 apresenta as principais diferen¸cas arquiteturais entre CPU e GPU. Enquanto na primeira o espa¸co destinado ao controle e a cache de dados é maior que o espa¸co destinado às unidades lógicas e aritméticas, do inglês Arithmetic Logic Units (ALUs), na segunda, muito mais espa¸co é destinado para unidades de processamento de dados do que ao controle de execu¸cão e a cache de informa¸cões.

A GPU é ideal para problemas em que o mesmo programa pode ser executado parale- lamente em vários elementos de dados e que tenha alta densidade aritmética - o número de opera¸cões aritméticas deve ser maior que o número de opera¸cões em memória. O processamento paralelo de dados permite que aplica¸cões que necessitam processar um grande conjunto de informa¸cões sejam executadas mais rapidamente. Desta maneira, o mesmo programa é executado sobre elementos de dados diferentes e não precisa de um mecanismo altamente eficiente de controle de fluxo. Muitos algoritmos fora do contexto de renderiza¸cão e processamento de imagens são acelerados pelo processamento paralelo

Figura 5.1: Opera¸c˜oes em ponto flutuante por segundo. Fonte: NVIDIA CUDA C Pro- gramming Guide. Version 4.0 [54].

Figura 5.2: Diferen¸cas arquiteturais entre CPU e GPU. Fonte: NVIDIA CUDA C Pro- gramming Guide. Version 4.0 [54].

de dados, dentre eles, os softwares voltados para a resolu¸c˜ao de problemas da biologia (biologia computacional), softwares de processamento de sinais, simula¸c˜oes f´ısicas, dentre outros [54].

5.1 Breve Hist´orico da Computa¸c˜ao com GPU

E interessante entender o processo evolutivo desde os primeiros pipelines gráficos até os modelos de programa¸cão conhecidos atualmente tais como CUDA™ e OpenCL™. Isso permite o entendimento do contexto que possibilitou a evolu¸cão dos dispositivos gráficos e também facilita a cria¸cão de melhores projetos para as futuras versões das GPUs.

Durante duas décadas, de 80 e 90, houve a predominância de hardwares gráficos con- figuráveis mas não programáveis. Neste per´ıodo, fun¸cões fixas (fixed-functions) eram utilizadas e as interfaces de programa¸cão de aplica¸cões, Application Programming Inter- faces (APIs), tornaram-se populares. Dentre elas, destacam-se o DirectX™ da Microsoft e o OpenGL™, um padrão aberto bastante popular e suportado por uma grande quantidade de fabricantes. Durante esta fase, a interface para o host recebia comandos, que chama- vam fun¸cões da API gráfica, e dados gráficos provenientes da CPU. A interface para o host também era responsável por retornar o estado e resultados de volta à CPU após a execu- ¸cão dos comandos. Durante estas duas décadas, cada nova gera¸cão de hardwares oferecia novas melhorias aos diferentes estágios do pipeline gráfico. Entretanto, essa evolu¸cão não acompanhava a demanda dos programadores por funcionalidades mais sofisticadas [56].

Assim que mecanismos de programa¸cão para GPU surgiram, pesquisadores foram atraidos pela possibilidade de utilizar esse hardware gráfico para o processamento e solu- ¸cão de problemas de natureza diferente da gráfica. Como inicialmente as únicas formas de construir aplica¸cões que utilizassem o hardware gráfico era por meio das APIs gráficas pa- drões como, por exemplo, OpenGL e DirectX, pesquisadores exploraram a computa¸cão de propósito geral, ou seja, de propósito que não seja gráfico, utilizando estas APIs. Assim, embora as aplica¸cões que eles desenvolviam em GPU não fossem aplica¸cões gráficas, estas eram progamadas de maneira que se parecesse com uma renderiza¸cão gráfica tradicional para a GPU [57].

Os pesquisadores perceberam, no come¸co do século XXI, que as GPUs foram projetadas para produzir uma cor para cada pixel presente na tela como resultado de opera¸cões realizadas sobre valores de entrada. Assim, a partir de algumas entradas, a cor de sa´ıda era calculada pela GPU. Como o cálculo executado sobre esses parâmetros de entrada eram controlados pelos programadores, estes pesquisadores observaram que os parâme- tros de entrada (cores, textura e outros) poderiam ser qualquer tipo de dado. Assim, a cor retornada pela GPU para cada um dos pixels da tela poderia ser interpretada como o resultado de qualquer opera¸cão que foi executada em GPU solicitada pelo programador.

Entretanto, apesar de apresentar resultados motivadores, este modelo de programa¸cão era muito restrito. Além da incapacidade de cálculo de valores em ponto flutuante de algumas GPUs, quando o programa trazia resultados incorretos ou falhava na sua finali- za¸cão, não existia um método eficiente de verificar como o código estava sendo executado naquele dispositivo. Além disso, o pesquisador que desejasse criar aplica¸cões para serem executadas em GPU deveria aprender OpenGL ou DirectX, o que era um obstáculo para uma maior aceita¸cão dessa arquitetura [57].

No documento Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação (páginas 63-67)