disección de ps3 y 360

Hola gente, la verdad es que este tema esta bastante quemado ya, pero e encontrado en meri a un forero que hace una disección de ambas maquinas bastante objetiva e interesante MUST-SEE

COPY&PASTE [poraki]
bueno es un poko toxo pero interesante


Sobre PlayStation 3 y Xbox 360 en general.

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? <.. Importante

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. <...Importante

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.

La cuestión del Disco Rígido.

Tanto PlayStation 3 como Xbox 360 dispondrán de discos rígidos. En ambos casos estos no serán un elemento de serie de todas las consolas.

En principio Microsoft parecía que tomaría la misma medida que con Xbox al colocar de serie un HDD en Xbox 360. Posteriormente y casi seguro que por ahorro de costes decidieron lanzar una versión económica sin el HDD. Esta decisión fue más que pésima de parte de Microsoft, ahora los desarrolladores ya no podrán tomar la existencia de un disco rígido como elemento de serie para sus juegos sino que tendrán que calcular su no existencia como el estándar de trabajo.

El problema de la decisión de Microsoft de quitar de serie el HDD fue además el haberla tomado en último momento poco antes del lanzamiento de su consola cuando muchos desarrolladores ya tenían en mente su uso para los juegos. Tal fue el caso de Bethesda Softworks que al recibir el comunicado de Microsoft de que tendrían que hacer sus juegos para que funcionasen como si el HDD no estuviera esta respondió que su juego correría en Xbox 360 sin el HDD, pero que era altamente recomendado que se lo corriera en una consola que si lo tiene.

Realmente como el juego aun no salio no sabemos hasta que punto se notaran las diferencias en este juego al correrlo en una Xbox 360 con HDD y otra sin el HDD. Pero podemos especular que corrido el juego en la versión de la consola sin HDD posiblemente tenga una cantidad de cargas muy superiores o algunos recortes eventualmente. En realidad es pura especulación, pero por algún motivo Bethesda Softworks recomendó altamente que el juego sea corrido en la versión con HDD.

El punto es que esto luego no se transforme en que ciertos juegos de Xbox 360 son “HDD recomended” y otros no. Haciendo que existan usuarios con mejores prestaciones y otros con menores al mejor estilo PC.

El motivo aparente de Microsoft al quitar el HDD fue el ahorro de costes. Según Microsoft el HDD es útil para las descargas, el juego en línea y la retrocompatibilidad actualizable (la cual por ahora es mas una teórica que real por sus constantes pantallas de “este juego no esta soportado por favor actualice la compatibilidad en línea”, que hace pensar que Xbox 360 es lo mismo que haberse comprado un juego PC para luego tener que parcharlo). Pero por ahorro de costes calcularon la existencia de jugadores no interesados en estas opciones y entonces quitaron el HDD como elemento de origen logrando así abaratar sus costes.

PlayStation 3 tampoco tendría un disco rígido de serie. También este seria un accesorio. Lo único que no esta claro es si se lanzara a la venta una versión con HDD y otra sin o todas vendrán sin el HDD y luego este tendría que ser comprado aparte.

¿Potencia o Rendimiento?

Esta es una cuestión crítica en la comparación entre PlayStation 3 y Xbox 360. En general es coincidente la opinión entre las desarrolladoras de que PlayStation 3 es marginalmente más potente que Xbox 360. Pero al mismo tiempo Xbox 360 ofrece un mejor rendimiento final en razón de su potencia.

En cuestiones de hardware no necesariamente mayor potencia es mejor rendimiento. Por ejemplo si tomáramos dos procesadores de PC. Uno de ellos un Intel de X potencia y otro de ellos AMD con 100 Mhz (reales, no los Mhz+) menos el Intel seria mas potente. Pero en rendimiento final el AMD seria mejor por su forma de trabajo con porciones de datos más grandes. También en el mundo de las placas de video esto es algo común. Muchas de las placas nVidia suelen ser más potentes que las ATi de la misma gama pero en muchos casos las ATi terminan teniendo el mismo rendimiento que las nVidia con menos potencia o aun mejor rendimiento final. Tal fue el caso de casi toda la línea Fx comparada con las de línea Radeon.

