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

1, 2, 3, 4, 513
Hace ya un tiempo que digo que voy a hacer una serie de hilos explicando un poco las entrañas de la consola, o como mínimo, lo que conocemos de ella. Dado que su arquitectura es a grandes trechos (muy grandes, enormes casi) comparable a la de Xbox 360 voy a establecer una comparación directa con esa consola para así tener una idea de qué esperar o no de ella.

Empiezo hoy por la parte con menos misterios de todos, la CPU de la consola.

Cosas que sabemos en general:
1. Herencia directa de la CPU de Wii/GC.
1.1 Ejecución de instrucción fuera de orden limitada
1.2 1 hilo de ejecución por núcleo
1.3 Pipeline corta (4 y 7 estapas para enteros/coma flotante)
2. 3 núcleos.
3. eDram en vez de SRAM para las cache L2. Como puede emular la Wii por hardware, sabemos que a nivel de latencias eso no ha supuesto ningún impacto negativo.
4. Caches L2 incrementadas de 256KB a 2MB/512KB dependiendo del núcleo.
5. Frecuencia a 1,243Ghz en vez de a 0,729Ghz como en la Wii

Diferencias no confirmadas
Parece ser que el análisis del núcleo que se ha hecho en foros ingleses a partir de una imagen proporcionada por una empresa dedicada al escaneo de chips hace sospechar que el número de registros se ha visto incrementado con respecto al núcleo de la Wii. Como eso no podrá saberse del cierto hasta que se filtren imágenes de más resolución o documentación, de momento lo dejamos al aire.
Personalmente tengo otra teoría de otras cosas que podrían haber “cambiado”, que comentaré cuando llegue el momento.

Claves en la comparación con el Xenon Xbox 360:
1. OOE vs IOE (re-ordenación de instrucciones vs no re-ordenación)

2. Pipelines mucho más cortas (4 y 7 etapas para entero/coma flotante vs 23 y 29 en el Xenon) lo que significa que las instrucciones se completan en menos ciclos.

3. Caches (en Xbox 360, 32+32KB L1 por núcleo y 1MB L2 a compartir entre núcleos).

4. Registros de memoria (+ numerosos en Xbox 360).


Empecemos a analizar un poco en profundidad.
Del diseño de la CPU de GC/Wii/WiiU hay que señalar que está basado en la eficiencia, es decir, se prioriza absolutamente las instrucciones ejecutadas por ciclo de reloj. Las ventajas de hacerlo así son muy notables de cara a abaratar el coste de programación.
Con la N64, que era una consola muy complicada debido a ciertos cuellos de botella y otras peculiaridades del hardware, Nintendo vio que lo más caro de una consola podría no ser la consola en sí, sino lo que luego le costaba a la compañía programar los juegos para ella.

Hasta la llegada del 3D los juegos eran muy sencillos, programados por poca gente, así que la diferencia entre una arquitectura fácil de dominar de una complicada no se notaba mucho. A medida que la complejidad de lo que se quería hacer aumentaba el impacto de tener una arquitectura amigable se iba haciendo cada vez más grande, y Nintendo dieron el salto con la GC en ese sentido.

En contraposición con las CPU anteriores, a falta de tener más detalles específicos cuyo impacto no podemos analizar, podemos destacar una cosa del Espresso: el tamaño de la cache L2 es sin duda un salto exponencial.
De GC a Wii los saltos habían sido muy moderados, casi inexistentes. Una de las pocas cosas que se cambiaron fue la versatilidad de la cache L2, 2 way-set associative en GC y 8 way set-associative en la Wii (no vale la pena entrar a explicarlo en profundidad, pero digamos que 8 way set associative es más eficiente en lo que al aprovechamiento de memoria se refiere).

De Wii a WiiU ese apartado ha dado un salto absolutamente bestial. Se pasa a 2MB y 512KB dependiendo del núcleos, lo que significa que más datos podrán ser gestionados sin tener que esperar a la lenta y lejana memoria principal. Además, como la “asociatividad” debe mantenerse PROPORCIONALMENTE en el caso de los núcleos “pequeños” (los de 512KB de cache L2, uno de los cuales se usa para emular la Wii y el otro que por razones obvias de rendimiento deberá ser idéntico), los núcleos pequeños deberían ser por lógica 16 way-set associative, ya que se debe lograr cuando se emula la Wii que los 256KB de cache L2 que se usan para hacerlo sean 8-way set associative.
Supongo que el chip grande también será 16-way set associative por temas de complejidad (a más asociatividad más complejidad en la circuiteria), sencillamente cada “set” será más grande y tendrá más bloques.

La comparación con el Xenon es más complicada ya que son CPUs que difieren en absolutamente todo lo que una CPU puede diferir excepto en el número de núcleos así que el análisis tendrá que ser mucho más extenso.

Tamaño del pipeline

La función de una CPU no es otra que la de ejecutar unas instrucciones, y la cantidad de pasos que realiza para lograrlo es el tamaño del pipeline.
Una CPU de una sola etapa lo haría todo de golpe, y tras terminar una instrucción se pondría a por la siguiente.

Para aumentar la eficiencia de las CPUs se dividió ese proceso en varias etapas menores. Como cada etapa era más sencilla, se podía aumentar la frecuencia. La explicación a grandes trechos es que dividiendo un circuito muy complejo en varios circuitos menos complejos entrelazados entre si, al ser esos circuitos más sencillos y la operación a realizar más pequeña, se completan antes y pueden volver a completarse de nuevo (ciclo) en menor intervalo de tiempo.

La gracia del invento es que como todas las instrucciones pasan por esas etapas de forma lineal, y cada etapa se completa por si misma, una vez una operación ha llegado a una etapa la anterior puede empezar a procesar la siguiente instrucción, para así traducir el incremento en frecuencia en incremento en instrucciones ejecutadas.

Así pues, si a más etapas más frecuencia, y si al final podemos seguir escupiendo una instrucción por ciclo, lo lógico sería hacer infinidad de etapas infinitamente pequeñas, no? Pues no.
Primero porque el tener muchas etapas significa que una instrucción no se completa hasta que ha pasado por todas. Si tenemos 10 etapas, significa que tendremos en el mejor de los casos (porque nos interesa que a cada ciclo se completen tantas instrucciones como sea posible) 10 instrucciones ejecutándose simultáneamente en vez de una sola, con lo que necesitaremos tener a mano un número mayor de datos y por tanto más memoria de bajo nivel para poder funcionar.

Otro impacto evidente es que en caso que haya que vaciar el pipeline por el motivo que sea, se pierden tantos ciclos como etapas a vaciar hay. Así pues, vaciar el pipeline en el Espresso es 4-6 veces más barato que hacerlo en el Xenon.
Y cuando hay que vaciar el pipeline? Bueno, el pipeline se vacía en los siguientes casos:
La operación B depende del resultado de la operación A y no hay nada más que hacer de mientras. Como B no puede empezar hasta que A termina, las etapas de la operación B no pueden completarse hasta el fin de A. Existen otros tipos de dependencia entre instrucciones que también pueden derivar en la necesidad de vaciar el pipeline, pero tampoco hace falta explicarlos uno por uno.

Error en la predicción de brancas. Cuando una CPU se encuentra una branca (un “if” en programación de alto nivel para que nos hagamos a la idea) para no quedarse sin hacer nada especula con qué resultado será el más probable y empieza a resolverlo de antemano. Si luego resulta que ha especulado mal debe vaciar el pipeline para resolver las operaciones buenas.
Adicionalmente, la predicción de brancas requiere de un tamaño muy superior en caso que la longitud de la Pipeline sea muy superior. El motivo es sencillo, un BP (branch predictor) es sencillamente una unidad encargada de resolver brancas (ifs) y que mientras las resuelve ejecutan una predicción basada en unos parámetros, y para optimizar empiezan a ejecutar instrucciones en base a esa predicción. Esas instrucciones aún cuando se ejecutan no pueden darse por finalizadas, y por tanto deben guardarse en un registro de instrucciones a parte, para luego en caso de confirmarse la predicción darse por bueno y copiarse donde toca, o en caso de predicción fallida toca vaciar pipeline (deshacer lo hecho) y volver a llenar-la con el código correcto.
En caso de que la branca no se haya resuelto cuando se ha llenado ese registro de la unidad de predicción de brancas se paraliza la ejecución de instrucciones hasta que se resuelva.

