La GPU de Wii U varias generaciones por delante de las consolas actuales?

El problema con Wii U también está en Nintendo, por no documentarla bien.

Aquí lo dice bien claro, si no tiras de dividir tareas entre núcleos y si no vacías la memoria principal de tareas que puedas descargar en las cachés (E incluyo los 35MB de caché de la GPU) , amén de lo que puedas hacer con la propia GPU (Que también parece un poco especial) vas a tener problemas de rendimiento por todos los lados.

Ahora bien, los creadores de middleware no tenían documentación ni nada, y no creo que gastasen mucho presupuesto. Las herramientas (Motores como Unreal Engine, por ejemplo) entonces tratarán a Wii U como si fuese una X360, y cuando el desarrollador llegue se encontrará con un rendimiento en consecuencia.

No me extraña ver que los juegos que se ven mejor en Wii U sean los de estudios con motores propios.

Ser mas potente que la de Xbox 360 y la de PS3 si que lo es si tenemos en cuenta ciertos elementos que normalmente se obvian como son las unidades de interpolacin por ejemplo, en todo caso explicar las diferencias supone explicar concepts aburridos y tirar de Algebra. En todo caso el problema de Wii U es el tener que gestionar a mano el Virtual Texturing con tal de evitar el problema del ancho de banda.

jey114 quizá esté equivocado pero yo lo que veo ahí son los 32MB EDRAM de memoría cache y no los 2GB de memoria RAM

Los 32MB no son cache.

Urian escribió:

Ser mas potente que la de Xbox 360 y la de PS3 si que lo es si tenemos en cuenta ciertos elementos que normalmente se obvian como son las unidades de interpolacin por ejemplo, en todo caso explicar las diferencias supone explicar concepts aburridos y tirar de Algebra. En todo caso el problema de Wii U es el tener que gestionar a mano el Virtual Texturing con tal de evitar el problema del ancho de banda.

Pero puedes dar muchos rodeos para evitar la memoria principal a través de la eDRAM y las cachés más grandes. Y a menos accesos, más se mantiene del máximo teórico de ancho de banda.

Sobre la propia GPU prefiero no meterme. No hay un consenso muy claro de lo que realmente tiene así que no se pueden sacar conclusiones definitivas sobre lo que puede hacer. Tampoco me parece que se pueda hacer mucho comparando con imágenes pixeladas de RV770 como están haciendo en GAF.

Berserker escribió:

jey114 quizá esté equivocado pero yo lo que veo ahí son los 32MB EDRAM de memoría cache y no los 2GB de memoria RAM

Es que en cada sitio dicen cosas diferentes... xD
En unos dicen la memoria de WiiU es EDRAM de 2GB y aparte la caché, en otros lados hablan de los diferentes tipos de caché como si fuera EDRAM y la memoria DDR3.

Yo los datos que originalmente se manejaban y en los que me he basado, hablaban que la caché estaba formada por SRAM de baja latencia (alta velocidad) 2MB en primer nivel (divididas en 1mb core 0 y 512kb los 1 y 2) y alta latencia 32mb en segundo nivel (conjunto para CPU y la GPU), para luego las memorias ram (2Gb divididas en 4 modulos de 512 Mb monocanal de alta velocidad) usaban EDRAM.

Esas eran las specs que se hablaron varias veces y las que me parecen mas lógicas, ya que la eDRAM es memoria ram normal, más rápida, y que a veces puede combinarse como caché de tercer nivel. Digamos que un punto intermedio entre la memoria ram normal y la caché.

La EDRAM, hasta donde yo se no puede usarse como memoria caché por que necesita ser "limpiada" por el sistema a menudo.

Urian escribió:

Los 32MB no son cache.

No son caché al uso, si no caché compartida de 2º nivel, que es diferente a la caché convencional.

Las cachés se dividen por niveles y velocidades. Cuanto menor sea el nivel menor es la capacidad de caché pero mucho mayor la velocidad.

Los 32 MB se hablaban de caché de alta latencia en 2º nivel (Para que compartir los datos de CPU y GPU fuera "jodida**nte" rápido). Pero la caché propia de la CPU serían 2 MB.

Si lo comparamos por ejemplo con Intel Core i5 (que también es una APU) nos encontramos con 6 MB de caché total, dividida en 1Mb de nivel 512 kb por core para nivel 1 y 1Mb por core para nivel 2.

Si vamos a un AMD A8 ya nos encontramos con 512 por nucleo para nivel 1 y 4 mb por nucleo para nivel 2, lo cual dan 18 MB

Aún así estamos lejos de los 34MB que tiene la WiiU.


Aunque todo hay que decirlo, posiblemente también me equivoque xD
Por que aquí cada uno dice las cosas al tuntún xD
Y nos encontramos con que tenemos 25 consolas diferentes xD

Estas confundiendo la eDRAM de la CPU que es cache L2 con la de la eDRAM GPU, que esta en otro chip y es memoria local, es más, la cache L2 de la GPU no es la eDRAM.

Urian escribió:

