Bien, la cuestión con estas dos consolas ya da lugar a muchos problemas. El problema principal es que ambas consolas (especialmente PlayStation 3) se venden como mucho más de lo que realmente son, y realmente pueden. No porque no puedan hacer mucho, sino porque lo que hacen son gráficos en 3D en el TV de mi casa y no en 4D con efectos de distorsión tiempo espacio. En muchos casos inclusive un PC de alta gama esta mejor parado que estas consolas, aunque en otros tantos casos no, y estas consolas tienen las de ganar (al menos por ahora) a un PC de alta gama (especialmente si tenemos en cuenta el precio de ellas). Por supuesto que si usted dispone de un presupuesto ilimitado y desea armar un sistema con 5 Gb de Ram y cuatro tarjetas 7800 GTX en Quad SLI obtendrá un rendimiento imposible para estas consolas. Pero a costa de un presupuesto que le hubiera alcanzado para comprarse todas las consolas del mercado y sobrarle para unos cuantos juegos también.
El punto es que una consola es para jugar y no para hacer benchmarks, y eso realmente tanto PlayStation 3 como Xbox 360 tienen poder de sobra suficiente como para hacerlo. Igualmente siempre existe el deseo de comparar que hardware es más rápido y potente, y cual realmente no lo es tanto.
El problema principal es que muchos de los datos de hardware y demás provienen de las empresas creadoras de las respectivas consolas y empresas con marcadas tendencias a una u otra consola, en el peor de los casos por acuerdos comerciales, y en otro solo por previas experiencias en ciertos campos de desarrollo. Tristemente en muchos casos los fanboys siempre caen en el juego de que “tal persona ha dicho tal cosa y yo le creo más a él que al resto” o peor aun “el resto de personas miente porque ha sido pagada, no sabe nada o tiene envidia”.
Volviendo al tema puedo decir que la meta en la creación de un hardware es el balance en la mayor cantidad de niveles posibles. No sirve de mucho decir que un CPU es muy potente porque su clock interno da muchos mas Mhz que otro si a cambio el FSB (Front Side Bus) es tan escaso que se convierte en un aro cerrado. Esta regla del balance rige todos los ámbitos del hardware, el de los PC y el de las consolas. No existe otra explicación.
Si bien podemos aceptar que en muchos casos los desarrolladores encuentran soluciones a los problemas de arquitectura de un hardware y logran crear a fuerza de ingenio muchas soluciones (que en muchos casos implican recortes de otros lados), eso no deja de ser un parche inadecuado a la realidad que es, que el hardware es inadecuado; y se podría haber trabajado mejor con un hardware mas completo.
En éste ámbito las consolas corren con una ventaja frente a un PC, que se diseñan para ser estables de origen. Aunque corren con la desventaja de que tienen limites de costos al momento de diseñarse. Si usted desea armar un PC de alta gama el único límite es su capital. Si dispone de capital suficiente, pues tendrá el mejor equipo jamás creado. Por el contrario las consolas se diseñan lo mejor posible pero siempre teniendo en cuenta que no puede luego costarle al usuario 1500 euros. Muchos de los límites que hoy PlayStation 3 y Xbox 360 tienen provienen de este problema.
CELL vs Xenon.
Tanto PlayStation 3 como Xbox 360 han elegido CPUs cuyos clocks están en los 3.2 Ghz y soportan múltiples hilos de trabajo. Llamativamente se parecen en líneas generales. Muchos de esto deriva de lo ocurrido en el CES 2005 donde las empresas desarrolladoras pidieron a las creadoras de consolas que sus sistemas tengan líneas comunes sobre las cuales trabajar, como forma de que los juegos multiplataformas puedan ser desarrollados sobre líneas lo mas generales posibles.
Por este motivo es muy llamativo que ambos sistemas compartan la velocidad del clock general y que también compartan una unidad de procesamiento general similar en forma de trabajar. En caso de PlayStation 3 es el PPE, y en caso de Xbox 360 cualquiera de los G5 custom puede cumplir esa función de unidad de trabajo general. Muy posiblemente un juego multiplataforma se apoye solo en el trabajo del PPE en PlayStation 3 y solo en el trabajo de un G5 en Xbox 360. Pero hasta aquí llegan las similitudes.
PlayStation 3 utiliza el CELL como CPU. Un conjunto de nueve unidades de procesamiento. En realidad ocho son funcionales, una de ellas se reserva como posible “unidad muerta” en el proceso de fabricación y por mas funcional que pueda ser eventualmente no se tiene en cuenta ni se puede acceder a ella por métodos normales (no descartemos el modding pero en si no viene al caso). De las ocho unidades una de ellas es el PPE, una unidad de procesamiento general con posibilidad de ejecutar cualquier tipo de código relativamente bien (muy similar a uno de los G5 custom de Xbox 360). Las siente unidades restantes son los SPE, unidades de procesamiento sinérgico especializadas en cierto tipo de código (punto flotante) que ejecutan con mayor rapidez que el PPE. Aunque a costa de que la ejecución de código no especializado en estos SPE sea con muy poco rendimiento final en comparación con el resultado que tendrían si son ejecutadas en el PPE.
Realmente no es que estos SPE no puedan ejecutar enteros o código no especializado. Poder, pueden. Pero con un rendimiento malo en comparación con el que tendrían si fueran ejecutados en el PPE. En este punto conviene aclarar que la emulación no es una solución. La emulación de condiciones ajenas es siempre un parche. Emular calculo de enteros en un SPE es posible pero con rendimiento pésimo.
Un punto a tener en cuenta de CELL es el hecho de que el PPE actúa como regulador del sistema de las tareas de los SPE. Esta forma de trabajo de CELL puede llegar a ser un problema grave en el rendimiento final en caso de que no se optimice muy bien el uso del PPE. Para que se entienda el poder de los SPE esta cercado por lo que el PPE pueda procesar para regular sus tiempos, al mismo tiempo que ese PPE también realiza sus tareas propias. Si el PPE por las tareas que esta generado tiene algún retraso (algo muy común si tenemos en cuenta que el PPE será la unidad de procesado central general del sistema) por tareas muy complejas, los SPE debe esperar para poder presentar sus resultados. Esto deviene en un cuello de botella algo molesto que hace que mucho del poder teórico de los SPE se quede en el camino cuando se lo coloca en una situación real.
Por el contrario Xenon (el CPU de Xbox 360) tiene tres unidades de procesamiento genéricas (G5 custom) útiles a todo tipo de código, Pueden perfectamente trabajar con código de punto flotante, pero evidentemente sin la aceleración que tendría este código de ser tratado en los SPE de CELL. Además cada unidad G5 puede internamente trabajar con dos hilos de trabajo virtual. Siendo un total de tres hilos reales que dentro de cada uno trabajan en grupos de dos hilos virtuales.
El resultado parcial por ahora es que mientras CELL es un monstruo al momento de calcular punto flotante que dobla fácilmente en potencia a Xenon, en cálculo de enteros este último sobrepasa a CELL.
Pero además hay otras diferencias más notorias. Si bien ambos sistemas se enfocan en las tareas de ejecución múltiple, los criterios seguidos son diferentes.
Mientras que Xenon apunta al equilibrio de ejecución, CELL lo hace a la especialización. El criterio seguido por CELL es el de que uno desarrollador debe separar las líneas de código según su naturaleza (enteros o punto flotante) en uno u otra unidad de procesamiento, mientras que el criterio de Xenon es que la distribución es igualitaria en cada unidad según elección del programador independientemente de la naturaleza del código.
El criterio de Xenon es un poco menos agresivo a la hora de tomar contacto con el multihilo. No obliga a un desarrollador a separar obligatoriamente las tareas en tal o cual unidad de trabajo por su naturaleza y luego obligatoriamente tener que balancear esa división ya hecha, sino que le permite elegir como puede separarlas teniendo en cuenta como prioridad el balanceo de hilos de trabajo y no la esencia del código con el que trabaja.
Teniendo en cuenta que en videojuegos el multihilo aun no es estándar es un poco mas acertada la forma en la que Xenon le da a los desarrolladores la forma de entrar a tomar contacto con tales cuestiones.
En ese sentido el acercamiento de Xenon al desarrollador ha sido más acertado. El desarrollador al trabajar para Xenon no tiene que preocuparse por el tipo de código que este usando. Puede elegirlo libremente y balancearlo a gusto no estando obligado a tener que ponerlo en tal o cual unidad de procesamiento porque de otra manera el rendimiento es malo (por ejemplo si quisiera ejecutar enteros en un SPE). Además el acercamiento al multitarea de Xenon es simétrico.
Por el contrario el acercamiento de CELL al multitarea es además de estar dividido por naturaleza del código a tratar, es asimétrico; lo que deja en tarea del desarrollador la difícil tarea de intentar balancear los procesos entre siete unidades de punto flotante y una de trabajo general. Nada fácil si tenemos en cuenta que el multiprocesamiento ya solo entre dos unidades independientes (aun simétricas) ya es un desafío.
Otra ventaja de Xenon es la portabilidad. Al ser Xenon un sistema igualitario los juegos hechos en diferentes plataformas podrían ser llevados con mejor facilidad a Xbox 360 y de Xbox 360 a otros sistemas con procesos de optimización sencillos.
De CELL no puede decirse lo mismo. Portar un código hecho en Xbox 360 a una PlayStation 3 significaría de pronto que el PPE tendría que trabajar con su único hilo de trabajo el equivalente a los seis hilos de trabajo de Xenon. En tal caso el rendimiento del PPE (que no es muy distinto a uno solo de los G5 custom de Xenon) apenas podría con los dos hilos de trabajo de un solo G5 y ahora le estarían exigiendo que rinda como para cubrir los seis hilos posibles que los tres G5 pueden generar.
Igualmente la portabilidad es posible, en tal caso recortando condiciones del juego de Xbox 360 a PlayStation 3. La otra opción es no portar directamente sino redesarrollar todo el código nuevamente para CELL en tal caso dividiendo las tareas por su condición entre el PPE y los SPE.
El punto es que por cuestiones de ahorro en el desarrollo la mayoría de empresas que tengan en mente utilizar el multiplataformeo de origen como solución elegirán no desarrollara mas que para una sola unidad G5 de Xbox 360 ni para mas que el PPE de PlayStation 3. De esta manera la portabilidad esta mas que asegurada con buenos resultados. Pero en ningún caso tales juegos explotaran mucho a las respectivas consolas.
Entrando mas en detalle con el tema de los ports, la que en peor situación esta en esto es PlayStation 3. Un juego de Xbox 360 puede portarse a PlayStation 3 rápidamente pero a costa de que lo que el PPE no pueda hacer se recorte (ya que rescribir el código para los SPE implicaría mas que un port redesarrollar el juego). Por el contrario un juego de PlayStation 3 portado a Xbox 360 se recortaría en aquello que los dos G5 restantes (teniendo en cuenta que uno reemplazaría al PPE) no puedan llegar a trabajar con la potencia que lo pueden hacer los SPE. En definitiva el recorte hecho de un juego de PlayStation 3 a Xbox 360 seria algo menor que el hecho de un juego de Xbox 360 a PlayStation 3.
Este problema repercute en las decisiones de los desarrolladores. Si un juego es pensado de origen para Xbox 360 y PlayStation 3 la respuesta ya esta dada. Será un juego que use un código genérico que un solo G5 y el PPE puedan trabajar bien. Seria un juego que no lleva al tope a ninguna consola.
Si un juego es pensado de origen para PlayStation 3 haciendo uso de todo el poder de CELL, es posible portarlo a Xbox 360 pero con las limitaciones en cálculo de punto flotante que tienen los tres G5.
Pero si un juego es pensado de origen para Xbox 360 haciendo uso de todo el poder de Xenon, el resultado al portarlo a PlayStation 3 será que recibirá recortes importantes en todo aquello que una sola unidad de calculo general (el PPE) no pueda hacer en relación con tres de esas unidades (los tres G5).
Si además tenemos en cuenta que Xbox 360 ya ha salido y ha distribuido mucho antes sus herramientas de trabajo desgraciadamente PlayStation 3 en muchos casos recibir ports recortados de juegos de Xbox 360 o directamente cancelaciones de juegos como fue el caso del “Condemned”. Al menos este problema PlayStation 3 lo tendrá con la primera tanda de juegos por su primer año de vida.
Inclusive algunas desarrolladoras de Japón han abandonado a Sony como el estándar de desarrollo para pasar a ser desarrolladoras con enfoque multiplaforma (caso de Capcom) o para basar sus desarrollos en las herramientas de trabajo de Xbox 360 por las facilidades que estas tienen.
Otro tema aparte, volviendo a las cuestiones de los CPU de ambas consolas, es el de la memoria cache L2 de ambos sistemas. Realmente uno de los problemas más notorios de CELL y Xenon lo podemos apreciar en este ámbito. La memoria cache es un elemento más que caro y que suele ser recortado.
Tanto CELL como Xenon tiene memoria cache L2 compartida entre todas las unidades de trabajo. Cada unidad aparte de su memoria local además puede acceder a una memoria de apoyo. CELL tiene 512 Kb disponibles para las ocho unidades de trabajo, y Xenon 1 Mb para las tres unidades de trabajo.
Las cifras de memoria cache L2 son algo escasas en ambos casos. Tomando el caso de Xenon, hoy día 1 Mb es algo común en procesadores de PC de un solo hilo de ejecución. En el caso de Xenon siendo seis los hilos de trabajo virtuales, le deja a cada hilo virtual algo de 170,66 Kb de memoria cache L2 para cada hilo.
Con CELL es aun más fuerte el detalle. Siendo solo 512 Kb para repartir en 8 hilos de trabajo serian 64 Kb de memoria cache L2.
Sobre este punto quiero aclarar, dejemos de lado de las explicaciones sin sentido como por ejemplo considerar que el problema no existe porque si por ejemplo un SPE (o un G5) necesita mas memoria cache L2 puede tomarla de la Ram general y con eso esta el problema solucionado. Con un mínimo conocimiento de hardware se sabe que nunca una Ram local tiene el mismo rendimiento que una memoria cache L2 y que de intentar hacer esto se podría, pero a costa de tener un rendimiento tan pésimo y peor que si no se lo hiciera.
Inclusive les es casi imposible para los SPE tomar memoria general para suplantar las faltas de cache L2 desde el momento que el PPE actúa como regulador de memoria. Por ejemplo si un SPE necesitara más memoria podría plantar una orden en el autobus. Esta orden se ejecutaría en último plano a lo que el PPE este haciendo y sobre la base de que el PPE la regula. Aparte de ser un proceso lento y de muy poco rendimiento además recarga tareas extra al PPE el cual ya tiene bastante trabajo por si solo.
Igualmente no es el fin de los tiempos este detalle, teniendo en cuenta que la Xbox actual solo tiene 128 Kb por uno solo hilo de trabajo, y teniendo en cuenta que se pudo trabajar bastante bien con ella; la cache L2 que presentan CELL y Xenon no son tan pobres después de todo. Aunque igualmente de haber habido mas el rendimiento general seria mucho mejor, más si tenemos en cuenta que estas consolas se pensaron para durar al menos entre cuatro y cinco años como hardware de punta.
¿Punto flotante o cálculo de enteros?
Esta es toda una cuestión. Toda la guerra entre CELL y Xenon parece cerrarse en esta condición. ¿Cual es realmente el nivel de uso del cálculo de enteros en un sistema y cuanto el de punto flotante?
Es difícil contestar esta pregunta, porque realmente no tiene respuesta. Depende mucho de lo que el desarrollador en cuestión quiera hacer con el juego que esta creando más que de un estándar tipo.
Por ejemplo cuando se realizo la demostración del motor Unreal 3.0 en el hardware que representaba una PlayStation 3, Epic concluyo que los SPE se podrían usar para calculo de tareas de lógica de alto nivel como IA, físicas, efectos de partículas o scripting.
Pero también Epic concluyo que tales tareas son relativamente poco del uso total de un CPU, y que también el PPE podría realizarlas para dejar a los SPE haciendo otras tareas.
En este punto es que queda la duda de hasta que punto es necesario tanto punto flotante en un CPU para necesitar de siete unidades de trabajo aceleradas si en general el punto flotante en los juegos es algo del 20% del total del código presente. Y también desde que la unidad de calculo general (el PPE) también puede trabajar con punto flotante en relativa buena manera.
El problema en el uso de punto flotante o enteros puede considerarse de esta manera: una operación de punto flotante puede ser cualquier cosa. Pero cuando usted intenta ejecutar un código específico cualquier cosa no se puede poner en una operación de punto flotante. El código de fines generales es casi imposible en el punto flotante con buen rendimiento. Siendo que el punto flotante se relaciona con gráficos entonces los GPU los harán, y no sirve de mucho que el CPU pueda hacerlos si a cambio el rendimiento en fines generales es pésimo.
En PS3 el arsenal de SPE le da más punto flotante que a 360, pero los desarrolladores ya están encontrando que no hay demasiado en que utilizar tal excedente de punto flotante. Si el 80% de código de un juego es enteros y 20% punto flotante entonces para usar al 100% el punto flotante de PS3 hay que multiplicar por cinco el 80% código de enteros y el PPE de PS3 no podría ni siquiera moverse si solo multiplicaran por dos el 80% de código general de un juego.
El hecho es que muchos desarrolladores tendrán problemas para ubicar en que usar tanto poder de punto flotante. Y su opinión esta algo alejada de la de Epic, ya que consideran que hubiera sido más útil otra unidad PPE y no tantas unidades SPE.
Pero en todo caso es cuestión de que los desarrolladores le encuentren uso a tal poder en alguna tarea que se pueda llevar bien por punto flotante. Aun así, el punto flotante es algo del 20% del proceso total de un videojuego, por lo que el problema será que para muchos desarrolladores que no busquen en que usar el poder de cálculo flotante extra, tales SPEs no serán de mucha utilidad.
Microsoft al catalogar a los SPE se refirió a ellos como un manojo de circuitos inútiles al hablar a las desarrolladoras. Sin embargo Epic demostró que los SPE tienen utilidad, el problema es ¿Qué tanta utilidad?
Esa respuesta no la puede dar Microsoft en si ni Sony tampoco. La pueden dar los desarrolladores y solo ellos al momento de crear un juego. Aunque teniendo en cuenta que el punto flotante es algo de un 20% del total de código de un juego y la dificultad de programar para un sistema asimétrico de ocho líneas de trabajo paralelas.
Una pregunta que aun queda por responder es ¿por qué Sony eligió especializar su sistema en cálculos de punto flotante a costa de tener un rendimiento de enteros bajo y porque Microsoft ha hecho exactamente lo contrario?
Cuando Sony se refirió al hardware de Xbox 360 dijo que erraron con el hardware, que era muy potente en enteros pero que realmente no servia de mucho esto porque eso seria bueno en un PC que tiene que cargar Word y otras aplicaciones similares. Por el contrario Microsoft al referirse al los SPE de PlaySation 3 los categórico como un manojo de circuitos inútiles que no satisfacen realmente las necesidades de un programador y solo están ahí ocupando espacio.
Los enfoques para las elecciones de hardware al menos en Xbox 360 están más claros. El motivo de Microsoft en necesitar más procesadores de fines generales viene en gran medida por haber eliminado el hardware de audio para pasarlo a ser ejecutado por software. Súmese que además Xbox 360 ejecuta en tiempo real tareas de soporte online para su servicio Live y es evidente que un solo núcleo de fines generales hubiera quedado muy escaso para trabajar con todos estos procesos.
Por el contrario no esta totalmente claro a que apunta Sony al haber especializado su hardware en punto flotante. En muchos casos esta es la forma de trabajo de Sony (muy contraria a la de Microsoft) que consiste en crear un hardware en base a posibilidades teóricas y dejar luego que los desarrolladores sean luego los que le encuentren finalidades. Mientras que Microsoft por el contrario sobre la base de un software tipo comienza a crear el hardware.
La forma de trabajo de Sony es en si casi siempre una apuesta a futuro. Tienen la garantía de que sus sistemas venderán por su nombre. Así que pueden darse el lujo de experimentar con un hardware nuevo. Si luego este hardware se convierte en el estándar futuro han logrado otro éxito aparte del que la consola significo. Pero por el contrario si su hardware es rechazado por la industria al menos igualmente la consola es exitosa por sus ventas y aceptación en el mercado aun cuando su hardware sea indeseable. Por ejemplo haciendo una comparación con PlayStation 2 esta incluía una segunda unidad vectorial de apoyo. La misma simplemente no tuvo uso y se convirtió en lo que Microsoft sentencio de los SPE, circuitos inútiles.
Mucho es posible que viendo las reacciones de los desarrolladores acerca de la complejidad de PlayStation 3 en cuanto a programación estemos ante otro caso Emotion Engine en el cual la industria lo considera un indeseable al momento de programar pero su apoyo se debió a que esta dentro de la consola PlayStation 2, mas no al hecho de ser un hardware amistoso.
Aunque por otro lado algo que si vale la pena destacar de CELL es que realmente no sigue, por suerte, los pasos errados que Emotion Egine había seguido con su sistema complejo y la curva de aprendizaje programación en PlayStation 3 es mucho mas sencilla que en PlayStation 2. Sin embargo la curva de aprendizaje de programación de Xbox 360 es aun mucho mejor que la de PlayStation 3, algo que tiene que ver con cual será el estándar de programación y hasta que punto se tendrá interés en aprovechar el potencial del hardware de PlayStation 3.
El estándar de programación.
Una cuestión a determinar es cual de las dos plataformas tiene mejores vistas de convertirse en el estándar de programación para juegos de la próxima generación.
La respuesta es más bien clara, Xbox 360 es el estándar. Las herramientas de programación que Microsoft ofreció a los programadores y su acercamiento al multitarea simétrico fue mejor recibido por los desarrolladores. Las desarrolladoras en su totalidad ya han elogiado a Microsoft por este tema; mientras que de PlayStation 3 se limitan a considerar que es más sencilla que PlayStation 2 pero aun así prefieren la oferta de desarrollo más amistosa que da Xbox 360.
En ese sentido uno de los grande problemas que PlayStation 3 va a tener que enfrentar será el que los desarrolladores no se interesen por tomar a su consola como base principal de programación sino a Xbox 360 y sean los juegos portados de Xbox 360 los que rijan la vida de PlayStation 3.
En mucho sentido es un problema que puede afectar a PlayStation 3 el que los desarrolladores elijan desarrollar sobre Xbox 360 y luego pasar esos ports a PlayStation 3 lo que dejaría muy despotenciada a la consola de Sony al limitarla a correr los ports de otro sistema con formas de trabajo diferentes. Si recordamos los primeros juegos de PlayStation 2 portados de Dreamcast de mala manera la cuestión toma algo de gravedad en caso de que se convierta en el esquema de toda la vida de PlayStation 3 ya que se calcula que Xbox 360 no se retirara como la consola de Sega, y que el mirar a Xbox 360 como base de programación es también mirar a PC y el mayor mercado de video jugadores existente con la base de usuarios mas grande de todas.
El motivo en todo esto es que Microsoft ya tenia ganada de origen la guerra por el estándar de desarrollo para juegos multiplataformas. Microsoft es una empresa dedicada a la creación de software y herramientas de middleware para el desarrollo que tiene más experiencia que Sony en ese campo. Trabajaba con estándares ya conocidos y usados en PC, y también distribuyo entre las desarrolladoras sus estaciones de trabajo más de un año antes que Sony. Aparte de que la capacidad de distribución y colocación de software de Microsoft en el mercado es mucho mayor que la de Sony.
Sony intento evitar esta movida de parte de Microsoft creando herramientas de trabajo mucho más sencillas que las usadas en PlayStation 2 y poniendo herramientas de trabajo estándares ya usadas como es el caso de incluir en PlayStation 3 APIs conocidos por los desarrolladores ya usados en PC. El grupo de herramientas derivadas de Collada en muchos sentidos son mucho mejor que las usadas en PlayStation 2, pero el hecho es que aun así son de menor categoría que las herramientas Middleware de Microsoft.
Cuestiones de formato.
La nueva generación se caracteriza por la implementación por parte de Sony del nuevo formato BR. Microsoft por el contrario prefirió usar uno de los estándares actuales, el DVD9, y dejar el HD-dvd como opción a futuro en un Add-on pero solo para reproducción de películas.
PlayStation 3 tendrá espacio de sobra con su formato para todo lo que pueda hacer. Mientras que Xbox 360 tendría que saber muy bien como utilizar el espacio vigente. 9 Gb para un sistema que tiene que durar cinco años al menos puede ser algo escaso. En algunas situaciones los juegos de Xbox 360 tendrían que usar algoritmos de compresión para ciertos elementos críticos de alto consumo de espacio, como ser los videos en alta resolución o gráficos prerenderizados.
En principio Xbox 360 no debería tener problemas de espacio. El DVD5 fue el estándar de esta generación en casi la totalidad de los juegos. Un número muy reducido que no representa más de una cifra menor al 8% de los juegos paso a ocupar un DVD9. Por lo que entonces el DVD9 no esta agotado.
El problema igualmente es que en la nueva generación algunos elementos aumentaran la cantidad de espacio que necesitan los juegos. Específicamente esos elementos críticos son los gráficos en alta definición y las secuencias prerenderizadas.
No hay otros elementos que sean críticos en el aumento de espacio. Dejemos de lado afirmaciones sin mucho sentido como hablar de nuevos gráficos o nuevas físicas. Específicamente no hay ni nuevos gráficos ni nuevas físicas que reemplacen a algo viejo. Lo que hay es un aumento de la definición en los gráficos y para eso el DVD9 tiene en general suficiente espacio. Luego citar que hay aumentos en las físicas es un sinsentido. Específicamente mas físicas o mas IA es solamente una mejora del motor básico de físicas o de los scripts que regulan la IA y son líneas de código mínimas en el total de lo que un juego es. En el caso de las físicas, mejores físicas no deriva de tener más espacio en el formato físico. Mejores físicas depende de un motor básico que puede ser casi el mismo que se usa en esta generación y usan una porción de espacio mínima. Las mejoras en esas físicas están dadas por mayor cantidad de cálculos en tiempo real dependientes de procesadores mas rápidos y una mayor Ram para calcularlas y no por aumentos en de espacio en el formato físico.
Para que se entienda exactamente el mismo motor de físicas usado en un juego hoy puede ser usado en un juego de la nueva generación. Pero los resultados en una consola de nueva generación al dispone de mayor capacidad de procesado y mas Ram para realizar en tiempo real tales cálculos harán que esas físicas sean totalmente superiores a las del juego de esta generación. Sin embargo el motor de físicas usado es el mismo y ocupa lo mismo de espacio en el formato físico que en un juego de esta generación.
En general el DVD9 puede ser suficiente cuando se trata de gráficos de alta definición, el problema esta cuando, además, el desarrollador desea colocar secuencias de video prerender también en alta definición. Este si es un elemento critico para el cual el espacio del DVD9 puede ser escaso.
Las desarrolladoras de occidente no han manifestado quejas contra la decisión del Microsoft de usar DVD9, teniendo en cuenta que es común que estas prefieran los gráficos en motor que las secuencias prerenderizadas. Son las desarrolladoras de oriente las que manifestaron que se encuentran algo limitadas a su forma de trabajo mas afecta a las secuencias CG por el espacio del DVD9.
El problema de las secuencias CG en alta definición en el DVD9 no es insalvable. Las desarrolladoras podrían hacer rendir en mucho el espacio del DVD9 si usaran algoritmos de compresión avanzados y formatos comprimidos. Mas teniendo en cuenta que es la misma Microsoft la que podría poner a disposición de estas desarrolladoras muchos de sus codecs de audio y video comprimidos.
Pero la compresión de datos no es la total solución a todos los problemas de espacio. Para que se entienda, al comprimir se tiene también que tener la capacidad de descomprimir en tiempo real a buena calidad. Si una secuencia CG es comprimida demasiado para que ocupe aun menos espacio luego la secuencia que se logre al descomprimirla será de menor calidad visual que si el video se corriera totalmente descomprimido o comprimido a menor ratio. El limite de ratio para comprimir una secuencia CG y poder luego descomprimirla en tiempo real a buena calidad esta dado por el hardware. En ese sentido se agradece que Xbox 360 no esta limitada en poder para realizar esta tarea.
Aunque a pesar de todo en algunos casos no será algo raro ver en Xbox 360 que algunos juegos terminen usando dos discos DVD9, especialmente si contienen de muchas secuencias CG.
Por el contrario Sony con el uso del BR no tendría problemas de espacio, y los desarrolladores podrían colocar la cantidad de secuencias CG que quisieran sin comprimir.
El punto preocupante del uso del BR es la velocidad de lectura, mientras que Xbox 360 dispondrá de menos espacio podrá leer los datos de su unidad mas rápido, mientras que PlayStation 3 por el contrario tendría mayores tiempos de lectura y consiguientes cargas.
El chip grafico.
Uno de los puntos interesantes de PlayStation 3 y Xbox 360 es el uso de desarrollos chips gráficos nacidos de empresas que desarrollan placas de videos para PC.
La elección originaria de Sony al momento de disponer un CELL enfocado a gráficos quedo en el camino al ver que CELL podía dar muy buen rendimiento en píxel Vertex pero en píxel Shader su rendimiento era muy bajo.
Tal es el caso que Sony cierra un acuerdo con nVidia para que le traslade uno de sus desarrollos actuales (la 7800GTX) a un chip adecuado a PlayStation 3 (el RSX).
Por el contrario Microsoft deja de lado a su antigua aliada (nVidia) para cerrar un acuerdo mas conveniente a nivel económico con ATi para la creación del Xenos.
El ATi Xenos.
Xenos es el resultante del trabajo de ATi en la creación de una nueva arquitectura de trabajo. Se trata de un desarrollo que por ahora no esta disponible en PC pero a futuro ATi plantea utilizarlo en ese campo. Asimismo nVidia también declaro que a futuro sus placas de video (posiblemente la 8800) también usaran un esquema de trabajo similar al de ATi Xenos.
La idea del Xenos se puede dividir en dos partes físicas. Una de ellas (la tradicional) con el chip grafico, las ALUs y demás procesos naturales de un chip grafico (aunque con una variable sobre la forma de trabajo), y otra con un integrado de memoria interna desarrollada por NEC de alto rendimiento.
El chip en general correría a 500 Mhz de velocidad, tendría un bus de trabajo de 256 bits, un clock de 500 Mhz, sobre un total de 512 Mb de memoria Ram GDDR3 a 700 Mhz a 22 Gb/s; con la salvedad de que la memoria total es compartida por todo el sistema y trabajaría con un bus 128 bits.
ATi catalogo a la memoria interna (Edram) como de apoyo para tareas del eje Z y plantilla de color, así como para procesos de filtrado como AA, con un ancho de banda al sistema del GPU con un bus de 32 bits pero teniendo en cuenta que los datos pueden pasar comprimidos así que el rendimiento de este ancho bus de datos seria aun mucho mayor. El resto del sistema trabajaría a un bus de 256 bits.
El objetivo de ATi al crear este sistema fue desbloquear muchos de los procesos de mayor peso en como ser la generación de color y los datos del eje Z que mueven el framebuffer. ATi espera con este modelo de trabajo eliminar los embotellamientos que ocurren al generar esas tareas moviendo tales tareas de la memoria de video a la Edram, y al mismo tiempo dejar lo mas libre posible a la memoria de video para generación de otras tareas como texturado.
El chip grafico Xenos actúa en este sistema como puerto norte para el sistema y esta en el centro de todo. Hay 10.8 Gb/s hacia arriba y abajo entre GPU y CPU. Mientras que el resto del sistema tiene 500 Mb/s de ancho de banda. Una de las ventajas de esta disposición es estar directamente ligada a la cache L2 y poder leer datos de esta en forma directa. Este sistema ya fue usado con éxito en Xbox.
Un punto que igualmente queda en duda es que tan útil puede ser la Edram. El problema es que las citadas tareas del eje Z y generación de color pueden ser muy densas para solo 10 Mb de Ram quedando esta cifra en un monto algo escaso. El hecho es que en muchos casos tales tareas van a necesitar mas de esos 10 Mb de Ram (especialmente en exhibiciones con AAx4); en cuyo caso, esa Edram, va a terminar funcionando más como apoyo para tales tareas que como elemento independiente que pueda sustraer totalmente las tareas del eje Z, generación de color y filtros de la memoria general. En estos casos la Edram serviría como intermediaria de almacenaje trasera del frambuffer y la intermediaria de almacenaje delantero estaría en la memoria general.
La otra base del Xenos es la que contiene las ALUs y demás procesos de gráficos. Un detalle sobre esta parte es que tampoco obedecen a los esquemas de chips gráficos de PC tradicionales sino a un esquema nuevo. El secreto consiste en que las unidades de Vertex son también unidades capaces de calcular Shaders.
Tradicionalmente los chips gráficos de ATi y nVidia tenían piezas de Shader y Vertex separadas. Existían ALUs dedicadas a una u otra tarea, siendo más en cantidad las que calculaban Shaders que las que calculaban Vertex.
La cantidad de unidades de unidades para Vertex y Shaders en esos esquemas tradicionales se decidían en base a esquemas teóricos y recomendaciones de los desarrolladores. El problema de estos sistemas ocurría cuando se necesitaban más unidades de una u otra clase de las que se tenían. En tales casos se necesitaba de más ciclos de trabajo para calcular esas diferencias.
Para que se entienda si un sistema tiene X cantidad de unidades de Shaders (o Vertex) y específicamente necesitaba calcular un número mayor entonces necesitaba de ciclos de trabajo extras para hacer ese cálculo. El problema generado es que en muchos casos era común que las unidades de la otra clase ya hubieran terminado de hacer sus cálculos pero debieran esperar a que las otras terminaran sus trabajos para poder exhibir un resultado combinado.
Con el sistema de unificación ATi pretende que cada desarrollador asigne libremente a cada ALU que es lo que deba calcular. En el caso del ejemplo anterior si es necesario calcular una X cantidad de Shaders (o Vertex) el desarrollador puede asignar la cantidad de ALUs que desee (de las que tiene disponibles y ociosas) para acelerar el proceso y no tener que estar limitado por la cantidad de origen que en un chip tradicional se tenia de unidades de una clase y tener que dejar al resto de la otra clase en estado de espera. El resultado final es el ahorro de ciclos de trabajo y mejoramiento del rendimiento final.
Un efecto secundario de haber unificado las unidades ALU es el hecho de que ahora el desarrollador disponga de una cantidad de unidades para Vertex mucho mayor que la que en otro tipo de chips gráficos habría tenido. Lo que en resultados visuales seria una capacidad de generación de figuras geométricas de mucha más complejidad que las vistas hasta ahora y que serian imposibles de lograr en chips gráficos tradicionales con el mismo rendimiento que en el Xenos. Esto no solo porque se puedan dedicar todas las unidades ALU a Vertex sino porque también hablamos de un sistema que es capaz de calcular el doble de operaciones del eje Z que cualquier otro chip grafico que se exista hoy en el mercado.
Un punto muy importante del Xenos es el API con el que trabaja. Como es de esperar es DirectX. Pero específicamente no es el DirectX 9 tradicional. Microsoft al ser propietaria de tal API realizo modificaciones en el mismo. Los resultados que se observan en estas modificaciones que el los requisitos de los Shaders Models 3.0 están excedidos por el Xenos. Específicamente tales excesos obedecen a cumplir con las primeras prestaciones de los requisitos de los fututos Shader Models 4.0 que se implementaran en el DirectX 10 (WGF 2.0) en Longhorn. En este sentido el API de Xenos si bien sobre la base del DirectX 9 es un paso mas alto con mira a las prestaciones del DirectX 10.
Un elemento llamativo del Xenos también es su adaptabilidad a cálculos de punto flotante de alto nivel. Aunque por ahora los desarrolladores han declarado no tener demasiadas ideas de cómo usarlo. En este punto ATi ha dado ideas de que tal exceso de capacidad de punto flotante puede usarse para acelerar tareas de lógica de alto nivel (como ser físicas o IA) o para mejorar los procesos de iluminaciones globales o el rendimiento general del sistema.
Aunque suena un poco complejo el tener que dedicar un chip grafico a tareas que normalmente serian propias de la CPU del sistema en el caso de que se utilice el Xenos para acelerar físicas o IA. El potencial esta disponible y son los desarrolladores los que tienen que utilizarlo en todo caso.
Por ultimo para cerrar con el Xenos hay un detalle a tomar en cuenta: la cantidad de memoria de la que dispone. El Xenos accede a 512 Mb de Ram GDDR3 a 700 Mhz. Lo característico de esos 512 Mb de Ram es que son compartidos por todo el sistema (UMA) el cual tiene accesos a esta memoria al mismo clock. El objetivo de una memoria dispuesta en condiciones UMA es que el desarrollador libremente pueda asignar cuanta Ram se dedica a procesos generales y procesos de video. Xbox contaba con 64 Mb de Ram en estas mismas condiciones.
Uno de los puntos ventajosos de la memoria UMA esta en poder destinar la cantidad de memoria que se desea a uno u otro proceso sin tener que contar con limites prefijados y problemas de asincronía. Un desarrollador cuando trabaje con Xenos podría destinar una cantidad de memoria mayor o menor a los 256 Mb tradicionales de las placas de video actuales para aumentar el potencial de los gráficos o el potencial del proceso general. El limite a estas variables esta en que cuando se asigna a un proceso mas memoria se le esta quitando al otro, por lo que no se podrían dedicar por ejemplo los 512 Mb totalmente a gráficos. Sin embargo teniendo en cuenta que Xbox con solo 64 Mb de Ram también UMA pudo tanto generar gráficos de alto nivel y a la vez procesar en buen sentido el resto de procesos generales de sus juegos, entonces no seria algo muy raro que los juegos de Xbox 360 usen en sus gráficos mas de 256 Mb de Ram hasta cifras de 400 Mb cono natural. Una ventaja que se puede apreciar mucho al momento de cargar texturas complejas en alta resolución y con procesos de AAx4.
nVidia y el RSX.
Sony al momento de crear su chip grafico encargo el diseño a nVidia. Esta ultima para crear el RSX tomo como base al desarrollo actual de ese momento, el G70, que da origen a la 7800 GTX.
Uno de los problemas al hablar del RSX es la poca información que hay específica sobre el mismo. Muchos de los datos que se tienen están extrapolados de la 7800 GTX pero no se sabe mucho en cuanto para mas o para menos habrían de cambiar o mantenerse iguales.
Otro inconveniente derivado de esta falta de información es el hype tradicional que nVidia hace acerca de sus chips gráficos al punto en este ultimo tiempo de considerar que el RSX es igual en rendimiento a cuatro placas de video 7800 GTX en Quad SLI. Si solo tenemos en cuenta que cada una de estas 7800 GTX conlleva 512 Mb de memoria Ram GDDR3 a 1700 Mhz y un ancho de banda 54.4 Gb/s y esta cifra debería además ser multiplicada por cuatro por la modalidad Quad SLI; es que entonces el RSX con solo 256 Mb GDDR3 a 700 Mhz de Ram y 35 Gb/s de ancho de banda no tiene ninguna explicación real ni posible para suponer mejor rendimiento del RSX contra la configuración anterior.
El RSX es en si una 7800 GTX custom. Las principales modificaciones que tiene están basadas en compatibilizar el chip con el funcionamiento del CELL y tendiente a un aumento del rendimiento final del sistema.
De las mejoras conocidas una de ellas es que nVidia declaro que el RSX correría a 550 Mhz (aunque en el tema de la velocidad nVidia a veces no llega a cumplir todo lo que promete, con Xbox prometió un chip a 300 Mhz y quedo en 233).
En general la serie de mejoras del RSX por los datos aportados por nVidia serian de un aumento de la velocidad general del sistema en un 28% de lo que una 7800 GTX puede dar. Aunque por otro lado el ancho de banda del RSX es algo menor al de una 7800 GTX y seria de solo un 60% aparentemente por los datos dados por nVidia. Se especula que algunas de las mejoras del RSX son provenientes de la arquitectura que nVidia tendría en mente usar en el G71 el cual esta planeado para correr a 650 Mhz.
Mucho del misterio del RSX esta en que no se sabe si las mejoras de potencia que tiene están generadas por el propio chip del RSX o por el apoyo que CELL le daría a este chip.
El problema por ahora del RSX es su ancho de banda menor que el de la 7800 GTX, lo cual impone un limite de lo que en teoría podría hacer, a lo que en realidad podrá hacer. Este límite puede ser contraproducente al momento de aumentar el traspaso de datos con CELL por lo que lo ideal es que RSX sea más potente por si, que por la colaboración que pueda tener con CELL (lo cual lo haría muy dependiente del limite del ancho de banda). Este problema, además, se notaria en juegos que pretendan llegar a los 1080p.
La memoria de que dispone el RSX es de 256 Mb GDDR3. El resto de la consola cuenta con otros 256 Mb Xdram (de mejor rendimiento). PlayStation 3 estipulo su forma de trabajo en dividir la memoria de video de la memoria general y hacerlas correr a diferentes clocks. Esto en principio implica que un desarrollador cuenta con 256 Mb de Ram para procesos generales y otros 256 Mb de Ram para video. Si un desarrollador pretendiese usar mas memoria para uno u otro proceso no le seria, en principio, posible.
Específicamente hablando existe igualmente la posibilidad de que un desarrollador en caso de necesitar mas memoria para uno u otro proceso tome el excedente de la otra. El problema es que esta no seria una acción normal para la cual PlayStation 3 esta preparada naturalmente. En detalle: si un desarrollador desea tener mas memoria para procesos generales y hay un sobrante de video, puede usar ese sobrante; pero a costa de perder rendimiento final.
Para que se entienda, desde el momento que las memorias corren a diferentes clocks y están separadas en grupos de trabajo diferentes el desarrollador tiene que enfrentarse a dos problemas al acceder a la memoria de un grupo diferente: por un lado tiene la tarea de considerar que ahora tendría dos grupos de memorias a diferentes velocidades pero corriendo un mismo proceso lo cual implica perder ciclos de trabajo solamente por la coordinación de ambos clocks, y al mismo tiempo regular ese acceso a la otra memoria por el ancho de banda general del RSX con el resto del sistema (ancho de banda que además es mas escaso que el de una 7800 GTX) a costa de no poder usar esa porción de ancho de banda (dedicada al acceso de memoria) para otros procesos naturales como la comunicación con el CPU. Por este motivo es que esta opción de acceder memorias de diferentes bloques seguramente no será tomada en cuenta y en caso de que lo sea a costa del rendimiento general en otras áreas.
Sobre el API por el cual trabaja el RSX este tiene un rango de variedad mucho mejor que el del Xenos de Microsoft. Cuenta con tres posibles APIs. Por un lado DirectX 9, el Open GL de turno y además el API propio de Sony (que seguramente será un derivado del que se estaba usando en PlayStation 2). Tanto el DirectX como el Open GL son totalmente compatibles con las especificaciones de los Shader Models 3.0. El desarrollador que desee programar para PlayStation 3 puede elegir entre tres posibilidades de librerías, según su experiencia previa, y no esta limitado a una sola como en el caso de Xbox 360.
El inconveniente del DirectX 9 y Open GL usados en RSX es que están trabajando sobre los estándares actuales de PC y no apuntando a futuro para las especificaciones de los Shader Models 4.0. En ese sentido esta limitación puede no ser aparente en los dos primeros años de vida de PlayStation 3 pero cuando la gama de placas de video cambie para cumplir con esta norma y el DirectX 10 y Open GL next estén presentes el desfase de API en PlayStation 3 implicara un tanto mas de trabajo para aquellos juegos que sean portados de Xbox 360 o de PC en readaptar los efectos a la librería anterior.
Un dato que aun queda por confirmar es el tema de cual es el rendimiento real del RSX. Este punto suele ser de conflicto en el caso de los chips gráficos nacidos de desarrollos para PC. Es un hecho común que los chips gráficos de placas de video tanto ATi como nVidia actuales solo llegan a promedios del 60% o 70% de su poder al momento de correr juegos. En muchos casos las propias limitaciones de arquitectura de tales chips impiden que todo el sistema este corriendo al 100% de su poder y en muy pocos y contados casos pueden pasar los topes anteriores. Por supuesto, en un benchmark cualquier chip grafico muestra un resultado que parece ser muy prometedor. Pero un benchmark no es un juego ni tiene la complejidad de condiciones de uno.
ATi considera que ha logrado solucionar ese tope de rendimiento al que las placas de video podían llegar en condiciones complejas con las innovaciones de arquitectura del Xenos. Por el contrario nVidia solía corregir estos límites al rendimiento simplemente aumentando el número de ALUs y clock de sus placas. Es común ver que placas de video ATi con menor clock y cantidad de valores superen en rendimiento a placas de nVidia de mayores especificaciones. Tal fue el caso de casi toda la línea FX en comparación con las de misma gama de las Radeon.
El RSX es el derivado del esquema de trabajo de nVidia y hereda los problemas de limitaciones de rendimiento propias de las arquitecturas de las placas de video de nVidia. El tema entonces esta en saber en cuanto la potencia del RSX ha sido aumentada para corregir estas limitaciones.
Mucho más del RSX no puede hablarse realmente porque el resto de datos son más especulaciones, que otras cosas y datos no confirmados.
1080p una cuestión problemática.
Una de las ventajas teóricas del RSX y PlayStation 3 por sobre Xenos y Xbox 360 es su mayor capacidad de resolución para llegar a 1080p cuando Xbox 360 solo llegaría a 1080i. La diferencia de calidad entre 720p y 1080p es más que notoria, y los 1080i en muchos casos resultan de menor calidad que los 720p.
Cuando se trata de visualizar películas el DVD9 esta algo agotado. Si hoy usted tiene un TV de 42” de plasma la calidad de una película en DVD9 no es del todo satisfactoria y la compresión de nota demasiado. La salida de 1080p de PlayStation 3 es más que necesaria si lo que realmente se desea crear es una consola de real alta definición para visualizar películas. Cuando Sony catalogo que la verdadera alta definición comenzaba con ellos no se equivoco al menos si a lo que se estaba refiriendo era a la reproducción de películas.
Pero ahora el problema con los 1080p de PlayStation 3 es en cuanto son reales en videojuegos y en cuanto se quedan en un agregado para visualizar películas haciendo uso del formato BR.
El inconveniente de la resolución 1080p es el alto consumo de recursos que en un videojuego puede implicar que en muchos casos implica el sacrificio de otros elementos como el framerate o el AA. Siendo que a 720p se podría combinar todo junto.
El punto es que el ancho de banda limitado del RSX actúa como tope real a lo que en teoría puede hacer poniendo en una balanza de un lado a los 1080p y del otro a las operaciones de Vertex, al framerate, y al AA.
El resultado es que el RSX no puede garantizar en todo sentido los 1080p a 60 frames estables y con AAx4 en todos los juegos. Entonces esto pone al desarrollador en la tarea de elegir en muchos casos entre una u otra condición, pudiendo en muy pocos casos combinar ambas.
Inclusive el no imponer ningún tipo de estándar de resolución mínima a las desarrolladoras en los juegos, por parte de Sony, deja aun más en algo teórico el mayor poder de resolución de PlayStation 3 ya que muchas desarrolladoras inclusive podrán optar por ni siquiera usar los 720p sino 420p o la definición estándar. Y teniendo en cuenta que desarrollar en definiciones mas bajas es mas económico es algo mas que preocupante darles esa libertad.
Además esta el tema de la doble DVI de PlayStation 3. Siendo claros, el modo 1080p a doble DVI es más que poco realista. En esa resolución el RSX seria exigido a tal nivel de 4 megapixels por marco que los el framerate sufriría todo tipo de recortes.
Microsoft por el contrario ha apuntado a un estándar mas bajo de 720p pero realista. Los juegos en Xbox 360 a 720p con AAX4 son totalmente posibles y en general deberían serlo a 60 frames estables (aunque esto también depende mucho del interés que los desarrolladores tengan en depurar el código de sus juegos y no sacarlos con apuros o poco depurados y a 30 frames).
Otro inconveniente para Sony es el tema de los TV actuales de alta definición. La mayoría de TVs de alta resolución venideros están trabajando a 720p porque esa es la resolución que han adoptado como estándar por los próximos años. Los TVs a 1080p por ahora no son una realidad. Los pocos que hay son altamente costosos y trabajan además a una tasa de Hertzios muy baja. Recién estos TVs serán accesibles en costo y trabajaran a buena tasa de Hertzios para cuando sean los últimos años de vida de PlayStation 3 como consola de alta gama.
La conclusión con el tema de la resolución es que los 1080p de PlayStation 3 son algo posible. Pero no en todos los juegos y con todas las condiciones. Los juegos que usen AA simplemente no llegaran a esa resolución o si lo hacen será a costa del framerate. Para Microsoft los 720p son algo real y combinados con el AAx4 se verán muy mejorados en TVs de 720p al punto de que estarán casi a altura de los que corran en 1080p.