Todo eso tiene un impacto superior en pipelines largas, que unido al hecho de que hay otros componentes físicos (resistencia a la electricidad, comportamientos de la energía a altas frecuencias, etc.) que impiden que un procesador de silicio incremente su frecuencia indefinidamente por el simple hecho de simplificar sus estructuras, hacen que una pipeline larga sea cada vez menos atractiva (siguen habiéndolas y siguen teniendo sus ventajas también, por ejemplo, las del Jaguar de PS4/Xbox One son también pipelines muy largas).

Ejecución en orden vs Ejecución fuera de orden
Un programa moderno es un conjunto de "sub-programas" que realizan tareas menores, y esos "sub-programas" están formados por instrucciones que se mandan a la CPU, y que con unos datos que también se le mandan, se ejecuta una funcionalidad determinada.
Por ejemplo, 1 + 3 sería un programa con dos datos y una instrucción (que internamente se traduce en más operaciones, ya que hay que escribir esos datos en los registros para luego ejecutar la operación y volver a escribir el resultado final).

Hay una condición que debe cumplirse, el resultado de las instrucciones tiene que ser el esperado, y por consiguiente, al final la cosa ha de quedar ordenada.
Pero qué sucedería si pudiésemos desordenar el código internamente, para luego ordenarlo otra vez y así aprovechar mejor la CPU?
Una CPU en orden funciona siempre así:
Coge instrucción.
Ejecuta instrucción.
Finaliza instrucción.

Una CPU fuera de orden, sin embargo, funciona así:
Coge instrucción/es
Ordena instrucciones (cola de instrucciones)
Ejecuta instrucciones en orden de cola
Guarda el resultado desordenado
Finaliza instrucción en orden

Veamos qué posibilidades conlleva eso:
Cada CPU cuenta con múltiples unidades de ejecución. Que nos interesen, en el Espresso tenemos, por cada núcleo:
IU0 4 etapas
IU1 4 etapas
FPU 7 etapas
BP (branch prediction unit, funciona distinto a las demás y no entraré en detalle, pero afecta debido al tema OOE vs IOE)
Adicionalmente están las unidades relacionadas con la memoria (Load/Store Unit y System Register Unit) para cargar/guardar datos desde/a la caché/registros.

El Xenon, por su parte, tiene:
IU 23 etapas
FPU 29 etapas
VMX128 (esta en realidad son 3 unidades distintas, pero no hace falta entrar en detalle porque no influye a nivel de lo que analizamos).
BP
Y también como el Espresso las unidades “secundarias” mencionadas ( LSU, SRU).

Bien, el caso es que el diseño In Order del Xenon es muy fácil de exlicar. Cada hilo de ejecución puede coger 1 instrucción, la manda a la unidad correspondiente (IU, FPU o VMX128) y en caso de situación idílica saldrá otra instrucción finalizada de la unidad en cuestión.

En el caso de WiiU, y basando ese análisis en lo que hacía el Gekko de GameCube (con lo que podría ser que hubiese alguna mejora no confirmada /filtrada que se me escape en ese análisis), cada núcleo hace lo siguiente por thread (aunque en ese caso no hay multi-threading y por consiguiente, sólo se ejecuta un thread concreto por núcleo):
Hasta 4 instrucciones se cogen de la cache L1 de instrucciones por cada ciclo. Esas se van para la cola de reordenamiento.
Desde allí, 2 instrucciones (+1 adicional en caso de que una sea para el BP) se pasan a las unidades correspondientes. En caso óptimo de código, se despacharán 2 (+1) instrucciones por ciclo.
Os habréis fijado que hay 2 unidades para enteros, IU1 e IU2. Ambas son idénticas excepto porque una puede hacer multiplicaciones y divisiones mientras que la otra no. Esa duplicidad existe porque en caso que la IU1 esté ocupada en una operación que dure múltiples ciclos (la instrucción está en una parte del pipeline y necesita permanecer allí durante varios ciclos) se puede mandar otras instrucciones a la IU2 para que vayan resolviéndose allí, para posteriormente reordenar.
En un diseño IOE esas duplicidades no tienen sentido, pues jamás puede una instrucción completarse sin que la anterior se haya completado también.

Multi-threading y caches
Tal y como he dicho antes, un programa complejo no deja de ser un conjunto de sub-programas más simples que hacen una función determinada. Cuando esos "sub-programas" no dependen el uno del otro pueden ejecutarse simultáneamente, y en caso de que la CPU lo soporte, así sucede.
En nuestro caso, el Xenon de Xbox 360 soporta multi-threading mientras que el Espresso no. Las ventajas del multi-threading se notan más en una arquitectura IOE que en una OOE, pues en las OOE la reordenación de instrucciones ya permite un aprovechamiento muy superior de los recursos, y la pipeline se llena más fácilmente. En el caso del Espresso, además, la pipeline es cortísima para tener máxima eficiencia con respecto a los teóricos, con lo que el multi-threading no sería ni mucho menos una opción inteligente.
Aún así, para el Xenon si supone una gran ventaja el tenerlo con respecto el no tenerlo, pero a diferencia del OOE que una vez implementado (con sentido, por supuesto) tiene unos beneficios “transparentes”, el multi-threading tiene sus inconvenientes.
Como los threads son “sub-programas” independientes, no pueden implementarse en todos los escenarios con la misma fuerza. La Xbox360 carece de muchos chips dedicados que si tiene la WiiU, así que en ese sentido lo tiene más fácil para llenar hilos.
El caso es que la naturaleza del multi-threading obliga a tener duplicidad de recursos en lo que a memoria interna de la CPU se refiere. A nivel interno la Xbox 360 tiene los registros de memoria duplicados para el multi-threading, pero cuando llegamos a las cache, aquí aparecen las primeras “penalizaciones” de ese sistema.
Tanto el Xenon como el Espresso tienen 32KB de cache L1 tanto para instrucciones como para datos. Pero si queremos un escenario óptimo de multi-threading para el Xenon, esos 32+32KB de cache L1 deben dividirse entre los threads. Ello aumentará las veces que no encontremos datos/instrucciones en la cache L1 y tengamos que irnos hasta la cache L2 a buscarlos, y aquí llegamos a otra de las grandes diferencias entre ambos procesadores.
El Xenon tiene 1MB de cache L2 a repartir entre 6 threads, suponiendo threads idénticos, eso se traduce en 166KB de cache L2 por cada thread. Los programadores pueden evidentemente programar los threads para que tengan más peso en función de las necesidades, pero el caso es que ese 1MB de cache L2 debe repartirse entre todos los threads.
En comparación, la WiiU implementa un sistema distinto. Cada núcleo tiene su cache dedicada, y esa se reparte en una configuración de 512KB para el núcleo 0, 2MB para el núcleo 1 y 512KB para el núcleo 2.
Si recordáis, antes he dicho que a una pipeline larga hace falta más cache porque se están manejando más instrucciones (y sus correspondientes datos) simultáneamente para aprovechar cada ciclo de reloj, así que la diferencia a nivel de caches es abismal.
Adicionalmente, la versatilidad de las caches del Espresso es superior. Las caches L1 del Xenon son 2-way set associative en el caso de la de instrucciones, y 4-way set associative en el caso de la de datos. Las del Espresso son 8-way set associative tanto para datos como para instrucciones.
En el caso de la cache L2 la diferencia es aún más grande, 2-way set associative en Xbox360 frente a 16-way set associative del Espresso. Proporcionalmente y por núcleo, incluso el más grande de la WiiU es mucho más versátil (doble de tamaño y 8 veces más de associatividad) que el MB que tiene el Xenon de L2.
Las ventajas de la associatividad no son proporcionales, es decir, se nota mucho más la diferencia entre 2-way set associative y 4-way set associative que entre 4-way set associative y 8-way set associative, pero aún así es bueno tenerlo en cuenta.
En resumen, la CPU de WiiU depende muchísimo menos de la RAM principal (tanto en latencias como en ancho de banda) que la de Xbox 360.

