NX Portátil: Posible hardware interno a partir de la posible filtración (II)

Comentario #1:

Más allá de que el soc que nombras de quealcomm no soporta opengl es 3.1 hay un modelo con potencia similar (bajandole las velocidades de reloj) que sí lo soporta. Hablo del snapdragon 805. Pero lo mejor de todo, es que usando un soc que sea utilizado por algunos fabricantes de celulares, el precio por chip disminuye. Eso haría de NX portátil más barata en relación a la potencia.

Bueno, más que un m0delo con potencia similar hay un modelo con igual configuración que soporta OpenGL ES 3.1 y cuando digo igual configuración me refiero a que el número de shaders y la cantidad de shaders por TMU es la misma, la GPU dentro del Snapdragon 805 es la Adreno 420 y por ciclo de reloj tiene la misma potencia bruta que la Adreno 330 pero es superior en el hecho de que implementa por hardware una serie de características añadidas que le permiten ser una GPU OpenGL ES 3.1 pero hay una cosa que para mi es importante y es el “Geómetra Shader”, no lo había tenido en cuenta ayer pero para Nintendo, para poder portar sus juegos de Wii U a la nueva portátil sin problemas la GPU debe soportar “Geómetry Shader”… ¿El motivo? Lo explique en su día y hasta yo lo había olvidado.

Bueno, me olvidaba que una vez comente lo del Adreno 420:

¿Y como es la arquitectura de los Adreno en lo que a Stream Processors/Shaders se refiere?

Como he dicho antes el Adreno 2xx lo descarto por soportar la API al nivel DX9.3/OGL 2 cuando necesitamos que la GPU soporte DX10/OGL 3.3 en adelante, la serie 3XX también la voy a descartar por no soportar Geometry Shaders, cosa que si que soporta la serie 4xx y estos son muy importantes también de cara a trasladar las herramientas de desarrollo de Wii U a NX.

Adreno420_Features_2

El soporte de los Geometry Shaders son importantes por el hecho que Nintendo los usa en sus juegos… ¿Pero que es el Geometry Shader? Esto se entiende facilmente mirando el pipeline gráfico de otra forma.

Pipeline

El Geometry Shader iría en la parte de generación de primitivas, con este podemos generar lineas, puntos, diferentes tipos de triángulos o incluso a la inversa, podemos eliminar primitivas de la escena.

Por ejemplo un detalle para lo que son muy útiles es para eliminar la carga poligonal de un modelado según la distancia o la visibilidad del mismo, otro elemento es el hecho de poder hacer copias de la geometría de la escena para no tenerla que recalcular de nuevo si es necesario (obviamente dentro del mismo fotograma). No obstante y aunque el trabajo más obvió parezca ser el de la teselación o subdivisión de primitivas…

tesselation

 

… en realidad desde el momento en que no subdivide directamente sino que hace evaluación de los vertices que le van llegando es lento para ello. ¿Entonces que utilidad tiene la generación de primitivas?

La primera capacidad que me viene a la mente el Displacement Mapping, es decir, la generación de geometría sobre una superficie, esto nos permite que por ejemplo una pared no sea plana o incluso similar el movimiento del agua del mar.

model_comparision

Como se puede ver el Bump Mapping no genera geometría adicional al no modificar la forma del modelo base mientras que el Displacement Mapping si, es más, la gran diferencia respecto a la teselación es que la teselación simplemente subdivide los vertices de un polígono mientras que en este caso la creación de geometría puede ser irregular y se pueden añadir primitivas que no sean del mismo tipo. Esto nos sirve para cosas como la generación de pelo por ejemplo.

FurShader

Este tipo de “Fur Shader” no es lo mismo que el falso Fur Shader utilizado en juegos como Star Fox Adventures y Shadow of the Colossus, ya que este es más avanzado. En el caso de Wii U el único juego en el que lo he visto ha sido el DKC: TF.

tropicalfreeze

¿Otro ejemplo del uso del Geometry Shader en Wii U?

zelda_wii_u-2551183

Por otro lado el soporte de DX 11.1/OGL 4.x es importante porque esto significa que los motores gráficos que dan soporte a estas APIs estarían disponibles en este supuesto sistema del que estamos hablando.

Pero hay un punto del que hable en dicha entrada y que es importante:

En la entrada del blog de failoverflow nos comentan que el SO de Wii U esta pensado para funcionar en una GPU con la ISA R600/R700/Evergreen.

Resulta que el firmware del Cafe OS esta lleno de referencias al R6XX. Sin embargo el R6xx y el R7XX son casi identicos. ATI incluso publico una documentación abierta de sus motores/procesadores 3D juntos, en un solo documento, y las únicas diferencias reales son unos pocos detalles en los shaders. La información de los registros (en Wii U) que hemos comprobado coinciden en su mayoría con los documentos. R7XX es claramente una evolución menor del R6XX. El Cafe OS también tiene referencias a “GPU7” que es otro nombre que Nintendo utiliza para el GX2. Con el R7XX disponible no hay ningún motivo para Nintendo para no usar el R7XX.

