Cosas curiosas sobre el hardware de Wii U antes “desconocidas”

Existe un pastebin que es la documentación de las actualizaciones de la librería GX2, la librería gráfica propietaria de bajo nivel para Wii U.  En dicho documento se pueden encontrar una serie de elementos sumamente interesantes que desconociamos con anterioridad, pero voy a destacar dos en particular:

#1 El DMAE

Añadido soporte oficial para el DMA Engine.

Las restricciones del DMAE para las operaciones de “copy & fill” se han reducido de los 8 bytes a los 4 bytes para coincidir con los requerimientos del hardware.

Tradicionalmente un motor DMA es lo que permite el acceso a la memoria principal desde un procesador diferente a lo que es la CPU del sistema. En el caso de las GPUs de PC cuando estas necesitan acceder a la RAM principal del sistema (no confundir con la RAM propia de la tarjeta gráfica) lo que hacen es acceder a través de un motor DMA que es el encargado de dicha tarea. En el caso concreto de Xbox One los llamados Move Engines son los encargados de mover los datos desde la DDR3 a la ESRAM y viceversa aunque el funcionamiento en Wii U es distinto ya que en el caso de la consola de Nintendo su GPU opera directamente sobre la MEM1 en lo que al texturizado se refiere y esto requiere volcar las texturas de la escena de la MEM2 (DDR3 externa) a la MEM1 (eDRAM) utililizando el DMAE.

Por lo visto lo hace a una velocidad de 550 Mhz (velocidad de la GPU7)*4 bytes por ciclo y dirección. Esto significa que la velocidad en la que transmite los datos desde MEM2 a la MEM1 es de 2.2 GB/seg. Parece una cifra pequeña pero hay que tener en cuenta que la memoria realmente necesaria en cada fotograma, que no escena, son solo las texturas utilizadas en dicho fotograma. Este técnica no es nueva y Nintendo la lleva usando en sus consolas desde Gamecube donde la cache de texturas era de solo 1MB ya que lo que se hace es almacenar en memoria las texturas necesarias para dicho fotograma. Dado que Nintendo ya tenia disponible esta tecnología para GCN/Wii y les había dado buenos resultados es normal que la hayan incluido en el hardware de Wii U y explica muy bien el motivo por el cual la consola pese a tener solo 12.8 GB/seg de ancho de banda con la RAM principal (MEM2/DDR3) tiene un rendimiento más que aceptable en lo que al texturizado se refiere.

Funciona diferente que en Xbox One porque mientras que en Xbox One se leen las texturas desde la DDR3 (a no ser que se haga desde la ESRAM y se quite espacio para los búfers de imagen y con ello se baje la resolución) en Wii U se leen desde la MEM1/eDRAM haciendo que la necesidad para el ancho de banda de lectura de la memoria principal sea muy bajo.

El DMAE es una pieza que pese a encontrarse dentro del “Latte” es completamente ajena a la GPU y pese a invocarse sus funciones a través de la API GX2 puede ser llevada a futuras iteraciones de la consola por la naturaleza real de la API GX2, pero esto ya es cosa del segundo punto.

#2 GLSL y GX2

Desconocía cual era el lenguaje utilizado para los shaders en Wii U y ahora que lo sabemos hay cosas que se aclaran por completo.

El GLSL es el OpenGL Shading Lenguaje. Esto significa que la API GX2 más que ser una API propietaria y exclusiva es una versión de OpenGL con extensiones alrededor del hardware de Wii U a la que se le ha puesto un nombre propio. El GLSL es el lenguaje de alto nivel para shaders. Siendo el OpenGL el estándar de programación de los shaders y competencia directa del HLSL (utilizado en Direct3D) y el propietario PSSL utilizado en PS4.

Esto explicaría el motivo por el cual Nintendo habría decidido entrar en el grupo Khronos encargado de los estándares del OpenGL, en realidad habrían estado utilizando dicha API gráfica desde el principio.

khronos_group

Esto tiene una serie de consecuencias respecto a NX que os voy a explicar a continuacion. Cuando desde la aplicación hablamos con la GPU a través de la API no lo estamos haciendo directamente con la GPU en si misma sino con su procesador de comandos, el cual lee una lista de tareas a realizar que luego el planificador de la GPU reparte entre las diferentes unidades. Normalmente las APIs de alto nivel lo que hacen es tener un interprete/controlador en medio que es una pieza de hardware encargada de interpretar dichas instrucciones a lo que cada GPU puede entender. ¿El problema añadido a este tipo de APIs? El tiempo de interpretación es una sobrecarga en la CPU que quita tiempo de renderizado a la GPU.

¿Pero es posible convertir una API de alto nivel como OpenGL en una API de bajo nivel? Por supuesto, Microsoft ya lo hizo con Direct3D en Xbox 360 haciendo que la aplicación/juego pudiese escribir directamente en el búfer de instrucciones desde donde lee el procesador de comandos sin necesidad de que participe el interprete. El hecho de que GX2 sea una versión a nivel de metal de OpenGL y el uso de GLSL para los shaders en vez de tecnologías propietarias es importante porque va a permitir a Nintendo trasladar todo lo desarrollado en Wii U a una nueva consola sin tener que arrastrar la GPU7 y con ello todo el hardware de Wii U por un lado para la compatibilidad hacía atrás por un lado y por otro lado para poder utilizar los bienes de producción desarrollados en Wii U de cara a juegos futuros y así no encontrarse con un borrón y cuenta nueva que es una de las cosas que afecto negativamente la linea editorial inicial de Wii U.

Pero es el hecho de no tener que depender de una GPU en concreto lo mejor de todo, Nintendo en el caso de la API GX, GCN y Wii, para conseguir que los juegos desarrollados en esta funcionen en un hardware posterior, Wii U, ha tenido que incluir dicha GPU de forma física dentro del hardware. El hecho de que GX2 sea OpenGL+Extensiones propietarias con otro nombre permite que el código gráfico funcione con cualquier GPU que soporte GLSL sin problemas (todas) y que solo haga falta la implementación de los elementos propios de Wii U en el nuevo hardware como es la MEM1 y el DMAE para tener una total compatibilidad hacía adelante.

 

 

Anuncios