Repertorio (Set) de instrucciones
En ese caso el de Xbox 360 es más completo. Gracias a la unidad VMX128 se pueden hacer un determinado número de operaciones relacionadas con los gráficos que en el Espresso no pueden llevarse a cabo, como mínimo, tan directamente. No es que los núcleos del Espresso estén totalmente mancos en ese sentido (de hecho en operaciones de la FPU tiene un rendimiento superior por ciclo a diseños chips como el Bobcat de AMD), pero sí que están cojos en comparación con los núcleos del Xenon.
Eso se traduce en que lo que en el Xenon puede ser una sola instrucción que se manda a la VMX128 en el Espresso el equivalente podrían ser 2 o más instrucciones que se mandan a la FPU.
Las operaciones de la unidad VMX128, eso sí, tienen una latencia de entre 4 y 14 ciclos (son instrucciones más complejas y su ejecución es más lenta, pero aún así, mejor eso que intentar hacer lo mismo con una FPU menos capaz).
Además, esa unidad VMX128 dispone de muchos más registros de los que normalmente se encontrarían en unidades equivalentes (128 por thread) con lo que se tendrá que acceder a la cache L1 con menos frecuencia y acelerará de forma considerable el rendimiento para ese tipo de código.

Chips adicionales
Otro punto para añadir en la comparación, y que en el caso de la WiiU no está relacionado con el tema de la CPU en sí pero que sí influye en la comparación es el de los chips dedicados, sobretodo el DSP.
Un DSP es un chip especializado en funciones de tratamiento del sonido (reverberación y cosas por el estilo), con esas funciones codificadas en hardware y unas pequeñas memorias locales propias para llevarlas a cabo.
Xbox 360 carece de ello, y por consiguiente, debe dedicar recursos de la CPU a hacer ese tipo de cosas. Puede parecer que eso del sonido no debe ser muy importante, pero para que os hagáis a la idea, en Xbox360 se dedica un hilo mínimo para hacer ese tipo de operaciones, y en algunos casos un núcleo entero.
Incluso en el caso de los juegos que ocupan “sólo” uno de los 6 hilos, debido a que el ser humano no tolera bien las distorsiones del sonido (se nota mucho más una distorsión en el sonido que por ejemplo un poco de tearing) el hilo que se dedica al sonido debe tener prioridad frente al otro, con lo que aún sin consumir el núcleo entero sí que pierdes una parte importante de él.
Otros chips que se encuentran en WiiU y no en Xbox 360 son los de compresión para el tabletomando (con lo que aquí no se gana, pero se evita perder ) o el ARM que en WiiU se encarga de procesar las funciones de seguridad del SO y que en 360 se las come la CPU principal aunque con una penalización según Microsoft de entre el 1 y el 3% como mucho. Aún así, ahí está.

Finalmente, el último aspecto que me parece digno de mencionar (y muy determinante también) es la diferencia de latencias con la RAM principal, pero eso lo explicaré en otro hilo en donde me centraré en explicar la arquitectura de memoria de la WiiU.

Conclusiones finales
La CPU de WiiU de coja no tiene nada, pero su uso es distinto al de la Xbox 360. El diseño ha sido heredado en parte de Wii y GC (ése era ya un diseño MUY ROBUSTO y eficiente) con innovaciones (caches eDram que permiten un tamaño brutal) y otros ajustes muy importantes como el tener 3 núcleos en vez de uno.

Su eficiencia le permitirá crujir a la CPU de Xbox 360 en código de propósito general. Pensad como comparación que un programa pensado sin multi-threading rendía en Xbox 360 en el mejor de los casos un 20% mejor que en la Wii.
Eso significa que ese programa usaba sólo un thread, con lo cual 2 de los 3 núcleos de la Xbox 360 estaban sin usar y del otro sólo aprovechaba uno de los dos hilos disponibles, pero también hay que señalar que ese thread tenía para si los 32+32KB de caché L1 (como en Wii o un núcleo del Espresso) y el 1MB de caché L2 (en donde la Wii se tenía que contentar con 256KB).

A partir de ahí la comparación con el Espresso para ese tipo de código es, incluso en el peor de los casos (suponiendo ese 20% de rendimiento superior como algo constante y no como el pico que realmente era), muy favorable a la CPU de WiiU.
No sólo por tener una frecuencia un 70% superior a la Wii, también porque en programas más complejos y con más hilos la disponibilidad de caches en Xbox 360 irá cayendo (sobretodo la L2), mientras que en WiiU cada núcleo tiene su porción para si misma.

Así pues, en un caso de 3 threads (1 por núcleo) la disponibilidad de recursos por núcleo en el caso de la L2 pasaría a ser de 333KB en Xbox 360, frente a los 512KB/2MB de la WiiU. Y la comparativa se vuelve más peliaguda aún porque el 20% anteriormente citado era en un escenario en donde el thread de Xbox 360 tenía disponible 4 veces la cantidad (un 400%) de cache L2 que tenía el procesador de Wii, mientras que ahora pasa a tener tan sólo 1/3 (un 33%) de la capacidad con la que cuenta el Espresso. Si a eso añadimos la brutal latencia con respecto a la RAM principal que hay en Xbox 360 la diferencia no puede hacer más que crecer y crecer en favor del Espresso.

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.

Por supuesto, el hecho de que el Xenon tenga que hacer tareas que el Espresso tiene relegadas a otros chips dedicados también servirá para aumentar/limar (propósito general/código de gráficos) esas diferencias de forma considerable, con lo que el diseño es en mi opinión, más que suficiente para disfrutar de unos juegos con un rendimiento aceptable.

Bueno, hasta aquí llega la primera parte (y seguramente la más extensa) de esa serie de 4 que voy a hacer para explicar desde mis modestos conocimientos lo que puede uno esperarse de WiiU, y compararlo con Xbox 360 para tener una referencia clara de lo que podemos esperar de ella.

PD: Como el tochaco ese lo he escrito a pedazos en distintos días seguro que habrá fallos en la redacción que ya iré editando a medida que los vea/me los señaléis.
Aún no me he leído el tochaco (lo haré esta noche sin falta), pero si vas a hacer un análisis en condiciones te sugiero dos cosas:

a) ¿No se puede crear el artículo como una wiki, igual que en los hilos de juegos? De ese modo, podríamos echarte una mano a la hora de arreglar el formato, posibles problemas ortográficos o gramaticales, etc... sin cargarte tú todo el trabajo.

b) Fotos, fotos, fotos... No sé de qué manera están haciendo el destripe, pero aunque sea tomadas de internet, estaría bien meter fotos de la placa y los diversos componentes para ilustrar el asunto.

Por lo demás, la idea me parece muy buena.
bartletrules escribió:Aún no me he leído el tochaco (lo haré esta noche sin falta), pero si vas a hacer un análisis en condiciones te sugiero dos cosas:

a) ¿No se puede crear el artículo como una wiki, igual que en los hilos de juegos? De ese modo, podríamos echarte una mano a la hora de arreglar el formato, posibles problemas ortográficos o gramaticales, etc... sin cargarte tú todo el trabajo.

b) Fotos, fotos, fotos... No sé de qué manera están haciendo el destripe, pero aunque sea tomadas de internet, estaría bien meter fotos de la placa y los diversos componentes para ilustrar el asunto.

Por lo demás, la idea me parece muy buena.


respecto a la wiki le veo un problema, que puede llegar el guay de turno escribir lo q no debe y joder algo, mientras que si le mandas un mp diciendole donde y como esta el error creo que sera mucho mas facil tener el hilo en perfecto estado

sobre el tema de fotos creo que todo lo que ha escrito es puramente teorico, aunq si que estaria bien ver esas fotos, a tono de curiosidad mas que nada

bart, una cosa, te parece si cuando siga escribiendo tochos le dejamos tu post, el mio, y el siguiente, para tener todo el tochaco en el mismo post y a continuacion uno de otro?

info, como ya te he dicho siempre, eres el puto amo [tadoramo] [tadoramo] [tadoramo] [tadoramo]
¿Cómo se hace eso de crear hilos estilo wiki?
Lo de las fotos es buena idea, voy a buscarlas y si a caso editaré el hilo cuando tenga tiempo.

