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.

Explicación al detalle de las técnicas de gestión de E/S

Un ordenador no puede funcionar si no tiene datos para poder trabajar con ellos. Estos datos no se crean de la nada, sino que tienen que alguien tiene que ponerlos en el ordenador a través de un sistema de Entrada/Salida.
Los dispositivos de E/S (teclado, ratón,…) se comunican con la CPU a través del bus del sistema. Al no estar tan optimizada la E/S como el resto de sistemas, puede llevar a la bajada de rendimiento de nuestros equipos. Para solucionar esto, se han ideado técnicas de gestión con las que realizar las tareas de E/S sin que afecte al resto del sistema.

E/S Programada.- Es tan simple como que la CPU realiza un sondeo (en bucle) sobre si los controladores del dispositivo de E/S para ver su estado, y usarlos cuando sea preciso. Este sistema está anticuado, ya que la CPU estará la mayoría de veces en espera de los dispositivos de E/S.

E/S por Interrupciones.- En vez de ser la CPU la que espere al dispositivo, será el dispositivo el que interrumpa a la CPU para avisar de la finalización de las operaciones. Entonces la CPU puede resolver que dispositivo ha lanzado la interrupción, realizar las operaciones necesarias (rutina de manejo de interrupciones) y enviar la siguiente operación al dispositivo.
Esta técnica permite a la CPU estar trabajando en otras operaciones sin dedicarle tiempo al dispositivo. Este manejo de la E/S puede parecer un mecanismo bastante bueno, pero todo depende de si hay excesiva carga de E/S, porque si se da el caso la CPU puede dedicar demasiado tiempo al manejo de estas instrucciones y llegar de nuevo a la bajada de rendimiento.

E/S por DMA (Acceso Directo a Memoria).- Tendremos un dispositivo auxiliar que controlará por sí mismo la escritura de E/S directamente en memoria, sin pasar por la CPU. La CPU sigue teniendo carga de trabajo, pero es mínima, solo se encarga de decirle a la DMA la fuente/destino de la transferencia de datos. Para poder llevar a cabo la transferencia de datos, la DMA “roba” un ciclo del bus el sistema para poder escribir en memoria. Una vez los datos estén en memoria la DMA avisa a la CPU que los datos están listos.
Esta forma de trabajar evita que la CPU tenga que estar cambiando de contextos de procesos cada vez que una operación de E/S de termine. En contra tenemos que el DMA y la CPU estarán compitiendo por el uso del bus y puede darse que la CPU trabaje a menor velocidad al final.

E/S por Procesador Dedicado.- Hoy en día el peso de las operaciones de E/S se deja sobre un co-procesador dedicado exclusivamente a ello. La CPU solo se comunica con él para comunicarle sus necesidades de los dispositivos de E/S. El procesador de E/S ejecuta código propio para controlar la operación. Además, en la actualidad, se añade cierta cantidad de memoria RAM a los dispositivos, y las transferencias se realizan sobre esta memoria.

Comparativa: PCI‐Express vs. PCI y AGP

Poniéndonos en antecedentes podemos ver como los buses PCI y AGP “competían” en la misma época. Ambos estaban presentes en numerosas tarjetas gráficas y de prestaciones equiparables, aunque cada una trabajase de cierta manera. PCI-Express es la evolución del PCI y el bus actual de las tarjetas gráficas. Pasemos a ver las características de cada uno.

PCI.- El bus PCI tiene 32 bits de comunicaciones que trabajan a una frecuencia de 33 MHz, por lo tanto la tasa de transferencias teórica es de 133 Mbits/s. Velocidad de transferencia más que suficiente para cualquier tarjeta gráfica 2D.
Evidentemente no solo hay un tipo de PCI, dependiendo de los requisitos electrónicos se pueden dividir en tres tipos.

1. PCI de 5 voltios.
2. PCI de 3.3 voltios, más usadas en ordenadores portátiles.
3. Universales, seleccionan el voltaje automáticamente y se utilizan tanto en sobremesas como en portátiles.

También existen distintas ranuras de acuerdo con los bits que se puedan transportar.

• Ranuras de 32 bits: son las normales y más extendidas.
• Ranuras de 64 bits: muy recientes, agregan 32 conectores más.

AGP.- Bus para conectar periféricos a la placa base del equipo. Los buses AGP trabajan a distintas frecuencias y voltajes, hay más diferencias entre ellas que en el caso de las PCI.

1. AGP 1X, frecuencia de 66 MHz y tasa de transferencia de 264 MB/s con un voltaje de 3,3 V.
2. AGP 2X, frecuencia de 133 MHz y tasa de transferencia de 528 MB/s con un voltaje de 3,3 V.
3. AGP 4X, frecuencia de 266 MHz y tasa de transferencia de 1 GB/s con un voltaje de 3,3 o 1,5 V, para poder adaptarse al diseño de tarjetas gráficas.
4. AGP 8X, frecuencia de 533 MHz y tasa de transferencia de 2 GB/s con un voltaje de 0,7 o 1,5 V.

PCI-Express.- Es mucho más veloz que los dos buses anteriores, convirtiéndose en el sustituto natural de los dos. Dependiendo del dispositivo existen PC-Express de distintas frecuencias de reloj. Para trabajar con dispositivos de sonido o de televisión se puede utilizar PCI-Express 1x (133Mhz). Pero en el caso de tarjetas gráficas se utiliza PCI-Express 16x de 2128Mhz. Existen más modelos (1x, 2x, 3x, 4x, 16x).
Se ha convertido en el sustituto de AGP por velocidad de transferencia y al ser la evolución del PCI se ha afianzado en el mercado.