| Artículos | 01 MAR 2007

GPGPU

Tags: Histórico
Uso de las GPU modernas para cálculos no gráficos
Eugenio Barahona.
El pasado mes de diciembre analizamos la última extensión que Intel ha desarrollado para el juego de instrucciones x86, la cual se denomina SSE4. Una de las principales características de casi todas las extensiones que han aparecido para la arquitectura x86 consiste en que una misma instrucción se ejecuta simultáneamente sobre varios elementos de datos. Dicha característica puede implementarse bajo la premisa de que el software va a tratar al mismo tiempo uno o más streams que contienen información del mismo tipo, como por ejemplo varios canales de sonido. En el caso de los procesadores, su arquitectura se define teniendo en cuenta que van a ejecutar aplicaciones de los más diversos propósitos, por lo que no es posible optimizar su diseño para la ejecución de una tarea concreta.
Lo curioso es que, a día de hoy, existe en casi todos los PC de sobremesa y estaciones de trabajo, un componente que desde su concepción está pensado para ejecutar cálculos en coma flotante sobre varios elementos de datos simultáneamente: se trata de la GPU de que disponen un gran número de tarjetas gráficas actuales. Desde hace ya algunos años, existen en el mercado procesadores gráficos programables que están optimizados para realizar cálculos sobre varios elementos de datos al mismo tiempo, por lo que sólo era cuestión de tiempo que apareciesen en el mercado los elementos necesarios para poder utilizar esa potencia de cálculo para aplicaciones que nada tienen que ver con la generación de gráficos tridimensionales en tiempo real.

Diferentes entornos de programación
Las diferentes API que existen para explotar las GPU modernas en su aspecto gráfico, están diseñadas para que las aplicaciones accedan a las funciones del hardware a través de un controlador de dispositivo, cuyo funcionamiento suele estar diseñado para ocultar al programador el verdadero funcionamiento interno del hardware. Además, dicho controlador impone al desarrollador de software una serie de restricciones en cuanto a cómo, cuándo y dónde residen los datos que va a gestionar su aplicación. Por otra parte, las respuestas a las anteriores cuestiones se elaboran teniendo en cuenta que el producto final está optimizado para generar gráficos. Quien desee realizar aplicaciones no gráficas que usen una GPU, también deben tener en cuenta que las actualizaciones de los controladores pueden hacer que varíe mucho el rendimiento que obtiene del hardware su aplicación.
Un entorno de programación de propósito más amplio que el meramente gráfico, debería revelar al programador las partes del hardware gráfico que sean de interés tal y como realmente son, mientras que oculte aquellas que sólo resultan de interés en el terreno de la generación de gráficos 3D. También sería deseable que se proporcionase un método de comunicación directa entre la aplicación y el dispositivo hardware, eliminando así la mediación que hasta ahora venía realizando el controlador de dispositivo, lo que podría dar lugar a una optimización del rendimiento de las aplicaciones al eliminarse una capa de software.

Programar la GPU
La manera convencional de programar un procesador gráfico es a través de una API gráfica, siendo DirectX y OpenGL las dos que más se utilizan actualmente. Una característica importante de cualquier aplicación que se desarrolle es su portabilidad, es decir, la posibilidad de ejecutar dicha aplicación, de manera sencilla, sobre una arquitectura hardware distinta de la utilizada para su desarrollo. El caso más óptimo suele requerir una recompilación del código fuente de la aplicación para que sea posible ejecutarla sobre una nueva plataforma hardware. La portabilidad también es importante a la hora de desarrollar software que aproveche los recursos de los procesadores gráficos, ya que cada fabricante de hardware suele crear un micro código propio que es el que realmente se ejecuta en el interior de la GPU.
En caso del hardware gráfico, la portabilidad se ha implementado mediante el desarrollo de lenguajes de alto nivel, orientados a la programación gráfica, como por ejemplo el lenguaje HLSL (High Level Shader Language) de Microsoft, Cg de nVIDIA y GLslang como lenguaje fuertemente vinculado a la API OpenGL. En estos tres casos se trata de lenguajes que están inspirados en el lenguaje C, por lo que su aprendizaje resulta relativamente sencillo para los programadores conocedores de C y C++. Por otro lado, los controladores de dispositivo del hardware gráfico disponen de compilador embebido que traduce el programa escrito en uno de los lenguajes anteriores al micro código nativo del hardware que se va a encargar de ejecutarlo.
Sin embargo, estos lenguajes están muy orientados hacia el trabajo gráfico, por lo que no ayudan al programador a gestionar funcionalidades que la API gráfica trata de forma, más o menos transparente para el programador, pero que al ejecutar algoritmos que no sean gráficos, deben estar bajo el control directo del desarrollador. Por lo tanto, el uso de estas API requiere del programador un conocimiento profundo de la programación gráfica, así como de las características y limitaciones del hardware gráfico con el que esté trabajando.
Por lo tanto, uno de los aspectos en los que más se está trabajando es en el desarrollo de API y lenguajes de programación que hacen posible usar la potencia del hardware gráfico actual, sin que por ello el desarrollador deba ser un experto en programación gráfica. Además, estas iniciativas requieren también la cooperación de las empresas que desarrollan las GPU, ya que es necesario implementar nuevas interfaces en los drivers que gestionan dicho hardware, para que las aplicaciones que se desarrollen usando los nuevos lenguajes y API que se creen, accedan al hardware de una forma lo más independiente posible de las peculiaridades concretas de cada modelo de GPU.

La solución de AMD
Desde el año pasado, la actual división de gráficos y multimedia de AMD, lo que anteriormente se conocía como ATI Technologies, ha estado trabajando en una solución para facilitar el desarrollo de aplicaciones que no tengan carácter gráfico, pero que aprovechen los recursos de las GPU de este fabricante. La solución a la que se ha llegado consiste en implementar una máquina virtual que procesa datos de forma paralela. Esta máquina virtual,hace que el programador pueda acceder a partes del hardware del procesador gráfico que son de interés para el desarrollo de aplicaciones. Concretamente, facilita el acceso al procesador de comandos del hardware, a los arrays de procesadores y al controlador de memoria de la GPU.
El procesador de comandos abstrae la comunicación entre la aplicación y el hardware, consiguiendo que la primera sea independiente de la implementación del hardware, ya que los comandos son independientes de la arquitectura. Además, acepta los comandos presentes en un buffer que reside en la memoria del sistema, e interpreta los comandos presentes en dicho buffer. En una etapa posterior, el procesador de comandos distribuye las órdenes presentes en el buffer entre los procesadores que forman parte de la matriz de procesadores integrados en la GPU.
Un aspecto importante del diseño de esta solución, es que es la aplicación, y no el controlador de dispositivo, quien tiene la responsabilidad de gestionar los buffers de

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información