PD: Dragonsacred lo de los múltiples mensajes podría estar muy bien. Mi idea era hacer 4 hilos dedicados a CPU, GPU, Arquitectura de memoria y análisis general, pero tal vez 1 hilo con 4 mensajes tochos editándose sería mucho mejor idea. Y gracias por cumplido! XD
dragonsacred escribió:respecto a la wiki le veo un problema, que puede llegar el guay de turno escribir lo q no debe y joder algo, mientras que si le mandas un mp diciendole donde y como esta el error creo que sera mucho mas facil tener el hilo en perfecto estado

sobre el tema de fotos creo que todo lo que ha escrito es puramente teorico, aunq si que estaria bien ver esas fotos, a tono de curiosidad mas que nada

bart, una cosa, te parece si cuando siga escribiendo tochos le dejamos tu post, el mio, y el siguiente, para tener todo el tochaco en el mismo post y a continuacion uno de otro?

info, como ya te he dicho siempre, eres el puto amo [tadoramo] [tadoramo] [tadoramo] [tadoramo]


Lo cierto es que no tengo experiencia en Wikis, pero imagino que siempre habrá un control de revisiones para poder corregir un "sabotaje" a malas, ¿no?

Pero vamos, que era una sugerencia por ahorrar trabajo. Y en cuanto a lo de las fotos, lógicamente a mí no es que me haga mucha ilusión ver fotos de circuitería (salvo que Rihanna o una de estas estén hechas de silicio... XD ), pero creo que ayuda a hacer más amenos estos tochos, y a estructurar un post tan largo con pausas visuales.

Lo de ceder el post, sin problemas. Me avisa, me pasa por MP el tocho de turno, y lo meto sin inconvenientes. Yo pensaba que su idea era hacer cuatro hilos, más bien.

Saludos
Gracias por currarte la info.Asi podemos hacernos una idea de lo que puede dar de si nuestra consolita [beer]
Info_Master escribió:Pensad como comparación que un programa pensado sin multi-threading rendía en Xbox 360 en el mejor de los casos un 20% mejor que en la Wii.


La parte informativa estaba muy bien pero la cagaste al tomar como eje principal de tu "comparación" ese "experimento" realizado en condiciones dudosas.

Por otro lado, olvidas comentar las declaraciones de muchos programadores que trabajan con la consola y que han mencionado un bajo rendimiento de la CPU con respecto a Xbox 360 y Playstation 3.
Como ya te han dicho hay un control de cambios. Cualquier sabotaje es facilmente enmendable.
rokyle está baneado del subforo por "Flames continuos"
(y vs con Xbox 360 de propina)

Ese vs, según lo leído en el topic de "debate" no se tendría que hacer con la XBONE o la PS4? Si Consideráis la WiiU "next gen" comparadla con las next gen no?
rokyle escribió:(y vs con Xbox 360 de propina)

Ese vs, según lo leído en el topic de "debate" no se tendría que hacer con la XBONE o la PS4? Si Consideráis la WiiU "next gen" comparadla con las next gen no?


Son consolas que no están a la venta, y su hardware aún es susceptible de cambios, como podrás comprobar si echas un ojo a la sección de portada de ésta nuestra web. Por lo que una comparación con ellas (aún) no tendría sentido.

¿Te vale la respuesta?.
T1100 escribió:
Info_Master escribió:Pensad como comparación que un programa pensado sin multi-threading rendía en Xbox 360 en el mejor de los casos un 20% mejor que en la Wii.


La parte informativa estaba muy bien pero la cagaste al tomar como eje principal de tu "comparación" ese "experimento" realizado en condiciones dudosas.

Por otro lado, olvidas comentar las declaraciones de muchos programadores que trabajan con la consola y que han mencionado un bajo rendimiento de la CPU con respecto a Xbox 360 y Playstation 3.

No, no la he cagado con el ejemplo. Ese "experimento" que dices son aplicaciones homebrew (que es como se ha obtenido los datos referentes a WiiU, y también de Wii en su momento) hechas por programadores con documentación extensa de la consola y optimizadas para la arquitectura hasta el absurdo por ser programas más sencillos y estar hechos por gente que lo hace por devoción.

El rendimiento para código de propósito general del Xenos es patético, en los test sintéticos saca 1879.630 dmips por cada núcleo, en comparación con los 1687.5 dmips del procesador de Wii (es decir, en test sintéticos rinde un 10% más).

Si no he usado esos test en vez del ejemplo es por dos motivos:
1. No me interesaba meter datos sintéticos que no son representativos de nada y que mucha gente tampoco va a entender si no lo explico, con lo que el post se alargaría aún más y ese era ya un tocho bastante grueso.
2. Me reservaba el ejemplo del test sintético para el hilo/post de la arquitectura de memoria, para evidenciar el impacto de las memorias de bajo nivel y sus implicaciones.

De hecho, ahora me va a tocar explicar un poco cómo es que si he dicho que el diseño del Espresso (y el de Wii también) es ta eficiente y el del Xenon tan poco, cómo es que la diferencia es más grande en una aplicación homebrew que en un test sintético.
Las explicaciones son las siguientes:
1. El más decisivo, tener el 1MB de cache L2 completo para la aplicación, es decir, 4 veces más que la L2 de la CPU de Wii.

2. Optimización extrema que jamás se dará en un juego grueso. Esos programadores son gente que se dedican a programar para pasar el tiempo, y lo hacen con una devoción fuera de toda duda (basta con ver las brutalidades que se consiguen hacer con amstards de hace la tira de años en demos técnicas hechas por gente como esa). Como los programas son pequeños (emuladores Snes, Mega Drive o así era en ese caso) han optimizado el código para que se perjudicase lo mínimo posible por las carencias de la arquitectura del Xenon, y optimizado al máximo el uso de ese MB extra de L2.

3. El 20% ese que he mencionado era un caso puntual, o como dijo aquella gente, una situación que incluso para ellos no era habitual. Como pretendo limpiar un poco esa imagen de que la CPU de WiiU es mala o que la WiiU en general es una Xbox 360, cojo escenarios que no puedan ser cuestionados en el sentido en que lo has hecho tu.

Insisto, la diferencia en test sintéticos (es decir, operaciones sencillas y repetitivas para evitar salirse siquiera de las caches L1, sin códigos de branca que puedan sacar las vergüenzas de esas pipelines tan largas) es tan sólo del 10%, y en el caso de la aplicación que he mencionado de un 20% en el mejor de los casos y por los motivos que he mencionado.

Cuando explique la arquitectura de memoria, se entenderá mucho mejor el porqué de eso.
Bastante interesante, ya faltaba un hilo así que muestre los detalles técnicos del CPU.
Metalrichy escribió:Bastante interesante, ya faltaba un hilo así que muestre los detalles técnicos del CPU.


A mi me falta que saquen juegos que rindan ya y exploten la CPU y la GPU de una puñetera vez, joer necesito un Zelda HD ya!!! (Y no el WW)!. Los datos técnicos para mi no son importantes aún así, el curro de hacer una disertación se agradece.
melovampire escribió:
Metalrichy escribió:Bastante interesante, ya faltaba un hilo así que muestre los detalles técnicos del CPU.


A mi me falta que saquen juegos que rindan ya y exploten la CPU y la GPU de una puñetera vez, joer necesito un Zelda HD ya!!! (Y no el WW)!. Los datos técnicos para mi no son importantes aún así, el curro de hacer una disertación se agradece.



Sí, a ver cuando sacan un Zelda como el de la demo técnica. [Ooooo]
Hilo buenísimo y muy bien explicado.

Una pregunta chorra desde mi ignorancia, ¿este tipo de arquitecturas quienes las diseñan? ¿ingenieros de Nintendo? ¿el fabricante de los circuitos?....
Uh sí, vaya GRÁFICOS tienen la ps4 y la One... madre de dios, salen hasta de la pantalla y empiezan a destrozarte la casa! Oh god why!!!!

En fin, el mismo cuento de siempre. :-|
000miguel escribió:Hilo buenísimo y muy bien explicado.

Una pregunta chorra desde mi ignorancia, ¿este tipo de arquitecturas quienes las diseñan? ¿ingenieros de Nintendo? ¿el fabricante de los circuitos?....