Inclusive en el mundo de las consolas mayor potencia no siempre significo mejor rendimiento. Para el caso de esta generación el Emotion Egine es el CPU de mayor potencia. Pero aun así el rendimiento de PlayStation 2 aun todo el apoyo que obtuvo de las desarrolladoras quedo por debajo de los resultados de NGC y Xbox con CPUs menores (en mucho parte por los defectos de arquitectura de PlayStation 2 relativos a su unidad de gráficos). Inclusive Dreamcast siendo marginalmente menor que PlayStation 2 en algunas cuestiones tenía un mejor rendimiento que esta ultima como ser en cuestiones de texturado, aunque con un resultado menor en velocidad de proceso.

Siendo que ambos sistemas en general son comparables en cuanto a condiciones en muchos casos queda la duda de que consola será la que mejores resultados obtenga.

¿Hasta que punto la mayor potencia de PlayStation 3 puede ser usada como una ventaja a su favor o hasta que punto el mejor rendimiento practico de Xbox 360 puede poner a su favor los resultados finales con un poco menos de potencia?

Esa pregunta no se puede responder en un análisis previo. Cada consola tendría que demostrarlo en la práctica.

Los mejores gráficos.

El aspecto más conflictivo de todos al momento de comparar una consola es el de determina cual tendrá los mejores gráficos. Habiendo ya sacado de la comparativa a Nintendo Revolution y estando en general claro que esta será una consola mas discreta en el tema de gráficos la pregunta esta centrada en PlayStation 3 y Xbox 360.

Ni un margen mayor de potencia ni uno de mayor rendimiento del otro le garantizan mejores gráficos a uno u otro sistema.

Lo evidente es que en cuestiones graficas PlayStation 3 viene mejor preparada en algunos elementos mientras que Xbox 360 lo esta en otros. El mayor poder en punto flotante de PlayStation 3 le puede permitir acceder a efectos de partículas muy complejos que en Xbox 360 le serian muy difícil de calcular a la misma velocidad y con la misma calidad. Por otro lado Xbox 360 al enfocar sus ALUs genéricas todas a procesos de Vertex y usar su potencia superior para cálculos del eje Z podría calcular escenas geométricas a un nivel tan complejo que para el RSX le serian imposibles en esa misma velocidad. El mayor poder de punto flotante de PlayStation 3 podría ser también enfocado para generar texturados más complejos y detallados, pero las mejores condiciones de memoria de Xbox 360 podrían ser enfocadas a cargar texturas más densas y definidas mejoradas por un AA de mayor nivel.

Podría seguir en todo sentido encontrando mejores elementos gráficos que un sistema puede manejar y otros que los maneja mejor el otro sistema.

En todo caso la batalla de los gráficos en la nueva generación no esta ganada de origen por un solo sistema como en esta que la superioridad tecnología de Xbox en general ya le daba casi la totalidad de condiciones a su favor por sobre el resto. Aunque en general el planteo de Xbox 360 puede en principio darle la victoria parcial al poder explotar su poder de manera más sencilla y rápida. Posteriormente se vera quien resulta ganador en ese tema aunque seguramente habrán victorias parciales en ciertas áreas para un sistema y para el otro en otras áreas.
Esto mismo lo postee yo en un post que se llama "Ps3 vs Xbox 360 (objetivo)" ya veras, hay gente por aqui que te va a freir a criticas como me hicieron a mi (Todos los criticones eran pro-Ps3...), la verdad esque yo te agradezco que me lo vuelvas a recordar, me parece un texto sumamente interesante del que se pueden aprender muxas cosas, un saludo!
Ya no es que sea el enésimo hilo sobre el mismo tema... es que me sorprende que se insista tanto en discutir estas cosas cuando aún no se saben los specs finales de PS3.

¿Nadie piensa en esperar a tener las dos para analizarlas debidamente? O mejor aún. ¿Sería necesario hacerlo aun en caso de estar ambas en la calle? Me preocupa más el apoyo que reciba cada una y, sobre todo, los juegos que tengan.
offtopic

