NX Opción B (III)

Hace unas semanas os comente que haría una segunda parte donde dije que haría una entrada acerca de la posible GPU de NX, tenía una entrada enorme preparada con un montón de cartas sobre la mesa…

cards-on-table

Pero era larga, confusa y mareante hasta para mi por lo que al final decidí volcar la mesa y plantear las cosas desde otro punto de vista.

mesa

Tengo muy, pero que muy claro que Nintendo lo que hará será portar el “Cafe OS” que es el SO de Wii U en lo máximo posible a NX, pero sobretodo la idea de que Nintendo quiere realizar una transición sencilla. ¿Es posible sin reciclar el hardware de Wii U o acaso Nintendo tendrá que realizar un borrón y cuenta nueva? Busquemos las respuestas.

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.

En ese momento me quede bloqueado porque existía un dilema claro…

doubt

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. Es decir, gracias a esto Nintendo puede portar tranquilamente y sin complicaciones todos los bienes de producción de Wii U a NX de forma directa, en especial los motores gráficos ya utilizados y con ello los juegos.

Obviamente por la diferencia del conjunto de instrucciones de la CPU los binarios de NX no funcionarán en Wii U y viceversa, pero esto evita un largo tiempo de transición de una plataforma a la otra, es más, creo que el objetivo de Nintendo es lanzar una consola con un catálogo de juegos amplió por su parte y esta es la forma que van a tener de conseguirlo, con secuelas de juegos de Wii U lanzados en la primera hornada, personalmente no me extrañaría ver cosas de lanzamiento como Super Mario 3D World 2, Pikmin 4… 

Otra de las cosa que me ha llamado la atencíon del Wii U Brew es saber a través de que interfaz se comunica la GPU con los núcleos de la CPU, pensaba que era una interfaz de AMD propietaria o de IBM en su defecto. Pero por lo visto la parte del uncore que comunica CPU y GPU es de Nintendo y bastante genérico, es decir, no han optado por un elemento propietario.

AHBWiiU

La GPU en Wii U esta conectada a una interfaz AHB, la cual esta conectada al anillo del uncore y este se encuentra conectado a la interfaz 60XE que comunica externamente con la CPU. ¿Pero que tiene de especial dicha interfaz AHB? Pues el hecho que es una interfaz de comunicación utilizada por los SoC que utilizan CPUs con arquitectura ARM de forma estandar, siendo el AHB un bus de 64/128 bits. Es a través de la interfaz AHB que la CPU se comunica con el Latte y viceversa. Esto significa que la comunicación con el Procesador de Comandos de la GPU se hace a través de dicho bus, en todo caso lo único que necesito que entendáis que solo hace falta enchufar el Latte en una interfaz AHB en el SoC para re-utilizarlo en un SoC que tenga el conjunto de instrucciones ARM, es decir, el uncore del SoC de Wii U es el mismo que el de cualquier SoC en el mercado que hace uso de una CPU con un conjunto de instrucciones ARM solo que donde tendría que haber la conexión directa con una CPU de ese tipo hay una conexión con la interfaz 60XE del PowerPC “Espresso”.

Pero hemos dejado claro que no vamos a utilizar el Latte sino un Adreno… ¿De que tipo? Hay que tener en cuenta que tenemos que partir de una GPU donde la API de Wii U pueda ser mapeads y no falten funciones. La API GX2 es una equivalente a DX10/OGL3 por lo que necesitaremos que la GPU escogida este a dicho nivel o superior en cuanto a soporte de la API, esto de entrada deja fuera la serie Adreno 2xx, pero no la serie Adreno 3xx en adelante, las cuales soportan DX11.1 por lo que la GPU a escoger como mínimo utilizaría esta arquitectura en adelante.

¿Pero que hay de la arquitectura interna del Adreno 3xx en adelante? En primer lugar hemos de entender que la composición de los Shaders no es la misma que en la serie R600/R700/Evergreen donde el formato utilizado es el VLIW5. Es decir, en el caso concreto de Wii U tenemos 8 Compute Units que en la siguiente litografía están señalados con los números N1 a N8.

wiiudie_blocks

Aquí se ven con más detalle:

5oArkj4

Cada uno de estos bloques tiene 20 Stream Processors, lo sabemos porque los bloques bicolor que hay dentro son los registros de proposito general de los shaders.

Evergreen_VLIW5