La arquitectura de Cube, Wii y WiiU es PowerPC, tecnología inventada por IBM. Los ordenadores de Apple montaban arquitectura PPC tambien, antes de que se pasaran a Intel, por ejemplo.
De verdad q no podeis dejar ni un hilo limpio? No tendreis bastante sitio donde soltar vuestras tonterias......
rokyle escribió:(y vs con Xbox 360 de propina)

Ese vs, según lo leído en el topic de "debate" no se tendría que hacer con la XBONE o la PS4? Si Consideráis la WiiU "next gen" comparadla con las next gen no?


Te parece a ti que la wiiu se pueda comparar con la ps4 o la One? pues entonces. Que ganas de liarla tenéis algunos eh?
Se compara con la 360 por el tipico comentario "La wiiu no se parece ni a la 360 en potencia"
Yo tengo la WIIU pero es que negar que la consola es un mojon en hardware es intentar engañarse.

Pero bueno si cada vez que se menciona el tema del precio y lo que ofrece en potencia alguno se irrita pues nada ya no digo mas y me piro del hilo que se llena de nostalgicos nintenderos

Adieu
BrainFlaseado escribió:Yo tengo la WIIU pero es que negar que la consola es un mojon en hardware es intentar engañarse.

Pero bueno si cada vez que se menciona el tema del precio y lo que ofrece en potencia alguno se irrita pues nada ya no digo mas y me piro del hilo que se llena de nostalgicos nintenderos

Adieu


para eso esta el hilo de debate, este es para hablar solo y exclusivamente del hardware
Exacto este hilo es para analizar la consola tecnicamente y no hay que entrar en cuestiones que corresponden al hilo del debate.
Info_Master escribió:El rendimiento para código de propósito general del Xenos es patético, en los test sintéticos saca 1879.630 dmips por cada núcleo, en comparación con los 1687.5 dmips del procesador de Wii (es decir, en test sintéticos rinde un 10% más).


Pues deberías revisar tus fuentes antes de darlas como certeras.
Según otra fuente el procesador de X360 saca 19,200 DMIPS y el núcleo principal del CPU de PS3 (sin contar los SPEs) hace 10,420 DMIPS.

http://en.wikipedia.org/wiki/Instructions_per_second

Estos datos están más en consonancia con lo que se suele afirmar cuando se habla del hardware de las consolas actuales: que están bien dotadas de CPU y ningún programador se ha quejado de su rendimiento como sí ha pasado con el de Wii U.
T1100 escribió:
Info_Master escribió:El rendimiento para código de propósito general del Xenos es patético, en los test sintéticos saca 1879.630 dmips por cada núcleo, en comparación con los 1687.5 dmips del procesador de Wii (es decir, en test sintéticos rinde un 10% más).


Pues deberías revisar tus fuentes antes de darlas como certeras.
Según otra fuente el procesador de X360 saca 19,200 DMIPS y el núcleo principal del CPU de PS3 (sin contar los SPEs) hace 10,420 DMIPS.

http://en.wikipedia.org/wiki/Instructions_per_second

Estos datos están más en consonancia con lo que se suele afirmar cuando se habla del hardware de las consolas actuales: que están bien dotadas de CPU y ningún programador se ha quejado de su rendimiento como sí ha pasado con el de Wii U.


Me parece muy bien que si un dato esta mal se rectifique pero la coletilla final te sobra.
Ya que haces el comentario tambien podrias decir que otros programadores han alabado la cpu de WiiU y estan encantadas de trabajar en ella.
Un poquito de por favor que el hilo esta para lo que esta. Ya te han cerrado un hilo y ahora por lo visto pretendes que este que tiene algo de interes lo cierren tambien?.
Yo en el conjunto general de ambas consolas veo q WiiU técnicamente es superior a 360, cuando vaya pasando el tiempo los juegos lo demostrarán, el hilo es súper interesante y ánimo a seguirlo.
tonizar escribió:
T1100 escribió:las consolas actuales: que están bien dotadas de CPU y ningún programador se ha quejado de su rendimiento como sí ha pasado con el de Wii U.

Me parece muy bien que si un dato esta mal se rectifique pero la coletilla final te sobra.
Ya que haces el comentario tambien podrias decir que otros programadores han alabado la cpu de WiiU y estan encantadas de trabajar en ella.


Si no te has fijado, el creador del hilo ha querido establecer un "versus" entre Wii U y X360 y los comentarios por parte de desarrolladores son adecuados ante la falta de información más directa.

Y no te confundas, ningún desarrollador ha elogiado la CPU de Wii U, a lo más que han llegado algunos desarrolladores de juegos menores es que la CPU de Wii U no los limita dado el tipo de juegos que suelen hacer (sin físicas o IA avanzadas ni otros procesos que exijan una CPU potente)
T1100 escribió:
tonizar escribió:
T1100 escribió:las consolas actuales: que están bien dotadas de CPU y ningún programador se ha quejado de su rendimiento como sí ha pasado con el de Wii U.

Me parece muy bien que si un dato esta mal se rectifique pero la coletilla final te sobra.
Ya que haces el comentario tambien podrias decir que otros programadores han alabado la cpu de WiiU y estan encantadas de trabajar en ella.


Si no te has fijado, el creador del hilo ha querido establecer un "versus" entre Wii U y X360 y los comentarios por parte de desarrolladores son adecuados ante la falta de información más directa.

Y no te confundas, ningún desarrollador ha elogiado la CPU de Wii U, a lo más que han llegado algunos desarrolladores de juegos menores es que la CPU de Wii U no los limita dado el tipo de juegos que suelen hacer (sin físicas o IA avanzadas ni otros procesos que exijan una CPU potente)


segun lo que yo entiendo esta desgranando la cpu de wiiu, y para que los profanos tengamos una ligera idea de lo que esta hablando, o de en que se traduce todo eso, lo compara con la 360, en ningun momento ha dicho "se ve mejor" o "se ve peor", ni ha puesto una grafica o una tabla

por cierto, de ps3 nadie hablaba maravillas, asiq si se quejaban de las cpus actuales, concretamente de la de ps3
O sea que la cpu de wiiu tecnicamente es mejor pero en rendimuento trafico es peor? No es eso lo contrario que se decia? Creo que no entendi la ultima parte.
jairolas escribió:O sea que la cpu de wiiu tecnicamente es mejor pero en rendimuento trafico es peor? No es eso lo contrario que se decia? Creo que no entendi la ultima parte.


segun lo que yo he entendido (que de hardware estoy totalmente pez) es mas lenta a nivel de herzios (velocidad) pero mas rapida en tanto en cuanto esta diseñada para que cada orden sea mucho mas rapida de procesar, y en caso de que una operacion sea erronea apenas se pierde tiempo, ahora faltaria que dijeran, a grosso modo, en que se traduce esa velocidad extra, porque me parecio leer que en caso "real" la cpu de 360 era solo un 10% mas rapida que la de wiiu(en el caso de que esta usara solo un nucleo, teniendo otros 2 sin usar)

si me confundo en algo avisar
jairolas escribió:O sea que la cpu de wiiu tecnicamente es mejor pero en rendimuento trafico es peor? No es eso lo contrario que se decia? Creo que no entendi la ultima parte.


En un ordenador o consola hay tres componentes básicos: CPU, GPU y RAM.
Cada uno cumple sus funciones específicas y según su capacidad se pueden hacer tales o cuales cosas dentro de su "rubro"

En un videojuego el componente que hace mayor trabajo es la GPU porque es la que se encarga de mover los "gráficos", la CPU se utiliza para tareas como calcular colisiones, inteligencia artificial, físicas y coordinar el funcionamiento de todo el juego.
La memoria RAM es la que almacena los datos con los que trabaja el ordenador o consola, cuanto más rápida sea mayor es el rendimiento que se le puede sacar a una GPU potente.

Por lo que se sabe hasta ahora de Wii U su GPU es más moderna que las de las consolas actuales aunque su capacidad "bruta" (polígonos, resolución) es parecida o ligeramente superior.

Las limitaciones vienen por el lado de la CPU que es básicamente el procesador de la antigua Wii overclockeado, por partida triple y con más caché. Varios desarrolladores se han quejado de su bajo rendimiento al tratar de adaptar juegos desde PS360.