Joder, te acabas de cargar la ruedecita de mi ratón

X-D
gran articulo pero todo ya se sabia..... y me parece que muchas personas se daran con un canto en los dientes por el rendimiento de ps3.
Excelente artículo, muy técnico y preciso. Gracias por la info.
..y de gastar un cartucho de tinta negra recién instalado XD

No he leído mas que dos párrafos, este ladrillo no se lo come nadie [mad] lo que no quita el mérito de haberlo escrito y puesto por supuesto. en fin, que como bien dicen, ya veremos como los juegos aprovechan las máquinas, entonces podremos deducir los inconvenientes de cada una.
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.


va a ser que no (a no ser que se esten refiriendo al disco duro de x360)
Project-2501 escribió:va a ser que no (a no ser que se esten refiriendo al disco duro de x360)
Se ha demostrado que el Blu-Ray resulta más lento a 2x (el supuesto lector de PS3) frente al DVD 12x de Xbox360.

O eso tengo entendido. Si encuentro algún link lo posteo.
Saludos
Jur he tardao un WEVO en leerlo, el jefe no para de pasar por detras mio¡¡ JAJAJA
Ha dicho sony en algun momento q su lector de blue-ray sea de 2x? (solo pregunto, xq no me suena haberlo leido)
Es por lo menos la tercera vez que se pone el mismo articulo en este foro.

Lo de la lectura de los BR y los DVD, pues un DVD de 12x tiene una velocidad de lectura media (los 12x solo se alcanzan en la parte más externa del DVD) ligeramente mejor que un lector de BR de 2x pero no hay diferencias significatibas.

Ha dicho sony en algun momento q su lector de blue-ray sea de 2x? (solo pregunto, xq no me suena haberlo leido)

No nunca lo ha dicho, 2x es la velocidad minima de los lectores/grabadores de blu-ray anunciados que soporten peliculas.
2 graves errores:

Primero las unidades PPC de la XBOX360 no son G5, son muy diferentes, son mas parecidas a un G3+VMX.

Segundo los SPE no tienen problema para calculo de enteros, su problema viene a que son micros vectoriales, buenos para el calculo vectorial y malos para el calculo trivial, es decir son malos cuando hay muchos saltos/ejecuciones condicinales en el codigo, algo muy habitual en juegos.
lo siento si el articulo ya se habia posteado [risita] si lo e puesto es por que parece interesante y parece que la persona qu habla entiende vastante de lo que dice, sin inchar ni tirar mierda hacia nadie.
Elohe con respecto a lo que dices del ppc yo diria que era 1 G5custom+vmx por core?¿?
Elohe escribió:2 graves errores:

Primero las unidades PPC de la XBOX360 no son G5, son muy diferentes, son mas parecidas a un G3+VMX.

Segundo los SPE no tienen problema para calculo de enteros, su problema viene a que son micros vectoriales, buenos para el calculo vectorial y malos para el calculo trivial, es decir son malos cuando hay muchos saltos/ejecuciones condicinales en el codigo, algo muy habitual en juegos.


Son malos en ese tipo de codigo por que no tienen predictor de saltos dinamico (soporta prediccion estatica), pero vamos si metes saltos que no son predecibles nunca tumbas cualquier CPU moderna.

Lo de que son micros vectoriales lo son tanto como cualquier CPU de IBM que tenga un VMX simplemente tienen el VMX integrado en el pipeline normal al haberse diseñado desde 0 para incluirlo.
Lo cierto es que CELL tiene muy buena pinta, en el futuro con un bajo coste podria ser el DSP perfecto, pudiendo hacer con el cosas interesantes digitalizar, decodificar y descomprimir directamente televisión digital sin necesidad de sintonizador, en decenas de canales simultaneos y poder grabar varios de ellos simultaneamente, sistemas de reconocimiento visual en tiempo real y un sinfín de cosas, cuando se reduzca de tamaño (porque ahora mismo es un chencho de 12 cm²) podria incluirse toda la circuiteria de un movil en el chip...