El caso es que pixeles se procesan en grupos de cuatro llamados quads  y no de uno en uno al igual que los vertices se calculan con cuatro valores (x,y,z,w) de ahí a que solemos tener los Stream Processors en grupos de cuatro, en el caso de la arquitectura R600/R700/Evergreen el quinto Stream Processor es para instrucciones especiales.

En Wii U tenemos que el planificador puede enviar unos Wavefront de 64 hilos/”kernels” a los stream processors/shaders por ciclo de reloj.

wavefront

Cada uno de los Wavefronts son procesados en 4 ciclos de reloj y esto significa que se procesan 16 hilos/”kernels” por ciclo y esto en las mejores condiciones, es decir, instrucciones que se puedan resolver en un ciclo de reloj.  Cada Compute Unite tiene 20 Stream Processors, es un número menor de 64 y no es multiple de 4 pero eso no es problema ya que lo hace el planificador de la GPU es enviar un Wavefront a cada Compute Unit y esta tarda un mínimo de cuatro ciclos de reloj, lo que significa que cada grupo de 16 es procesado como mínimo por ciclo, aunque ese es el mínimo ya que hay instrucciones que tendrán ocupados más tiempo a los stram processors.

wavefront2

Cada Compute Unit en este caso sabemos que tiene unas 20 unidades y cada una de ellas puede procesar un “kernel”/hilo distinto, si hacemos una repartición 1:1 entonces nos encontramos con que el quinto Stream Processor queda en desuso, pero es que el quinto es de apoyo para ciertas funciones/instrucciones especiales.

¿Para que he explicado esto? Es el planificador de dentro de la GPU el que se encarga en cada arquitectura de repartir el trabajo a las diferentes unidades y no el desarrollador y es completamente igual cual sea la configuración que tengan estos, de la misma manera que es completamente igual de cuando sean los bloques que haga el planificador, eso es igual a los desarrolladores porque la comunicación que tienen es con el procesador de comandos de la GPU, el cual lee una lista de instrucciones desde búfer FIFO y lo envia al planificador y sobre este los programadores no tienen control.

Es decir, los Adreno nos interesan porque su procesador de comandos nos da una compatibilidad total con las herramientas para Wii U, pero esto no significa que su funcionamiento interno sea exactamente el mismo.

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

Tenemos que tener en cuenta que la consola ha de ser como mínimo capaz de procesar los 192 hilos/kernels desde el planificador, claro esta que en un escenario especial un servidor preferiría que la configuración de portátil y sobremesa fuese distinta de la misma manera que lo es entre el iPhone y el iPad de Apple pese a que en cada generación usen la misma arquitectura. Me gustaría que la versión de sobremesa fuese una Wii U 1080P en cuanto a capacidad técnica y esto significaría unos 432 hilos/”kernels” pero dudo mucho de este escenario y aún más del escenario 1080p60 donde entonces estaráimos hablando de 864 hilos/”kernels” a repartir. Eso si, no olvidemos que un simple aumento de resolución no significa un aumento de los valores de producción, son cosas distintas.

¿Pero cual sería la configuración de los shaders? A partir del Adreno 3xx en adelante la configuración del modelo más bajo de las familias es una Compute Unit de 16 Stream Processors con capacidad FMADD, la diferencia respecto al modelo de Wii U es que las funciones/instrucciones especiales son soportadas por los cuatro Stream Processors por lo que el quinta que es de apoyo en Wii U en la configuración de los Adreno deja de tener sentido y con su eliminación se gana espacio que permite reducir costes o en su defecto permite aumentar el número de unidades.

El otro problema a trasladar desde Wii U a NX es el problema de la eDRAM/MEM1, una particularidad que tiene los procesadores bajo arquitectura Adreno es que pueden renderizar en modo directo o en modo tile rendering donde el búfer de imagen se ejecuta sobre una memoria interna. Dicha memoria se llama GMEM y realiza precisamente la misma tarea que la MEM1 en el Latte de Wii U pero de forma más avanzada ya que lo que realiza es un tipo de Tile Rendering, el cual se ve aquí descrito.

Como muchas GPUs embebidas/para SoC, Adreno es una arquitectura basada en tile rendering. Sin embargo la forma en la que esta implementado es un poco más simple.

Muchos tilers renderizan en pequeños tiles (32×32 y/o 64×64), con el hardware ordenando la geometría por tile. Habitualmente las superficies no visibles para un tile dado son ignorados.

