Escuela T´
ecnica Superior de Ingenier´ıa Inform´
atica
Departamento de Ciencias de la Computaci´
on
Curso Acad´
emico 2009/2010
Proyecto de Fin de Carrera
Seguimiento visual en PlayStation 3
Autor:
Alberto Mat´ıas Vega
Tutores:
Antonio Sanz Montemayor Ra´ul Cabido Valladolid
A mi familia y amigos, por aguantarme.
A los compa˜neros del laboratorio, por ayudarme cuando me he atascado. A mis tutores, por las explicaciones y su inestimable ayuda y paciencia.
La visi´on artificial tiene como finalidad la extracci´on de informaci´on del mundo f´ısico a partir de im´agenes, utilizando para ello un computador. Se trata de un objetivo ambicioso y complejo que actualmente se encuentra en una etapa primitiva [19]. Dentro de esta disciplina existen multitud de problemas que resolver, como por ejemplo la segmentaci´on y filtrado, la autolocalizaci´on o el reconocimiento. Universidades y empresas de todo el mundo est´an constantemente investigando en este campo con el fin de desarrollar y mejorar algoritmos que solucionen dichos problemas.
En este documento se tratar´a el problema del seguimiento visual 2D, para el cual existen en la actualidad diferentes soluciones como por ejemplo el filtro de Kalman o el filtro de part´ıculas. Estos algoritmos persiguen describir un sistema que evoluciona con el tiempo mediante una serie de par´ametros y observaciones previas del sistema, y ya han sido satisfactoriamente implementados y comercializados en multitud de casos: sistemas de vigilancia, entretenimiento multimedia, monitorizaci´on de personas dependientes, etc. En general el rendimiento en computadores de consumo es bueno en los casos m´as simples, pero en cuanto se pretenden abordar casos m´as complejos se ha de recurrir a sistemas especializados. En este proyecto se propone el uso del procesador Cell que se puede en-contrar en la consola de juegos PlayStation 3 para resolver el problema del seguimiento 2D mediante la implementaci´on y posterior optimizaci´on de un filtro de part´ıculas.
El Cell se apoya en la computaci´on en paralelo y en las operaciones vectoriales para acelerar su funcionamiento, todo ello soportado por un sistema de memoria espec´ıfico de esta arquitectura. Es por estas caracter´ısticas que se espera obtener una importante mejora al emplear dicha tecnolog´ıa para el procesamiento de im´agenes, ya que las operaciones sobre ellas pueden realizarse de manera independiente a nivel de p´ıxel.
Agradecimientos I
Resumen III
1. Introducci´on 1
1.1. Introducci´on a la visi´on computacional . . . 1
1.2. Seguimiento Visual . . . 2
1.2.1. Soluciones al problema del seguimiento . . . 3
1.3. Arquitectura del procesador Cell . . . 5
1.3.1. La arquitectura . . . 6
1.3.2. Modelo de desarrollo . . . 9
1.3.3. T´ecnicas de adaptaci´on y optimizaci´on . . . 9
2. Objetivo del proyecto 15 2.1. Objetivo principal . . . 15
2.2. Objetivos parciales y etapas del desarrollo . . . 15
3. Descripci´on Inform´atica 17 3.1. Herramientas . . . 17
3.1.1. Consola PlayStation 3 . . . 17
3.1.2. Lenguajes de programaci´on . . . 18
3.1.3. SDK de IBM para Cell . . . 18
3.1.4. OpenCV . . . 26
3.1.5. Sistemas operativos . . . 26
3.2. Implementaci´on . . . 27
3.2.1. Filtro de part´ıculas b´asico . . . 28
3.2.2. Filtro de part´ıculas con vectorizaci´on en PPE . . . 32
3.2.3. Filtro de part´ıculas utilizando los SPEs . . . 35
4. Resultados experimentales 45
4.1. Rendimiento . . . 45 4.1.1. Precisi´on y exactitud . . . 48
5. Conclusiones y trabajos futuros 53
5.1. Conclusiones . . . 53 5.2. Trabajos futuros . . . 54
Anexo: Ejecuci´on de las aplicaciones y consideraciones previas 57
5.1. Flags y variables de entorno necesarias . . . . 57 5.2. Opciones del programa principal . . . 57 5.3. Protocolo para las secuencias de im´agenes . . . 59
1.1. Etapas dentro del filtro de part´ıculas . . . 5
1.2. Elementos dentro del procesador Cell . . . 6
1.3. Estructura de un SPE . . . 8
1.4. Flujo de trabajo para adaptar un algoritmo a Cell . . . 10
1.5. Descarga de una funci´on en un SPE . . . 10
1.6. Esquema de funcionamiento de la configuraci´on para streaming . . . . 11
1.7. Array de estructuras . . . . 12
1.8. Estructura de arrays . . . . 12
3.1. Sincronizaci´on de DMA mediante un mecanismo de cerca o fence . . . 22
3.2. Sincronizaci´on de DMA mediante un mecanismo de barrera . . . 22
3.3. Esquema de funcionamiento de CvCell . . . 27
3.4. Definici´on del ´area de inter´es de una part´ıcula (rango=3) . . . 29
3.5. Ejemplo del proceso de evaluaci´on de una part´ıcula . . . 30
3.6. Funcionamiento del m´etodo de la ruleta . . . 31
3.7. Esquema de m´odulos del filtro de part´ıculas simple . . . 32
3.8. Funcionamiento del m´etodo de torneo . . . 34
3.9. Divisi´on del trabajo en los filtros de segmentaci´on adaptados a los SPEs . . 36
3.10. Distribuci´on de las part´ıculas en los SPEs . . . 37
3.11. Esquema de alineamiento del ´area de inter´es en un SPE . . . 38
3.12. Esquema de m´odulos del filtro de part´ıculas mediante SPEs . . . 40
3.13. Funcionamiento con un solo buffer para transferencias . . . . 41
3.14. Funcionamiento utilizando doble buffering . . . . 41
4.1. Comparativa de rendimiento con un n´umero moderado de part´ıculas . . . . 46
4.2. Comparativa de rendimiento con mayor cantidad de part´ıculas . . . 47
4.3. Muestra del problema de inicializaci´on en la secuencia parabola cuadrado 50 4.4. Estimaciones para BrowseWhileWaiting1 320 672 20, PFSimple (izquier-da) contra PFOtimizado (derecha) . . . 51
4.5. Estimaciones para Walk2 312 474 20, PFSimple (izquierda) contra PFOtimizado (derecha) . . . 51 4.6. Estimaciones para parabola cuadrado (sint´etica), PFSimple (izquierda)
1.1. Organizaci´on del pipeline en un SPE . . . . 13
3.1. Tipos de vectores disponibles . . . 20
3.2. Instrucciones para acceder a los buzones . . . 25
4.1. Estad´ısticas de precisi´on para la secuencia Walk2 312 474 20 . . . 49
4.2. Estad´ısticas de precisi´on para la secuencia sint´etica parabola cuadrado . . 49
Introducci´
on
1.1.
Introducci´
on a la visi´
on computacional
La visi´on computacional es una disciplina que persigue reproducir las capacidades vi-suales de los seres vivos en un computador. Para ello, obtiene una representaci´on de la realidad que le proporciona informaci´on sobre brillo, colores, formas, etc. Estas repre-sentaciones suelen venir dadas en forma de im´agenes est´aticas, escenas tridimensionales o im´agenes en movimiento [19].
Una imagen es una funci´on para la que dado un par de coordenadas (x,y) se obtiene un valor relativo al color del p´ıxel en dichas coordenadas, por ejemplo el brillo en una imagen en escala de grises, o su color en una RGB. Una escena 3D asigna una propiedad a cada terna (x,y,z) del espacio de manera similar a una imagen, solo que en este caso, el hecho de existir un objeto que ocupa dicha posici´on puede ser m´as relevante que su color. Por ´ultimo, las secuencias animadas no son m´as que una agrupaci´on ordenada de im´agenes o fotogramas, reproducidas a una velocidad suficiente (25 fotogramas por segundo) para que el ojo las interprete como contiguas ocasionando la sensaci´on de movimiento fluido. Es el mismo efecto utilizado en el cine o la televisi´on.
Etapas de un sistema de visi´on artificial
La visi´on artificial, en un intento de reproducir el funcionamiento del sentido de la vista humano, divide el funcionamiento de un sistema de visi´on artificial en cuatro etapas:
1. Captura de la imagen digital mediante un sensor.
2. Procesamiento previo de la imagen mediante t´ecnicas de tratamiento digital como filtros y transformaciones geom´etricas que eliminan las partes no deseadas de la imagen o resaltan aquellas que son de inter´es.
3. Segmentaci´on de la imagen con el objetivo de extraer los objetos que aparecen en
ella.
4. Clasificaci´on de los objetos analizando las caracter´ısticas de cada uno de ellos.
Estas etapas no son siempre secuenciales y es com´un que tengan que repetirse en caso de fallo.
Existen multitud de sistemas de visi´on artificial dise˜nados en funci´on del objetivo deseado: sistemas que reconocen formas o patrones (OCR), localizaci´on de un punto de inter´es (brazos rob´oticos) o de la propia posici´on (navegaci´on en un entorno), etc. El problema que se tratar´a en este proyecto es el correspondiente al seguimiento visual 2D.
1.2.
Seguimiento Visual
El seguimiento visual es una tarea compleja que consiste en la estimaci´on de la posi-ci´on de uno o varios objetos en movimiento dentro de una escena [16]. Su aplicaci´on es posible en campos muy variados como el entretenimiento multimedia, la videovigilancia, la rob´otica o en sistemas de realidad aumentada. Cl´asicamente estos sistemas se han im-plementado extrayendo la escena 2D mediante una ´unica fuente en forma de c´amara o v´ıdeo sint´etico, aunque se ha estudiado su adaptaci´on a un entorno con varias fuentes si-mult´aneas, con el objetivo de recrear una escena tridimensional o solapar varias im´agenes contiguas [18].
A la hora de desarrollar una soluci´on a este problema, hay que tener en cuenta varios factores:
Para desarrollar un algoritmo capaz de seguir un objeto, es necesario hacer ciertas suposiciones que nos permitan reducir el espacio de b´usqueda. La principal es cono-cida como la hip´otesis de continuidad, por la que se supone que el sistema es
capaz de mostrar el movimiento como continuo o lo que es equivalente, la posici´on de un objeto en dos instantes contiguos es cercana en la representaci´on de la escena que sirve como base [17].
Es deseable que la soluci´on pueda trabajar en tiempo real, por lo que el rendimiento del algoritmo implementado tiene que garantizar que esto sea posible.
puede ser la forma, el color, la textura o el tama˜no. Estas caracter´ısticas han de ser extra´ıdas del dominio de trabajo y el sistema debe ser capaz de poder clasificar la informaci´on de las im´agenes en funci´on de ellas.
El algoritmo tiene que proporcionar cierto grado de protecci´on contra el ruido en las caracter´ısticas, derivado del paso de una escena tridimensional a dos dimensiones (cambio de forma del objeto cuando gira, cambio de tama˜no cuando se aleja o acerca al dispositivo de captura), o cambios bruscos en la iluminaci´on (variando los niveles de intensidad de los colores).
El sistema desarrollado debe ser preciso, devolviendo resultados similares en distin-tas ejecuciones sobre un mismo escenario, y exacto a la hora de estimar la posici´on del objeto sobre el que se realiza el seguimiento.
Es deseable que el sistema sea capaz de seguir varios objetos y diferenciar entre cada uno de ellos en todos los instantes.
Tambi´en es deseable que la soluci´on sea tolerante a oclusiones que se puedan producir en la escena (para el ejemplo del seguimiento de una persona en un pasillo, si esta pasa detr´as de una columna en el escenario).
1.2.1.
Soluciones al problema del seguimiento
Se han propuesto diferentes enfoques para solucionar el problema del seguimiento: basados algoritmos gen´eticos, metaheur´ıstica o m´etodos probabil´ısticos. En la actuali-dad, las soluciones m´as populares son el filtro de Kalman y el filtro de part´ıculas, que cuentan con numerosas variaciones. Estos dos m´etodos se basan en un esquema de
predicci´on-actualizaci´on, utilizando la informaci´on de instantes anteriores para prede-cir el estado del objeto en el futuro.
A la hora de actualizar la informaci´on del sistema, cada uno utiliza distintos enfo-ques. As´ı, el filtro de Kalman utiliza el Teorema de Bayes para combinar la informaci´on a priori y a posteriori mediante un sistema de confianza relativa en las medidas tomadas. Por otro lado, el filtro de part´ıculas utiliza un enfoque de Montecarlo, recogiendo muestras aleatorias del estado del sistema de manera peri´odica y operando sobre ellas para predecir la posici´on m´as probable del objeto en el siguiente instante.
funcionamiento a la hora de evaluar las muestras es altamente paralelizable, mientras que el segundo est´a limitado a los casos unimodales y su adaptaci´on a esquemas de procesamiento en paralelo es m´as compleja.
Filtro de part´ıculas
El filtro de part´ıculas o algoritmo de condensaci´on es un algoritmo que permite
estimar el estado de un sistema que cambia de forma din´amica. Se trata de un m´etodo de Montecarlo com´unmente utilizado en la visi´on computacional. El algoritmo fue ini-cialmente propuesto en 1993 por Gordon y colaboradores [12], y en 1998 Isard y Blake adaptaron el marco de trabajo del filtro de part´ıculas para su aplicaci´on en el problema del seguimiento visual [14].
El algoritmo comienza con la definici´on de un conjunto de muestras denominadas
part´ıculas, conformadas por dos partes: un estado y un valor denominado peso que
simboliza el grado de confianza en que la part´ıcula se encuentre cerca del objetivo; en el caso del seguimiento visual, el estado se corresponde con una posici´on (x,y) dentro de la imagen y el peso puede calcularse en funci´on del valor de los p´ıxeles cercanos a ella. A mayor n´umero de part´ıculas, el algoritmo conseguir´a predecir el siguiente estado con mayor fiabilidad.
Para su funcionamiento, el filtro comprende las siguientes etapas (Figura 1.1):
1. Inicializaci´on, en la que se distribuyen las part´ıculas de manera aleatoria en el
espacio de la imagen.
2. Evaluaci´on, en la que a cada part´ıcula se le asigna un peso. Para ello, se define
una funci´on que dada la posici´on asociada a una part´ıcula, eval´ua el contenido de la imagen en dicha posici´on y sus cercan´ıas y devuelve el valor a asignar como peso.
3. Estimaci´on de la posici´on que el algoritmo devolver´a como predicci´on de la posici´on del objeto en el instante actual. Esto se puede realizar bien mediante un m´etodo simple como por ejemplo escoger la part´ıcula con mayor peso, o generando una posici´on a partir de varias part´ıculas como por ejemplo una media ponderada.
4. Selecci´on. A partir del conjunto de part´ıculas en el estado actual, se genera un
5. Difusi´on. A la posici´on de cada uno de los elementos del conjunto que se acaba de generar se le a˜nade cierto ruido aleatorio. Aplicando la hip´otesis de continuidad y debido a que el objeto se desplaza de manera continua, se puede esperar que en la siguiente iteraci´on se encuentre en una posici´on cercana a la anterior. El objetivo de este paso es distribuir las part´ıculas que se hayan concentrado en la posici´on seleccionada durante el paso anterior para aumentar las posibilidades de que las part´ıculas est´en cerca del objeto en el siguiente instante de tiempo.
6. Con el nuevo conjunto de part´ıculas se vuelve a la fase de evaluaci´on, repitiendo todos los pasos hasta que finalice el seguimiento.
Figura 1.1: Etapas dentro del filtro de part´ıculas
1.3.
Arquitectura del procesador Cell
El procesador de banda ancha Cell (Cell Broadband Engine, o Cell/B.E.) es la primera implementaci´on de una nueva familia de multiprocesadores ajustados a la arqui-tectura Cell/B.E. (CBEA). Tanto la arquiarqui-tectura como el procesador Cell son el resultado de la colaboraci´on que comenz´o el 2001 entre Sony, IBM y Toshiba (grupo tambi´en conocido como STI por las iniciales de las tres empresas). Aunque estos procesadores esta-ban inicialmente dise˜nados para aplicaciones en electrodom´esticos multimedia de consumo como videoconsolas o televisiones de alta definici´on, la arquitectura ha sido dotada de los ´
ultimos avances en el ´ambito de los procesadores de consumo. Se espera que gracias a estos avances, se pueda soportar un amplio abanico de aplicaciones tanto en el campo comercial como en el cient´ıfico [10].
1.3.1.
La arquitectura
El procesador Cell est´a constituido por nueve procesadores en un solo chip, que funcio-nan de manera concurrente. Aunque todos pueden compartir y acceder a toda la memoria disponible en el sistema, por sus funcionalidades se pueden agrupar en dos tipos:
Power Processor Element o PPE. Solo hay uno en el chip.
Synergistic Processor Element o SPE. Los ocho procesadores restantes son de
este tipo.
Ambos tipos de procesadores dependen el uno del otro: los SPEs necesitan al PPE para ejecutar el sistema operativo y, en la mayor´ıa de casos, el control general del algoritmo; mientras que el PPE necesita de la capacidad de c´omputo de los SPEs para acelerar la ejecuci´on durante las operaciones de mayor peso computacional. Los nueve procesadores est´an conectados mediante el Element Interconect Bus o EIB, un bus de alta capaci-dad que es el encargado de transmitir los datos entre todos ellos y hacia los interfaces que comunican el procesador con el resto de componentes hardware: el que comunica el chip con la memoria principal (Memory Interface Controller o MIC) y el que lo hace con el resto de dispositivos de entrada/salida (Cell Broadband Engine Interface o
BEI). La Figura 1.2 muestra todos estos componentes y como se organizan dentro del
procesador.
Figura 1.2: Elementos dentro del procesador Cell
A continuaci´on se detallar´an las caracter´ısticas de cada uno de estos elementos.
El PPE
El Power Processor Element o PPE contiene un n´ucleo PowerPC⃝RISC (ReducedR
denominado Power Processor Unit o PPU, con dos niveles de memoria cach´e (L1 de 32 KB y L2 de 512 KB) y una unidad de procesamiento vectorial con 32 registros (denom-inada VMX) que utiliza el juego de instrucciones AltiVec [13]. La tarea principal del PPE dentro del Cell consiste en ejecutar la l´ogica de control de los algoritmos, administrar los recursos del sistema, proporcionar los par´ametros a los SPEs y coordinarlos para que estos realicen el grueso del trabajo.
El SPE
Cada SPE est´a formado por tres componentes (Figura 1.3):
La unidad de procesamiento Synergistic Processor Unit o SPU. Se trata de una unidad de proceso RISC, con un registro de 128 entradas y de 128 bits cada una y que incorpora una unidad de procesamiento vectorial (VPU) con un juego de instrucciones propio, aunque muy similar a las de una unidad AltiVec y dos pipelines de ejecuci´on. Estos elementos est´an optimizados para trabajo intensivo con datos y su uso para ejecutar c´odigo de control est´a fuertemente desaconsejado (debido principalmente a su lentitud en cambios de contexto y que carece de mecanismos de predicci´on hardware).
Un ´area privada de memoria denominada Local Store o LS de 256 KB de capaci-dad, tanto para c´odigo como para datos. Los SPEs han de transferir los datos a esta memoria local para poder trabajar con ellos, ya que son incapaces de acceder a la memoria principal mediante operaciones load y store cl´asicas. Aunque no se trata de una memoria cach´e, se puede utilizar como tal si se controla mediante software. Adem´as, el PPE puede acceder desde el exterior al LS de cada uno de los SPEs mediante una serie de instrucciones especiales.
Un interfaz de memoria denominado Memory Flow Controller o MFC, que trabaja de forma as´ıncrona respecto a la SPU. Se trata de un controlador que im-plementa instrucciones de acceso directo a memoria (DMA), y que hace de interfaz entre la LS y la memoria principal del sistema. Adem´as de las instrucciones DMA, el MFC tambi´en dota al SPE de un sistema de buzones o mailboxes con el que puede enviar peque˜nos mensajes de sincronizaci´on, bien entre PPE y SPE, bien entre varios SPEs.
trabajar con los datos, puede asegurarse de la finalizaci´on de la transferencia medi-ante el canal privado. El MFC guarda una cola de peticiones que maneja y ordena de manera independiente y cuyo comportamiento puede ser modificado mediante el uso de instrucciones concretas de sincronizaci´on.
Todos estos procesos son completamente dependientes del c´odigo y es el
pro-gramador el que ha de implementar cada una de estas transferencias mediante las distintas instrucciones disponibles.
Figura 1.3: Estructura de un SPE
Como se coment´o anteriormente, se pueden encontrar ocho de estos procesadores en los chips m´as comunes, aunque tambi´en se fabrican con mayor o menor cantidad para otros componentes que precisan de distintas capacidades de c´omputo (como televisores de alta definici´on, tarjetas gr´aficas o componentes para servidores).
El EIB
El EIB constituye el sistema de comunicaci´on de datos e instrucciones entre todos los elementos del chip. Est´a dise˜nado espec´ıficamente para el Cell, y es capaz de soportar sistemas SMP (Symmetric Multi-Processing) y clusters de varios procesadores mediante una jerarqu´ıa de memoria coherente. Seg´un IBM, este bus es capaz de alcanzar un ancho de banda te´orico de 204.8 GB/s1
El EIB est´a constituido por cuatro anillos (dos en cada sentido), cada uno de ellos de 16 bytes de ancho y que transmiten 128 bytes por ciclo (una l´ınea de cach´e de PPE) y es capaz de mantener hasta 16 transferencias a la vez. Para transferir datos por ´el, los SPEs utilizan su MFC para generar instrucciones DMA as´ıncronas, mientras que el PPE lo hace con instrucciones load y store cl´asicas. Cada uno de los elementos conectados a ´el puede recibir y enviar datos de manera simult´anea, y el propio bus puede mantener varias transferencias al mismo tiempo.
1.3.2.
Modelo de desarrollo
El portar una aplicaci´on a un sistema Cell es un proceso incremental e iterativo. Es incremental en el sentido en que los puntos con mayores oportunidades de paralelismo en la aplicaci´on deben ser desplazados desde el PPE hacia los SPEs de manera progresiva, e iterativo para cada uno de los puntos. La optimizaci´on puede ser refinada en las etapas de vectorizaci´on, sincronizaci´on y movimiento de datos hasta que se alcancen niveles satisfactorios de rendimiento [10].
Como comienzo, se pueden utilizar herramientas de profiling en una implementaci´on para una arquitectura general como el PPE para encontrar dichos puntos conflictivos en el c´odigo. Tras ello, para cada punto se implementar´a una primera versi´on que haga uso de los SPEs, y tras asegurar su funcionamiento, se podr´a comenzar a optimizar dicha versi´on mediante instrucciones vectoriales o el ajuste fino de las transferencias DMA. La Figura 1.4 describe todo el proceso.
1.3.3.
T´
ecnicas de adaptaci´
on y optimizaci´
on
La tarea de adaptar de un algoritmo a un procesador Cell se divide en dos ´areas: el modelo de divisi´on de trabajo entre los SPEs disponibles y las optimizaciones posteriores al c´odigo, entre ellas la vectorizaci´on.
Figura 1.4: Flujo de trabajo para adaptar un algoritmo a Cell
Esquemas de divisi´on del trabajo
Existen numerosas configuraciones posibles a la hora de dividir las distintas tareas dentro de un algoritmo y adaptarlas al procesador Cell. Aunque en [8, 15] se pueden encontrar numerosos ejemplos, los m´as destacados son los siguientes:
Descarga de funciones: En este modelo de programaci´on, los SPEs se utilizan como aceleradores para funciones cr´ıticas, y es el mas sencillo para comenzar a aprovechar las capacidades del Cell. De manera similar a la tecnolog´ıa de llamada a procedimiento remoto (RPC), el PPE ejecuta una peque˜na funci´on o stub, que inicializa los SPEs y solicita que estos ejecuten la funci´on requerida por ´el. El SPE recoge sus par´ametros, realiza el trabajo solicitado y devuelve los resultados al PPE para que este contin´ue su ejecuci´on (Figura 1.5).
Figura 1.5: Descarga de una funci´on en un SPE
Extensi´on de dispositivo: Es un caso particular del modelo de descarga de
(por ejemplo, un sistema de ficheros seguro o un hardware gr´afico) mediante c´ odi-go con privilegios especiales asociado al sistema operativo. Utilizando los mailboxes y las transferencias DMA, el resto de elementos de proceso pueden solicitar fun-cionalidades a dicho dispositivo: en el caso del sistema de ficheros, la encriptaci´on y desencriptaci´on de datos de dicho sistema.
Streaming : En este caso, los SPEs act´uan como etapas de un sistema de streaming, en el que los datos entran, son procesados y contin´uan en la siguiente etapa y posteriormente hacia otro dispositivo. El PPE queda en un segundo plano ejecutando la l´ogica de control y sincronizaci´on (Figura 1.6).
Figura 1.6: Esquema de funcionamiento de la configuraci´on para streaming
Overlays: Si el c´odigo de un SPE es demasiado grande, es necesario el uso de
overlays. Un overlay es una porci´on de c´odigo que reside en memoria y es cargada y ejecutada por un SPE de manera din´amica, permitiendo al programador organizar el c´odigo de manera modular. Tambi´en se pueden utilizar para implementar plugins: el PPE carga un binario en memoria, y de esta manera el SPE adquiere funcionalidad nueva dependiendo del contexto de la aplicaci´on.
Existen otras variaciones posibles: utilizar un entorno con m´as de un procesador Cell, implementar una pol´ıtica din´amica de creaci´on y ejecuci´on de hilos controlada por un proceso central en el PPE o utilizar frameworks espec´ıficos dise˜nados para ayudar al programador a la hora de integrar nuevas aplicaciones.
Vectorizaci´on y optimizaciones
A nivel de datos. La computaci´on vectorial o SIMD (Single Instruction,
Multiple Data ) persigue acelerar la ejecuci´on de las operaciones en un procesador ayud´andose de unidades de procesamiento adicionales que son capaces de ejecutar operaciones con m´ultiples elementos de manera paralela. A la hora de adaptar un c´odigo a este m´etodo de computaci´on, es necesario organizar los datos de las apli-caciones de tal forma que se maximice el rendimiento de las unidades vectoriales. Principalmente se diferencia entre dos tipos de organizaci´on:
• Array de estructuras o AOS. En la Figura 1.7, se muestra una organizaci´on
de este estilo. Los vectores se utilizan para guardar las posiciones 3D de un elemento, por lo que al final se consigue un vector por cada elemento a procesar. Este esquema normalmente genera c´odigo corto, pero con un rendimiento pobre que requiere de muchas optimizaciones posteriores.
Figura 1.7: Array de estructuras
• Estructura de arrays o SOA. En esta ocasi´on se almacenan los datos de manera
homog´enea, un tipo de dato en cada vector y tantos tipos de vectores como componentes tenga el elemento tal como se muestra en la Figura 1.8. En este esquema, las optimizaciones posteriores son mucho m´as sencillas.
Figura 1.8: Estructura de arrays
A nivel de c´odigo. Una vez se ha vectorizado el algoritmo a nivel de datos, existen
• Organizar el c´odigo para aprovechar de la mejor manera posible los dos pipelines
que existen en la SPU (denominados “par” o “0”, e “impar” o “1”). En cada uno de ellos, la SPU eval´ua ciertos tipos de instrucciones de manera simult´anea cada ciclo. Si se consigue organizar el c´odigo en parejas de instrucciones que pertenecen a distintos pipelines, se conseguir´an ejecutar dos instrucciones en un solo ciclo. En la Tabla 1.1 se muestran los distintos tipos de instrucciones y su pipeline asociado [8].
Tipo de instrucci´on Ciclos Pipeline
Carga y almacenamiento 6 Impar
Pista de salto 15 Impar
Resoluci´on de salto 4 Impar
Registros de prop´osito especial y canales 6 Impar Coma flotante precisi´on simple 6 Par
Coma flotante precisi´on doble 13 Par
Enteros con coma flotante 7 Par
Mezcla 4 Impar
Simple con coma fija 2 Par
Rotaci´on y desplazamiento 4 Par
Operaciones de byte 4 Par
Sin operaci´on (ejecutar) - Par
Sin operaci´on (carga) - Impar
Tabla 1.1: Organizaci´on del pipeline en un SPE
• Function-inlining, con la que se construyen funciones inline que permitir´an
evitar saltos en el c´odigo al llamarlas. Ha de usarse con precauci´on ya que si se utiliza de forma demasiado agresiva puede aumentar demasiado el tama˜no del c´odigo (y hay que recordar que la capacidad del LS de un SPE es muy limitada).
• Loop-unrolling. Esta t´ecnica consiste en reducir el n´umero de iteraciones de
los bucles en los que se hace c´alculo vectorial computando varios vectores en cada una de las repeticiones. Con ella se consigue reducir el n´umero de ramas condicionales en el c´odigo. De la misma manera que la anterior, esta t´ecnica produce c´odigos de gran tama˜no que pueden no caber en el LS.
• Condicionales y predicci´on utilizando la unidad vectorial. Como se
del c´odigo, mediante pistas o hints. En contraste con el sistema de predicci´on de los procesadores modernos, es bastante menos fiable y complejo, dejando la responsabilidad en manos del programador.
Objetivo del proyecto
2.1.
Objetivo principal
El objetivo del proyecto es adaptar un algoritmo de seguimiento visual a la arquitectura especializada de un procesador Cell. Mediante este desarrollo se pretende definir un modelo alternativo que permita implementar el filtro de part´ıculas en esta arquitectura para as´ı acelerar su funcionamiento.
2.2.
Objetivos parciales y etapas del desarrollo
Verificar que en la consola donde se va a desarrollar se disponen de todas las her-ramientas necesarias.
Comprender el funcionamiento de ciertos algoritmos de visi´on computacional, prin-cipalmente del filtro de part´ıculas.
Aprender a utilizar la librer´ıa OpenCV y toda la funcionalidad que esta ofrece, generando programas que resuelvan tareas sencillas como filtros o interacci´on con ficheros.
Implementar el algoritmo del filtro de part´ıculas sin optimizaciones dependientes de hardware.
Estudiar la arquitectura interna del procesador Cell y los mecanismos de opti-mizaci´on que ofrece, como por ejemplo la vectorizaci´on.
Estudiar el plugin CvCell de OpenCV y su funcionamiento.
Aprender a utilizar el kit de desarrollo software que provee IBM con el cual se implementar´an los programas que hagan pleno uso de las capacidades que ofrece el procesador.
Desarrollar aplicaciones de car´acter general que utilicen las capacidades de la arqui-tectura del procesador Cell (programas que realicen tareas simples, como paso de mensajes o transferencias DMA).
Experimentar con el plugin CvCell que adapta las funciones de OpenCV a la arqui-tectura de este procesador, as´ı como su funcionamiento. Posteriormente se inten-tar´a a˜nadir la funcionalidad desarrollada a dicha librer´ıa.
Adaptar el filtro de part´ıculas previamente desarrollado a un esquema de proce-samiento vectorial y utilizar las capacidades del procesador Cell para optimizarlo y mejorar as´ı su rendimiento.
Descripci´
on Inform´
atica
3.1.
Herramientas
A la hora de trabajar en el proyecto ha sido necesario manejar gran variedad de herramientas, tanto software como hardware. A continuaci´on se introducen las m´as im-portantes a la hora de entender el funcionamiento del sistema desarrollado.
3.1.1.
Consola PlayStation 3
Para poder desarrollar algoritmos de seguimiento en un procesador Cell lo primero y esencial es el propio hardware. Como se ha comentado anteriormente, el procesador Cell se puede encontrar en la actualidad en multitud de sistemas y componentes, pero el que destaca sobre todos ellos por su bajo coste es la consola PlayStation 3 de Sony, que gracias a la opci´on OtherOS que incorpora de forma nativa1, permite al usuario disponer de un sistema operativo Linux y de un entorno de desarrollo plenamente funcional para experimentar con la arquitectura.
El hardware de PlayStation 3 esta compuesto por2:
Un procesador Cell a 3.2 GHz, con 6 de los 8 SPEs disponibles para su uso. De los dos que no est´an disponibles, uno de ellos se bloquea en el momento de la fabricaci´on para abaratar costes, mientras que el otro (denominado Hypervisor) est´a reservado por el sistema operativo para monitorizar las operaciones sobre el hardware y mantener la seguridad del sistema.
1Las primeras versiones de PS3 (denominadas “Fat”) disponen de esta opci´on siempre que el sistema
operativo de juego de la consola no sea actualizado m´as all´a de la versi´on 3.21, en el cual Sony deshabilit´o la opci´on OtherOS; aunque existe ya un firmware no oficial que restaura dicha opci´on, en nuestro caso no se actualiza el sistema nativo de la consola en ning´un momento por lo que se puede continuar usando Linux sin problema. Las versiones m´as recientes de la consola (o “Slim”) carecen de esta opci´on de f´abrica.
2http://www.scei.co.jp/corporate/release/pdf/050517e.pdf
256 MB de memoria Rambus XDR RAM. Aunque la velocidad de este tipo de
memoria es elevada, su baja cantidad hace que el hecho de desarrollar aplicaciones se complique, sobre todo teniendo en consideraci´on que necesita cargar en ella un sistema Linux completo.
Un procesador gr´afico o GPU conocido con el nombre de RSX, desarrollada espec´ıfi-camente para PS3 y de manera conjunta por Sony y NVIDIA. En la actualidad su uso para aceleraci´on gr´afica no es posible si se utiliza la utilidad OtherOS, al estar esta unidad protegida por el anteriormente mencionado Hypervisor.
Varios sistemas de entrada-salida: un lector de CD / DVD / Blu-ray, varios puertos USB, puertos Ethernet, etc.
Para el desarrollo del proyecto se har´a uso de la consola PS3 que el grupo de inves-tigaci´on GAVAB adquiri´o en el 2008. Se ha conectado a la red de la universidad, se le ha instalado un sistema operativo Yellow Dog Linux mediante OtherOS y activado var-ios servicvar-ios del sistema con la intenci´on de que el trabajo se pueda realizar de manera remota.
3.1.2.
Lenguajes de programaci´
on
El lenguaje de programaci´on elegido para desarrollar el proyecto ha sido C, debido principalmente a dos razones:
1. Es el lenguaje preferente a la hora de usar el kit de desarrollo de software propor-cionado por IBM que se utilizar´a en el proyecto.
2. Experiencia previa en el uso del lenguaje.
A la hora de compilar y depurar los programas se ha hecho uso extensivo de aplica-ciones cl´asicas como gcc, gdb o valgrind; adem´as se han implementado diversos scripts para automatizar la compilaci´on y experimentaci´on mediante el lenguaje de scripting de la shell bash de Linux.
3.1.3.
SDK de IBM para Cell
La propia IBM distribuye de manera gratuita una paquete (Software Development
Kit o SDK) de utilidades y librer´ıas para programar aprovechando las caracter´ısticas del
Librer´ıas y cabeceras b´asicas para implementar aplicaciones que utilicen las SPUs. Las principales son libspe2, spu mfcio y spu intrinsics.
Gran variedad de librer´ıas auxiliares que ofrecen funcionalidad extra o implementan operaciones comunes en la arquitectura espec´ıfica del procesador Cell: vectorizaci´on (tanto para PPE como SPE), tratamiento de im´agenes, operaciones matem´aticas avanzadas, manejo y transferencia de memoria, sincronizaci´on, computaci´on en pa-ralelo entre varios Cell, etc.
Utilidades de compilaci´on, depuraci´on y optimizaci´on adaptadas espec´ıficamente a Cell, como por ejemplo ppu32-gcc, spu-gcc, gdb-ppu, gdb-spu, plantillas para compilar mediante make, etc.
Un simulador con el que probar los programas desde cualquier m´aquina Linux. Tras realizar diversas pruebas con el hardware disponible (principalmente procesadores de doble n´ucleo de consumo) se percibi´o que el rendimiento del simulador era muy bajo y se tardaba un tiempo excesivo en ejecutar programas simples para Cell. Esto es debido al n´umero de hilos de ejecuci´on que el simulador genera y utiliza para sustituir a cada uno de los SPEs.
Un plugin para Eclipse con el que realizar compilaci´on cruzada y ejecuci´on en m´aquinas remotas. Aunque utilizado durante las etapas iniciales del desarrollo, de-bido a varios problemas relacionados con la instalaci´on y compilaci´on de programas se ha decidido no hacer uso de ´el en este proyecto.
Vectorizaci´on
Tanto el PPE como los SPEs disponen de una unidad vectorial para acelerar la com-putaci´on mediante instrucciones SIMD. El juego de instrucciones utilizado en PPE es el denominado AltiVec, mientras que los SPEs tienen un juego de instrucciones propio pero con muchas similitudes al de PPE denominado Synergistic Processor Unit Instruction Set
Architecture. Estas instrucciones est´an implementadas mediante funciones denominadas
intr´ınsecas, que son funciones conocidas por el compilador, y que en el momento de
generar el binario ejecutable sustituir´a por instrucciones espec´ıficas del procesador.
A la hora de utilizar estas operaciones, hay que tener en cuenta ciertas considera-ciones importantes:
Los tipos de datos: Tanto AltiVec como el juego de instrucciones de los SPEs
los que trabajar, y es imposible definir nuevos tipos de vectores. Todos ellos son de tama˜no fijo de 128 bits, y en ese espacio almacenan un distinto n´umero de elementos seg´un el tipo de vector, por lo que a menor tama˜no de elemento, mayor es la mejora en rendimiento obtenida durante la vectorizaci´on al procesar m´as elementos en una sola instrucci´on. En la Tabla 3.1 se muestran los distintos tipos de datos disponibles seg´un el juego de instrucciones a utilizar [8, 2].
Tipo de dato Soportado por Contenido Valores posibles
vector unsigned char Ambos 16 unsigned char 0 ... 255 vector signed char Ambos 16 signed char -128 ... 127
vector bool char PPE 16 unsigned char 0 (FALSE) - 255 (TRUE) vector unsigned short Ambos 8 unsigned short 0 ... 65535
vector signed short Ambos 8 signed short -32768 ... 32767
vector bool short PPE 8 unsigned short 0 (FALSE) - 655365 (TRUE) vector pixel PPE 8 unsigned short pixel 1/5/5/5 (1/R/G/B) vector unsigned int Ambos 4 unsigned int 0 ... 232 - 1
vector signed int Ambos 4 signed int −231 ... 231 - 1
vector bool int PPE 4 unsigned int 0 (FALSE) - 232 - 1 (TRUE)
vector float Ambos 4 float IEEE-754 32 bits
vector unsigned long long SPE 2 unsigned longs 0 ... 264 - 1 vector signed long long SPE 2 signed longs −263 ... 263 - 1
vector double SPE 2 doubles IEEE-754 64 bits
Tabla 3.1: Tipos de vectores disponibles
Los juegos de instrucciones son demasiado extensos para ser plasmados en este documento, pero se pueden encontrar en [4, 1, 2]. Ambos son muy similares entre s´ı y la mayor´ıa de las instrucciones var´ıan ´unicamente en su nomenclatura.
Para las instrucciones de las que no existe una conversi´on directa entre AltiVec y el juego de instrucciones SPE (o viceversa), el SDK incluye varias librer´ıas auxiliares que las implementan como funciones inline. De esta manera, se facilita la tarea de portar c´odigo entre ambas arquitecturas.
A la hora de cargar de memoria los vectores de datos, hay que resaltar que la unidad vectorial (tanto de PPE como de SPE) carece de capacidad de alineamiento. La especificaci´on de ambas unidades requiere que los datos residan en memoria alineada a 16 bytes (esto es, la direcci´on es m´ultiplo de 16 o lo que es lo mismo sus cuatro ´
cumplen este requisito para el correcto funcionamiento del programa. Para ello, se disponen del especificador de tipo aligned() para variables est´aticas y de las fun-ciones memaling() para PPE (librer´ıa stdlib) y malloc align() para SPU (librer´ıa auxiliar libmisc incluida en el SDK) en el caso de memoria din´amica.
Es posible la conversi´on de tipo entre vectores y arrays de escalares en la mayor´ıa de los casos siempre y cuando se respete la restricci´on de memoria alineada.
DMA
Para transferir datos entre memoria principal y cada uno de los SPEs, se debe recurrir al uso de operaciones DMA gestionadas por el MFC de cada uno de ellos. Existen dos maneras de iniciar dichas transferencias:
Desde el propio SPE, mediante el paso de mensajes por el canal privado que existe entre SPU y MFC. Se trata de un m´etodo de baja latencia y sin impacto negativo en el EIB. El SDK proporciona cuatro formas distintas de iniciar transferencias mediante este m´etodo, seg´un se requiera un mayor o menor control a bajo nivel: mediante funciones del MFC, intr´ınsecos compuestos o intr´ınsecos de bajo
nivel, o mediante instrucciones de lenguaje ensamblador [7].
Desde el exterior, el PPE u otros SPEs pueden acceder a la memoria privada y a los registros del MFC de un tercer SPE, y utilizar funciones espec´ıficas para enviar las solicitudes de DMA a dicho MFC. Esta t´ecnica se denomina interfaz MMIO.
El MFC asocia cada solicitud a una etiqueta o tag, con la cual se pueden agrupar varias solicitudes y consultar el estado de las transferencias mediante las funciones que este ofrece al exterior. En cuanto a las operaciones DMA que se pueden realizar, existen las siguientes posibilidades:
Seg´un el tipo de operaci´on que se vaya a realizar en memoria principal se diferencia
entre operaciones de carga (o get) que transmiten datos de memoria principal hacia el LS del SPE, y operaciones de almacenamiento (o put) que transmiten datos desde el LS a memoria principal.
• Comienzo de ejecuci´on (modificador s): Ordena al SPU comenzar su
ejecu-ci´on cuando se termine la transferencia DMA (solo se puede utilizar desde el exterior).
• Sincronizaci´on por cerca (modificador f): Ordena la transferencia respecto a
todas las solicitudes previas con la misma etiqueta, de forma que se asegura que todas las peticiones anteriores a la que sincroniza mediante cerca se completan antes que ella (Figura 3.1).
Figura 3.1: Sincronizaci´on de DMA mediante un mecanismo de cerca o fence
• Sincronizaci´on por barrera (modificador b): Ordena la transferencias respecto a
todas las solicitudes previas con la misma etiqueta, de forma que se asegura que todas las peticiones anteriores a la que sincroniza mediante cerca se completan antes que ella o que cualquier otra solicitada despu´es (Figura 3.2).
Figura 3.2: Sincronizaci´on de DMA mediante un mecanismo de barrera
• Lista de transferencias (modificador l): El comando procesa una lista de
Para utilizar estos modificadores, simplemente se adjunta el modificador asocia-do como sufijo a la hora de utilizar la operaci´on deseada: por ejemplo, al solici-tar una transferencia mediante el comando putb (o su equivalente funci´on MFC mfc putb()), se generar´a una solicitud de almacenamiento sincronizada mediante un mecanismo de barrera. No todas las combinaciones de operaciones son v´alidas, por lo que es preciso consultar [9, 5, 4] a la hora de utilizar uno de estos modifi-cadores.
En cuanto a los par´ametros de las transferencias, a continuaci´on se muestra una lista con sus caracter´ısticas obligatorias y/o recomendadas [10]:
Tama˜no de las transferencias: El tama˜no de las transferencias ha de ser 1,
2, 4, 8, 16 bytes o un m´ultiplo de 16 bytes, siendo el tama˜no m´aximo 16 KB por transferencia. El mejor rendimiento se obtiene cuando el tama˜no de la transferencia es un m´ultiplo de 128 bytes.
Alineamiento: Las direcciones tanto de memoria principal como del LS han de tener los cuatro bits menos significativos iguales. Para transferencias menores
de 16 bytes, las direcciones tienen que estar alineadas naturalmente seg´un el tama˜no. Para las mayores o iguales a 16 bytes, ambas direcciones han de estar
alineadas a 16 bytes o lo que es equivalente, tener sus ´ultimos 4 bits igual a cero. El pico de rendimiento se obtiene cuanto las dos direcciones est´an alineadas a 128 bytes, siendo sus seis bits menos significativos iguales a cero.
Listas: Para utilizar las operaciones con listas, se han de cumplir los siguientes
requisitos:
• Todos los par´ametros de cada una de las transferencias cumplen las
restric-ciones anteriormente citadas.
• Las direcciones de 64 bits han de tener los 32 bits superiores iguales entre s´ı. • Todas las transferencias utilizan la misma etiqueta.
• La lista puede constar de hasta 2048 solicitudes, ocupando la propia estructura
16 KB de memoria en el LS. Debido a que cada solicitud en la misma puede ser de hasta 16 KB, un ´unico comando este tipo puede transferir hasta 32 MB, o lo que es lo mismo 128 veces el tama˜no del LS de un SPE.
• Mientras que el ´area del LS objeto de las transferencias ha de ser contigua,
mediante operaciones de lista m´etodos que siguen el esquema scatter-gather, unificando la informaci´on de varias ´areas en un solo buffer general.
• La direcci´on de LS donde reside la lista de solicitudes ha de estar alineada a 8
bytes o lo que es equivalente, los ´ultimos tres bits de su direcci´on son cero.
Para asegurar que los datos cumplen todos estos requisitos, el programador tiene a su disposici´on las mismas herramientas de alineamiento que en el caso de los vectores, y ha de asegurarse del correcto tama˜no de las transferencias a˜nadiendo relleno o padding a los datos si es necesario.
Comunicaci´on entre procesos
Adem´as del DMA, Cell posee varios mecanismos que le permiten la comunicaci´on entre el PPE y un SPE, o entre dos SPEs, y est´an implementados por el MFC que cada uno de los SPEs contiene. El c´odigo ejecutado en un SPU puede interactuar con el MFC de su SPE asociado mediante su canal privado de comunicaci´on, mientras que el c´odigo de PPE ha de utilizar el interfaz MMIO [10]. Los distintos mecanismos ofrecidos por el MFC son los siguientes:
Buzones o mailboxes: Los buzones permiten a los elementos del Cell de
inter-cambiar mensajes cortos de 32 bits entre los distintos componentes mediante un mecanismo de muy baja latencia.
Cada SPE tiene disponibles en su MFC tres buzones distintos divididos en dos categor´ıas desde el punto de vista del SPE: dos buzones de salida (uno para mensajes y otro para generar interrupciones en dispositivos externos) y uno de entrada de mensajes. Todos ellos siguen una pol´ıtica FIFO, y su uso es bloqueante en el lado de SPU y no bloqueante en el lado de PPU, aunque es posible implementar las opciones contrarias para cada uno de ellos mediante funciones no bloqueantes que consultan el estado de los buzones sin leer o escribir mensaje alguno. Las funciones disponibles para el uso de este mecanismo est´an detalladas en la Tabla 3.2:
Buz´on Funci´on SPU Bloquea Funci´on PPU Bloquea
Salida spu write out mbox() Si spe out mbox read() No
spu stat out mbox() No spe out mbox status() No Salida int. spu write out intr mbox() Si spe out intr mbox read() Ambos
1 spu stat out intr mbox() No spe out intr mbox status() No
Entrada spu read in mbox() Si spe in mbox write() Ambos
1 spu stat in mbox() No spe in mbox status() No 1 Se puede controlar mediante par´ametros de la funci´on
Tabla 3.2: Instrucciones para acceder a los buzones
los SPUs externos lo hacen mediante las instrucciones especiales implementadas mediante instrucciones DMA put.
Cada vez que se realiza una lectura de uno de los registros por el SPE local, su valor vuelve a cero, mientras que si se lee desde el exterior su valor no cambia. Para escribir, se pueden utilizar dos modos: acumular los valores de las sucesivas se˜nales mediante un OR l´ogico, o sobreescribir los valores anteriores y solo almacenar la ´
ultima se˜nal. La lectura de un registro de se˜nal es bloqueante (aunque existe una funci´on stat no bloqueante similar a la de los mailboxes), mientras que la escritura lo es solo para un SPE externo en el caso en el que la cola de peticiones de su MFC local est´e llena.
Eventos: Con el sistema de eventos de los SPE, un c´odigo que se ejecuta en un SPU puede identificar y reaccionar ante ciertos eventos, que pueden estar especificados por hardware o ser situaciones externas como una se˜nal o una escritura a un buz´on; de manera similar, el PPE es capaz de reaccionar ante eventos en los SPEs mediante funciones del SDK. En concreto est´an soportados cuatro tipos de eventos:
• Relacionados con los comandos del MFC de un SPE. • Lectura o escritura de se˜nales y buzones.
• Sincronizaci´on.
• Registro especial de decremento, que permite hacer cuentas hacia atr´as
pro-gramadas por el usuario.
3.1.4.
OpenCV
OpenCV es una librer´ıa de visi´on computacional de c´odigo abierto escrita en C/C++ disponible para Linux, Windows y Mac OS X, y existe un desarrollo activo de interfaces para otros lenguajes como Python, Ruby o Matlab [11], y que actualmente se encuentra en su versi´on 2.0. Se trata de una librer´ıa de confianza, ampliamente probada y usada en m´ultiples proyectos por universidades y organismos de todo el mundo. Dispone de un amplio abanico de funcionalidades: desde filtros sencillos hasta opciones para trabajar con c´amaras web, soportando multitud de formatos de v´ıdeo e imagen. Adem´as, proporciona la posibilidad de mostrar resultados mediante un interfaz sencillo e intuitivo.
CvCell
Junto con OpenCV se utilizar´a un plugin para esta librer´ıa denominado CvCell, desar-rollado por el grupo FixStars [6]. Su objetivo es acelerar los filtros y funciones de OpenCV adapt´andolos a la arquitectura del procesador Cell. Al contrario que OpenCV, se trata de una utilidad minoritaria y con escasa documentaci´on. Solamente es compatible con la versi´on 1.0 de OpenCV.
Para su implementaci´on, CvCell hace uso del mecanismo de plugins existente en OpenCV, capaz de cargar librer´ıas de manera din´amica. Su funcionamiento es simple: en su inicializaci´on, CvCell lanza en cada SPE una funci´on de dispatch que realiza una espera activa en su buz´on de entrada de mensajes, y cuando se realiza una llamada al API de OpenCV este llama a su vez al c´odigo de CvCell que env´ıa una se˜nal a cada SPE para que ejecute la funci´on deseada. La Figura 3.3 describe este funcionamiento [6].
3.1.5.
Sistemas operativos
Dado que solo se dispone de una consola que se encuentra en las instalaciones de la universidad, gran parte del desarrollo del proyecto se ha realizado de manera remota. Por esta raz´on se ha tenido que trabajar con diversos sistemas operativos:
Yellow Dog Linux 6.1, el sistema operativo instalado en la consola mediante
Figura 3.3: Esquema de funcionamiento de CvCell
Fedora 10: Se trata de una distribuci´on de GNU/Linux basada en Red Hat, y tambi´en compatible con el SDK para Cell. Se utiliz´o principalmente para trabajo remoto y realizaci´on de pruebas con las librer´ıas del SDK. El objetivo era instalar el SDK en ´el, utilizar el plugin de Eclipse para desarrollar, compilar de manera cruzada y traspasar los binarios a la consola para comprobar su funcionamiento. Debido a repetidos problemas con la instalaci´on del SDK y su uso, esta opci´on fue desechada.
Ubuntu 9.10, una distribuci´on de Linux basada en Debian. Adem´as de integrar de serie muchas de las herramientas auxiliares que se han necesitado, constituye un buen sistema para hacer pruebas simples que no requieran del Cell sin tener que recurrir a conexiones remotas.
3.2.
Implementaci´
on
vectorial en PPE, el desarrollo de una versi´on que utilice los SPEs del procesador Cell y por ´ultimo un proceso de mejora de esta ´ultima implementaci´on.
3.2.1.
Filtro de part´ıculas b´
asico
El desarrollo inicial est´a dise˜nado de forma modular para facilitar las posteriores mo-dificaciones. Siguiendo el funcionamiento de un filtro de part´ıculas general, la aplicaci´on desarrollada cuenta con un bucle principal de proceso, en el cual solicita las distintas operaciones del algoritmo a cada uno de los m´odulos. A continuaci´on se muestra un pseu-doc´odigo de su funcionamiento general:
Secuencia de im´agenes S; Imagen I;
Conjunto de part´ıculas P; Posici´on Pos;
inicializar(P)
while estado(S) ̸= fin do
I ← obtener siguiente frame(S); segmentar(I);
evaluaci´on(I,P); pos← estimaci´on(P);
{. . . Aqu´ı es posible utilizar Pos para implementar una funcionalidad . . . }
selecci´on(P); difusi´on(P);
end while
La secuencia de im´agenes
Uno de los primeros problemas encontrados en el desarrollo fue que OpenCV no era capaz de abrir archivos de v´ıdeo mediante sus funciones en la instalaci´on existente en la consola, por lo que no fue posible utilizar el material disponible (principalmente secuencias de v´ıdeo) para comprobar el correcto comportamiento del filtro. Tras estudiar el problema e intentar solucionarlo sin ´exito, se opt´o por implementar un m´etodo alternativo mediante un mecanismo de gesti´on de secuencias de im´agenes ordenadas.
Segmentaci´on
Debido a la naturaleza del material de pruebas a utilizar (principalmente v´ıdeos de c´amaras de seguridad del repositorio CAVIAR), se decidi´o por un modelo de segmentaci´on basado en tres etapas en el siguiente orden: el paso de las im´agenes a escala de grises, la sustracci´on del fondo a partir de una imagen en la que la escena carece de objetos en movimiento, y por ´ultimo el umbralizado de los resultados a partir de un valor umbral determinado de manera que
ISegmentado(x, y) =
{
0 si I(x, y) < umbral ; 255 si I(x, y)≥ umbral;
donde I es la imagen resultado de aplicar los dos filtros anteriores a la imagen original. Con este procesamiento se consigue resaltar de forma sencilla los objetos en movimien-to en la escena y eliminar gran cantidad de ruido sin necesidad de aplicar operaciones excesivamente complejas.
Representaci´on de las part´ıculas
En la implementaci´on desarrollada, cada part´ıcula est´a descrita por una posici´on (x,y) en el espacio de coordenadas de la imagen y un peso. La posici´on define el centro de una regi´on, ´area o ventana de inter´es dentro de la imagen, de forma cuadrada y de
tama˜no variable en tiempo de compilaci´on mediante una macro que define el rango.
Figura 3.4: Definici´on del ´area de inter´es de una part´ıcula (rango=3)
del ´area de inter´es deseado. Adem´as, en proporci´on al rango se definen unos m´argenes para que en ning´un momento la regi´on salga fuera de la imagen.
Las part´ıculas est´an agrupadas en un conjunto de longitud variable mediante el uso de opciones en l´ınea de comandos, que adem´as de contener cada part´ıcula y su infor-maci´on asociada guarda otra informaci´on ´util para el algoritmo como las medidas de los fotogramas de la secuencia.
Inicializaci´on
La inicializaci´on es un proceso sencillo que se realiza generando dos n´umeros aleato-rios para cada part´ıcula, xIni ∈ [0, AnchoF otograma) e yIni ∈ [0, AltoF otograma), y asignando
dichos n´umeros a su posici´on asociada. El m´etodo desarrollado que implementa este com-portamiento tambi´en sirve para reservar la memoria din´amica necesaria para almacenar el conjunto y su informaci´on auxiliar.
Evaluaci´on
Para calcular el peso de cada part´ıcula, primero se localiza el ´area de inter´es dentro de la imagen segmentada, se aplica un AND l´ogico para normalizar los valores de los p´ıxeles entre 0 y 1, y por ´ultimo se realiza el sumatorio del ´area, siendo este valor es el que se asignar´a como peso de la part´ıcula. La Figura 3.5 muestra un ejemplo de este proceso.
Estimaci´on
En esta etapa, adem´as de seleccionar y devolver la posici´on estimada en el instante ac-tual, es posible la visualizaci´on por pantalla de los resultados de manera opcional mediante las herramientas de interfaz incluidas en OpenCV. El programa ofrece dos posibilidades para seleccionar la posici´on: devolver la de la part´ıcula que tenga el peso asociado mayor de todo el conjunto o una media ponderada de todos los elementos. Para la visualizaci´on, se puede mostrar bien la part´ıcula con mayor peso, la media ponderada o todas las part´ıculas al mismo tiempo.
Selecci´on
Para la regeneraci´on se utiliza el algoritmo de la ruleta: a cada part´ıcula se le asigna una parte de un conjunto de estados en proporci´on a su peso, y en el momento de crear cada una de las part´ıculas hijas se genera un estado aleatorio a perteneciente a dicho conjunto; la hija tendr´a la misma posici´on que part´ıcula padre asociada al estado generado. De esta manera, las part´ıculas con mayor peso tendr´an m´as posibilidades de tener descendencia, pero manteniendo cierta variedad en el conjunto. La Figura 3.6 muestra un ejemplo de este proceso, en el cual la part´ıcula hija conservar´ıa el estado correspondiente al elemento
P2 del instante anterior.
Figura 3.6: Funcionamiento del m´etodo de la ruleta
Difusi´on
La difusi´on se realiza mediante un valor ruido modificable en tiempo de ejecuci´on, a partir del cual se generan dos valores para cada part´ıcula, ruidox ∈ [−ruido, ruido] y
ruidoy ∈ [−ruido, ruido]. Estos valores se suman a las posiciones obtenidas en la etapa
Organizaci´on en m´odulos
Para finalizar, la Figura 3.7 muestra como est´a organizado el c´odigo desarrollado para esta versi´on: en naranja el m´odulo que contiene el programa principal, en amarillo las librer´ıas auxiliares desarrolladas y en verde las librer´ıas externas a destacar.
Figura 3.7: Esquema de m´odulos del filtro de part´ıculas simple
3.2.2.
Filtro de part´ıculas con vectorizaci´
on en PPE
El siguiente paso en el desarrollo consiste en identificar las zonas donde existe alto paralelismo e implementarlas utilizando computaci´on vectorial AltiVec en PPE. Para facilitar el paso a un esquema vectorial, el modelo de representaci´on de las part´ıculas en memoria ha sido alterado para acomodarse a un enfoque de estructura de arrays, mediante tres arrays de vectores de enteros cortos con tres clasificaciones distintas (dos para las componentes x e y de la posici´on y uno para el peso).
De las distintas partes que componen el algoritmo, para el proceso de optimizaci´on mediante vectores se pueden descartar varias de manera inmediata:
La herramienta de obtenci´on de im´agenes a partir de una secuencia no ofrece posibil-idad alguna de optimizaci´on al tratarse de operaciones de entrada/salida. En cuanto al interfaz con c´amara web, est´a integrado en OpenCV y tampoco deja lugar para modificaciones.
El sistema de ventanas para mostrar los resultados est´a incluido en OpenCV y se encuentra en la misma situaci´on que el sistema de captura por webcam.
En cuanto a la inicializaci´on de las part´ıculas, no existe una manera sencilla de generar un vector con elementos aleatorios mediante un n´umero reducido de in-strucciones SIMD, y a su vez asegurar que las coordenadas generadas se encuentran dentro del rango de la imagen.
Tras descartar estos componentes, las ´unicas operaciones candidatas son los propios pasos del filtro de part´ıculas.
Evaluaci´on
La suma de los valores en la regi´on de inter´es es una tarea atractiva para un esque-ma de computaci´on vectorial, pero como contrapartida se observa que existen funciones en OpenCV que permiten realizar este mismo trabajo, estando aceleradas por CvCell. Finalmente se decidi´o no optimizar el m´etodo asociado, limit´andose las modificaciones producidas al cambio en la representaci´on de las part´ıculas.
Estimaci´on
Las posibilidades de vectorizaci´on para este paso tambi´en son escasas: el algoritmo tiene que consultar todos y cada uno de los elementos de manera individual para buscar el m´aximo, pero las funciones vectoriales se limitan a operaciones aritm´eticas en paralelo, y no existe ninguna que permita extraer el valor m´aximo de un vector de manera autom´atica. Debido a ello, esta funci´on se descart´o como objetivo de la optimizaci´on en esta etapa, y de nuevo sus modificaciones se deben exclusivamente al cambio en la representaci´on de las part´ıculas al esquema vectorial.
Selecci´on
Figura 3.8: Funcionamiento del m´etodo de torneo
La Figura 3.8 muestra un esquema del funcionamiento del torneo: conociendo la posici´on (x,y) y el peso de la mejor part´ıcula, se genera un conjunto de n´umeros aleatorios entre cero y dicho peso, de longitud igual al n´umero de part´ıculas. A continuaci´on, se comparan los valores generados con los pesos reales de las part´ıculas. Si una part´ıcula tiene un peso inferior a su n´umero aleatorio opuesto, se insertar´a una copia de la part´ıcula con mayor peso en su lugar en el nuevo conjunto hijo; en caso de que sea mayor o igual, la part´ıcula sobrevive y es replicada. Se ha demostrado que este m´etodo es capaz de propagar las mejores part´ıculas durante la ejecuci´on del algoritmo, manteniendo cierta variedad en el conjunto.
Difusi´on
Ya que la selecci´on ha sido modificada, es tambi´en necesario modificar el m´etodo de difusi´on de las part´ıculas. Este paso es f´acil de paralelizar, ya que consiste en simples op-eraciones aritm´eticas con los vectores de coordenadas. Para ello, a partir de un valor ruido modificable en tiempo de compilaci´on se generan varios vectores con n´umeros aleatorios
∈ [−ruido, ruido], y utilizando operaciones vectoriales se suman a los vectores de
De manera similar a la versi´on b´asica y por conveniencia, selecci´on y difusi´on se unen en un ´unico m´etodo.
3.2.3.
Filtro de part´ıculas utilizando los SPEs
Esta tercera versi´on del filtro de part´ıculas trae consigo numerosos cambios, fruto de la necesidad de dividir el trabajo y de las limitaciones del sistema. De manera similar a la versi´on vectorizada en PPE, los sistemas de entrada/salida contin´uan sin cambios.
Inicializaci´on
Antes de poder utilizar cualquier m´etodo que utilice los SPEs, es necesaria la inicia-lizaci´on de los hilos de ejecuci´on para los SPEs y de ciertos par´ametros adicionales. Por una cuesti´on de simplicidad, este paso se ha unido en un mismo m´etodo junto con la inicializaci´on de las part´ıculas, que en esta etapa se realiza en el PPE de manera similar a como se realizaba en la versi´on inicial. Es posible modificar el n´umero de SPEs a utilizar mediante una macro de compilaci´on.
Segmentaci´on
En esta versi´on surge un importante problema en la etapa de segmentaci´on asociado con CvCell. Este plugin genera para su funcionamiento seis hilos de ejecuci´on que corren los programas de cada uno de los SPEs. Aunque la intenci´on inicial del proyecto fue llegada esta etapa del desarrollo, integrar la funcionalidad del filtro de part´ıculas dentro de CvCell y utilizar la segmentaci´on que este ofrece, la escasa documentaci´on disponible imposibilit´o dicha tarea.
Al no ser posible manipular los hilos de CvCell, para generar c´odigo que utilice los SPEs es necesaria la creaci´on de hilos propios adicionales. Como se mencion´o al describir la arquitectura, los cambios de contexto son altamente perjudiciales para el rendimiento de las aplicaciones en SPE, y es este exceso de hilos el que provoca el problema, generando un rendimiento muy pobre.
Figura 3.9: Divisi´on del trabajo en los filtros de segmentaci´on adaptados a los SPEs
A cada SPE le corresponde el tratamiento de un segmento continuo de la imagen, compuesto por un n´umero de l´ıneas igual a la altura de ´esta dividida entre el n´umero de SPEs. Ya que durante la etapa de vectorizaci´on el filtro a´un utilizaba CvCell, se ha adoptado un esquema vectorial desde el inicio de la implementaci´on. Para ello, cada uno de los filtros divide el segmento de trabajo en l´ıneas y trabaja una a una, subdividi´endolas a su vez en vectores de 16 elementos que se computan de manera simult´anea mediante operaciones SIMD.
Comunicaci´on y paso de par´ametros
El PPE mantiene un ´area en memoria principal de tama˜no fijo para cada SPE, de la que ellos poseen la direcci´on. Este ´area est´a destinada a almacenar los par´ametros de las funciones que los SPEs necesitan para ejecutarlo, como punteros de memoria, datos de ancho/alto de la imagen, etc. Mediante la definici´on de uniones de C, en ella pueden almacenarse varios tipos de datos seg´un se necesite.
El c´odigo de los SPEs est´a dise˜nado de forma similar a como funciona el plugin CvCell: Justo tras ser lanzado, cada SPE pasa a la ejecuci´on de un m´etodo de dispatch que espera indefinidamente a que llegue un mensaje con la funci´on a ejecutar en su buz´on de entrada de mensajes. Cuando al c´odigo de PPE se le solicita una de las funciones descargadas en los SPEs, este primero actualiza los par´ametros en el ´area de memoria destinada a ello, tras lo cual env´ıa un mensaje al buz´on de entrada de cada uno de los SPEs con un c´odigo ´unico asociado a la funci´on que necesita ejecutar. Tras enviar el mensaje, espera que todos ellos le respondan leyendo de su buz´on de salida de manera bloqueante.
Cuando dispone de los datos, comienza su ejecuci´on y al finalizar, primero deposita en memoria principal los resultados, tras lo cual escribe un mensaje hacia el PPE mediante su buz´on de salida. Una vez le´ıdo, vuelve al dispatcher hasta la siguiente solicitud.
Restricciones en los par´ametros de entrada
En esta versi´on, se ha de tener especial cuidado con los requisitos que imponen las transferencias DMA y las unidades vectoriales a los datos del programa. Por ello, se establecido ciertas restricciones respecto a la versi´on simple:
Las im´agenes que se deseen tratar con los filtros optimizados han de tener una altura m´ultiplo del n´umero de SPEs a utilizar, y una anchura m´ultiplo de 16.
El n´umero de part´ıculas por cada uno de los SPEs ha de ser m´ultiplo de 16. En esta versi´on, con la opci´on de l´ınea de comandos asociada no se declara el total de part´ıculas, sino solamente el n´umero de part´ıculas a usar por cada SPE.
El rango del ´area de inter´es ha de ser un m´ultiplo de 8.
Distribuci´on del conjunto de part´ıculas
En cuanto a los pasos del filtro de seguimiento, la distribuci´on del trabajo se efect´ua por n´umero de part´ıculas seleccionado como muestra la Figura 3.10. El PPE tiene visibilidad sobre todo el conjunto de part´ıculas, mientras que a la hora de trabajar con los SPEs, env´ıa una porci´on a cada uno de ellos. Cuando estos terminan, depositan los resultados (el peso de las part´ıculas en la evaluaci´on y el conjunto hijo en la regeneraci´on/difusi´on) en memoria principal para que el PPE contin´ue con todos los datos actualizados.
Todos los pasos del algoritmo del filtro de part´ıculas han sido adaptados a los SPEs excepto la estimaci´on, que sigue ejecut´andose en el PPE ya que es dependiente del conjunto total de part´ıculas para buscar tanto la de mayor peso como la media de todas ellas.
Evaluaci´on
La evaluaci´on necesita que el SPE obtenga dos tipos de datos de memoria principal: las coordenadas de las part´ıculas y, para cada una de ellas, el ´area de inter´es del fotograma. Pero ahora las limitaciones de los par´ametros de las transferencias DMA incorporan un nuevo problema: si la direcci´on de memoria en la que reside el ´area de inter´es no est´a ali-neada, el SPE tendr´a que transferir informaci´on extra para poder alinearla de manera local. El proceso se muestra en la Figura 3.11 y se explica a continuaci´on.
Figura 3.11: Esquema de alineamiento del ´area de inter´es en un SPE
1. Sabiendo la direcci´on inicial del fotograma en memoria principal y las coordenadas de la part´ıcula a evaluar (par´ametros que env´ıa el PPE), se puede calcular la di-recci´on de memoria del p´ıxel donde comienza el ´area de inter´es (esquina superior izquierda, en el ejemplo 0xFFFF000D).
2. A continuaci´on, el SPE calcula la direcci´on alineada anterior m´as cercana igualando a 0 los ´ultimos cuatro bits de la direcci´on donde comienza la regi´on de inter´es (en el ejemplo, 0xFFFF0000).
3. El SPE solicita una transferencia a partir de la direcci´on alineada que se acaba de calcular, de tama˜no igual al ancho del ´area de inter´es en bytes 3 m´as 16.
4. Se repite el proceso para cada una de las l´ıneas que compone el ´area de inter´es, hasta completar la transferencia de toda la regi´on y los bordes laterales (en el
3Se est´a trabajando con im´agenes en escala de grises tras la segmentaci´on, por lo que un p´ıxel se
