Destripando la WiiU 1/4: La CPU (y vs con Xbox 360 de propina)

Johny27 escribió:

dragonsacred escribió:lo de 19.000 dmips que dijistes sacado de la wikipedia?

ya te dije en su momento que la wikipedia no tiene ninguna fuente, y te puse una fuente de lo que puso info, concretamente neogaf

Sí, ese hilo de neogaf donde se reconoce que es código a pelo sin optimizar para cpus In Order y que si se optimiza puede multiplicar fácilmente por 10 el resultado, y que encima no usa lo spe's en caso de ps3, ya que dichos spe's se usan para lo que uno quiera por mucho que estén dedicados a cálculos más específicos. Y más curioso es que los spe's en especial sobresalgan en dhrystones. Y más aún que solo mide cálculo con enteros, obviando la muy muy importante parte del cálculo en coma flotante,y que encima los spe's hacen el cálculo con enteros con las únidades de coma flotante sin perder apenas rendimiento:

http://www.realworldtech.com/cell/7/

Y encima creemos los datos de uno que ha ejecutado el test a pelo sin saber qué hace, porque como él mismo reconoce "I don't do programming" y que no sabía que los spe's podían ejecutar código de propósito general más rápido que el propio PPE en muchísimos casos.

Pues vaya manera de comparar si nos basamos en eso.

Ya en serio, lo que no se pueden es coger números sueltos e integrarlos en una comparativa sin entender qué significan. Yo veo bien que la gente haga análisis, pero joder, lo suyo es entender lo que estás haciendo, qué significan los datos que tomas y en qué circunstancias fueron tomados antes de dar resultados.

Vamos, que vas dando lecciones por ahí sin saber siquiera lo que es un test de dhrystones.
Dime, ¿cómo se optimiza ese test para CPUs in-order? Ni te molestes, sencillamente no se optimiza porque más optimizado no puede estar.
Un drystone es un programa sencillisímo que se centra en operaciones de enteros una tras otra. ¿Qué vas a optimizar ahí si puede saberse, si ese es el escenario más óptimo para una CPU como esa?
Programa diminuto que cabe perfectamente en la cache L1, con lo que la ventaja sustancial de la cache L2 de tamaño superior queda completamente anulada (aunque en el caso del Cell el PPE cuenta con 512KB de L2 para si mismo, un poco más que los 333KB que le tocaría a cada núcleo del Xenon si se reservase la misma cantidad de caché para todos, pero sigue estando a años luz de los 2MB de cache L2 dedicados del núcleo principal del Espresso).

Además sólo usa un tipo de operaciones (enteros), ideal para el PPE que se las come tal y como llegan se evite los problemas típicos de cuando le metes en un mismo thread operaciones enteras y de coma flotante, que al cambiar la unidad de ejecución se tiene que esperar a que se vacíe la otra porque el pipeline tiene distintos tamaños y se crearían conflictos de no hacerse. El multi-threading, por supuesto, queda descartado porque sólo hay una unidad para enteros, por tanto para qué vas a poner dos threads si al final se tendrán que intercalar entre ellos como si sólo hubiese uno.

Por cierto, en lo referente a lo de que "porqué no se corre el dhrystone" en los SPE, pues la respuesta te la da el mismo enlace que tú mismo pones:
"The SPE is a specialized processing element dedicated to the computation of SIMD-type data streams."
Pones enlaces que ni te lees, me acusas de huir (para qué tendría que huir exactamente? Si me equivoco en algo, me gusta que me corrijan, pero siempre con argumentos y no con acusaciones sin fundamento como haces tú) cuando lo que sucede es que tengo muy poco tiempo para participar en foros y encima te veo un tono de prepotente que "Déu ni dó".

PD: Los que preguntáis por el siguiente destripe, deciros que caerá pronto, y que si está tardando tanto es por dos motivos:
1. Poco tiempo para postear como le he dicho a Johny27.
2. Tenía pensado hacer el 2o sobre la GPU, pero por más que indague no saldrá nada decente, y lo más que se podría hablar de la GPU (la eDram que tiene) resulta que sería mejor detallarlo en el apartado de la arquitectura de memoria, que es el siguiente que vendrá.

Saludos!

Vamos que demuestras que sigues sin comprender lo que lees y que de programación vas pelado. Si ni siquiera entiebdes lo de que los spes trabajan con enteros casi igual que con los de coma flotante o que te crees que lo de la cache es la única optimización para cpu in-order (mira el sdk, supongo que lo tienes), no puedo tomar el resto en serio.

En serio, antes de regurgitar lo que otros escriben trata de entender BIEN del tema.

Y.con esto lo.dejo, que me piro de vacaciones.

Johny27 escribió:Vamos que demuestras que sigues sin comprender lo que lees y que de programación vas pelado. Si ni siquiera entiebdes lo de que los spes trabajan con enteros casi igual que con los de coma flotante o que te crees que lo de la cache es la única optimización para cpu in-order (mira el sdk, supongo que lo tienes), no puedo tomar el resto en serio.

En serio, antes de regurgitar lo que otros escriben trata de entender BIEN del tema.

Y.con esto lo.dejo, que me piro de vacaciones.

Veamos, aquí el que no entiende nada eres tú (y lo demuestras con cada post). El Test Dhrystone es un programa ultra-sencillo (y enfocado a una serie de características de una CPU) que se ejecuta una vez tras otra, y no tiene nada que ver con el cálculo de matrices (sean de enteros o de números decimales), y te digo, tanto que sabes de programación, dime cuál es la parte que se podría optimizar de él para ejecutarse en Cell? Usar las SPE, que están especializadas en cálculo matricial?
Podría ser una opción si no fuese porque nadie en su sano juicio haría un test de Dhrystones en una "cpu" que no tiene Branch Predictor (predictor de brancas) por hardware, uno de los principales focos del test de Dhrystones.
Aquí no se trata de si las SPE pueden ejecutar operaciones con enteros sino de que en su proceso de especialización para cálculo matricial sacrificaron partes esenciales de una CPU.
El resultado de un Dhrystone en una SPE sería tan patético que ni me lo planteo, y por eso por más que busques no verás a nadie que lo haya intentado siquiera.
Qué será lo siguiente, ejecutar Dhrystone en un DSP que ni siquiera tendrá las instrucciones? A ese paso ya hasta eso me esperaría de ti...

Pero lo más importante de todo... sabes lo que es un test? Es decir, si se "optimiza" el Dhrystone entonces qué sentido tiene ejectutarlo si ya no será el Dhrystone, sinó otro programa que hará lo mismo pero de forma distinta y que seguramente atacará el "problema" por otro lado?
Dicho de otra manera, un TEST sirve para probar el rendimiento de una CPU para una tasca (a nivel muy bajo, no entendida como un problema general) concreta, si eliminas instrucciones o las sustituyes por otras para que el programa se ejecute más rápido en la CPU, entonces ya no es un Dhrystone, es un programa distinto que hace lo mismo de otra manera, y lógicamente la comparación con otras CPU no tiene sentido.

Info_Master escribió:

Johny27 escribió:Vamos que demuestras que sigues sin comprender lo que lees y que de programación vas pelado. Si ni siquiera entiebdes lo de que los spes trabajan con enteros casi igual que con los de coma flotante o que te crees que lo de la cache es la única optimización para cpu in-order (mira el sdk, supongo que lo tienes), no puedo tomar el resto en serio.

En serio, antes de regurgitar lo que otros escriben trata de entender BIEN del tema.

Y.con esto lo.dejo, que me piro de vacaciones.

Veamos, aquí el que no entiende nada eres tú (y lo demuestras con cada post). El Test Dhrystone es un programa ultra-sencillo (y enfocado a una serie de características de una CPU) que se ejecuta una vez tras otra, y no tiene nada que ver con el cálculo de matrices (sean de enteros o de números decimales), y te digo, tanto que sabes de programación, dime cuál es la parte que se podría optimizar de él para ejecutarse en Cell? Usar las SPE, que están especializadas en cálculo matricial?
Podría ser una opción si no fuese porque nadie en su sano juicio haría un test de Dhrystones en una "cpu" que no tiene Branch Predictor (predictor de brancas) por hardware, uno de los principales focos del test de Dhrystones.
Aquí no se trata de si las SPE pueden ejecutar operaciones con enteros sino de que en su proceso de especialización para cálculo matricial sacrificaron partes esenciales de una CPU.
El resultado de un Dhrystone en una SPE sería tan patético que ni me lo planteo, y por eso por más que busques no verás a nadie que lo haya intentado siquiera.
Qué será lo siguiente, ejecutar Dhrystone en un DSP que ni siquiera tendrá las instrucciones? A ese paso ya hasta eso me esperaría de ti...

Pero lo más importante de todo... sabes lo que es un test? Es decir, si se "optimiza" el Dhrystone entonces qué sentido tiene ejectutarlo si ya no será el Dhrystone, sinó otro programa que hará lo mismo pero de forma distinta y que seguramente atacará el "problema" por otro lado?
Dicho de otra manera, un TEST sirve para probar el rendimiento de una CPU para una tasca (a nivel muy bajo, no entendida como un problema general) concreta, si eliminas instrucciones o las sustituyes por otras para que el programa se ejecute más rápido en la CPU, entonces ya no es un Dhrystone, es un programa distinto que hace lo mismo de otra manera, y lógicamente la comparación con otras CPU no tiene sentido.

Una lastima que el hilo se convierta en otro hilo de debate gracias a la gente de siempre.
No le hagas ni caso, utiliza el boton ignorar, no sabes lo agusto que entro yo en el foro desde que tengo a este y algunos mas en la lista de ignorados, se les ve venir a la legua.

