Programando la PS3 vs XBOX360

Con la llegada de la PS3 tendremos también el estreno de un nuevo CHIP llamado CELL del que se ha hablado mucho y sobre el que los desarrolladores de juegos tendrán que poner su arte y conocimientos para sacarle el máximo partido a la consola de Sony.

Algunos ya han comentado que el CELL será un gran procesador siempre que se le pueda sacar todo el rendimiento que de él se espera, pero la pregunta está en si eso será fácil para los desarrolladores.

El CELL cuenta con 1 procesador principal (Power Processing Element o PPE) que es básicamente una variación de un Power PC 970 con una cache L1 de 32KB de Datos y 32KB de Instr., además una L2 de 512KB, todo ello a 4GHz. Junto a este PPE hay ocho módulos de procesamiento llamados Synergistic Processor Element o SPE, con toda esta artillería no es de extrañar que tenga una marca teórica de nada menos que 256 GFLOPS.

Cada uno de los SPE tendrá una memoria única de 256KB, 128 registros con una anchura de 128 bits y elementos de ejecución de 128bits, se puede decir que cada SPE es una máquina de 128bits. Con esta capacidad de procesamiento tenemos que cada SPE puede ejecutar 2 Double-Float, 4 Floats o Long integers, ocho integers... etc, cada uno en un solo ciclo de reloj. Además cada SPE contiene siete elementos de ejecución de los que solamente dos podrán estar activos a la vez.

Esta arquitectura, bastante impresionante, tiene un 'pero' y es que cada SPE solamente puede acceder a sus 256 KB de memoria y no verá nada más 'allá', para pedir una palabra fuera de esos 256 KB se debe acceder a un DMA conectado a un BUS llamado Element Interconnect Bus (EIB). Esto presenta un problema a la hora de procesar grandes cantidades de información, pues hay que optimizar el "troceado" para que no haya perdida de rendimiento.

En la PS3 no veremos títulos con más de 256 MB de texturas, debido a la política de memoria, mientras que si que los habrá en X360.