Wii U utiliza una API gráfica propietaria de bajo nivel llamada GX2, dicha API esta altamente relacionada con el procesador de comandos de las series R600/R700/Evergreen de AMD pero tenemos el problema que las series GCN utilizan un procesador de comandos completamente distinto y esto significaría la escritura de una nueva API de bajo nivel para NX.

Es decir, los juegos tendrían que ser re-programados en lo que a la parte de gráficos se refiere, pues bien, continuemos haciendo memoria:

A primera vista el uso de la API GX2 significaba el re-uso de la GPU de Wii U y esta no esta diseñada para una versión portátil de la consola, en ese momento me estanque, hasta que hace unas horas mirando por Wii U Brew, en la página dedicada al Cafe OS hubo algo que me llamo la atención.

VMWiiU

Lo que me ha llamado la atención es lo de “Radeon PKT3” y he decidido buscarlo para ver que era y para mi sorpresa me he encontrado en una Wiki sobre las GPU Adreno lo siguiente:

Las GPU Adreno tienen su ascendencia en la linea de GPUs móviles ATI Imageon que se pensaron para su aplicación en SoCs, como tales comparten ciertas particularidades con las GPUs Radeon. En particular, su CPU (Procesador de Comandos) parece ser identico. Sin embargo, ninguno de los op-codes o direcciónde los registros no parecen ser los mismos.

El procesador de comandos es el que recibe la lista de comandos desde la CPU y lo procesa para que la GPU los pueda procesar. Más abajo en la siguiente página nos encontramos con lo siguiente:

Esta es la parte más fácil, ya que es idéntico a los Radeon. El CP es un bloque que lee una serie de comandos de renderizados desde un ringbuffer (el PM4 commmand stream) y tanto activa algunos valores de los registros (de la GPU) como activa algunas acciones de renderizado. Consiste principalemente en comandos Type-0 (PT0) y Type-3 (PKT3).

Es decir, si Nintendo optase por una GPU Adreno entonces podría portar facilmente la API GX2 a dicha GPU y no tendría que realizar una API gráfica de bajo nivel desde 0 y realizar un proceso de transición en cuanto al desarrollo gracias al uso de un CP casi idéntico.

El Adreno 420 como GPU no entra en contradicción con esto:

VulkanStatus api-vulkan-nintendo-nintendon1

Una vez solventado el problema de la API en la especulación hay que tener en cuenta cual es la configuracion tanto del Adreno 330 como del Adreno 420 en lo que a la configuración de shaders se refiere, algo que me ha llamado la atención:

Captura de pantalla 2016-03-22 a las 8.44.13

Wii U tiene 8 pipelines/Compute Units con una TMU cada una de ellas pero cada pipeline esta compuesto por cuatro unidades VLIW5 (20 ALUs)… ¿Como es que la potencia en FLOPS del Adreno 330 es inferior si la GPU tiene más ALUs? Obviamente la respuesta es simple, los números que dan AMD y Nvidia es la velocidad máxima ejecutando la instrucción FMADD que da dos operaciones en ciclo, aquí es la simple multiplicación del número de ALUs por el número de pipelines y esto por la velocidad de reloj, pero no se utiliza la instrucción FMADD en el cálculo

32 ALUs*8 Pipelines*450 Mhz= 115.2 GFLOPS.

Sigue sin cuadrar… ¿Que es lo que ocurre? Bueno, os lo explico y esto es algo que ocurre en todas las GPUs que es el hecho que aparte de la unidad SIMD de varios operandos lo que suele tener todas las unidades shader es un núcleo escalar en solitario, en algunos casos se cuenta y en otros no. En el caso de los Adreno hay un escalar por cada 8 ALUs colocados en un SIMD haciendo un total de 36 ALUs en el caso del Adreno 330/420 en lo que a la configuración de los Shaders se refiere:

36 ALUs*8 Pipelines*450 Mhz= 129.6 GFLOPS.

Pero alto, antes he comentado que los FLOPS en el caso de Wii U están contados utilizando la instrucción FMADD y en el caso de los Adreno haciendo uso de la unidad escalar. La instrucción FMADD se encuentra en todas las GPUs porque es indispensable para ciertas operaciones gráficas por lo que si tenemos en cuenta la unidad FMADD veremos que el Adreno 330/420 es superior en potencia de cálculo a la GPU de Wii U:

36 ALUs*8 Pipelines*450 Mhz*2 (FMADD)= 259.2 GFLOPS.