^ Al contrario, es bueno el debate y así se aclaran las dudas, en este caso Info deja todo bastante claro y fácil de comprender para todos lo cual es interesante en mi opinión.
Claro que a Johny y muchos otros se les nota un aire presuntuoso pero no importa ya que se ha dejado ver claramente que rebaten temas que no dominan.

Tmv_Josue escribió:^ Al contrario, es bueno el debate y así se aclaran las dudas, en este caso Info deja todo bastante claro y fácil de comprender para todos lo cual es interesante en mi opinión.

¿Y qué es lo que has entendido de tan "magnífica" exposición?

Pues que queréis que os diga, yo con este hilo estoy aprendiendo bastante.

Siempre dudando de la información claro está

Info_Master escribió:PD: Los que preguntáis por el siguiente destripe, deciros que caerá pronto, y que si está tardando tanto es por dos motivos:
1. Poco tiempo para postear como le he dicho a Johny27.
2. Tenía pensado hacer el 2o sobre la GPU, pero por más que indague no saldrá nada decente, y lo más que se podría hablar de la GPU (la eDram que tiene) resulta que sería mejor detallarlo en el apartado de la arquitectura de memoria, que es el siguiente que vendrá.

Saludos!

Habrá que estar pendiente entonces.

T1100 escribió:¿Y qué es lo que has entendido de tan "magnífica" exposición?

Siendo sincero no todo ya que lo he leído aprisa por no tener tiempo disponible y hay temas que no domino así que no entiendo todo completamente, pero aún así he entendido buena parte y en general lo principal que quiere explicar Info, que la CPU de la Wii no es tan débil como se piensa o ve a simple vista, gracias a que está muy bien explicado y escribe coherentemente/ordenadamente... ahh y que Johny al igual que otros (heaters?) no tienen idea de lo que hablan y que "regurgitan lo que otros escriben sin entender BIEN del tema".

¿Por qué, quieres saber algo en especial o solo estás caldeando el ambiente?

Tmv_Josue escribió:Siendo sincero no todo ya que lo he leído aprisa por no tener tiempo disponible y hay temas que no domino así que no entiendo todo completamente, pero aún así he entendido buena parte y en general lo principal que quiere explicar Info, que la CPU de la Wii no es tan débil como se piensa o ve a simple vista.

¿Por qué, quieres saber algo en especial o solo estás caldeando el ambiente?

Lo digo porque muchos de aquí no han entendido ni pizca y se limitan a asentir o "masunear" (+1) solamente porque el creador del post quiere poner en buen lugar al procesador de Wii U aunque no ha dado argumentos al respecto y sus conocimientos parecen muy limitados y completamente sesgados.

Info_Master escribió:Podría ser una opción si no fuese porque nadie en su sano juicio haría un test de Dhrystones en una "cpu" que no tiene Branch Predictor (predictor de brancas) por hardware, uno de los principales focos del test de Dhrystones.

Pero lo más importante de todo... sabes lo que es un test? Es decir, si se "optimiza" el Dhrystone entonces qué sentido tiene ejectutarlo si ya no será el Dhrystone, sinó otro programa que hará lo mismo pero de forma distinta y que seguramente atacará el "problema" por otro lado?
Dicho de otra manera, un TEST sirve para probar el rendimiento de una CPU para una tasca (a nivel muy bajo, no entendida como un problema general) concreta, si eliminas instrucciones o las sustituyes por otras para que el programa se ejecute más rápido en la CPU, entonces ya no es un Dhrystone, es un programa distinto que hace lo mismo de otra manera, y lógicamente la comparación con otras CPU no tiene sentido.

Desde hace bastantes posts he notado que usas el palabro "branca" ( ), pensaba que sería un error de escritura o algo parecido y no le di importancia pero veo que la sigues usando y encima lo has rematado con otro palabro "tasca" (supongo que te refieres a task o tarea).
Dime, ¿tú entiendes aunque sea un mínimo de inglés?
Pregunto porque la mayor parte de información fiable sobre el tema (Cell o Xenon) se encuentra únicamente en inglés y muchas fuentes con información en castellano tienen una fiabilidad muuy cuestionable.


Con respecto al Dhrystone, supongo que sabes (aunque, claro, ni siquiera se te ocurrió mencionar) que es un test muy dependiente del compilador y además el rendimiento tanto de Cell como de Xenon debido a su arquitectura tambien son muy dependientes de la gestión del código que hagan el compilador y/o programador.

Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.


Según tu opinión, info_master, ¿cual procesador estaría más capacitado para manejar físicas como las de Battlefield o GTA (dos de los juegos más importantes de la actualidad y que no van a salir en Wii U aparentemente por problemas técnicos, entre otras cosas)? ¿Cell o Espresso? ¿qué procesador es más útil para juegos actuales?

Antes de todo una traducción para evitar malentendidos:

- "tasca" (catalán) es tarea, es decir, task en inglés.
- "branca" (catalán) es rama, es de suponer branch en inglés.

Yo tampoco soy un especialista en estos temas, no tengo ningún tipo de carrera ni ingeniería informática (aunque la empecé en su día) pero me ha gustado leer este primer apartado ya que he asimilado y entendido muchos conceptos, muy bien explicados por cierto. Quiero decir sobre ello que, pese a tener una base ínfima en comparación a especialistas en hardware y programación, he conseguido diferenciar y ver puntos fuertes y/o débiles de cada tipo de arquitectura.

Esperando a la segunda parte del análisis me hallo, Info_Master .

T1100 escribió:
Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.

tu como compararias los diferentes procesadores?

dragonsacred escribió:

T1100 escribió:Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.

tu como compararias los diferentes procesadores?

No es posible hacer una comparación directa, ni los MIPS ni los FLOPS son totalmente determinantes aisladamente.
Solamente podemos fiarnos de los resultados reales, es decir, los juegos.
El día que vea un juego de Wii U con una físicas iguales o superiores a las de Battlefield o GTA, el día que los ports multiplataforma no tengan recortes misteriosos ni existan quejas de los programadores será evidente que la CPU de Wii U es suficientemente capaz.

A menos claro, que un buen desarrollador haga correr su código en todas las plataformas y publique sus resultados, creo que ese podría ser un dato más o menos fiable.

T1100 escribió:

dragonsacred escribió:

T1100 escribió:Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.

tu como compararias los diferentes procesadores?

No es posible hacer una comparación directa, ni los MIPS ni los FLOPS son totalmente determinantes aisladamente.
Solamente podemos fiarnos de los resultados reales, es decir, los juegos.
El día que vea un juego de Wii U con una físicas iguales o superiores a las de Battlefield o GTA, el día que los ports multiplataforma no tengan recortes misteriosos ni existan quejas de los programadores será evidente que la CPU de Wii U es suficientemente capaz.

A menos claro, que un buen desarrollador haga correr su código en todas las plataformas y publique sus resultados, creo que ese podría ser un dato más o menos fiable.

hay un problema para los juegos, que en unas plataformas se lleva trabajando 7 años y en otra año y poco, con lo cual eso tp es determinante

las quejas de los desarrolladores son todas validas?y que pasa con los desarrolladores que no se quejan e incluso alaban la cpu?que opinion es mas valida?

si la cpu de la 360 y de la ps3 son iguales desde el dia que salieron a que se debe entonces que los juegos actuales no se vieran hace 7 años?

mientras bases tus comparaciones en algo tan subjetivo como lo que ves, siempre daras opiniones subjetivas, y por tanto, no seran opiniones reales y ciertas, sino tu percepcion de la realidad, de ahi lo de subjetivas

sobre lo de correr un codigo en todas las plataformas, que es sino un test?un codigo estandar ejecutandose en todas las plataformas

para prueba un boton, los benchmarks que demuestran la potencia de un movil, hay varios benchmarks diferentes, al estar optimizado cada uno para un tipo de cpu, gpu, etc, cada uno da diferente resultados, y mientras que en el test A el movil A da 10, y el B 8, en el test B es al contrario, el mobil A da 8 y el B da 10, de ahi que haga falta un test sin optimizar para poder comparar con todas las plataformas en igualdad de condiciones

dragonsacred escribió:hay un problema para los juegos, que en unas plataformas se lleva trabajando 7 años y en otra año y poco, con lo cual eso tp es determinante

El procesador de Wii U no es nuevo, está basado en el de Wii, que a su vez estaba basado en los 750XX (G3), vamos, que esa arquitectura está requetesobada y no tiene muchos misterios.

Cell y Xenon utilizaban un arquitectura totalmente atípica, a la cual se tenían que adaptar los programadores y por tanto en estos casos sí había margen de mejora con un mayor conocimiento y optimizacion de las herramientas.

Los programadores ya han comentado que sus problemas con el procesador de Wii U no son por "dificultad para sacarle rendimiento" (como pasaba en PS360) sino porque "no hay más", ya tienen al procesador funcionando a full y aún así a veces se queda corto.

Es difícil que esto sea algo que se arregle con el tiempo, porque como dije este tipo de procesador ya es muy conocido y no es complicado aprovechar su capacidad.

dragonsacred escribió:

T1100 escribió:
Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.

tu como compararias los diferentes procesadores?

Haciendolos funcionar para lo que dicen trabajar, en este caso juegos. Los test, bechmarks, analisis y demas son muy bonitos e igual de facil que te vendan la moto.

El movimiento se demuestra andando no haciendo un analisis de las zapatillas que llevas.

T1100 escribió:Es difícil que esto sea algo que se arregle con el tiempo, porque como dije este tipo de procesador ya es muy conocido y no es complicado aprovechar su capacidad.

Lo dicho, ni puta idea...

sabran escribió:

dragonsacred escribió:

T1100 escribió:
Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.

tu como compararias los diferentes procesadores?