Estas confundiendo la eDRAM de la CPU que es cache L2 con la de la eDRAM GPU, que esta en otro chip y es memoria local, es más, la cache L2 de la GPU no es la eDRAM.

Vaaale, eso explica algunas cosas... xD (precios más que nada)
Si es que al final, es lo que yo decía, aquí cada uno dice lo que le da la gana y no me entero xD

De todas maneras las cantidades de memoria caché que nombré antes (las del i5 y el a8) son verídicas y siguen siendo mucho menores que los de la WiiU, si además me dices que la GPU tiene memoria aparte... pues hasta cierto punto mejor, se pierde parte de esa "supervelocidad" pero se gana capacidad.

El problema es que la gran mayoria de desarrolladores son unos vagos de cuidado y prefieren lidiar con un pozo de memoria que no con dos.

En el caso de las texturas en teoria no necesitas más memoria que la resolución de pantalla * la profundidad de color. Eso en teoria dado que habitualmente se combina la pagina de texturas con el búfer de texturas en cada fotograma, esto provoca que en cada fotograma tengas que tener un ancho de banda enorme, pero de cara a los programadores es mejor dado que les evita lidiar con dos pozos de memoria.

El otro esquema sl separar las dos memorias supone gastar parte de la potencia de la GPU en trasladar los datos necesarios al búfer de texturas cada fotograma, pero hay una trampa con eso, dado que el entorno apenas cambia de un fotograma a otro esas operaciones son mínimas la gran mayoria de veces y encima solo necesitas de ancho de banda una cantidad ridícula desde la RAM principal.

Una vez tienes los datos en la eDRAM puedes operar con ellos sin quitar ancho de banda a la memoria principal para operaciones que requieran acceso multiple. El problema viene con la practica, y es por eso que vemos a desarrolladores cagandose en Wii U, el esquema de Xbox One y cualquier cosa con eDRAM.

Recuerdo como hace unos años Sony se cagaba en ciertos desarrolladores de PS2 que en vez de cargar las texturas en la eDRAM cada fotograma las leían desde la principal e incluso hicieron una presentación de eso, así que no viene de Wii U, viene de largo y desde hace mucho tiempo.

Lo de los 12.8 GB/seg de Wii U se convierte en un problema en el primer momento en que fuerza a esos desarrolladores a tocar el código gráfico, para no hacerlo al unisono dicen que es menos potente incluso que la generación actual o simplemente ves ports recortados por el hecho de que no usan la eDRAM.

Urian escribió:

El problema es que la gran mayoria de desarrolladores son unos vagos de cuidado y prefieren lidiar con un pozo de memoria que no con dos.

En el caso de las texturas en teoria no necesitas más memoria que la resolución de pantalla * la profundidad de color. Eso en teoria dado que habitualmente se combina la pagina de texturas con el búfer de texturas en cada fotograma, esto provoca que en cada fotograma tengas que tener un ancho de banda enorme, pero de cara a los programadores es mejor dado que les evita lidiar con dos pozos de memoria.

El otro esquema sl separar las dos memorias supone gastar parte de la potencia de la GPU en trasladar los datos necesarios al búfer de texturas cada fotograma, pero hay una trampa con eso, dado que el entorno apenas cambia de un fotograma a otro esas operaciones son mínimas la gran mayoria de veces y encima solo necesitas de ancho de banda una cantidad ridícula desde la RAM principal.

Una vez tienes los datos en la eDRAM puedes operar con ellos sin quitar ancho de banda a la memoria principal para operaciones que requieran acceso multiple. El problema viene con la practica, y es por eso que vemos a desarrolladores cagandose en Wii U, el esquema de Xbox One y cualquier cosa con eDRAM.

Recuerdo como hace unos años Sony se cagaba en ciertos desarrolladores de PS2 que en vez de cargar las texturas en la eDRAM cada fotograma las leían desde la principal e incluso hicieron una presentación de eso, así que no viene de Wii U, viene de largo y desde hace mucho tiempo.

Lo de los 12.8 GB/seg de Wii U se convierte en un problema en el primer momento en que fuerza a esos desarrolladores a tocar el código gráfico, para no hacerlo al unisono dicen que es menos potente incluso que la generación actual o simplemente ves ports recortados por el hecho de que no usan la eDRAM.

Pero yo creo que tiene más que ver con los desarrolladores de middleware y los peces gordos de las third parties. (Y también Nintendo por no documentarla)
Lo habrán hecho mal desde el propio motor, y el pobre grupo de cuatro tíos contados a los que han dado cuatro días y el Unreal Engine para que hagan el port no van a estar mirando cómo va la consola, porque bastante tienen con conseguir que funcione. Luego los entrevistan y ponen a parir a la consola para que no los echen.
Ya lo digo más arriba, los que tienen su propio motor (Criterion, Frozenbyte, Shin'En...) hablan bien de la consola.

Este E3 creo que los juegos de Wii U van a sorprender para bien, y van a dar un salto notorio. Dicho esto, ya podían los imbéciles de Nintendo haber demostrado antes lo que la consola puede hacer.