Antes de que existieran los chips especializados en el proceso de gráficos, los pioneros en el campo de la visualización utilizaba superordenadores de multinúcleo para convertir los datos en tres dimensiones. Hoy día, sin embargo, la velocidad a la que los superordenadores son capaces de procesar los datos está tomando la delantera rápidamente a la velocidad con la que pueden entrar y salir dichos datos. Los clusters de nucleos para el proceso de gráficos se están volviendo algo obsoleto.

Unos investigadores del Laboratorio Nacional Argonne, además de en otros centros, están trabajando en una solución. En vez de trasladar cantidades masivas de datos para que sean renderizados en grupos de ordenadores especializados en el proceso de gráficos, que es la forma en que se suele hacer en la actualidad, están creando un software que permite a los miles de procesadores de los superordenadores hacer la visualización ellos mismos.

Tom Peterka y Rob Ross, científicos informáticos en el Laboratorio Nacional Argonne, y Hongfeng Yu y Kwan-Liu Ma de la Universidad de California en Davis, han creado un software para Intrepid, el superordenador Blue Gene/P de IBM, que se salta completamente el proceso de gráficos en clusters “Nos permite [visualizar experimentos] en lugares que son más cercanos a donde los datos residen—en la misma máquina,” afirma Peterka. La solución de su equipo obvia la necesidad perder tiempo llevando los datos desde donde son generados hasta un grupo de procesadores secundarios.

Los datos de las pruebas de Peterka, obtenidos a partir de John Blondin en la Universidad del Estado de Carolina del Norte y Anthony Mezzacappa del Laboratorio Nacional Oak Ridge, representan 30 pasos secuenciales en la simulación de la muerte explosiva de una estrella, y son el tipo de información a la que normalmente se enfrenta un superordenador como Argonne. Las pruebas de mayor tamaño de Peterka con los datos se maximizaron con una resolución tridimensional de 89 mil millones de voxels (pixels tridimensionales) y dieron como resultado dos imágenes bidimensionales de 4.096 pixels en un lado. Para procesar los datos se necesitaron 32.768 de los 163.840 núcleos del Intrepid. Las imágenes bidimensionales fueron generadas con un algoritmo paralelo para el proceso de volúmenes, un método clásico para crear imágenes bidimensionales a partir de una serie de datos tridimensionales.

Normalmente, la visualización y el post-procesado de datos generado por el Intrepid, el cual, con 557 teraflops es el séptimo superordenador más rápido del mundo, requiere una unidad de proceso de gráficos individual llamada Eureka. (Un teraflop es el equivalente a un billón de cálculos por segundo.) Construida a partir de las GPU (unidades de proceso gráfico) Quadro Plex S4 de NVIDIA, Eureka funciona con 111 teraflops. Los superordenadores más potentes, en el rango de los petaflops, presentan retos aún mayores.

“Cuanto más crecemos, más problemas encontramos con las velocidades de entrada/salida,” afirma Peterka. Sólo el hecho de escribir en el disco la cantidad de datos producidos por una simulación ejecutada en un superordenador de petaflops podría llevar una cantidad de tiempo totalmente irrazonable. La razón es sencilla: de una generación de superordenadores a la siguiente, la capacidad de almacenamiento y el ancho de banda no están creciendo con la misma rapidez que la velocidad de proceso.

Esta disparidad significa que los futuros centros de superordenadores simplemente no serán capaces de permitirse tener unidades de proceso gráfico por separado. “A petaescala, [las unidades de proceso gráfico por separado] son menos efectiva a nivel de costes,” señala Hank Childs, ingeniero de sistemas de ordenadores y experto en visualización en el Laboratorio Nacional Lawrence Berkeley. Childs señala que los grupos de ordenadores dedicados a la visualización, como el del superordenador Intrepid en Argonne, a menudo cuestan un millón de dólares, aunque en el futuro este coste puede que se incremente 20 veces más.

Pat McCormick, que trabaja en los procesos de visualización del superordenador más rápido del mundo, el “Correcaminos” del Laboratorio Nacional Los Alamos, hecho a partir del Optaron de AMD y el Cell de IBM, afirma que el trabajo de Peterka en la visualización directa de datos resulta crítico puesto que “estas máquinas se están haciendo tan enormes que realmente no tienes otra opción.” Los métodos de visualización existentes, basados en GPUs, continuarán siendo apropiados sólo para ciertos tipos de visualizaciones, señala McCormick.

“Si vas a consumir un superordenador entero con cálculos, no creo que tengas otra opción,” afirma McCormick. “Si estás funcionando a esa escala, tendrás que hacer el trabajo allí mismo, puesto que se tardaría una eternidad en trasladarlo todo, y ¿a qué otro lugar puedes ir para procesar tal cantidad de datos?”

“La idea detrás del procesado in-situ consiste en saltarse todos los procesos de entradas y salidas,” afirma Childs. “Nunca escribes nada en el disco. Tomas las rutinas de visualización y las vinculas directamente al código de simulación, y generas la imagen según se está procesando.”

Sin embargo, este método tiene sus problemas asociados. Por un lado, se tardaría un segundo o más en renderizar cada imagen, lo que evitaría la posibilidad de interactuar con modelos tridimensionales de forma natural. Otro problema viene dado por el hecho de que interactuar con los datos de esta forma acaba quemando ciclos en este tipo de máquinas, las más caras del mundo.

“Los superordenadores son recursos de un valor increíble,” afirma Childs. “El hecho de que alguien haga una simulación y después interactúe con los datos durante una hora—estamos hablando de un recurso muy caro como para tenerlo retenido durante una hora.”

Al tiempo que los ordenadores de sobremesa siguen los pasos de los superordenadores y las GPUs y se adentran en el mundo de los núcleos múltiples y procesado paralelo masivo, Peterka cree que podría generarse una tendencia a alejarse del tipo de procesadores especializados en funciones particulares. En la actualidad, AMD ofrece la librería de código OpenCL, que hace posible ejecutar código diseñado para una GPU en cualquier chip x86—y viceversa.

Xavier Cavin, fundador y director de Scalable Graphics, una compañía dedicada al diseño de software para las unidades de proceso gráfico de mayor tamaño utilizadas en negocios, señala que el primer algoritmo de renderizado de volúmenes paralelo se ejecutó en las CPUs de un superordenador. “Después de aquello, la gente empezó a utilizar las GPUs y los grupos de GPUs para llevar a cabo la misma función,” afirma Cavin. “Y ahora volvemos a las CPUs. El círculo está completo.”