PDF de programación - OpenCL

OpenCL

Rubén Akagi

[email protected]

Universidad Católica - Nuestra Señora de la Asunción

Abstract. Una breve introducción al OpenCL framework. Analiza la es-
tructura interna de la plataforma, las memorias, los procesos. El lenguaje
OpenCL junto con algunos aspectos interesantes. Los ambientes de eje-
cución y las herramientas de desarrollo. También compara las competen-
cias actuales en el área de GPGPU con sus ventajas y desventajas.

Key words: OpenCL, GPGPU

1

Introducción

En los últimos tiempos, las unidades de procesamiento gráfico han evolucionado
de forma sorprendente, ya sea por su capacidad de procesamiento o las variadas
funcionalidades que ofrecen al programador con sus sets de instrucciones, así
como el aumento en la presición numérica. Este avance ha encaminado necesari-
amente a la idea de aprovechar su potencial computacional para realizar cálculos
no necesariamente gráficos. Pero los APIs tradicionales para manejar los gráficos
no eran aptos para programar computación de propósito general.

1.1 GPGPU

Así surge la técnica llamada GPGPU, o General-Purpose computation on Graph-
ics Processing Units por su sigla en en inglés. Consiste en utilizar la capacidad
de las Unidades de Procesamiento Gráfico para asignar tareas que normalmente
son procesadas por la CPU. [2]

Las grandes empresas como Nvidia, AMD, ATI, y últimamente Microsoft,
han echo el esfuerzo de explotar esta capacidad desaprovechada lanzando al
mercado sus propias versiones que se analizaran a continuación.

1.2 CUDA

Sigla en inglés de Compute Unified Device Architecture, fué desarrollado por
Nvidia. Utiliza un lenguaje parecido a C llamado C for Cuda. Tiene soporte total
para punteros, funcionalidades de C++ como el templating, muchas librerías que
tienen aceleración por excelencia sobre GPU, buenas herramientas de desarrollo,
bien documentadas llenos de ejemplos disponiles. Son signos de la madurez que
ha alcanzado estando un tiempo considerable en el mercado, aunque tiene la
gran desventaja de que se ejecuta solamente sobre GPU de Nvidia.

2

Rubén Akagi [email protected]

1.3 DirectCompute

Es la respuesta de Microsoft frente al surgimiento de las GPGPU. Están inclu-
idas en los últimos dos DirectX, la10 y la 11. Mantiene la sintaxis del lenguaje
HLSL (High Level Shading Language), así que los programadores de DirectX
pueden aprender con mayor facilidad. Lo malo es que DirectX está disponible
solamente para windows 7 y Vista. También es muy notable la falta de ejemplos
y documentaciones, así como una muy pequeña cantidad de bindings disponibles.

2

¿Qué es OpenCL?

Los sistemas actuales tienen una amplia variedad de dispositivos, desde los tradi-
cionales CPU hasta los GPU, procesadores Cell, DSP, FPGA y otros. Cada uno
tienen diferentes capacidades de procesamientos y niveles de paralelismo. Desar-
rollar softwares eficientes capaces de aprovechar estos recursos siempre ha sido
un reto para los programadores. [4]

OpenCL, un framework multiplataforma libre y abierto mantenido por Khronos

Group un consorcio sin fines de lucro, ha tratado de resolver este problema pro-
porcionando una interfaz estándar de programación.

Las unidades de procesamiento actuales vienen en varios núcleos, ya que la
velocidad del clock individual ha sentido el límite teórico. En especial las GPUs,
que están diseñadas para realizar calculos vectoriales de espacios dimensionales,
tienen capacidades de procesamiento paralelo enorme para manejar estas opera-
ciones de forma efectiva.

OpenCL aprovecha de estas capacidades de procesamiento en paralelo que
ofrecen cada dispositivo, con un lenguaje de programación propia basado en C99
que permite realizar paralelismo de taeas o de datos, aumentando drásticamente
la capacidad total de procesamiento, especialmente de las aplicaciones computa-
cionalmente intensas. [11]

3

¿Cómo funciona el OpenCL?

3.1 Modelo de pataforma

El ambiente de ejecución o la platafora sobre la cual corren los programas en
OpenCL, como vemos en la figura 1, consta de varios dispositivos. Cada dis-
positivo, por ejemplo las CPUs o las GPUs, pueden tener varias unidades de
cómputo o núcleos. [11][3]

Cada una de las unidades de pocesamiento pueden tener varias unidades de

cómputo que son ejecutadas como SIMD o SPMD.

El host, normalmente la CPU, es el que administra el comportameinto global

de la plataforma.

OpenCL

3

Fig. 1. Modelo de plataforma.

3.2 Modelo de ejecución

Los programas en OpenCL están formados por kernels, que son unidades básicas
de código paralelamente ejecutable.

Cuando se ejecuta un programa, el host va instanciando los kernels necesarios

y agregada en las colas de espera de distintos dispositivos. [11]

3.3 Los work-items y los workgroups