Otra limitación de Wii U es la velocidad de su memoria RAM (12 GB/s contra los 23-25 GB/s de las consolas actuales). Tiene el doble de memoria disponible para juegos que PS360 pero su velocidad es la mitad de estas.
Para paliar esto lleva la eDRAM, que es memoria muy rápida pero al ser cara solamente se puede poner en pequeña cantidad.
No es lo mismo tener bastante memoria rápida que tener memoria lenta + eDRAM pero para algunas cosas puede servir muy bien.
T1100 escribió:
tonizar escribió:
T1100 escribió:las consolas actuales: que están bien dotadas de CPU y ningún programador se ha quejado de su rendimiento como sí ha pasado con el de Wii U.

Me parece muy bien que si un dato esta mal se rectifique pero la coletilla final te sobra.
Ya que haces el comentario tambien podrias decir que otros programadores han alabado la cpu de WiiU y estan encantadas de trabajar en ella.


Si no te has fijado, el creador del hilo ha querido establecer un "versus" entre Wii U y X360 y los comentarios por parte de desarrolladores son adecuados ante la falta de información más directa.

Y no te confundas, ningún desarrollador ha elogiado la CPU de Wii U, a lo más que han llegado algunos desarrolladores de juegos menores es que la CPU de Wii U no los limita dado el tipo de juegos que suelen hacer (sin físicas o IA avanzadas ni otros procesos que exijan una CPU potente)


Si a todo lo que afirmas (e impones a los demás) fuera verdad, el foro sería un cúmulo de información real. En este caso no lo es, afirmas algo únicamente para llevar razón en tus críticas y como es lógico, lo demuestras en cada post del foro. No me quiero ni imaginar todo lo que has querido "meter" a los demás, eso en mi casa, mi ciudad y en cualquier sitio es desinformar totalmente.

No he buscado mucho, pero también existen alabanzas a la consola de Nintendo y, por supuesto, a su hardware. Y sobre los juegos menores...es para reírse y mucho xD. Las críticas en las consolas siempre son visibles, pero huele mucho que únicamente se repitan una y otra vez, a la hora de opinar, las noticias malas pero los puntos positivos de muchas desarrolladoras...se omiten y ya.

A la hora de afirmar cosas de hardware, es muy importante el componente software y como se ha desarrollado, pero bueno...no es importante ¿verdad? ;).

http://www.wii-brasil.com/noticia.php?id=41875
http://www.irconquerors.com/vuelven-a-i ... x-360.html
http://www.nextn.es/2013/02/criterion-e ... -nintendo/
http://www.gamerzona.com/2012/11/05/des ... -de-wii-u/
http://wiiclube.uol.com.br/blog/2013/05 ... ii-u/83918
etc etc




Muy interesante el tema, lo seguiré muy de cerca :).
T1100 escribió:
jairolas escribió:O sea que la cpu de wiiu tecnicamente es mejor pero en rendimuento trafico es peor? No es eso lo contrario que se decia? Creo que no entendi la ultima parte.


En un ordenador o consola hay tres componentes básicos: CPU, GPU y RAM.
Cada uno cumple sus funciones específicas y según su capacidad se pueden hacer tales o cuales cosas dentro de su "rubro"

En un videojuego el componente que hace mayor trabajo es la GPU porque es la que se encarga de mover los "gráficos", la CPU se utiliza para tareas como calcular colisiones, inteligencia artificial, físicas y coordinar el funcionamiento de todo el juego.
La memoria RAM es la que almacena los datos con los que trabaja el ordenador o consola, cuanto más rápida sea mayor es el rendimiento que se le puede sacar a una GPU potente.

Por lo que se sabe hasta ahora de Wii U su GPU es más moderna que las de las consolas actuales aunque su capacidad "bruta" (polígonos, resolución) es parecida o ligeramente superior.

Las limitaciones vienen por el lado de la CPU que es básicamente el procesador de la antigua Wii overclockeado, por partida triple y con más caché. Varios desarrolladores se han quejado de su bajo rendimiento al tratar de adaptar juegos desde PS360.

Otra limitación de Wii U es la velocidad de su memoria RAM (12 GB/s contra los 23-25 GB/s de las consolas actuales). Tiene el doble de memoria disponible para juegos que PS360 pero su velocidad es la mitad de estas.
Para paliar esto lleva la eDRAM, que es memoria muy rápida pero al ser cara solamente se puede poner en pequeña cantidad.
No es lo mismo tener bastante memoria rápida que tener memoria lenta + eDRAM pero para algunas cosas puede servir muy bien.


lo que se sabe, segun sega:

Ciertamente hemos encontrado más facilidad para obtener prototipos en funcionamiento con una definición visual next-gen, así que estamos muy contentos. Teniendo en cuenta el hecho de que uno de nuestros ingenieros gráficos portea cosas muy rápido, yo diría que la respuesta a si tiene una arquitectura fácil de comprender, debo decir que sí. - Gary Dunn, vicepresidente de desarrollo de Sega West


segun parece a sega no le parecia mala la gpu

http://blogocio.net/shinen-la-gpu-de-wii-u-esta-varias-generaciones-por-delante-de-las-consolas-actuales-no-67358/

a shinen tampoco

por cierto, segun shinen,sus proximos juegos usaran teselacion, con lo que nos vamos a directx11, o mas bien, a open gl 4.2 que es lo mismo pero sin royalties

podrias dar datos t1100?lo digo xa hacernos una idea de si hablas con conocimiento de causa, o de oidas

te dejo unos articulos acerca de la gpu de wiiu

http://www.eurogamer.es/articles/df-hardware-wii-u-potencia-grafica

Sin embargo, las 16 TMUs a 550 MHz y las mejoras en la cache de texturas del RV770 sí elevan la capacidad de este hardware por encima de la GPU Xenos de Xbox 360 - multiplica por 1,5 el rendimiento puro en shaders, más o menos.


http://www.techpowerup.com/gpudb/1903/wii-u-gpu.html

http://blogocio.net/se-filtra-supuesta-informacion-sobre-la-gpu-de-wii-u-no-62869/
Spyfull27 escribió:
T1100 escribió:Y no te confundas, ningún desarrollador ha elogiado la CPU de Wii U, a lo más que han llegado algunos desarrolladores de juegos menores es que la CPU de Wii U no los limita dado el tipo de juegos que suelen hacer (sin físicas o IA avanzadas ni otros procesos que exijan una CPU potente)

Si a todo lo que afirmas (e impones a los demás) fuera verdad, el foro sería un cúmulo de información real. En este caso no lo es, afirmas algo únicamente para llevar razón en tus críticas y como es lógico, lo demuestras en cada post del foro. No me quiero ni imaginar todo lo que has querido "meter" a los demás, eso en mi casa, mi ciudad y en cualquier sitio es desinformar totalmente.

No he buscado mucho, pero también existen alabanzas a la consola de Nintendo y, por supuesto, a su hardware. Y sobre los juegos menores...es para reírse y mucho xD. Las críticas en las consolas siempre son visibles, pero huele mucho que únicamente se repitan una y otra vez, a la hora de opinar, las noticias malas pero los puntos positivos de muchas desarrolladoras...se omiten y ya.

A la hora de afirmar cosas de hardware, es muy importante el componente software y como se ha desarrollado, pero bueno...no es importante ¿verdad? ;).

http://www.wii-brasil.com/noticia.php?id=41875
http://www.irconquerors.com/vuelven-a-i ... x-360.html
http://www.nextn.es/2013/02/criterion-e ... -nintendo/
http://www.gamerzona.com/2012/11/05/des ... -de-wii-u/
http://wiiclube.uol.com.br/blog/2013/05 ... ii-u/83918
etc etc


Los desarrolladores han elogiado principalmente la cantidad de memoria de Wii U, lo cual les facilita bastante el trabajo.

De los juegos que has mencionado en tus enlaces el más destacado es Trine 2, uno de los pocos en los que la versión de Wii U es superior a las de PS360.
Este juego utiliza muy poca CPU y en PC funciona perfectamente incluso con un Pentium 4 chustero (Trine 2 es un juego nativo de ordenador).