El Blu Ray seguramente sea tambien un formato de disco estupendo para almacenaje de datos, seguramente las consolas de proxima generación lo implementen todas si para entonces los cartuchitos holográficos no son aun competitivos (sino seguro que nintendo los usará porque la cabra tira al monte).

La cuestión es que son tecnologias muy nuevas, aun no están en el mercado ninguna de las dos y van a usar para ello como caballo de troya (o cabeza de turco) PS3, esperando que la utilización en un cacharro de consumo masivo haga bajar el precio de producción de ambos. Y mi opinión es que nunca se puede poner "lo último" en una consola de videojuegos, porque al final te acaba costando un ojo de la cara y no llegas a aprovecharlo bien. Si el coste de producción llega a 800$ les va a salir por un ojo de la cara venderlo. Es una jugada excesivamente arriesgada sobretodo cuando eres el primero del mercado, y si encima dichos componentes no son los más adecuados para lo que se propone (una máquina de videojuegos), se puede decir que están haciendo un pan como unas ostias.

Veremos en que queda todo.
Gurlukovich escribió:Lo cierto es que CELL tiene muy buena pinta, en el futuro con un bajo coste podria ser el DSP perfecto, pudiendo hacer con el cosas interesantes digitalizar, decodificar y descomprimir directamente televisión digital sin necesidad de sintonizador, en decenas de canales simultaneos y poder grabar varios de ellos simultaneamente


Para eso mejor usas un DSP de verdad, los hay tirados de precio, todabia no tengo claro para que quiere Toshiba meter Cell en Televisores.
Es que CELL en si es un DSP como aquel que dice, puede ser fabricado con diseños personalizados, tiene más uso para tratamiento de señal que no para uso general. Por supuesto hoy en dia no es lo más economico ni lo más recomendable, pero puede ser perfectamente la base de este tipo de aplicaciones en un futuro.

En cuanto a por que quieren meterlo está claro, primero que nada porque se han dejado la pasta en su desarrollo, y segundo porque vale para lo que he dicho, reducir circuiteria y dar funcionalidades nuevas. Despues de todo cada cacharro vale para lo que vale.
pasodelnik escribió:Elohe con respecto a lo que dices del ppc yo diria que era 1 G5custom+vmx por core?¿?
Se parece mas al G3, pero no deriva de ningun diseño previo, mira esto para tenerlo mas claro:
http://arstechnica.com/articles/paedia/cpu/ppc970.ars/1
http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars
deathkiller escribió:Son malos en ese tipo de codigo por que no tienen predictor de saltos dinamico (soporta prediccion estatica), pero vamos si metes saltos que no son predecibles nunca tumbas cualquier CPU moderna.
No tumbaras a un CPU, pero a los SPE los tumbas.
deathkiller escribió:Lo de que son micros vectoriales lo son tanto como cualquier CPU de IBM que tenga un VMX simplemente tienen el VMX integrado en el pipeline normal al haberse diseñado desde 0 para incluirlo.
Las SPU no tiene el VMX implementado en el pieline normal, es un diseño vectorial SIMD casi puro. Y cualquier CPU de IBM con una unidad VMX no es una CPU vectorial, es un CPU de proposito general con capacidades vectoriales, necesita cumplir algunos requisitos para ser una cpu vectorial que no cumplen y que los SPE si que cumplen.

A ver si esto te aclara algo, para estas diferenciaciones no se consideran algunas intrucciones especiales.

Un G5 es capaz de ejecutar intruciones SISD y SIMD, por lo tanto no es una CPU vectorial.
El SPE solo puede ejecuat instruciones SIMD, por lo tanto es una CPU vectorial.
EL Itanium puede ejecutar instruciones MIMD, Por lo tanto es una CPU vectorial.(Emula intruciones SISD con intruciones MIMD conteniendo operandos nulos, ejecutar MIMD implica poder ejecutar SIMD al poder ser consideradas un operando especial de MIMD)