Haciendolos funcionar para lo que dicen trabajar, en este caso juegos. Los test, bechmarks, analisis y demas son muy bonitos e igual de facil que te vendan la moto.

El movimiento se demuestra andando no haciendo un analisis de las zapatillas que llevas.

los juegos se supone que es algo mensurable y objetivo?que todos los juegos son exactamente iguales?o unos juegos son mas exigentes que otros, o unos tiran mas de cpu o de otras cosas?y ya diendo un paso mas alla, para ti un juego es igual que para mi?lo que a ti te parece una mierda a mi me parece una obra de antes

lo del movimiento queda muy bonito, pero yo con tus zapatillas puedo ir a mitad de velocidad que con las mias simplemente xq me quedan pequeñas o grandes(no estan optimizadas)

T1100 escribió:

dragonsacred escribió:hay un problema para los juegos, que en unas plataformas se lleva trabajando 7 años y en otra año y poco, con lo cual eso tp es determinante

El procesador de Wii U no es nuevo, está basado en el de Wii, que a su vez estaba basado en los 750XX (G3), vamos, que esa arquitectura está requetesobada y no tiene muchos misterios.

Cell y Xenon utilizaban un arquitectura totalmente atípica, a la cual se tenían que adaptar los programadores y por tanto en estos casos sí había margen de mejora con un mayor conocimiento y optimizacion de las herramientas.

Los programadores ya han comentado que sus problemas con el procesador de Wii U no son por "dificultad para sacarle rendimiento" (como pasaba en PS360) sino porque "no hay más", ya tienen al procesador funcionando a full y aún así a veces se queda corto.

Es difícil que esto sea algo que se arregle con el tiempo, porque como dije este tipo de procesador ya es muy conocido y no es complicado aprovechar su capacidad.

fuente de esa afirmacion?

No os preocupéis por Johny27. Es un troll bien conocido por los foros y lo mejor que se puede hacer es ignorarle. A ver si es verdad que se va de vacaciones y nos deja a todos tranquilos.

Mi enhorabuena al autor del hilo. Todo muy bien explicado y a la espera de las siguientes entregas

capitanquartz escribió:No os preocupéis por Johny27. Es un troll bien conocido por los foros y lo mejor que se puede hacer es ignorarle. A ver si es verdad que se va de vacaciones y nos deja a todos tranquilos.

Cierto, por menos se quemaba en la Edad Media a la gente, que pecado, llevar la contraria a la "masa nintendera" argumentando con coherencia, deberia denegarsele el acceso a este subforo, no vaya a ser que rompa la armonia reinante........

Sigamos con el tema del hilo, que hasta ahora iba por buen camino.

dragonsacred escribió:El movimiento se demuestra andando no haciendo un analisis de las zapatillas que llevas.

los juegos se supone que es algo mensurable y objetivo?que todos los juegos son exactamente iguales?o unos juegos son mas exigentes que otros, o unos tiran mas de cpu o de otras cosas?y ya diendo un paso mas alla, para ti un juego es igual que para mi?lo que a ti te parece una mierda a mi me parece una obra de antes
[/quote]

Por eso he dicho juegos en general. No puedes quedarte con un solo juego para hacer la prueba. De momento ya llevamos unos cuantos en WiiU, tanto the third, que serian las zapatillas pequeñas segun tu, como algunos de nintendo, zapatillas idoneas.

triki1 escribió:Cierto, por menos se quemaba en la Edad Media a la gente, que pecado, llevar la contraria a la "masa nintendera" argumentando con coherencia, deberia denegarsele el acceso a este subforo, no vaya a ser que rompa la armonia reinante........

Buen chiste... hasta yo que no soy un "genio del tema" con mi poco conocimiento de él logro vislumbrar que Info domina el tema y Johny27 no, sin ofensas, pero la verdad es inevitable, pero mas allá de eso es su actitud la que me desagrada, no que este mal cuando escribe (creo que es el colmo no? querer verse way cuando ni siquiera dominas el tema, una actitud muy común en foros eso si).

T1100 escribió:

Tmv_Josue escribió:Siendo sincero no todo ya que lo he leído aprisa por no tener tiempo disponible y hay temas que no domino así que no entiendo todo completamente, pero aún así he entendido buena parte y en general lo principal que quiere explicar Info, que la CPU de la Wii no es tan débil como se piensa o ve a simple vista.

¿Por qué, quieres saber algo en especial o solo estás caldeando el ambiente?

Lo digo porque muchos de aquí no han entendido ni pizca y se limitan a asentir o "masunear" (+1) solamente porque el creador del post quiere poner en buen lugar al procesador de Wii U aunque no ha dado argumentos al respecto y sus conocimientos parecen muy limitados y completamente sesgados.

Eres libre de corregir lo que te parezca, pero vigila con eso de acusar a los demás de ignorantes o manipuladores, no sea que te encuentres como el caso de Johny27 que también acusaba mucho, y a mi juicio erróneamente.

T1100 escribió:Desde hace bastantes posts he notado que usas el palabro "branca" ( ), pensaba que sería un error de escritura o algo parecido y no le di importancia pero veo que la sigues usando y encima lo has rematado con otro palabro "tasca" (supongo que te refieres a task o tarea).
Dime, ¿tú entiendes aunque sea un mínimo de inglés?
Pregunto porque la mayor parte de información fiable sobre el tema (Cell o Xenon) se encuentra únicamente en inglés y muchas fuentes con información en castellano tienen una fiabilidad muuy cuestionable.

Sucede que estoy en contra de los barbarismos, escriba en el idioma que escriba, y los evito lo máximo posible. Como mi lengua es el catalán se me ha colado (tal y como te ha explicado luego otro forero) "branca" en vez de "rama" y "tasca" en vez de "tarea" (barbarismos catalanes en vez de ingleses, está igual de mal escrito, pero veo que esos te ofenden más ).
Efectivamente, la documentación la leo en inglés.

T1100 escribió:Con respecto al Dhrystone, supongo que sabes (aunque, claro, ni siquiera se te ocurrió mencionar) que es un test muy dependiente del compilador y además el rendimiento tanto de Cell como de Xenon debido a su arquitectura tambien son muy dependientes de la gestión del código que hagan el compilador y/o programador.

Hay compiladores que optimizan el Dhrystone, pre-calculando ciertas cosas y eliminando instrucciones intermedias que no afectan a la salida del programa. Dicho eso, cuando intentas sintetizar la información (y aún así me quedó un tochaco) hay cosas que se obvian, y en ese juzgué que tan optimizado para Dhrystone estaría un compilador como el otro (si se trata de scene dudo que se curren compiladores específicos, y menos para hacer un test, porque le quitaría el significado al asunto).

T1100 escribió:Pretender usar test genéricos que tocan apenas una fracción de la capacidad real de un procesador como una prueba fehaciente y determinante es una locura, totalmente absurdo.

¿Reduces todo mi mensaje a "usar test genéricos"? ¿O sencillamente tienes lectura selectiva?

T1100 escribió:Según tu opinión, info_master, ¿cual procesador estaría más capacitado para manejar físicas como las de Battlefield o GTA (dos de los juegos más importantes de la actualidad y que no van a salir en Wii U aparentemente por problemas técnicos, entre otras cosas)? ¿Cell o Espresso? ¿qué procesador es más útil para juegos actuales?

¿Battlefield o GTA no salen por problemas técnicos? Y yo que creía que no salían porque las empresas desarrolladoras no han creído conveniente hacer la inversión...
En cuanto a las físicas, si te hubieses leído todo mi mensaje cosa que dudo seriamente, verías que ya hice referencia (comparaba con el Xenon, no con el Cell) a la unidad VMX128 y las ventajas de tenerla frente a no tenerla.

En lo que respecta a código de gráficos, ese código es más fácil de paralelizar y más predecible (más threads y menos necesidad de hacer predicciones de branca que en el caso de Xbox 360 penalizan mucho más que en el de Wii/WiiU) con lo que el diseño de Xbox 360 tendría un rendimiento comparativamente muy superior al que tenía con el código de propósito general y se aproximaría más a sus cifras teóricas.

El cálculo de físicas es otro cálculo matricial que aún sin ser de gráficos, sí que se ve beneficiado por la superior capacidad del Xenon y sobretodo el Cell en ese sentido. Ahora bien, no empecemos con que si esa es mejor para juegos que las otras, porque contestando a tu pregunta yo también podría hacer otra:
¿Qué CPU es mejor para algoritmos de IA como por ejemplo podría ser uno de "pathfinding" (para el que no lo sepa, un algoritmo usado para determinar por donde debe pasar un personaje controlado por la IA para ir a un determinado punto, teniendo en cuenta las particularidades del escenario)?

T1100 escribió:No es posible hacer una comparación directa, ni los MIPS ni los FLOPS son totalmente determinantes aisladamente.

¿Y quien ha comparado mips (dmips, de hecho) o flops aisladamente? Si la mayor parte del análisis va destinado a la arquitectura de los procesadores, a sus puntos fuertes y sus puntos débiles. No es hasta el final que uso esos test, explicando qué hacen y cómo deben contextualizarse en la arquitectura de cada CPU.

T1100 escribió:Solamente podemos fiarnos de los resultados reales, es decir, los juegos.

El problema de eso es que es muy sencillo hacer afirmaciones absolutas y manipular la realidad. Leñes, si me acuerdo de una discusión que hubo en el hilo de "debate sobre WiiU" en donde se posteaban BULLSHOTS de PS3 para demostrar que WiiU no era más potente, y las imágenes estaban tan absolutamente retocadas y falseadas respecto al juego real que hasta parecía que también PS4 estaba por debajo.

