CoProcesadores para las GPU

Con la misma idea inicial que nacieron las tarjetas gráficas se llega a plantear añadir procesadores auxiliares que trabajen con nuestras GPU. Estos procesadores llevarán a cabo tareas más específicas y resolverlas por hardware en vez de dejar el peso en la programación. Actualmente las GPU están enfocadas a un uso más genérico como unidades de altos rendimientos de calculo en vez de la inicial idea de gráficos simplemente. Por ello se vuelve a pensar en coprocesadores más centrados en gráficos que las ayuden.
Como ejemplo de estos coprocesadores vamos a ver la Unidad de Procesamiento de Física o PPU: PHYSX. En particular, yo conocí la existencia de este coprocesador por noticias de varios videojuegos desarrollados con esa base (Batman: Arkham Asylum). Este coprocesador está diseñado por Nvidia y permite realizar calculos físicos de en entornos 3D de videojuegos. Este coprocesador hace aparición a partir de la serie 8 de tarjetas, además la compañía provee de un kit de desarrollo específico para el coprocesador.
A continuación una demo sobre líquidos y partículas representadas con el coprocesador:

Analizando análisis: Tom Hardware

Los análisis y comparativas de tarjetas gráficas son muy abundantes en los foros de videojuegos. Pero tal y como hemos visto en clase la mayoría de comparaciones son realizadas sobre medidas poco correctas, como el numero de teraflots o la memoria de cada tarjeta gráfica.
En clase estuvimos analizando este tipo de medidas y una de las páginas que vimos fue Tom´s Hardware. Así que quise informarme a través de esta página de análisis de GPUs actuales y no tan actuales. En esta página web encontré un un articulo bastante interesante (y creo que completo) sobre distintas tarjetas gráficas: Resumen del cuarto trimestre de 2009
En este artículo veíamos una comparativa de las gráficas de alto rendimiento del mercado. Está enfocado concretamente al rendimiento de juegos actuales pero no deja atrás el análisis de la tarjeta gráfica por parte de dos Bechmark (3dMark, por ejemplo)...eso si, ambos están enfocados a gráficos de juegos.
Cada análisis deja claro varios datos que son importantes a la hora de realizar el análisis de rendimiento, como la resolución con la que se va a trabajar. Estos detalles son clave en el fondo, ya que podemos ver si el rendimientos varía por las distintas configuraciones con las que trabajemos o por la tarjeta gráfica con que trabajemos en sí.
Algo que me ha llamado la antención de los análisis es que prueban muchos juegos, indican la configuración con la que los prueban y cosas por el estilo, pero no hablan del PC que se utiliza. El resto de componentes del PC también son importantes al evaluar el rendimiento de las tarjetas gráficas, pueden darse cuellos de botella en el Bus, por ejemplo. Imagino que los PCs utilizados serán de prácticamente iguales, pero cuando nosotros hagamos algún análisis de rendimiento deberíamos tenerlo en cuenta (fallo por mi parte en la evaluación que llevé a cabo en el Tema 1).
Por último resaltar que la medida que nos muestran de rendimiento es el número de frames por segundo (FPS). Como vimos en clase esta medida de rendimiento es bastante orientativa si tenemos en cuenta todos los demás aspectos del PC que estamos evaluando. Así que como conclusión, creo que la próxima vez que tenga que comprarme una tarjeta gráfica buscare información en esta página web.

Modelos de programación para el Cell

El Cell es un procesador muy potente y lo que es más importante, aunque lo tengamos en nuestras PS3, es un procesador de propósito general. Actualmente se está intentando sacar partido del Cell no solo en consola sino en investigaciones científicas. Por eso cuando debamos ponernos a programar en este tipo de máquina debemos pensar en que modelo de programación queremos seguir. A contiuación doy unos ejemplos.

1. Programación Secuencial.- O también podemos llamarlo "como desaprovechar el multinucleo". Con este modelo (el de toda la vida) vamos realizando las tareas paso a paso y no indicamos a los distintos procesadores como deben repartirse las tareas, por lo tanto, no se la reparten.
2. Modelo de programación de Dispositivos.- Este modelo consiste en tratar los distintos núcleos como dispositivos. Es parecido al modelo que se utiliza en los PC al programar aplicaciones en las que la CPU manda tareas a (por ejemplo) la tarjeta gráfica del PC. El procesador central (PPE) se dedicará a mandar tareas específicas a los SPE.
3. Modelo de Streaming.- Básicamente, creamos un pipeline o cauce de ejecución con los distintos SPE, con esto conseguimos que tareas complejas se dividan en tareas simples y se puedan ejecutar en paralelo. Para hacernos una idea, es parecido a la filosofia de dividir las instrucciones del procesador en etapas simples y solapar la ejecución de las etapas en un mismo momento.
4. Modelo de memoria compartida.- Este modelo se basa en que los SPE se encarguen de la misma tarea pero para muchos datos al mismo tiempo. Nuestra aplicación tendría un hilo de ejecución central por así decirlo, y en distintas partes del código tendríamos zonas en las que una misma tarea se reparte en distintos hilos para ejecutarse más rápidamente. Imaginaos un tabla muy grande que debemos procesar, pues llegada la zona en la que dividimos en hilos, cada dato de la tabla (o grupo de datos) se ejecuta por separado en distintos núcleos y se unifica el resultado después.