Y aún así los estándares son los mismos que en las versiones de las demás consolas: resolución 720p y a 30 fps.
¿No crees que si el hardware de Wii U fuese muy superior al de las consolas actuales en este juego tendría que notarse?
Si Wii U fuese el doble de potente que PS360 Trine 2 iría a 1080p o a 60 fps, la realidad es otra.

El otro juego destacado es NFS Most Wanted y aquí tambien las únicas diferencias son gracias a la mayor cantidad de memoria, el resto es igual a las versiones de PS360: resolución Sub-HD (1280x704), 30 fps y encima han recortado el número de coches en carrera para los modos online.

Créeme que no tengo ningún problema en reconocer las virtudes del hardware de Wii U si las tuviere, lamentablemente hay poca cosa destacable.
T1100 escribió:
Spyfull27 escribió:
T1100 escribió:Y no te confundas, ningún desarrollador ha elogiado la CPU de Wii U, a lo más que han llegado algunos desarrolladores de juegos menores es que la CPU de Wii U no los limita dado el tipo de juegos que suelen hacer (sin físicas o IA avanzadas ni otros procesos que exijan una CPU potente)

Si a todo lo que afirmas (e impones a los demás) fuera verdad, el foro sería un cúmulo de información real. En este caso no lo es, afirmas algo únicamente para llevar razón en tus críticas y como es lógico, lo demuestras en cada post del foro. No me quiero ni imaginar todo lo que has querido "meter" a los demás, eso en mi casa, mi ciudad y en cualquier sitio es desinformar totalmente.

No he buscado mucho, pero también existen alabanzas a la consola de Nintendo y, por supuesto, a su hardware. Y sobre los juegos menores...es para reírse y mucho xD. Las críticas en las consolas siempre son visibles, pero huele mucho que únicamente se repitan una y otra vez, a la hora de opinar, las noticias malas pero los puntos positivos de muchas desarrolladoras...se omiten y ya.

A la hora de afirmar cosas de hardware, es muy importante el componente software y como se ha desarrollado, pero bueno...no es importante ¿verdad? ;).

http://www.wii-brasil.com/noticia.php?id=41875
http://www.irconquerors.com/vuelven-a-i ... x-360.html
http://www.nextn.es/2013/02/criterion-e ... -nintendo/
http://www.gamerzona.com/2012/11/05/des ... -de-wii-u/
http://wiiclube.uol.com.br/blog/2013/05 ... ii-u/83918
etc etc


Los desarrolladores han elogiado principalmente la cantidad de memoria de Wii U, lo cual les facilita bastante el trabajo.

De los juegos que has mencionado en tus enlaces el más destacado es Trine 2, uno de los pocos en los que la versión de Wii U es superior a las de PS360.
Este juego utiliza muy poca CPU y en PC funciona perfectamente incluso con un Pentium 4 chustero (Trine 2 es un juego nativo de ordenador).

Y aún así los estándares son los mismos que en las versiones de las demás consolas: resolución 720p y a 30 fps.
¿No crees que si el hardware de Wii U fuese muy superior al de las consolas actuales en este juego tendría que notarse?
Si Wii U fuese el doble de potente que PS360 Trine 2 iría a 1080p o a 60 fps, la realidad es otra.

El otro juego destacado es NFS Most Wanted y aquí tambien las únicas diferencias son gracias a la mayor cantidad de memoria, el resto es igual a las versiones de PS360: resolución Sub-HD (1280x704), 30 fps y encima han recortado el número de coches en carrera para los modos online.

Créeme que no tengo ningún problema en reconocer las virtudes del hardware de Wii U si las tuviere, lamentablemente hay poca cosa destacable.


podrias dar datos?en el fifa 13 les sobro potencia para hacer al publico y al cesped en condiciones, la expansion del trine 2, goblin menace, no saben si podria correr en ps360 sin retocarla, el nfs se ve mejor.........todos sabemos hablar de oidas, la diferencia es que este hilo es para datos, no para hablar de oidas, si quieres hablar de oidas al de debate por favor
dragonsacred escribió:podrias dar datos?en el fifa 13 les sobro potencia para hacer al publico y al cesped en condiciones, la expansion del trine 2, goblin menace, no saben si podria correr en ps360 sin retocarla, el nfs se ve mejor.........todos sabemos hablar de oidas, la diferencia es que este hilo es para datos, no para hablar de oidas


El césped de FIFA aprovecha la mayor cantidad de memoria de Wii U porque es una textura, el público son billboards o sprites y teniendo más memoria se pueden utilizar sprites de mayor resolución.

Los de Trine tambien se referían a la memoria cuando dijeron que tendrían que recortar o utilizar métodos para que cupiesen los assets en la RAM de PS360 (de nuevo, recordar que Trine 2 es un juego de PC y alli la cantidad de RAM no es un problema y es más fácil adaptar un juego de PC a Wii U que a PS360 en cuestión de memoria)

El NFS, como ya dije, corre a la misma resolución que en PS360 (1280x704) y a los mismos 30 fps, solamente se han mejorado algunas texturas gracias a la mayor cantidad de memoria de Wii U.
T1100 escribió:
dragonsacred escribió:podrias dar datos?en el fifa 13 les sobro potencia para hacer al publico y al cesped en condiciones, la expansion del trine 2, goblin menace, no saben si podria correr en ps360 sin retocarla, el nfs se ve mejor.........todos sabemos hablar de oidas, la diferencia es que este hilo es para datos, no para hablar de oidas


El césped de FIFA aprovecha la mayor cantidad de memoria de Wii U porque es una textura, el público son billboards o sprites y teniendo más memoria se pueden utilizar sprites de mayor resolución.

Los de Trine tambien se referían a la memoria cuando dijeron que tendrían que recortar o utilizar métodos para que cupiesen los assets en la RAM de PS360 (de nuevo, recordar que Trine 2 es un juego de PC y alli la cantidad de RAM no es un problema y es más fácil adaptar un juego de PC a Wii U que a PS360 en cuestión de memoria)

El NFS, como ya dije, corre a la misma resolución que en PS360 (1280x704) y a los mismos 30 fps, solamente se han mejorado algunas texturas gracias a la mayor cantidad de memoria de Wii U.

Con la diferencia de que en Wii U lleva sincronizacion vertical, que consume bastantes recursos y añadele que procesa 2 imagenes, la tele y el mando, y en xbox 360 y ps3 no
Menudo post os habeis currado... alguien podría hacer un resumen con el concepto final? XD
peloconcelo escribió:Con la diferencia de que en Wii U lleva sincronizacion vertical, que consume bastantes recursos y añadele que procesa 2 imagenes, la tele y el mando, y en xbox 360 y ps3 no


La sincronización vertical no consume recursos, solamente se requiere un buffer extra (memoria) para evitar tiempos de espera cuando el buffer principal está ocupado.
Aún así hay juegos que en Wii U tampoco tienen sincronización vertical activada (Darksiders 2) y otros como NFS Most Wanted en el que todas las versiones tienen v-sync.

La señal para el mando solamente requiere un buffer más y no consume prácticamente recursos del sistema a menos que se esté renderizando en cada pantalla dos vistas del juego totalmente distintas.
Soy chachi escribió:Menudo post os habeis currado... alguien podría hacer un resumen con el concepto final? XD


que wiiu es mas potente que xbox 360, pero con arquitectura muy diferente que necesita trabajo para sacarle la chicha
T1100 escribió:La señal para el mando solamente requiere un buffer más y no consume prácticamente recursos del sistema a menos que se esté renderizando en cada pantalla dos vistas del juego totalmente distintas.


¿Y con que llenas el buffer? ¿Transmites las 60 imágenes por segúndo en tiempo real sin compresión por wi-fi? Pues no, tienes que llenar el buffer, codificar la información con x264 o algun codec propietario para que sea "transmitible" al tabletomando y debes hacerlo en tiempo real sin lag. Seguramente Wii U posea algún chip dedicado para hacer dicha codificación porque no es algo trivial, requiere recursos.

Por cierto, yo no creo que Wii U sea mucho mas potente que PS360, tiene una potencia similar pero con hardware mucho mas eficiente, pequeño y que genera menos calor.

En mi opinión Wii U tiene un hardware impecable, es un diseño muy inteligente con un rendimiento aceptable. :o
AntoniousBlock escribió:
T1100 escribió:La señal para el mando solamente requiere un buffer más y no consume prácticamente recursos del sistema a menos que se esté renderizando en cada pantalla dos vistas del juego totalmente distintas.