*MISD no se contempla al ser consideradas intruciones SISD complejas.
esto ya lo he leido...

Imagen

fallo en matrix?

saludos cordiales.
GXY escribió:esto ya lo he leido...

Imagen

fallo en matrix?

saludos cordiales.


No en nuestras putas cabezas :P

Habrá que leerlo, deseadme suerte [jaja] [jaja]
Elohe escribió:Se parece mas al G3, pero no deriva de ningun diseño previo, mira esto para tenerlo mas claro:
http://arstechnica.com/articles/paedia/cpu/ppc970.ars/1
http://arstechnica.com/articles/paedia/cpu/xbox360-2.ars
No tumbaras a un CPU, pero a los SPE los tumbas.
Las SPU no tiene el VMX implementado en el pieline normal, es un diseño vectorial SIMD casi puro. Y cualquier CPU de IBM con una unidad VMX no es una CPU vectorial, es un CPU de proposito general con capacidades vectoriales, necesita cumplir algunos requisitos para ser una cpu vectorial que no cumplen y que los SPE si que cumplen.

A ver si esto te aclara algo, para estas diferenciaciones no se consideran algunas intrucciones especiales.

Un G5 es capaz de ejecutar intruciones SISD y SIMD, por lo tanto no es una CPU vectorial.
El SPE solo puede ejecuat instruciones SIMD, por lo tanto es una CPU vectorial.
EL Itanium puede ejecutar instruciones MIMD, Por lo tanto es una CPU vectorial.(Emula intruciones SISD con intruciones MIMD conteniendo operandos nulos, ejecutar MIMD implica poder ejecutar SIMD al poder ser consideradas un operando especial de MIMD)

*MISD no se contempla al ser consideradas intruciones SISD complejas.


Me habia liado al ver el ISA, de todas maneras excepto por que todos los calculos usan grupos de 4 u 8 numeros (sin tener peor rendimiento que una CPU que solo hiciera el calculo sobre un numero) no hay tanta diferencia.

Comparativamente el PPU tiene una penalizacion de 8 ciclos de latencia cuando hace operaciones de coma flotante o vectoriales (ambas se hacen en el VMX).

Y te digo que si, los saltos fallidos tienen una penalizacion brutal en P4 y Athlon, dependes de que se repitan mas o menos igual durante la ejecución siempre.
deathkiller escribió:Me habia liado al ver el ISA, de todas maneras excepto por que todos los calculos usan grupos de 4 u 8 numeros (sin tener peor rendimiento que una CPU que solo hiciera el calculo sobre un numero) no hay tanta diferencia.
En calculo bruto, rinden mejor, pero los saltos condicionales estan jodidos en las SPU por la ISA(llegan a penalizar asta mas de 80 ciclos), hay un grupo de menos 20 instruciones que si se hubiesen incluido en la ISA de la SPU la habrian tranformado en un CPU interesante y no habria echo falta la PPU para nada.


deathkiller escribió:Y te digo que si, los saltos fallidos tienen una penalizacion brutal en P4 y Athlon, dependes de que se repitan mas o menos igual durante la ejecución siempre.
Seran los saltos mal predecidos, la penalizacion del Athlon no es tan brutal, es muy comedida, la de los P4 llega a ser brutal.

penalizacion -> cpu

20 ciclos -> Pentium4 antes de la llegada de los Prescott
31 ciclos -> Pentium 4 Prescott y posteriores
10 ciclos -> Athlon
12 ciclos -> Hammer (Athlon64, Opteron, Turion)
16 cislos -> PPC970
07 ciclos -> G4
21 ciclos -> CELL PPU
GXY escribió:esto ya lo he leido...

Imagen

fallo en matrix?

saludos cordiales.


Y yo, pero mas o menos me acuerdo de algo, lo hizo un tal heulen, ke es el creador de
este hilo (el original) y despues puso en eol el link

salu2
Elohe escribió:En calculo bruto, rinden mejor, pero los saltos condicionales estan jodidos en las SPU por la ISA(llegan a penalizar asta mas de 80 ciclos), hay un grupo de menos 20 instruciones que si se hubiesen incluido en la ISA de la SPU la habrian tranformado en un CPU interesante y no habria echo falta la PPU para nada.