Estos solo son unos cuantos de los modelos que podemos utilizar. Evidentemente no son modelos exclusivos de la PS3, si os fijáis pueden ser utilizados para cualquier arquitectura multinucleo en la que queramos programar.

Versus: Cell contra Xenon

Existen millones de foros con hilos de comparativas entre Xbox 360 y PS3, con la única base de como se ve un juego en una consola u otra, o de el número de núcleos o TFlops que pueden ejecutar. Aquí voy a intentar hacer una comparativa un poco distinto,vamos a comparar las arquitecturas y veremos cual nos parece "mejor".
En la entrada anterior me dediqué a analizar la CPU de la Xbox 360 haciendo referencia a mejoras de rendimiento. Ahora voy a analizar un poco el Cell y comparando paso a paso con el Xenon.
El Cell es un procesador multicore formado por 1 PPE y 8 SPE. El PPE es un procesador al estilo de los 3 que tiene el Xenon, Power PC de intel con 23 etapas por instrucción y a 3,2 Ghz. Al igual que los del Xenon no permiten ejecución fuera de orden pero si multithreading. La única gran diferencia que encontramos es que el PPE del Cell, además de incorporar cache de nivel 1 tiene su propia cache de 512 KB de nivel 2.


Los SPE son la gran diferencia de la CPU. Nos encontramos con 8 núcleos que trabajan a la misma frecuencia que el PPE y que tampoco permiten ejecución fuera de orden pero si multihilo. ¿Entonces en que lo diferenciamos? Pues en que los SPE, no tienen memoria cache de ningún tipo, utilizan almacenamiento local de 256 KB. Esto parece un desperdicio de procesador, pero la filosofía de la arquitectura se pueden aprovechar. Los SPE están conectados a un Bus de muy altas prestaciones llamado EIB que permite la comunicación entre ellos y además cada SPE puede acceder a los registros locales de otros SPE, intentan explotar que los SPE trabajen con el mayor paralelismo posible. Estos procesadores no son tan complejos como los del Xenon, pero son más y trabajan casi del mismo modo.
Resumiendo un poco las ideas, parece que el Cell es mejor, pero todo tiene un pero. Es cierto que el Cell es más complejo y puede llevar a cabo tareas con más paralelismo que el Xenon, pero tiene la misma pega pero con mayor complejidad, no resuelve problemas de eficiencia por hardware, dejando mucha responsabilidad a los programadores o compiladores. Esto en la Xbox 360 es notable, pero en la PS3 es mucho mayor el problema. Ninguna de las CPU están siendo programadas como es debido, ya que no es fácil pero en una destaca más que en otra, por eso se ven juegos en PS3 de la misma calidad que en Xbox 360, se realizan de forma genérica sin centrarse en la arquitectura y sin sacar el rendimiento debidamente.

PD: Casi todas las conclusiones son opinión propia.

Xenon Xbox 360, al detalle

Vamos a comenzar por dar un vistazo en general al Xenon. Según las especificaciones tiene tres núcleos PowerPC de 21 etapas de segmentación, cada núcleo permite hyperthreading y trabaja a 3.2 GHz. Dicho así suena muy impresionante, pero vamos a mirarlo más de cerca.
Tanta frecuencia de reloj parece un poco abrumadora, pero si tenemos en cuenta que en cada ciclo se ejecuta una etapa de una instrucción cualquiera, y que una instrucción se divide en 21 etapas, ya veis que la velocidad de ejecución por instrucción es menor (y mejor medida de rendimiento) que la frecuencia de reloj. Pero de cara al mercado es mucho mejor decir que la CPU corre a 3.2 GHz, cosas del marketing.
Ahora vamos a meternos en la manera de trabajar del Xenon. AL contrario que otras CPU de proposito general, la Xenon no puede trabajar con ejecución fuera de orden con las instrucciones, pero si tiene la ventaja del multithreading. Esto nos permitirá ejecutar por ejemplo en cada núcleo un par de hilos de ejecución y teniendo en cuenta sus 3 núcleos, en la teoría podríamos ejecutar 6 hilos al mismo tiempo. Esto nos da un rendimiento bastante bueno al fin y al cabo, pero la arquitectura tiene un pega, esta filosofía es un problema para el desarrollo de software eficiente en la consola.
Cambiemos de ámbito a analizar de la consola, la jerarquía de memoria y el acceso a ella es otro ámbito que merece la pena mencionar. La arquitectura tiene dos niveles de memoria cache, que nos da una mejora de rendimiento respecto a 1 solo nivel o el acceso a memoria principal directamente. Cada procesador tiene su propia cache de primer nivel de 64, dividida en dos (instrucciones/datos) para evitar fallos de acceso. En cambio el nivel 2 de memoria cache es compartida entre todos los procesadores, y la mayoría de veces utilizado únicamente como simple buffer de almacenamiento.
Toda esta arquitectura nos da un máquina con eficiente, centrada en el multithreading y parecida a las de propósito general, pero con mucha carga de eficiencia de rendimiento que deben solucionar los programadores.