¿Y con que llenas el buffer? ¿Transmites las 60 imágenes por segúndo en tiempo real sin compresión por wi-fi? Pues no, tienes que llenar el buffer, codificar la información con x264 o algun codec propietario para que sea "transmitible" al tabletomando y debes hacerlo en tiempo real sin lag. Seguramente Wii U posea algún chip dedicado para hacer dicha codificación porque no es algo trivial, requiere recursos.


Wii U (al igual que PS4 y XOne) lleva un chip aparte para codificar la señal que va a la tableta.
El buffer se llena con un simple mapa, o un menú, o replicando la señal que va a la TV sin consumir prácticamente recursos.
T1100 escribió:
AntoniousBlock escribió:
T1100 escribió:La señal para el mando solamente requiere un buffer más y no consume prácticamente recursos del sistema a menos que se esté renderizando en cada pantalla dos vistas del juego totalmente distintas.


¿Y con que llenas el buffer? ¿Transmites las 60 imágenes por segúndo en tiempo real sin compresión por wi-fi? Pues no, tienes que llenar el buffer, codificar la información con x264 o algun codec propietario para que sea "transmitible" al tabletomando y debes hacerlo en tiempo real sin lag. Seguramente Wii U posea algún chip dedicado para hacer dicha codificación porque no es algo trivial, requiere recursos.


Wii U (al igual que PS4 y XOne) lleva un chip aparte para codificar la señal que va a la tableta.
El buffer se llena con un simple mapa, o un menú, o replicando la señal que va a la TV sin consumir prácticamente recursos.

Y en casos como el cod a dobles? por que en ese caso tiene que procesar 2 partidas con sus fisicas, sus efectos y su todo, no creo que eso lo haga un chip dedicado, el chip se encarga de que lo que ha procesado la gpu llegue al mando sin lag, pero como digo, primero tiene que tirar de gpu.
AntoniousBlock escribió:
T1100 escribió:La señal para el mando solamente requiere un buffer más y no consume prácticamente recursos del sistema a menos que se esté renderizando en cada pantalla dos vistas del juego totalmente distintas.


¿Y con que llenas el buffer? ¿Transmites las 60 imágenes por segúndo en tiempo real sin compresión por wi-fi? Pues no, tienes que llenar el buffer, codificar la información con x264 o algun codec propietario para que sea "transmitible" al tabletomando y debes hacerlo en tiempo real sin lag. Seguramente Wii U posea algún chip dedicado para hacer dicha codificación porque no es algo trivial, requiere recursos.

Por cierto, yo no creo que Wii U sea mucho mas potente que PS360, tiene una potencia similar pero con hardware mucho mas eficiente, pequeño y que genera menos calor.

En mi opinión Wii U tiene un hardware impecable
, es un diseño muy inteligente con un rendimiento aceptable. :o


Estoy muy de acuerdo. Yo sólo opino como aficionado, no tengo experiencia en hardware ni nada, pero mis sensaciones a base de leer los diferentes artículos y noticias que han ido saliendo, están por ese camino que has expuesto.

Y francamente, no creo que el problema de Wii U venga por parte de la potencia. Estamos viendo que en plataformas móviles se están consiguiendo cosas alucinantes, estamos terminando esta generación con juegos que realmente explotan PS360 hasta límites que yo no me esperaba (con ciertos compromisos y limitaciones de diseño, pero el acabado de juegos como TLOU, Halo 4, Forza Horizon, Bioshock Infinite y (espero) GT6 dentro de poco, nos han enseñado lo que estas consolas pueden hacer).

Si se le dedica tiempo y ganas (que es lo que no sé si están dispuestas a hacer muchas compañías, porque las third buscan ingresos más inmediatos -ojo, eso no es criticable. Lo digo simplemente como un hecho que tener en cuenta-), Wii U va a ser capaz de grandes cosas.

No es un hard perfecto, será más limitado que PS4 y XO pero yo creo que la máquina merece la pena.
peloconcelo escribió:
T1100 escribió:Wii U (al igual que PS4 y XOne) lleva un chip aparte para codificar la señal que va a la tableta.
El buffer se llena con un simple mapa, o un menú, o replicando la señal que va a la TV sin consumir prácticamente recursos.

Y en casos como el cod a dobles? por que en ese caso tiene que procesar 2 partidas con sus fisicas, sus efectos y su todo, no creo que eso lo haga un chip dedicado, el chip se encarga de que lo que ha procesado la gpu llegue al mando sin lag, pero como digo, primero tiene que tirar de gpu.


Igual que las versiones de PS360, las cuales tambien tienen modo multijugador local para cuatro jugadores a pantalla dividida, solamente que en el caso de Wii U una de las vistas se envía a la tableta.
aun no entiendo, si este hilo es para datos, xq nadie da datos aparte de infomaster
T1100 escribió:
Igual que las versiones de PS360, las cuales tambien tienen modo multijugador local para cuatro jugadores a pantalla dividida, solamente que en el caso de Wii U una de las vistas se envía a la tableta.

Igualito una p..., no me compares partir la pantalla con lo que cada jugador dispone de la mitad por lo tanto la GPU no tiene que hacer el doble por ser 2 jugadores, en cambio la wii u cada jugador tiene una pantalla entera para el, o lo que es lo mismo, al procesado de la partida del primer jugador que seria lo mismo que jugar en single, se le suma lo que tiene que procesar para la 2ª pantalla que aunque tenga menos resolucion sigue teniendo todos los efectos, todo lo contrario que jugar a pantalla dividida, que para mantener el frame rate en xbox recortan de los efectos.
PD: Queda claro que tu unico interes es llevar la contraria teniendo o sin tener razon, a cualquier cosa que favorezca a nintendo, por mi parte quedas ignorado.
peloconcelo escribió:
T1100 escribió:
Igual que las versiones de PS360, las cuales tambien tienen modo multijugador local para cuatro jugadores a pantalla dividida, solamente que en el caso de Wii U una de las vistas se envía a la tableta.

Igualito una p..., no me compares partir la pantalla con lo que cada jugador dispone de la mitad por lo tanto la GPU no tiene que hacer el doble por ser 2 jugadores, en cambio la wii u cada jugador tiene una pantalla entera para el, o lo que es lo mismo, al procesado de la partida del primer jugador que seria lo mismo que jugar en single, se le suma lo que tiene que procesar para la 2ª pantalla que aunque tenga menos resolucion sigue teniendo todos los efectos, todo lo contrario que jugar a pantalla dividida, que para mantener el frame rate en xbox recortan de los efectos.
PD: Queda claro que tu unico interes es llevar la contraria teniendo o sin tener razon, a cualquier cosa que favorezca a nintendo, por mi parte quedas ignorado.


T1100 tiene razon, ya que tambien te "muestra" como tu has dicho en el otro comentario "2 partidas con sus fisicas, sus efectos y su todo" tambien lo hace la 360, pero sin tener que mandarlo a una pantallita a parte como hace Wii U donde ella si tiene un Chip dedicado para eso, y veo que tienes el titulo de programador con tu comentario "no me compares partir la pantalla con lo que cada jugador dispone de la mitad por lo tanto la GPU no tiene que hacer el doble por ser 2 jugadores, en cambio la wii u cada jugador tiene una pantalla entera para el, o lo que es lo mismo, al procesado de la partida del primer jugador que seria lo mismo que jugar en single, se le suma lo que tiene que procesar para la 2ª pantalla que aunque tenga menos resolucion sigue teniendo todos los efectos, todo lo contrario que jugar a pantalla dividida"de verdad tio leetelo un par de veces y saca otra vez las conclusiones que tu dices, entonces las 4 pantallitas que te muestra el Black Ops 2 de Xbox que es? no hace el doble por no mostrartelo en otra pantallita?? Y bueno, veo que te quedas sin argumentos, y como te lleva la contraria en tu opinion "no profesional" (por no ser desarrolador) le hechas en cara que "teniendo" o no teniendo la razon, le tachas ahora de antiNintendo por que no teda la razon.
649 respuestas
1, 2, 3, 4, 513