En OpenCL se puede definir un dominio computacional de 1, 2 o 3 dimensiones.
Cada elemento del dominio se llama work-item, y representa a una unidad de
procesamiento capaz de ejecutar un kernel a la vez. Dicho de otra forma, las
dimensiones del dominio define la cantidad de work-tems que se va a ejecutar en
paralelo.[11][3]

Por ejemplo, sea un programa que necesite sumar dos vectores a y b de

tamaño n. La forma tradicional de programación escalar sería:

void
scalar_sum(int n,

const float *a,
const float *b,
float *result){

int i;
for (i=0; i<n; i++) result[i] = a[i] + b[i];

}

Pero utilizando OpenCL, se define un dominio de una sola dimensión de
longitud n, que contiene n work-items. Luego se ejecuta el siguiente kernel en
cada uno de los work-items en forma paralela.

kernel void
dp_sum(globalconst float *a,
globalconst float *b,
globalfloat *result){

int id = get_global_id(0);

Rubén Akagi [email protected]

result[id] = a[id] + b[id];

4

}

Los work-items se pueden agrupar para formar un workgroup. Todos los
work-items que conforman un workgroup se ejecutan en un mismo dispositivo.
Así pueden compartir la memoria local o realizar sincronizaciones entre los work-
items. (o entre los kernels que se ejecutan en cada work-item)[4]

Fig. 2. Los work-items y los workgroups.

La figura 2 muestra en un espacio global computacional de dos dimensiones
de 1024x1024 que contiene a 64 workspaces también de dos dimensiones de
128x128, o sea 64x128x128 work-items en total. Los work-items rojos no pueden
sincronizar entre sí por estar en workgroups distintos pero sí los work-items
verdes.[11]

3.4 Modelo de memoria

Como vemos en la figura 3, las memorias dentro de la plataforma están or-
ganizadas en forma jerárquica. Esta jerarquía es una abstracción que ofrece el
framework, y no necesariamente está físicamente organizado de esta forma.[4]

La memoria privada es exlusivo para cada work-item y sirve para almacenar

informaciones necesarias para ejecutar un kernel.

La memoria local es compartida por los work-items dentro del workgroup así

como la memoria global es compartida entre los workgroups. [11]

3.5 Uniendo todos

La ejecución del programa se inicia con la compilación de los kernels que los
componen. Se compilan de diferente manera para cada dispositivo, ya que tienen

OpenCL

5

Fig. 3. Modelo de memoria.

Fig. 4. Uniendo todos.

6

Rubén Akagi [email protected]

diferentes sets de instrucciones, pudiendo especificar cuál kernel ejecutar sobre
cual dispositivo. Cuando se terima la compilación, OpenCL realiza el chequeo
de la compilación para ver si no hubo algún error en el proceso.

Después viene la fase de creación de las estructuras de memorias que se van a
consumir, y luego la asignación de los parametros a las instancias de los kernels.
Finalmente, cuando los kernels están listos para ser ejecutados, son enviados
a las colas de espera de los dispositivos para su posterior ejecución. Es posible
especificar la manera en que se va a atender las colas de los dispositivos. Los
In-Order son como los CPU clásicos en donde otras istrucciones esperan hasta
terminar por completo una instrucción. Los Out-Order en cambio, son cuando
las instrucciones no se ejecutan en realidad en el orden real, por ejemplo para
realizar pipeline cuando una instrucción tarda más de un clock.

4 CPU vs GPGPU

Con la generalización de las GPU, se han creado una rivalidad hasta ahora
inexistente entre las empresas de CPU y las de GPGPU. Cada una realiza y
publica métricas con resultados diferentes.

Pero dependiendo de los problemas a resolver, se han observado en una can-
tidad de universidades e institutos de renombre, resultados realmente asombroso
a favor de GPGPU como se puede observar en la figura 5.

5

¿Por qué utilizar OpenCL?

OpenCL, como los otros frameworks de GPGPU, permite aprovechar el enorme
poder computacional paralelo, mejorando drásticamente el rendimiento de los
programas computacionalmente intensas.

Pero a diferencia del resto, es el primero en ser abierto y gratuito. Permite
escribir códigos que pueden correr en multiples plataformas despreocupandonos
de muchos aspectos del hardware. [9] La compilación se realiza en tiempo de
ejecución mediante el API, permitiendo la oportunidad de optimizar para ciertos
tipos de dispositivos. [4]

6 Desventajas de OpenCL

OpenCL tiene dos grandes desventajas.

Primero, como trata de crear una interfaz uniforme para distintos dispositivos
con sus respectivas ventajas y desventajas, inevitablemente es simpre menos
eficiente que los frameworks diseñados específicamente para ciertos dispositivos.
Segundo, es un framework joven. No tiene la maduración suficiente com-
parado con otros frameworks, que han estado ya un buen tiempo en el mercado.
Necesita acumular experiencias, funtes de información y una buena cantidad de
ejemplos documentados, desarrollar buenas herramientas de desarrollo, y como
todos los frameworks, una buena calidad y cantidad de librerías.

OpenCL

7

Fig. 5. GPGPU vs CPU.

8

Rubén Akagi [email protected]

7 OpenCLTM C Language

7.1 Características

Es un lenguaje que trae consigo el framework. Está bas