Ayer por la tarde asistimos al acto celebrado en el Tech Talent Center de la UPC dentro del marco Open Talent. Una conferencia a cargo de Miguel Ángel Pastor enfocada para los alumnos, exalumnos y futuros alumnos del Máster en videojuegos que se imparte en la propia UPC, y en la que a partir del año que viene Miguel colaborará como profesor.
Desconsolados asistió al evento para poder saber de buena mano que hay dentro de PS3, y descubrir si realmente es tan difícil de programar como se dice.
Y para ello quien mejor que Miguel, uno de los profesionales españoles con más experiencia en el mercado, con trabajos tanto a nivel nacional como internacional.
Si por el nombre no os viene nadie a la cabeza, quizás si os decimos que trabajó en el juego Praetorians cuando estuvo en Pyro Studios empecéis a sentir curiosidad, y si os digo que también ha trabajado en el juego de Lucasarts, Clone Wars DS, empezareis a pensar que realmente vale la pena seguir leyendo esta cobertura. Pero si os digo que Miguel trabajó en Guerrilla Games desarrollando Killzone 2, y que además, se encargaba de programar a bajo nivel trabajando directamente con el hardware de la consola para optimizar al limite el código del juego y así exprimir la consola… supongo que no os marchareis sin saber qué opinión tiene sobre el hardware de vuestras PS3… no?
La conferencia estuvo presidida por Jesus Alonso, profesor del Master en programación de Videojuegos de UPC, y por el propio Miguel, que tras una pequeña presentación de Jesus se puso manos a la hora para hablarnos de las interioridades de la negrita de Sony.
Miguel nos explico componente por componente las peculiaridades de la arquitectura de PS3, cuáles eran sus puntos fuertes, sus puntos flacos, y en general como se debía programar en PS3 para conseguir buenos resultados. Y viendo los resultados obtenidos por él y los chicos de Guerrilla Games en Killzone 2, ¡desde luego hay que tener en cuenta lo que nos explicó!
Como podréis comprobar, básicamente se encarga de explicarnos todos los puntos por los cuales PS3 es tan difícil de programar.
Antes de nada quiero aclarar que todo lo que explico aquí está basado en coger apuntes sumamente rápido de lo que se iba explicando, y pese a que como ingeniero tengo cierta base en arquitectura de computadores algunas cosillas de se me escapaban de las manos, así que si hay algún error no me lo tengáis muy en cuenta ;), además he intentado escribir el minimo de cosas técnicas posibles para que cualquiera pueda más o menos entender de qué va el asunto.
El primer tema que trató Miguel fue sobre que compiladores y lenguajes se usan para programar en PS3, no indagaré sobre esto porque imagino que es algo que no interesa excesivamente a la gente. Sólo comentaré que en líneas generales es mucho más fácil trabajar con 360 que con PS3, debido a que las herramientas están mucho más depuradas y que PS3 da algunos problemas de incompatibilidad al programar en C++, que no es compatible con algunas librerías y que incluso usa una versión propia de OpenGL llamada psGL bastante menos eficiente.
Como contrapartida, los desarrolladores de PS3 cuentan con la librería libGCM que permite acceder directamente al hardware de la consola, algo que ni en PC ni en 360 se hace, y que le da ese margen sobre las demás de poder exprimir al límite la consola, pero en contrapartida le hace incompatible con directX o openGL.
Pasemos a los componentes por sí mismos.
CELL
Como ya sabéis el chip CELL está compuesto de un PowerPC 3.2 Ghz + 7 ppu’s también a 3.2 Ghz, y que de estos 7 spe’s sólo se puede acceder a 5 para la programación de los juegos.
Miguel nos comentó que el rendimiento del procesador central, el PowerPC, es realmente malo, obteniendo resultados muy inferiores a la teoría, nos habló de resultados que se acercan más bien a un 1.5 Ghz, entre otras cosas por contar con un pipeline muy largo.
Debido a la lentitud y bajo rendimiento de la unidad central, casi todo el trabajo se envía a las spu’s.
Cada Spu (Synergistic Processing Unit) puede acceder a una memoria propia de 256 KB, no pudiendo acceder a la memoria principal del sistema, lo que complica nuevamente las cosas a la hora de programar, al tener que estar cargando información constantemente a estas memorias internas, lo que es su principal inconveniente.
Las spu’s son una evolución de los procesadores vectoriales de PS2 (Emotion Engine), a diferencia de PS2, donde debías programarlas bajo ensamblador dificultando enormemente la programación, en PS3 los spu’s pueden programarse en C.
Las spu’s son rapidísimas e independientes entre sí, con un pipeline muy corto, pero realmente difíciles de programar, complicando más si cabe las programación multihilo.
Otra cosa que complica la programación en PS3 es el tratarse de un sistema Big-endian, lo que provoca que los datos deban ser convertidos a dicho sistema, este hándicap lo comparte tanto con 360 como con Wii, que también son Big-endian.
En este punto Miguel nos explicó que en Guerrilla eran hasta 10 programadores de tecnología pasando tareas a los spu’s, y que les llevaba muchísimo tiempo, lo que se traduce en una enorme inversión que pocas compañías pueden permitirse. Y que pese a que el SDK ha mejorado muchísimo en los últimos tiempos, sigue siendo peor que el de 360.
RSX
Ahora toca hablar de la gráfica de PS3, RSX resulta ser una grafica muy lenta en el procesado de vértices, skinning y clipping, por lo que nuevamente se deberá usar los spu’s para que vengan en su ayuda y así poder alcanzar unos resultados satisfactorios.
Al tener que usar las spu’s y estas tener una ram interna tan pequeña… Para hacer el skinning debían comprimir y descomprimir el formato de los vértices o dividir la geometría en bloques más pequeños, lo que dificulta nuevamente el trabajo de programación.
Pese a estos inconvenientes trabajar con los spu’s es optimo por la enorme velocidad de sus memorias internas, que tardan tan solo 8 ciclos en poder leerse, por los 600 ciclos que se tardaría en leer la ram desde cpu si no está almacenada en cache.
En la última versión del SDK se ha introducido una “cache de software”, para poder gestionar todo esto de forma mucho más amigable, y aunque no es tan rápido como hacerlo a mano, se consiguen resultados muy satisfactorios. Por ejemplo, la portabilidad del motor de físicas Havock se hizo usando esta “cache de software”.
Otro problema de PS3 en relación a 360 es el hecho de que su memoria está dividida entre VRAM y principal, a diferencia de 360 que esta unificada, lo que da menos libertad para los desarrolladores viéndose limitados en el uso de la memoria en momentos puntuales.
Además los shaders de PS3 son específicos, a diferencia de en 360 que son unificados, lo que da una mayor libertad de trabajo en 360 y mejores resultados, por tener un sistema más moderno y efectivo.
Los efectos postprocesado (shaders), como el HDR, también son enviados a las spu’s, ya que la GPU de PS3 no es suficientemente rápida y el resultado no es bueno, lo que hace que los shaders en PS3 estén programados en C en vez de GLSL.
PS3 tiene un extraño problema en los shaders (lo de extraño es una apreciación personal mía) al no poder usar datos uniform (constantes), lo que hace que se tenga que crear un nuevo shader para cada valor nuevo en vez de recibir nuevos valores el mismo shader, lo que es lentísimo y consume muchísima memoria, y como no podía ser de otra forma no es fácil de programar.
Las transparencias mediante Alpha Blending son muy lentas en PS3, y de hecho no se puede conseguir fuego o niebla a pantalla completa, ya que el frame buffer es demasiado pequeño para hacerlo, en 360 no hay ningún problema, ya que el Alpha Blending es gratuito, no consume recursos.
Para poder sacarle buen rendimiento a la consola hay que enviar el frame buffer a la vram, y las texturas a la memoria del sistema.
BLU RAY
El lector de discos es muy lento, 9 MB/s (por 15 MB/s la 360)
Hay que hacer streaming si o si, es muy difícil conseguir que sea 100% automático, por lo que hay que hacer intervenir a los grafistas y diseñadores para colocar estratégicamente pasillos largos o puertas que den un poco de margen a la lectura de datos.
Nos comenta que un truco muy peculiar para disimular el streaming lo usaba Jack & Daxter 2 en PS2, que si no cargaba a tiempo cuando el personaje estaba girando, este se caia al suelo, dando un tiempo extra a la consola para cargar decorado.
Debido a la enorme cantidad de capas de los blu ray, los seek times son carísimos, por lo que aprovechando la gran cantidad de espacio de los discos, se replica constantemente información en él, para así evitar más lentitud en la lectura, ganando así velocidad de acceso a base de replicar la misma información en varios lugares del disco.
TRC
En este punto Miguel ya dejó de lado la parte de hardware, y entró a comentar los requisitos impuestos por las compañías a la hora de desarrollar juegos, los terribles TRC que tantos juegos han hecho retrasarse e incluso desaparecer.
En las listas de TRC (con hasta 100 requisitos) puedes encontrar desde cosas tan básicas como: “El juego no se puede colgar”, ha cosas tan curiosas como “El juego no puede provocar que el usuario este 10 segundos sin hacer nada”. (Es evidente que Kojima Productions se pasa a veces por el forro las TRC)
Algunos contratiempos que se encuentran las compañías, es que al lanzarse un nuevo SDK cambian los TRC, y provocan que se alargue el desarrollo al tener que retocar o rehacer ciertas partes.
Miguel nos comenta que en este campo Sony son los menos “tocapelotas”, luego vendría Microsoft, y por último, como máximos quisquillosos del mercado Nintendo, como no podía ser de otra forma.
En general, el mensaje que nos da Miguel es que PS3 es una plataforma muchísimo más complicada de programar que 360, pero que gracias a poder acceder al hardware se pude exprimir muchísimo más. Y que su arquitectura te obliga a programar de forma totalmente diferente a la del resto de sistemas, haciendo cosas tan raras como trabajar los shaders fuera de la gpu…
Por lo que tenemos como resultado que en números teóricos PS3 es bastante más potente que 360, pero en la realidad llegar a esos números teóricos es muy complicado, y además debido a tener que trabajar todo con los spu’s “trampeando” provoca que para hacer algunas cosas en PS3 tengas que usar muchísimas más instrucciones y ciclos que en 360, por lo que la cosa se nivela y es muy difícil calibrar como son los resultados reales. Pero que en general, considera más potente PS3 que 360.
Según Miguel, se podría resumir todo en esta frase:
“Si pones a 3 ingenieros con PS3 y 3 con 360, te saldrá un juego mejor en 360. Si pones a 10 ingenieros en PS3 y 10 en 360 te saldrá mejor juego en PS3”