Seran los saltos mal predecidos, la penalizacion del Athlon no es tan brutal, es muy comedida, la de los P4 llega a ser brutal.

penalizacion -> cpu

20 ciclos -> Pentium4 antes de la llegada de los Prescott
31 ciclos -> Pentium 4 Prescott y posteriores
10 ciclos -> Athlon
12 ciclos -> Hammer (Athlon64, Opteron, Turion)
16 cislos -> PPC970
07 ciclos -> G4
21 ciclos -> CELL PPU

Curioso, la unica penalizacion que se menciona en la ISA es 18 ciclos ¿donde leiste 80?
¿Que instrucciones son las que has hechado en falta?
Yo la multiplicacion de 32 bit, operaciones de 64 bit e instrucciones de division.
La primera implica usar 3 instrucciones para una multiplicacion de 32 bit, el resto no se.
GXY escribió:esto ya lo he leido...

Imagen

fallo en matrix?

saludos cordiales.

Ya que lo has leido dos veces, ¿podrias hacerme un resumen? [carcajad]
Yo le veo un error al texto.. dice que X360 se va a convertir en el estándar.... y si la PS3 tiene ya no más, sino casi el mismo éxito que PS2, lo que veremos serán ports de PS3 a X360, tal como hemos visto ports de PS2 a Xbox...

El estándar no lo marca la calidad técnica, ni la facilidad de programamar, ni la potencia... lo marca la pasta. Si hay más PS3 que X360, los estudios se volcarán en programar para PS3, e intentarán gastarse lo mínimo en el port a X360... así lo aprendí yo :Ð
deathkiller escribió:Curioso, la unica penalizacion que se menciona en la ISA es 18 ciclos ¿donde leiste 80?
No lo lei, viene de haber portado un trozo de codigo de X86_64+SSE2, paso de una penalizacion maxima de 12 ciclos a entre 76 y 90 ciclos cuando lo esperando eran 18 y no hay manera de reducirla, si bien es cierto que en la version X86_64 se usa tanto la ALU como la UV simultaneamente, incorporando alguna intsrucion especial de salto las penalizacion habria desaparecido.
deathkiller escribió:¿Que instrucciones son las que has hechado en falta?
Yo la multiplicacion de 32 bit, operaciones de 64 bit e instrucciones de division.
La primera implica usar 3 instrucciones para una multiplicacion de 32 bit, el resto no se.
Yo echo de falta algunas instruciones condicionales usando mascaras de seleccion, a parte de las que as dicho.
Elohe escribió:No lo lei, viene de haber portado un trozo de codigo de X86_64+SSE2, paso de una penalizacion maxima de 12 ciclos a entre 76 y 90 ciclos cuando lo esperando eran 18 y no hay manera de reducirla, si bien es cierto que en la version X86_64 se usa tanto la ALU como la UV simultaneamente, incorporando alguna intsrucion especial de salto las penalizacion habria desaparecido.
Yo echo de falta algunas instruciones condicionales usando mascaras de seleccion, a parte de las que as dicho.

¿Has intentado trazar que ocurre en la pipeline cuando la penalización es de 90 ciclos?

Me parece raro que se pueda producir un penalización mayor que el pipeline, deberia simplemente vaciarse y comenzar a cargar las instrucciones correctas cuando se da cuenta de error.
deathkiller escribió:¿Has intentado trazar que ocurre en la pipeline cuando la penalización es de 90 ciclos?

Me parece raro que se pueda producir un penalización mayor que el pipeline, deberia simplemente vaciarse y comenzar a cargar las instrucciones correctas cuando se da cuenta de error.
Lo que pasa es que hay varias penalizaciones encadenadas, en el X86_64 el codigo que se ejecuta en la ALU y no en la VU impide dichas penalizaciones y para evitarlas se necesita o ejecutar un poco de codigo en una alu o intruciones especiales que lo eviten como algunas que posee el Itanium.
29 respuestas