Por otro lado tenemos una CPU mucho más potente como comente en la entrada anterior y por tanto no es un cuello de botella y alto, que podría ser la velocidad de reloj algo superior. En todo caso es potencia suficiente para realizar ports desde la anterior generación a la portátil sin recortes de ningún tipo o en su defecto con pocos recortes. Pero es que además tenemos que tener en cuenta que la CPU no es la misma sino algo más potente:

Captura de pantalla 2016-03-22 a las 9.08.52

En DMIPS la potencia de la CPU es de 3.51 DMIPS/Mhz, por lo que su potencia total es de 37.908 DMIPS/seg, una potencia mas que suficiente para ejecutar juegos del nivel Wii U y aplicaciones en segundo plano sin problema alguno. ¿Lo otro que llama la atención? Se trata de un Tile Renderer, lo cual es normal teniendo en cuenta que es un chip de móvil.

Microsoft PowerPoint - Adreno_AnalystsBloggers_2012_v5 [Read-Onl

La GPU puede renderizar de dos formas: Convencional o por Tile Rendering utilizando para ello la memoria GMEM.

optimizing-unity-games-google-io-2014-58-638

El Tile Rendering es la técnica de calcular el búfer trasero por partes pequeñas para así que se pueda calcular en un búfer interno y reducir así la necesidad de ancho de banda de la memoria externa. Esto en el caso que nos ocupa es importante porque acelera el renderizado en diferido que utiliza varios búfers de imagen para la composición de la imagen. La diferencia es que el Tile Rendering de los PowerVR es diferente ya que es fijo en cuanto a resolución, en el caso de los Adreno el desarrollador ha de especificar la resolución del Tile con el que quiere trabajar con el único handicap que ha de tener en cuenta que le ha de caber en memoria.

Los 1.5 MB de memoria interna del Adreno 330 son el GMEM/OCMEM, ahí es donde se almacenan los Tiles que forman el búfer de imagen trasero. Mirando la información por ingeniería inversa nos encontramos que cada bloque es de 256KB:

Captura de pantalla 2016-03-22 a las 9.24.14

Es decir, los Tiles de lo PowerVR son pequeños, los del Adreno pueden ser grandes:

Captura de pantalla 2016-03-22 a las 9.22.06

¿En que se traduce esto? En que Nintendo no le hace falta una memoria embebida dentro del chip con un tamaño como para almacenar todo el búfer de imagen por lo que deja de ser necesaria la MEM1.

Bueno, supongo que el supuesto hardware interno esta más que explicado, recordad que por el momento es supuesto y el hecho de que sea un Snapdragon no esta confirmado.

Comentario#2:

Sinceramente, veo la imagen del mando y tiendo mas a pensar que es un fake que otra cosa. Típica imagen sin demasiada nitidez, tal vez para difuminar defectos de montaje. Y la imagen que supuestamente aparece del juego en pantalla ya se ha visto que es un recorte pequeño de una imagen mucho mas grande. Si se mostrara dicho juego en dicha pantalla ¿porque iba a mostrar solo una parte tan reducida de esta? no le veo sentido, mas que en un montaje relativamente fácil. En serio, no es por trolear, es solo mi impresión, y que conste que a pesar de ser seguidor de Nintendo, no tengo ningún miedo a que saquen una consola original y diferenciada respecto a las demás, de hecho me gustaría que me sorprendieran con algo nuevo, como lo fue en su momento Wii, con la única condición de que consigan el apoyo de terceras compañías para tener un catalogo de juegos menos escaso que el de Wii U. Esto lo digo para disipar dudas de que no soy un N64kid.

Dejando de lado interpretaciones visuales personales de la foto, de ser cierta, no parecería muy practica para una consola de sobremesa por el hecho de que los botones sean “virtuales”

Sencillamente no te enteras y me irrita porque me da la sensación de que escribo para la pared, no hay ninguna evidencia mirando fuentes primarias como las patentes de que esto sea un mando de control para la sobremesa e incluso tu mismo lo dices un motivo aparte de las patentes: Botones Virtuales.

Estoy viendo una disonancia cognitiva enorme con esto, producto del miedo de unos de que esto sea algo como el mando de Wii, es decir un gimmick para la de sobremesa, por parte de unos y el terror de que lo sea por parte de otros. El hecho de tener botones virtuales fuerza a que estos estén a la vista del jugador… ¿Que ocurre entonces? La atención ya no se centra en el televisor sino en la pantalla del mando… ¿Entonces para que esta el televisor?

En cuanto a la pantalla, lo he explicado en una entrada anterior, mirando las medidas del dibujo de la patente que son exactas a lo que algunos llamáis fake y que para mi es real:

NintendoNX_Patente

La elipse parece estar en una proporción 24:9 en vez 16:9, lo que hace que la imagen no este cortada en horizontal pero si en vertical, esto da un resolución de 1920*720 pixeles aunque realmente no son todos esos pixeles porque es una elipse. 😉

Con esto termino ya que pienso que es suficiente para aclarar ciertas cosas.

 

Anuncios