Adreno, por el otro lado, tiene un tile búfer relativamente grande en el núcleo (GMEM) o en el chip (OCMEM) que va de los 256KB a 1MB. El búfer que es renderizado es dividido en “tiles” o “bins” para los cuales los búfers de color (y si están activos) los búfers de profundidad/stencil pueden caber dentro del tile buffer. El driver es completamente responsable del dibujado en el tile/bin, así como la recuperación (mover datos de la memoria del sistema al GMEM) y la resolución (mover datos del GMEM a la memoria del sistema).

Es el mismo mecanismo que los PowerVR pero la diferencia es que mientras en los PowerVR el tamaño físico de cada tile esta limitado (32×32) en este caso la limitación es la cantidad de memoria, es decir, podemos hacer que la GMEM almacene un tile del tamaño que queramos y que tenga las muestras que queramos mientras quepa en su memoria. ¿Que utilidad tiene esto y como concuerda con la forma de trabajar de Nintendo? Nintendo desde GameCube en sobremesa y a partir de 3DS en portátiles ha utilizado una memoria interna dentro del chip como búfer de imagen, pero no para realizar tile rendering sino que en estos casos el búfer de imagen se almacena de forma completa. En Wii U que es una consola pensada para funcionar a 720P (1 Megapixel), 32 bits de color (4 bytes) y que puede soportar por API hasta 8 muestras esto son unos 32MB de memoria que se encuentra embebida en el chip. Nintendo llama a esta memoria VRAM en los diagramas de patente y no se tiene que confundir con la Internal RAM.

WiiUDiagram

La VRAM almacen el búfer de imagen trasero (color y Z+Stencil) por un lado y la cache de texturas por otro.  La RAM interna es una reminiscencia de Wii donde la consola tenía dos pozos de memoria principal, uno en el mismo encapsulado que el Hollywood y otra fuera del misma. En Wii U tanto la VRAM como la memoria interna están unificadas en una misma memoria, la MEM1 pero la diferenciación entre MEM1 y MEM2 solo aparece cuando Wii U esta en modo Wii, en modo Wii U las texturas de la escena son cargadas directamente desde la memoria principal ya que la GPU de Wii U no necesita una memoria que le haga de cache de texturas, haciendo que toda la eDRAM se utilice en modo Wii U como búfer de imagen, extrañamente la CPU tiene permiso para acceder a dicha memoria pero es por compatibilidad hacía atrás con Wii, en los juegos de Wii U ese hecho es inutil.

Bajo esta paradigma si se quisiese aumentar la resolución a 1080P (2 Mpixeles) entonces haría falta unos 64MB de memoria embebida, por lo que la ventaja de utilizar una arquitectura que soporte Tile Rendering es enorme porque esto reduce enormemente el tamaño de la memoria embebida incluida de serie en el chip y con ello el tamaño y el consumo del mismo. Aparte nos evita tener que utilizar cosas como la memoria HBM2, la cual no es viable en un sistema de bolsillo y por tanto permite la unificación completa del hardware en sobremesa y portátil.

Ahora la pregunta es… ¿Existe un SoC con GPU Adreno lo suficientemente potente como para mover los gráficos a nivel Wii U?

SD810

En el Snapdragon 810, un SoC para dispositivos de bolsillo que lleva un tiempo en el mercad, hay en su interior un Adreno 430 con 192 Stream Processors, 32 más que la GPU de Wii U y a una velocidad de 600Mhz, 50 Mhz más que Wii U. No digo que este sea el SoC, pero una GPU compatible con las herramientas de desarrollo de Wii U, de bajo consumo y con la capacidad de colocarse en una consola portátil aparte de una de sobremesa existe.

El último motivo es que la relación de Nintendo-AMD era realmente con la gente que había trabajado en ArtX en el desarrollo de la GPU de GCN/Wii y anteriormente en SGI en el desarrollo de N64. La mayoría de esta gente se encuentra en estos momentos Qualcomm y esto es lo que hace que entre todos los proveedores de una GPU de bajo consumo sean los que tengan más números de que su GPU vaya a parar a las entrañas de NX, al fin y al cabo y aunque sea bajo otra compañía esta gente ya ha trabajado junto a Nintendo en el pasado.

Esto es todo, ordenadas las ideas y actualizada la entrada dire que esta será la última entrada sobre el posible hardware de NX que realizare durante un tiempo.

Anuncios