Sony ha elegido bien, sin embargo, y su consola podrá ser programada en Cg (http://developer.nvidia.com/page/cg_main.html y http://en.wikipedia.org/wiki/Cg_programming_language), C++ y la API de gráficos será OpenGL|ES (http://www.khronos.org/opengles/), esta librería es un estándar con la que muchos desarrolladores están acostumbrados a trabajar, no solo en el mundo de los videojuegos sino también en CAD/CAM y otros. Además, es conocido que la curva de aprendizaje de OpenGL es muy buena y aumenta las posibilidades de encontrar buenos desarrolladores y los estudios podrán contratar a gente nueva para los desarrollos en PS3. En cuanto a Cg es una excelente elección por la facilidad de uso que tiene para los desarrolladores en cuanto a gestión de objetos gráficos, con una gran potencia, yo personalmente no he programado con Cg, pero después de haber visto algunos ejemplos y haber leído un poco, desde luego que tengo ganas de probar un poco :d...

El aspecto más duro al que sin duda se enfrentarán los desarrolladores en la PS3 no será hacer juegos, sino hacer juegos buenos y rápidos. Y no es que esto sea fácil para las demás, el problema es que esto será más difícil en la PS3.

Con el esquema del procesador que ya hemos comentado tenemos básicamente ocho elementos de ejecución más o menos independientes, que se deben usar organizadamente para poder sacarle el máximo rendimiento.

Uno de los aspectos más complejos en cualquier sistema software que se desarrolle es el hecho de la concurrencia, hacer que varios hilos de ejecución se coordinen para un objetivo común es un problema bastante complejo de afrontar.

El desarrollo de un juego con varios hilos de ejecución es el nuevo reto de los estudios de desarrollo, los procesadores de las nuevas consolas tienen varios CORES de ejecución (XBOX360 cuenta con 3 procesadores en uno, PS3 cuenta con 8 elementos de ejecución, un PC puede tener entre 1 y cuatro CORES en un mismo procesador). Este nuevo elemento en el panorama de los juegos no hace mas que enriquecer cada uno de los aspectos de los mismo, podemos tener un hilo de procesamiento para el reenderezado, otro para la física, otro para el sonido y otro para la IA... obviamente las posibilidades aumentan muchísimo cuando cada uno de los aspectos principales del juego cuenta con una unidad de ejecución que no tendrá que compartir. Este enfoque no carece de problemas, pues hay que organizar muy bien la ejecución para que la física tenga el resultado junto a la IA y el resto antes de renderizar la escena. En el siguiente artículo podemos ver este enfoque más en detalle .

Sony, consciente de que este va a ser su caballo de batalla, ya desde el principio dio algunas directrices a los desarrolladores para enfrentarse a este esquema de programación paralela. Un o de ellos es, por ejemplo, la cola de trabajo, si cada una de las operaciones que tiene que realizar la aplicación se ponen en una cola de trabajo en orden y según se van quedando elementos de ejecución libres se les va asignando la tarea tendremos un resultado que organizado a su salida nos ofrecerá el resultado esperado... obviamente el overhead que supone la organización a la entrada y a la salida de la cola, tanto como la potencia que requiere la solución de las distintas dependencias entre las distintas tareas no son gratis. Este esquema será muy valido cuando hay una alta independencia entre las tareas a realizar, caso en el que no están los juegos.

Otra de las aproximaciones, por nombrar dos, es que sea el programador quien a base de artificios típicos de la programación concurrente sea quien realice la coordinación entre las distintas tareas y cada una de ellas se va asignando a cada uno de los módulos de ejecución. El problema que presenta esta aproximación es que se necesita mucha destreza. Un ejemplo del dolor de cabeza que esto puede suponer es el QUAKE III Arena, que en su versión multithreaded era capaz de incrementar el rendimiento nada menos que en un 40%, sin embargo, fue notoria la cantidad de problemas y la fragilidad y poca estabilidad de este tipo de ejecución en el juego, que era tremendamente inestable con muchos drivers gráficos excepto con unos cuantos. Desde el punto de vista de John Carmack, en la mejora del rendimiento se ve hacia donde van los juegos actualmente, pero en la fragilidad se ve la dificultad a la que se enfrentan los desarrolladores ().

Como ultima nota dejaré este interesante articulo en donde se explican los modelos de programación y si se puede considerar fácil o no la programación en la PS3. .

En definitiva, lo que vemos es un proceso de involución en la abstracción en el desarrollo software, ya que ahora se debe tener muy en cuenta sobre qué hardware va a correr cada juego para adaptar el código de forma que se saque el mayor rendimiento, esto es un problema para lo estudios que lo que desean es tener que hacer las cosas una sola vez y poder disfrutar de ese trabajo en el mayor número de plataformas posibles.

Hasta aquí lo objetivo... ahora lo subjetivo. ¿Es difícil la programación en la PS3?, yo creo que la respuesta es si. Lo cierto que la programación de cualquier sistema concurrente conlleva una serie de problemas que en la PS3 se aumentan, debido a su arquitectura, sobre si va a ser un problema capital para la PS3, creo que no. De todos es conocido el "dolor" que supone programar en la PS2 y aunque se ha tardado en pillarle la medida, creo que se han hecho títulos increíbles para el hardware de que estamos hablando, BLACK es un ejemplo muy claro, cualquiera que haya probado este juego se da cuenta del impresionante número de objetos que se mueven en la pantalla, lo cierto es que es increíble lo que han llegado a hacer con la PS2. No creo que con la PS3 vaya a ser necesariamente mas difícil, al contrario, creo que Sony ha trabajado en facilitar las labores de desarrollo usando OpenGL y Cg.

Sin embargo, si lo que nos preguntamos es si es mas fácil desarrollar en la XBOX360, por lo que cuentan los desarrolladores, Microsoft ha creado herramientas de desarrollo muy superiores de las que tiene Sony, no obstante se debe pensar que Microsoft es una empresa de Software, cosa que no lo es Sony, o al menos si la comparamos con la maquina de hacer Software que es Microsoft.

Comenta John Carmack que es deseable que el desarrollo de un juego sea un 20% mas fácil a tener un 20% mas de potencia para poder hacer cosas. Esto es totalmente lógico si además pensamos que la XBOX360 es una excelente máquina con un Hardware que no la deja demasiado detrás de la PS3. Lo que ha conseguido Microsoft, es una plataforma de desarrollo fácil, cómoda y cuyo código se puede mudar fácilmente al PC, mientras que pasar código de la XBOX360 a la PS3 y viceversa, va a ser una tarea compleja, por la diferencia en las arquitecturas de la consola.

Creo que en todas las plataformas vamos a ver gráficos muy parecidos, pero que el motor interno y el comportamiento del juego va a ser muy distinto dependiendo de la consola. Un ejemplo lo tenemos en Assasins Creed, el impresionante juego que están haciendo en el estudio de Ubisoft en Montreal, parece que va a tener un aspecto igual en ambas consolas, sin embargo, ya se ha adecentado que la IA en la XBOX360 será un poco mejor que en la PS3, y la verdad es que esto no deja precisamente bien a la consola de Sony. En mi opinión este caso se va a repetir durante un tiempo hasta que la PS3 alcance la calidad en el desarrollo de la XBOX y a partir de ese momento Sony llevará las riendas en los juegos.

Update: Me comentan (lo ví, pero no hice el update en su momento)... y es cierto, que Ubisoft ya ha dicho que la IA será la misma para ambas consolas (el código será el mismo) y que la diferencia no será apreciable... Lo cierto es que cuando dicen que el código de la IA sea el mismo no significa, per-se, las mismas soluciones de la IA, pues el tiempo de CPU dedicado a ese hilo no es el mismo. Aunque ciertamente, no creo que veamos diferencias apreciables en el juego.
Update:A lo largo de artículo comento las características técnicas que el CELL debería haber tenido. Son 3,2Ghz en vez de 4Ghz y Siete (7) SPE, uno de ellos usado como unidad de ejecución del sistema operativo.