T1100 escribió:El día que vea un juego de Wii U con una físicas iguales o superiores a las de Battlefield o GTA, el día que los ports multiplataforma no tengan recortes misteriosos ni existan quejas de los programadores será evidente que la CPU de Wii U es suficientemente capaz.

Si nos limitamos a las físicas había unos en Wii (elebits y bloombox si no recuerdo mal) que demuestran más que GTA o Battlefield en PS3 o 360, pero claro, con palos en vez de con objetos complejos.
Mira, el tiempo pondrá a cada cuál en su lugar, eso sin duda. Pero teniendo en cuenta que los kits de desarrollo de la consola estaban muchísimo más verdes de lo que sería normal para una consola puesta a la venta, es lógico que ese tipo de problemas aparezcan.

Por cierto, y ya que te centras tanto en físicas y efectos gráficos en CPU, supongo que sabrás que en ese sentido tanto el Xenon como sobretodo el Cell también superan y no por poco precisamente a los Jaguar de PS4/XboxOne...

T1100 escribió:El procesador de Wii U no es nuevo, está basado en el de Wii, que a su vez estaba basado en los 750XX (G3), vamos, que esa arquitectura está requetesobada y no tiene muchos misterios.

Ostras, lo que me faltaba. Ahora resultará que los Jaguar de PS4/Xbox One son procesadores salidos de la nada y diseñados por el mismísimo Jesús.
Para un programador no funcionan así las cosas, para empezar, porque lo primero y más importante de todo son las herramientas. De lo que he leído de foros ingleses, de la poca información que se ha filtrado y que aún así hay que coger con pinzas, es que de la CPU de WiiU sólo se podía usar un núcleo cuando la consola salió al mercado.
A ese rumor de un supuesto insider que lógicamente hay que coger con pinzas, añadir las declaraciones de Shin'en diciendo que ellos sólo usaban un núcleo de la CPU y que no optimizaron en absoluto con Nano Assault Neo, las de Criterion diciendo que programar para la consola era un infierno hasta entrado 2013 por la falta de herramientas y la propia Nintendo que lo ha dicho ya en 2 o 3 ocasiones.

Al margen de eso, que son cosas que ya deberían estar resueltas a esas alturas, la CPU de WiiU tiene cosas con las que los programadores no están acostumbrados a trabajar, como por ejemplo, unas cache L2 muy grandes. Eso unido a que el ancho de banda del módulo de 2GB de memoria de la consola es tan sólo de 12,8 GB/s (un 57% de lo que tenía la 360) obliga a replantear el código casi que por completo, y a re-balancearlo.

En el caso de WiiU, las instrucciones que se soportan y el comportamiento de un núcleo de la CPU frente a un código concreto estarán más o menos estudiadas (como en el caso de los Jaguar, sea dicho de paso), pero el tener una arquitectura de memoria tan poco común va a obligar a replantearse ciertas cosas y a atacar ciertos problemas desde otras perspectivas.

PD: Para los interesados, entre mañana y pasado mañana tengo intención de colgar el análisis de la arquitectura de memoria. ¡A ver si puedo tenerlo listo!

Esta bastante interesante tu articulo.

En mi opinión es de pena que la CPU de WIIU no barra en absolutamente todo a la de XBOX360, esto esta impidiendo muchos ports directos de las consolas anteriores hacia WIIU.

Una pregunta acerca de la gráfica, soporta los efectos DirectX11 tales como tesselation y esas cosas o es una DirectX9.

¿Vas a hablar de ella detenidamente?

Un Saludo.

naxeras escribió:Esta bastante interesante tu articulo.

En mi opinión es de pena que la CPU de WIIU no barra en absolutamente todo a la de XBOX360, esto esta impidiendo muchos ports directos de las consolas anteriores hacia WIIU.

Una pregunta acerca de la gráfica, soporta los efectos DirectX11 tales como tesselation y esas cosas o es una DirectX9.

¿Vas a hablar de ella detenidamente?

Un Saludo.

Por partes:
Barrer en absolutamente todo a las CPU de Xbox 360 es imposible a menos que se diseñe la CPU con la intención de hacerlo o que te dejes un pastizal en el proceso.
La CPU de Xbox 360 tenía un diseño enfocado a cálculo matricial (físicas, procesos gráficos) mientras que la de WiiU es un diseño más polivalente, pero menos capaz en el área en donde el de 360 se luce.
Lo mismo se aplica a los Jaguar de PS4 e Xbox One, por cierto, ninguna de esas CPU puede competir en números brutos con el Xenon.
Los ports en WiiU no llegan por la mala relación de las thirds con Nintendo y las bajas ventas.

En cuanto a la GPU su diseño partió de la base de un R700 que era DirectX 10.1. Sobre ese diseño se ha trabajado durante 3 años en los que el chip se ha ido especializando según los requisitos de Nintendo hasta tener lo que tenemos ahora, algo irreconocible. Bien podría ser equivalente a DX11, bien podía no serlo y tener otras funcionalidades que DX11 aún no incluye. Es un misterio, y como falta demasiada información, de momento el artículo de la GPU me lo voy a ahorrar.

Si, tienes razón, he visto que efectivamente donde gana XENON es donde los desarrolladores de la CPU pusieron el énfasis y estamos hablando de números brutos a bajo nivel que probablemente ni se aprovechen.

¿Realmente las físicas usan esas características en un mismo motor que funciona en PC/360 y PS3? no veo diferencias de una consola a otra, ni son mas relistas ni veo que se resienta el rendimiento.

Al final yo creo que todas estas cosas de la CPU no se suelen tener ya en en cuenta hoy día y se deja todo el trabajo al compilador o al CPU Profiler que se ven en los SDK.

Gracias a tu artículo he visto por qué la XBOX360 es tan mala emulando, sobre todo al principio que era más lenta que WIIU cuando portaron los emuladores al vuelo.

Visto lo visto WiiU es más de propósito general como la PS4 y XBOXONE (X86).

Por favor corrígeme en lo que sea solo estoy especulando de lo que entiendo de tu artículo.

Veo que controlas un huevo a ver si me puedes resolver estas dudas que siempre he tenido:

¿WII y XBOX360 comparten mismo juego de instrucciones?, las 2 son PowerPC pero no se si se agregaron o eliminaron instrucciones de una CPU a otra.
¿La CPU de WII sería "virtualizable" en XBOX360?
¿Seria posible virtualizar una WII completa en XBOX360?

Un Saludo.

¿Y qué tan potente sería la CPU de Wii U comparada con la de PS Vita (cuatro núcleos Cortex A9)?

Aparentemente la CPU de Vita puede calcular 20,000 DMIPS.
http://g3ar.co.za/2011/09/20/ps-vita-an ... pc-speeds/

¿Es verdad lo que se comenta de que el SO de wiiu corre sobre un arm aparte para no interferir en la CPU principal y esta vaya destinada exclusivamente a los juegos?

Custom, Nintendo-made Wii U operating system that runs on a separate, ARM-based processor.

Esto explicaría que el SO no sea lo más rápido del universo pero sería una buena desición para optimizar en todo lo posible la consola.
Aunque no sé si esta info es erronea y el arm sólo se encarga de la seguridad como comentas.

Yo creo que el Starbuck solo se encarga de la seguridad y de los "controladores" tal como sucedía en Wii con sus IOS corriendo en el Starlet (procesador ARM).

He intentado leerme todo el hilo, estoy alucinado del buen nivel y el clima de la discusión. Me habéis transportado a mis clases de arquitectura de procesadores con las "pipelines" y todo eso... lo tenía en el baúl de los recuerdos

No puedo participar ni opinar, no tengo ni idea, pero felicito a Info por su gran esfuerzo. Os leo pero no escribo más.

tocho recopilatorio de todo lo más interesante que he encontrado.


sacado de la Wiki

Procesadores:

CPU: microprocesador tri-núcleo IBM Arquitectura Power de 45 nm basado en la arquitectura POWER7 del superordenador Watson a 3.24 Ghz.90 91
GPU: una AMD Radeon HD diseñada en especial para la consola, similar a la arquitectura de la Radeon HD 4800 con core R770 corriendo a 800 MHz.92

Almacenamiento:

Memoria flash interna: la del pack básico será de 8 GB y la del pack premium de 32 GB,81 ampliable vía discos duros externos USB93
Bandeja de carga de discos compatible con discos propietarios de alta densidad de 12 cm (capacidad de 25GB en un disco de una sola capa)94 95 y discos de Wii de 12 cm

Puertos y capacidades periféricas:

Ranura para tarjetas SD y SDHC
Puertos USB 2.0 (2 en el frontal y 2 en la parte trasera)
Puerto para la barra de sensores
Puerto para la señal de vídeo
Puerto del cable de corriente
Puerto HDMI 1.465

GamePad:

Acelerómetro, giroscopio y sensor geomagnético incorporados, cada uno de ellos de 3 ejes.
Altavoces y micrófono
Cámara frontal
IR Sensor strip
Pantalla de 15,7 cm 854×480 FWVGA 16:9 resistiva
Dos sticks analógicos y una cruceta
Puntero
Botones Select, Start, Home y de encendido
Botones A/B/X/Y, gatillos L/R y botones ZL/ZR
Vibración
Botón de sincronización
Bluetooth
NFC68
Infrarrojo

Nota: Wii U también es compatible con el Wii Remote, el Wii Nunchuk, el Wii Classic Controller y la Wii Balance Board.96 Se anunció a través de la Nintendo Network que el Wiimote todavía se usará no sólo para los juegos de Wii, sino como una nueva forma de combinarlo con la nueva experiencia de usuario proporcionada por la tableta controladora.97

Vídeo:

1080p, 1080i, 720p, 480p, o 480i, en 4:3 o 16:9 anamórfico
Puerto "AV Multi Out", que soporta vídeo compuesto, vídeo por componentes YPBPR, S-Video (sólo en consolas NTSC), RGB SCART (Sólo consolas PAL) and D-Terminal (sólo Japón)
HDMI 1.4 con soporte para 3D estereoscópico.65

Audio:

Puerto "AV Multi Out". Salida de PCM de seis canales vía HDMI

Más fotos y desmontaje de la misma:
http://www.ifixit.com/Teardown/Nintendo ... wn/11796/1


A modo recopilación esto sería lo más importante que se sabe (se sabe lo mismo que cuando salió a finales de 2012) , aunque hay que coger la información con pinzas porque no se sabe aún cuáles son las specs reales de la máquina.

Según Marcan, conocido hack por su trabajo en otras videoconsolas...

Wii U codenames worth knowing: system Cafe, CPU Espresso, GPU/SoC/etc. Latte, ARM secure processor Starbuck (we made that one up).

1.243125GHz, exactly. 3 PowerPC 750 type cores (similar to Wii's Broadway, but more cache).

GPU core at 549.999755MHz.

we're calling the WiiU security processor the Starbuck (vs. Starlet on Wii). And it seems to be about equally vulnerable, too

sorry, I'd rather not talk about how I got that yet. It doesn't involve leaks, it involves Wii U hacks

La información es totalmente correcta.
Y los nombres de los componentes también. Todos hacen referencia a nombres de café (de ahí el project cafe).

Por cierto como bien apunta Marcan (flipo de la gente que duda de los datos de este hombre ...) no se pueden comparar velocidades a la ligera, no es un método válido salvo que sea el mismo procesador.

Wii U tiene un mayor IPC que ps360 pero es muy mala en SIMD (ps360 son unas bestias pardas en eso). Así que si un juego está muy optimizado para utilizar calculos SIMD ... pues jodido.

Lo que me estoy riendo viendo a los supuestos insiders dar explicaciones de por que wiiu ha resultado ser peor hard que el de ps360 cuando ellos decian lo contrario.En fin lo màs interesante es ver si nintendo es capaz de crear un ecosistema de juegos alrrededor de wiiu y la calidad de esos juegos.


Quien dice que es "peor"? Wii U es más potente que x360 y ps3, otra cosa es en qué campos y por cuanta diferencia. No es todo blanco o negro ... y un sistema no es sólo algunos datos. Simplificas demasiado las cosas.[/quote]


Hay móviles con mas CPU y núcleos, eso no es excusa. Además que tenga mas núcleos no es precisamente mejor ya que hay tareas que son indivisibles y no se pueden correr en paralelo, es mejor tener una alta frecuencia a un mayor número de núcleos, y en mi opinión ningún producto de "Sobremesa" que se califique a si mismo de "Consola Moderna" debería bajar de 3,2Ghz.

sin entrar en otros parametros, la frecuencia por nucleo en si no es relativa a su rendimiento bruto final, un nucleo con un mayor ipc puede dar mejor rendimiento, que un core con mayor frecuencia y peor ipc, esta claro que si conseguimos la suma alta frecuencia + alto ipc podremos tener una bestia, el problema es que no sabemos realmente como es el el nucleo de la cpu de wiiU y por ahora lo unico que se ha comentado marcan es que, las cpus no son comparables, tambien indica que la cpu de wiiU tiene mayor ipc clock x clock que la de xbox360 por lo que usando una menor frecuencia podria igualar el rendimiento de esta y que tiene en princpio el nucleo de wiiU una menor eficiencia en smid que xbox360, pero por contra estas intrucciones o parte de ellas se podria hacer carga la gpu de wiiU

pero por ahora no ahi nada realmente confirmado y se desconoce la arquitectura de funcionamiento de wii U, por lo que aun es precipitado hacer comparaciones, ahora solo nos queda disfrutar de los juegos que es lo unico realmente palpable por el usuario final y sus gustos, tengas la consola que tengas.

No voy a entrar a valorar la fiabilidad de las pruebas de Marcan, desconozco su reputación, pero lo que comenta es razonable.

Parecen núcleos basados en PPC7xx pero con algunas mejoras considerables respecto a IBM Broadway.

IBM Broadway: Monocore, 90 nm, ISA 1.10, frecuencia 729 Mhz, cache L1 32/32 KB, cache L2 256 KB, eDRAM 3 MB.

PPC7xx Wii-U: Tri-Core (parece que sin SMT), 45 nm (menos calor y consumo), por retrocompatibilidad con Wii seguramente ISA 1.10 (si tuviese Wii-U un set de instrucciones superior incluiría SIMD VSX, y dado que según Marcan no es su punto fuerte, pues se deduce que no mejoraron este aspecto), frecuencia 1.24 Ghz (casi el doble que Broadway), L1 desconocida pero sabemos que más cantidad que Wii, L2 desconocida pero sabemos que más cantidad que Wii, L3 eDRAM parece que no tiene, eDRAM desconocida pero sabemos que más cantidad que Wii y compartida con la GPU.

Se ve que implementar POWER 7 encarecía mucho el precio final de la consola, así que debieron optar por reinventar una vez más la rueda, aunque modernizándola en varios aspectos. La verdad es que a Nintendo le debe salir cada CPU de Wii-U por dos pavos.

En general el rendimiento de la CPU de Wii-U es probablemente algo inferior al Xenon y Cell. Aunque no creo que la diferencia sea muy significativa.

En cuanto a la GPU de Wii-U esta claro que le da un buen repaso tanto al Xenos como al RSX.

Según Anandtech la GPU esta basada en RV740 con un proceso de fabricación más reducido que la original, es decir a 40 nm en lugar de los 55 nm originales. Tal vez podría ser una RV770, pero bueno es irrelevante, el caso es que el rendimiento es muy superior a la GPU de Xbox 360 y PS3.

En cifras os puedo decir que tanto la GPU RV740 como la RV770 no bajan de los 736 GFLOPS. Así que en el peor de los casos la GPU de Wii-U es tres veces más rápida que la de Xbox 360.

Xenos (Xbox 360): 240 GFLOPS.
GPU Wii-U: 736 GFLOPS.

Aunque el Xenon de Xbox 360 pudiera ser superior al PPC7xx de Wii-U (aun esta por verse en que aspectos concretos y por cuanto). La diferencia tan abismal que hay entre la GPU de Xbox 360 y la de Wii-U, hace que la diferencia de rendimiento entre las CPU se quede en algo anecdótico.

Pese a que la GPU sea casi tres veces más potente, los videojuegos multiplataforma van a ser prácticamente similares entres las tres consolas. Quizás en Wii-U se puedan ver mejor algunos ports, con algún efecto más, pero no esperéis gran cosa porque el desarrollo actual es multiplataforma.

Para que de verdad se noten unas diferencias graficas notables, se necesitaría que Wii-U fuera como mínimo diez veces más potente que una Xbox 360. Con lo cual Wii-U es una consola que esta de camino entre esta generación y la próxima, aunque sin duda más pegada a la generación actual que a la siguiente. Así que desde un punto de vista grafico no espereis gran cosa de los exclusivos de Wii-U.

De todas formas Wii-U hay que compararla con Xbox 720 y PlayStation 4. Es normal que sea más potente (aunque no sea por mucho), que la bisabuela Xbox 360 y la abuela Play Station 3.

En cualquier caso todo esto es un poco irrelevante, ya que desde la Wii no creo que nadie compre una consola de Nintendo por su potencia grafica. Además todos estos debates sobre si la tiene más larga una consola u otra me parecen ridículos, si de verdad queréis gráficos compraros un PC.

Es más inteligente comparar una consola por su catalogo de videojuegos exclusivos, por su precio, por sus periféricos si queréis, incluso por si incorpora un lector Blu Ray para ver películas.


Viendo la arquitectura de la CPU de Wii-U, esta claro que se va a apoyar para el cálculo de coma flotante en la GPU. Creo que estamos ante un sistema que utilizara algunas técnicas GPGPU.

Obviamente una CPU basada en PPC7xx no va a consumir apenas nada de energía, casi todo el consumo de la consola va a estar en la GPU.

Si la consola utiliza finalmente una GPU basada en RV740, y teniendo en cuenta el consumo medio de Wii-U que es de 40 W con picos de 75 W, es relativamente fácil imaginar que características aproximadas de rendimiento tendrá esa GPU.

RV740: 960 GFLOPS, 750 Mhz, 80 W. En bruto es casi cuatro veces más potente que Xenos.
Custom RV740 Wii-U: 450 GFLOPS, 550 Mhz, 30-35 W. La capan y optimizan un poco y listo.

Teniendo en cuenta el limitado tamaño de Wii-U no se puede pedir más de eso, sino se cocería todo en su propia salsa.

Más importante que la cantidad de cache que tendrá la CPU de Wii-U, será la cantidad de eDRAM que compartirán la CPU y la GPU. Sin olvidarnos de que la RAM esta unificada.

Así por encima se puede concluir que Wii-U es aproximadamente alrededor de un 50-75 % más potente que Xbox 360.

La GPU de Wii-U tendrá que compensar las carencias en cálculo de coma flotante de la CPU, así que aunque esta sea más potente que la GPU de Xbox 360. Parte de ese rendimiento se destina a compensar la CPU. No esta demás recordar que lo más importante para mover un videojuegos son los calculos de coma flotante de precisión simple.

La única GPU de la serie HD 4xxx fabricada a 40nm tiene un core de 750 Mhz. Marcan ya demostró que esta funcionando a 550 Mhz, así que ahí esta un underclocking para controlar el calor y consumo de la GPU.

Si ya de por si la CPU IBM Broadway consume poco fabricada a 90 nm, ahora que esta fabricada a 45 nm debe ser de risa, y eso pese a que la frecuencia esta aumentada.


Underclock, también conocido por downclock, es un anglicismo usado en informática que significa debajo del reloj. Underclock es el proceso inverso a overclock: mientras que en el overclock se aumenta la velocidad de reloj de la CPU o memorias para ganar rendimiento, en el underclock se baja la velocidad de reloj.
Aunque con esta práctica se reduce el rendimiento del componente, puede tener algún uso, por ejemplo: hacer underclock al procesador permite jugar a juegos antiguos (por ejemplo, del emulador MAME) que si se utilizan con el hardware actual sin underclock funcionan a velocidades de hasta 3 veces mayores a las normales. Esta técnica también ayuda a reducir la temperatura de los componentes, por lo que algunas personas la usan en computadoras donde la refrigeración no es suficiente para mantener los componentes a una temperatura funcional aceptable.


La wii u tiene un lector de blu-ray modificado, capaz de leer 25 gigas por capa. Tiene una velocidad de lectura de 4X/5X (el de Ps3 es de 2x, para hacerse una idea).

Sobre las velocidades de lectura, lo que hay que ver es la velocidad "real" del lector:

- PS3 tiene un lector BD a 2X. Eso significa una lectura de 9 MB/s constantes.

- Xbox360 tiene un DVD-Rom a 12x. Su velocidad de lectura real es oscilante. En discos con una sola capa lee entre 9.25MB/s hasta los 15.85MB/s dependiendo de la parte del disco. La velocidad media es de unos 10,25 MB/s

En doble capa va mucho más lento, de 4.36MB/s hasta los 10.57MB/s, con una media de 8 MB/s aproximadamente.

- Wii U lee a 22Mb/s. Desconozco si es constante o tiene fluctuaciones. Si el disco se basa en la tecnología BD en este aspecto la lectura debe ser constante.

En resumen: la velocidad del lector de Xbox360 y PS3 a efectos prácticos es la misma (BD x2). Wii U lee a una velocidad similar a un lector BD x4 o 5x.


Tecnología Gamepad:

"Nuestros sensores tiene una resolución mayor, unas 15 veces más resolución, de lo que es habitual en teléfonos móviles," ha dicho Becky Oh, presidenta de esta empresa californiana. Ha contado que Nintendo hizo muchas pruebas en varias áreas de modo que "si hacían un seguimiento de 9 ejes funcionara en distintas situaciones." Así es como encontraron a este socio en el camino de Wii U, que añade un tercer elemento al giroscopio y el acelerómetro del Wii MotionPlus, el sensor geomagnético.

El giroscopio y el acelerómetro "son buenos para registrar cambios relativistas. Pero no te dicen en valor absoluto a dónde estás apuntando o dónde está el puntero. Lo que hace el sensor magnético es utilizar el campo magnético de la tierra como referencia." Así siempre puede guiar de vuelta al Gamepad a su posición inicial prácticamente sin marge de error. Este vídeo es una demostración técnica de sus resultados.

Usos del sensor magnético del Wii U Gamepad

No es solo cuestión de superar lo que ofrecen los apartos de mano, también de lo que ha presentado la competencia en cuanto a juegos basados en el movimiento.

Oh piensa que "juegos como los fps, los de conducción o algún tipo de juego de vuelo podrían ser buenos candiados para este tipo de tecnología".

El sensor del Wii U Gamepad también es superior al Move de PlayStation 3. "Sharpshooter de Sony hizo algo parecido pero cuando jugamos con él vimos que no hacía un registro preciso. Tenía latencia e impercisión", ha comparado la CEO de la compañía. "En este caso, los jugadores tracionales volverían a utilizar un joystick o mandos clásicos, pero si tuvieras una forma muy precisa de utilizar el arma con el que apuntar el arma con la que estás disparando, creo que cambiaría la forma de jugar."

Esta es otra de las piezas escondidas dentro del Wii U Gamepad, que también incorpora la pantalla táctil de 6,2 pulgadas, cámara y un lector de chips NFC aun sin estrenar.



modo resumen para tontos:

- la GPU de la wii u es más potente que la de Ps3 y Xbox 360, su CPU es peor. Pero aún así, la wii u es alrededor de un 50-75 % más potente que la Xbox 360 y Ps3.

- Los juegos multiplataforma van a verse de manera muy similar en las tres consolas.

- La gente que se compra una consola de Nintendo, no es por la potencia, ni por los juegos multiplataforma, es por sus controladores exclusivos y por sus juegos exclusivos que no se encuentran en las consolas de la competencia ni en el PC.

- La Wii U tiene retrocompatibilidad con los mandos, cables de video y juegos de la Wii al 100% por hardware, cosa que no se puede decir lo mismo de Ps4 y Xbox One con respecto a Ps3 y Xbox 360. Esto es un hecho importante para muchos.

superfenix2020 escribió:....

Es un tocho, pero muy interesante, sobre lo de Marcan, no estoy seguro pero creo haber leido que para saber las frecuencias de cpu y gpu, lo hizo en el modo vWii, por lo que esas cifras podrian variar en el modo wii u.

peloconcelo escribió:

superfenix2020 escribió:....

Es un tocho, pero muy interesante, sobre lo de Marcan, no estoy seguro pero creo haber leido que para saber las frecuencias de cpu y gpu, lo hizo en el modo vWii, por lo que esas cifras podrian variar en el modo wii u.

supuestamente desde el modo vwii hackeo los 3 nucleos para hacer las comprobaciones, de todos modos los datos de marcan son totalmente fiables, lherre en persona los confirmo

http://www.elotrolado.net/hilo_marcan-descubre-la-velocidad-real-de-la-cpu-y-gpu-de-wiiu_1837031_s100#p1730911139

dragonsacred escribió:

peloconcelo escribió:

superfenix2020 escribió:....

Es un tocho, pero muy interesante, sobre lo de Marcan, no estoy seguro pero creo haber leido que para saber las frecuencias de cpu y gpu, lo hizo en el modo vWii, por lo que esas cifras podrian variar en el modo wii u.

supuestamente desde el modo vwii hackeo los 3 nucleos para hacer las comprobaciones, de todos modos los datos de marcan son totalmente fiables, lherre en persona los confirmo

http://www.elotrolado.net/hilo_marcan-descubre-la-velocidad-real-de-la-cpu-y-gpu-de-wiiu_1837031_s100#p1730911139

Lo de hackear los nucleos no lo sabia, esta bien saberlo, gracias por la aclaracion

Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´. Nintendo lo ha conseguido jugando con los colores que se envían al mando, e incluso tratando parte del audio que se envía. Por supuesto que en Google habían pensado algo parecido, pero llevarlo a cabo es algo muy distinto.

Pero es una consola desfasada, con tecnologia obsoleta, y bla, bla, bla

Fanzelda escribió:

Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´. Nintendo lo ha conseguido jugando con los colores que se envían al mando, e incluso tratando parte del audio que se envía. Por supuesto que en Google habían pensado algo parecido, pero llevarlo a cabo es algo muy distinto.

Pero es una consola desfasada, con tecnologia obsoleta, y bla, bla, bla

fuente?me gustaria leer la noticia entera

Fanzelda escribió:

Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´.

Pero es una consola desfasada, con tecnologia obsoleta, y bla, bla, bla

Que va a ser obsoleta, si es capaz de enviar la imagen al Gamepad "con adelanto", antes incluso de renderizarla.
Para conseguir esto incorpora el revolucionario condensador de fluzo integrado en la GPGPU y refrigerado por un mini iceberg.

T1100 escribió:

Fanzelda escribió:

Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´.

Pero es una consola desfasada, con tecnologia obsoleta, y bla, bla, bla

Que va a ser obsoleta, si es capaz de enviar la imagen al Gamepad "con adelanto", antes incluso de renderizarla.
Para conseguir esto incorpora el revolucionario condensador de fluzo integrado en la GPGPU y refrigerado por un mini iceberg.

Esas chorreadas y tu sarcasmo barato puedes ahorrartelo amigo, que a ti la consola te parezca mala tecnológicamente no quiere decir que actúes de esa manare tan nefasta. Reportado estas...

T1100 escribió:

Fanzelda escribió:

Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´.

Pero es una consola desfasada, con tecnologia obsoleta, y bla, bla, bla

Que va a ser obsoleta, si es capaz de enviar la imagen al Gamepad "con adelanto", antes incluso de renderizarla.
Para conseguir esto incorpora el revolucionario condensador de fluzo integrado en la GPGPU y refrigerado por un mini iceberg.

hostia, esa broma tiene, cuantos años, 30?enhorabuena, has marcado un nuevo hito en coñas tontas obsoletas...........

Era un broma que ha hecho el chaval, como sois algunos.

Y sí efectivamente WIIU es una consola tecnológicamente obsoleta yo no se que tecnologias mágicas en el tablet (que al final lo usan 2 juegos) queréis ver.

Pero juer ese no es su atractivo, su atractivo son los exclusivos nintendo y el que se la compra se la compra por eso independientemente de gráficos.

Un Saludo.

dragonsacred escribió:

Fanzelda escribió:

Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´. Nintendo lo ha conseguido jugando con los colores que se envían al mando, e incluso tratando parte del audio que se envía. Por supuesto que en Google habían pensado algo parecido, pero llevarlo a cabo es algo muy distinto.

Pero es una consola desfasada, con tecnologia obsoleta, y bla, bla, bla

fuente?me gustaria leer la noticia entera

Aqui la tienes compañero http://www.revogamers.net/articulos/wii ... 537/1.html

El Wii U GamePad y sus imitadores
¿Qué artilugios y programas han salido inspirados en el Wii U GamePad?


Una de las mejores maneras de ver si una tecnología es buena, es preguntando a la competencia, pero no a las cabezas visibles, estos nunca te dirán que un producto de la competencia es bueno. Lo mejor es preguntar a lostécnicos de campo, a los que tienen que probar la tecnología de la competencia para determinar sus virtudes y después, copiarlas si es posible.
Bueno, pues eso es lo que he hecho. He hablado con técnicos de Google expertos en Chromecast y con técnicos de Microsoft, sobre el Wii U GamePad y su tecnología.
Resulta que lo que ha conseguido Nintendo con el Wii U GamePad es admirado por las principales compañíastecnológicas. De hecho, muchas de estas compañías llevaban años intentando conseguir algo parecido, y gracias al Wii U GamePad, han visto cual es el camino a seguir.
El Wii U GamePad inspira otras tecnologías
Nintendo ha sufrido el `copiar y pegar´ en sus propias carnes muchas veces, ahora le toca el turno al Wii U GamePad. No sólo estamos hablando de una PS Vita conectada a una PS4 o de Smartglass de Microsoft, hablamos de la creación de tecnología para hacer lo mismo que hace Wii U con su GamePad, pero aplicado a otros dispositivos y a otros entornos.
Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´. Nintendo lo ha conseguido jugando con los colores que se envían al mando, e incluso tratando parte del audio que se envía. Por supuesto que en Google habían pensado algo parecido, pero llevarlo a cabo es algo muy distinto.
Los técnicos de Microsoft no son tan abiertos a la hora de expresar su admiración, pero sí reconocen que Nintendo les ha enseñado el camino a seguir.
El Wii U GamePad inspira otras tecnologías
Existen en la actualidad tres tipos de tecnologías que destacan por encima del resto. Estas son DLNA, Miracast yChromecast. La base sobre la que se apoyan esas tres tecnologías es Wi-Fi Direct, conocida originalmente también como Wi-Fi P2P, que llegó al mercado en 2010 y permitía la conexión punto a punto de manera sencilla entre dos dispositivos.
Wi-Fi Direct dio lugar a un nuevo método de transmisión de archivos entre dispositivos que permitía velocidades muy superiores a Bluetooth, es unas 10 veces más rápido y además es más eficaz para trasferir ficheros. Sin embargo, seguía sufriendo de cierto retardo al transmitir video, lo que impedía hacer algo parecido a lo que hace Wii U.
Veamos qué tecnologías existen en la actualidad y cuál ha sido su evolución.

Miracast
Pese a que Miracast es un estándar abierto, creado por la Wi-Fi Alliance, son Google y sus dispositivos Android quienes más se están aprovechando de sus capacidades.
Miracast es una funcionalidad que permite mandar vía Wi-Fi Direct la pantalla de un dispositivo Android en tiempo real, con un retraso muy pequeño, a otro dispositivo, normalmente la TV. Vio la luz con Android 4.2 Jelly Bean y para que funcione necesitamos que el móvil/tablet ofrezca esta posibilidad y que la TV sea compatible. La mayoría de televisiones de última generación con Wi-Fi Direct lo son. Curiosamente, Wii U, PS4 y Xbox One también.
El Wii U GamePad y sus imitadores
Con Miracast se puede transmitir inalámbricamente contenido de audio y vídeo con calidad HDMI, hasta Full HD, y audio 5.1 a una TV compatible que servirá de pantalla clonada de nuestro dispositivo.
Poco más se puede hacer con esta tecnología. La aplicación habitual es mandar algo desde el móvil o Tablet a la TV. Es posible que Miracast lo hayáis visto o incluso usado con otros nombres, pues cada fabricante está usando el suyo propio. Por ejemplo, Samsung lo llama AllShare Cast.

DLNA
DLNA corresponden a las siglas de Digital Living Network Alliance que no es más que una asociación de compañías electrónicas que buscaban un método para poder compartir elementos multimedia entre distintos dispositivos, creando un modelo que fuera estándar.
Esta asociación fue creada por Sony y llevaban desde el 2003 intentando hacer lo mismo que hace Nintendo con el Wii U GamePad, pero ha sido en los últimos 2 años cuando más movimiento está teniendo, gracias a que ahora la tecnología permite cosas que antes eran imposibles. ¿Adivináis quien se subió al carro de DLNA? Pues Microsoft, entre otros fabricantes como Samsung o LG.
DLNA se compone de varios componentes: una Digital Media Server, lo que sería la consola (o la TV), y un Digital Media Controller, que sería la Tablet, el teléfono o el mando para controlar la consola. Al igual que el Wii U GamePad, DLNA está pensado para compartir archivos multimedia y sólo permite el envío y visualización de archivos de vídeo, audio y fotos. Se pretende que DLNA tenga soporte estándar de tal forma que se pueda usar, por ejemplo, un móvil Sony para controlar una consola de Microsoft.
El Wii U GamePad y sus imitadores
El punto de vista de Microsoft es el siguiente: si el punto fuerte de Wii U es su mando, demuestra que Xbox One puede hacer algo muy similar y le habrás quitado su valor diferencial. Parte de razón no les falta.
Microsoft contempla la evolución de DLNA para mejorar Smartglass y hacer con una Tablet y una Xbox One algo muy similar a lo que es Wii U. Ya están experimentando en esta dirección con varias experiencias relacionadas con videojuegos.
Curiosamente, uno de los componentes más usados en la tecnología DLNA, está desarrollado por Access, que son losresponsables del navegador de Wii U. Se trata de NetFront Living Connect. Tanto Microsoft como Google saben que Nintendo usa esta tecnología en su Wii U, que a su vez es la misma que usa Xbox 360 para su Xbox Media Player. Lo que no tienen claro es cómo la usa y para qué, pero creen que es para enviar los videos desde la consola al mando cuando se usa el navegador Web.

Chromecast
Por último está Chromecast, del cual tuve la ocasión de presenciar una demo en vivo y que se trata de la más avanzada de las tres tecnologías.
Google ha lanzado un pequeño dispositivo que en principio sirve para la visualización de contenidos en la TV que mezcla conceptos de DLNA y Miracast. En un futuro, Google no descarta expandir este sistema a otros dispositivos, incluidas las consolas.
Para ello utilizan un pequeño dispositivo con sistema operativo Android que recibe órdenes desde un Smartphone o tablet para conectarse a Internet y reproducir contenidos.
El Wii U GamePad y sus imitadores
El móvil o la Tablet se comportan como un control remoto. Veamos un par de ejemplos:
YouTube: buscas un vídeo en tu smartphone, que está conectado a la misma red inalámbrica que Chromecast. Podemos enviar el vídeo directamente desde el Smartphone a Chromecast pero, en lugar de eso, lo que realmente sucede es que se manda a Chromecast la orden de que reproduzca directamente el contenido elegido desde Internet, liberando de esa manera el ancho de banda entre el móvil y Chromecast. Por supuesto, desde el móvil o tabletpodemos controlar la reproducción en todo momento. Este método también puede aligerar los juegos en la nube ya que parte del proceso se hace en local.
Otra de las funcionalidades de Chromecast es la posibilidad de poder enviar los contenidos de una pestaña del navegador del movil a la TV y verlos en tiempo real. Aquí se incluyen, por supuesto, los juegos Web.
Chromecast es un dispositivo que si llega a gran escala recibirá numerosos plugins para distintos servicios web, incluido juegos, y entonces sí tendrá sentido en muchos casos. Actualmente da soporte a YouTube, Google Play y Netflix, aunque se espera que haya un gran desembarco de aplicaciones y servicios web que ofrezcan app para Chromecast en los próximos meses.
A diferencia de lo que hizo Nintendo con el Gamepad, Chromecast requiere que el dispositivo controlador tenga cierta capacidad de proceso, sin eso no serían capaces de hacerlo funcionar. Se vuelve a destacar el trabajo de Nintendo, ya que Wii U usa un GamePad prácticamente sin capacidad de proceso y capaz de hacer todo lo que hace.
De todas las tecnologías que he visto esta es la que mejor podría imitar a un Wii U GamePad. Pero, a pesar de lo avanzado de su desarrollo, sigue habiendo retardo, sobre todo si lo queremos usar con videojuegos. Para muestra este video:

Por supuesto que hay otras tecnologías, como AirPlay o DIAL, pero estas se centran más en el simple envío de video desde un terminal a otro, sin estar abiertos a otras posibilidades mas interactivas.
DLNA, Miracast, Chromecast, AirPlay o DIAL consiguen enviar video y audio de un dispositivo a otro. Y lo consiguen con poco retardo, casi nulo. Otro tema es tratar algo interactivo como son los videojuegos. Ahí todos estos sistemas cojean. Por supuesto que tienen la base para conseguir buenos resultados, pero necesitan años de desarrollo para conseguir un resultado como el que ahora tiene Nintendo.
El resumen es que Nintendo ha hecho un excelente trabajo con el Wii U GamePad, consiguiendo algo que muchos persiguen y yendo incluso un paso más allá, sirviendo de referencia a otras compañías que buscan hacer algo similar ¿Era este el campo en el que había que invertir? ¿Es lo que querían los jugadores? Eso ya es otro asunto…
Ricardo Garcia de Consuegra es al autor de este artículo y el Responsable de IT de idearapida.com
Debate en la comunidad sobre el Wii U GamePad, su tecnología y las imitaciones en el sector tecnológico

Este hilo es para quitarse el sombrero,me sorprende lo mucho que controla la gente de estos temas,gracias por molestarse en explicarlo para los demas

Fanzelda escribió:
Aqui la tienes compañero http://www.revogamers.net/articulos/wii ... 537/1.html

El Wii U GamePad y sus imitadores
¿Qué artilugios y programas han salido inspirados en el Wii U GamePad?


Una de las mejores maneras de ver si una tecnología es buena, es preguntando a la competencia, pero no a las cabezas visibles, estos nunca te dirán que un producto de la competencia es bueno. Lo mejor es preguntar a lostécnicos de campo, a los que tienen que probar la tecnología de la competencia para determinar sus virtudes y después, copiarlas si es posible.
Bueno, pues eso es lo que he hecho. He hablado con técnicos de Google expertos en Chromecast y con técnicos de Microsoft, sobre el Wii U GamePad y su tecnología.
Resulta que lo que ha conseguido Nintendo con el Wii U GamePad es admirado por las principales compañíastecnológicas. De hecho, muchas de estas compañías llevaban años intentando conseguir algo parecido, y gracias al Wii U GamePad, han visto cual es el camino a seguir.
El Wii U GamePad inspira otras tecnologías
Nintendo ha sufrido el `copiar y pegar´ en sus propias carnes muchas veces, ahora le toca el turno al Wii U GamePad. No sólo estamos hablando de una PS Vita conectada a una PS4 o de Smartglass de Microsoft, hablamos de la creación de tecnología para hacer lo mismo que hace Wii U con su GamePad, pero aplicado a otros dispositivos y a otros entornos.
Según los técnicos de Google, lo que ha hecho Nintendo es admirable, no sólo han conseguido enviar toda la información al Wii U GamePad sin retardo, si no, que incluso llega con `adelanto´. Nintendo lo ha conseguido jugando con los colores que se envían al mando, e incluso tratando parte del audio que se envía. Por supuesto que en Google habían pensado algo parecido, pero llevarlo a cabo es algo muy distinto.
Los técnicos de Microsoft no son tan abiertos a la hora de expresar su admiración, pero sí reconocen que Nintendo les ha enseñado el camino a seguir.
El Wii U GamePad inspira otras tecnologías
Existen en la actualidad tres tipos de tecnologías que destacan por encima del resto. Estas son DLNA, Miracast yChromecast. La base sobre la que se apoyan esas tres tecnologías es Wi-Fi Direct, conocida originalmente también como Wi-Fi P2P, que llegó al mercado en 2010 y permitía la conexión punto a punto de manera sencilla entre dos dispositivos.
Wi-Fi Direct dio lugar a un nuevo método de transmisión de archivos entre dispositivos que permitía velocidades muy superiores a Bluetooth, es unas 10 veces más rápido y además es más eficaz para trasferir ficheros. Sin embargo, seguía sufriendo de cierto retardo al transmitir video, lo que impedía hacer algo parecido a lo que hace Wii U.
Veamos qué tecnologías existen en la actualidad y cuál ha sido su evolución.

Miracast
Pese a que Miracast es un estándar abierto, creado por la Wi-Fi Alliance, son Google y sus dispositivos Android quienes más se están aprovechando de sus capacidades.
Miracast es una funcionalidad que permite mandar vía Wi-Fi Direct la pantalla de un dispositivo Android en tiempo real, con un retraso muy pequeño, a otro dispositivo, normalmente la TV. Vio la luz con Android 4.2 Jelly Bean y para que funcione necesitamos que el móvil/tablet ofrezca esta posibilidad y que la TV sea compatible. La mayoría de televisiones de última generación con Wi-Fi Direct lo son. Curiosamente, Wii U, PS4 y Xbox One también.
El Wii U GamePad y sus imitadores
Con Miracast se puede transmitir inalámbricamente contenido de audio y vídeo con calidad HDMI, hasta Full HD, y audio 5.1 a una TV compatible que servirá de pantalla clonada de nuestro dispositivo.
Poco más se puede hacer con esta tecnología. La aplicación habitual es mandar algo desde el móvil o Tablet a la TV. Es posible que Miracast lo hayáis visto o incluso usado con otros nombres, pues cada fabricante está usando el suyo propio. Por ejemplo, Samsung lo llama AllShare Cast.

DLNA
DLNA corresponden a las siglas de Digital Living Network Alliance que no es más que una asociación de compañías electrónicas que buscaban un método para poder compartir elementos multimedia entre distintos dispositivos, creando un modelo que fuera estándar.
Esta asociación fue creada por Sony y llevaban desde el 2003 intentando hacer lo mismo que hace Nintendo con el Wii U GamePad, pero ha sido en los últimos 2 años cuando más movimiento está teniendo, gracias a que ahora la tecnología permite cosas que antes eran imposibles. ¿Adivináis quien se subió al carro de DLNA? Pues Microsoft, entre otros fabricantes como Samsung o LG.
DLNA se compone de varios componentes: una Digital Media Server, lo que sería la consola (o la TV), y un Digital Media Controller, que sería la Tablet, el teléfono o el mando para controlar la consola. Al igual que el Wii U GamePad, DLNA está pensado para compartir archivos multimedia y sólo permite el envío y visualización de archivos de vídeo, audio y fotos. Se pretende que DLNA tenga soporte estándar de tal forma que se pueda usar, por ejemplo, un móvil Sony para controlar una consola de Microsoft.
El Wii U GamePad y sus imitadores
El punto de vista de Microsoft es el siguiente: si el punto fuerte de Wii U es su mando, demuestra que Xbox One puede hacer algo muy similar y le habrás quitado su valor diferencial. Parte de razón no les falta.
Microsoft contempla la evolución de DLNA para mejorar Smartglass y hacer con una Tablet y una Xbox One algo muy similar a lo que es Wii U. Ya están experimentando en esta dirección con varias experiencias relacionadas con videojuegos.
Curiosamente, uno de los componentes más usados en la tecnología DLNA, está desarrollado por Access, que son losresponsables del navegador de Wii U. Se trata de NetFront Living Connect. Tanto Microsoft como Google saben que Nintendo usa esta tecnología en su Wii U, que a su vez es la misma que usa Xbox 360 para su Xbox Media Player. Lo que no tienen claro es cómo la usa y para qué, pero creen que es para enviar los videos desde la consola al mando cuando se usa el navegador Web.

Chromecast
Por último está Chromecast, del cual tuve la ocasión de presenciar una demo en vivo y que se trata de la más avanzada de las tres tecnologías.
Google ha lanzado un pequeño dispositivo que en principio sirve para la visualización de contenidos en la TV que mezcla conceptos de DLNA y Miracast. En un futuro, Google no descarta expandir este sistema a otros dispositivos, incluidas las consolas.
Para ello utilizan un pequeño dispositivo con sistema operativo Android que recibe órdenes desde un Smartphone o tablet para conectarse a Internet y reproducir contenidos.
El Wii U GamePad y sus imitadores
El móvil o la Tablet se comportan como un control remoto. Veamos un par de ejemplos:
YouTube: buscas un vídeo en tu smartphone, que está conectado a la misma red inalámbrica que Chromecast. Podemos enviar el vídeo directamente desde el Smartphone a Chromecast pero, en lugar de eso, lo que realmente sucede es que se manda a Chromecast la orden de que reproduzca directamente el contenido elegido desde Internet, liberando de esa manera el ancho de banda entre el móvil y Chromecast. Por supuesto, desde el móvil o tabletpodemos controlar la reproducción en todo momento. Este método también puede aligerar los juegos en la nube ya que parte del proceso se hace en local.
Otra de las funcionalidades de Chromecast es la posibilidad de poder enviar los contenidos de una pestaña del navegador del movil a la TV y verlos en tiempo real. Aquí se incluyen, por supuesto, los juegos Web.
Chromecast es un dispositivo que si llega a gran escala recibirá numerosos plugins para distintos servicios web, incluido juegos, y entonces sí tendrá sentido en muchos casos. Actualmente da soporte a YouTube, Google Play y Netflix, aunque se espera que haya un gran desembarco de aplicaciones y servicios web que ofrezcan app para Chromecast en los próximos meses.
A diferencia de lo que hizo Nintendo con el Gamepad, Chromecast requiere que el dispositivo controlador tenga cierta capacidad de proceso, sin eso no serían capaces de hacerlo funcionar. Se vuelve a destacar el trabajo de Nintendo, ya que Wii U usa un GamePad prácticamente sin capacidad de proceso y capaz de hacer todo lo que hace.
De todas las tecnologías que he visto esta es la que mejor podría imitar a un Wii U GamePad. Pero, a pesar de lo avanzado de su desarrollo, sigue habiendo retardo, sobre todo si lo queremos usar con videojuegos. Para muestra este video:

Por supuesto que hay otras tecnologías, como AirPlay o DIAL, pero estas se centran más en el simple envío de video desde un terminal a otro, sin estar abiertos a otras posibilidades mas interactivas.
DLNA, Miracast, Chromecast, AirPlay o DIAL consiguen enviar video y audio de un dispositivo a otro. Y lo consiguen con poco retardo, casi nulo. Otro tema es tratar algo interactivo como son los videojuegos. Ahí todos estos sistemas cojean. Por supuesto que tienen la base para conseguir buenos resultados, pero necesitan años de desarrollo para conseguir un resultado como el que ahora tiene Nintendo.
El resumen es que Nintendo ha hecho un excelente trabajo con el Wii U GamePad, consiguiendo algo que muchos persiguen y yendo incluso un paso más allá, sirviendo de referencia a otras compañías que buscan hacer algo similar ¿Era este el campo en el que había que invertir? ¿Es lo que querían los jugadores? Eso ya es otro asunto…
Ricardo Garcia de Consuegra es al autor de este artículo y el Responsable de IT de idearapida.com
Debate en la comunidad sobre el Wii U GamePad, su tecnología y las imitaciones en el sector tecnológico