El Emulador de 3DS y la complicación de la compatibilidad hacía atrás en un futuro sistema

No defiendo el uso de emuladores de productos que se encuentran en el mercado y/o que hayá sido re-editados de nuevo en otra plataformas, esta entrada es informativa.

Por lo visto los responsables de Citra ha conseguido hacer funcionar en primer juego comercial de 3DS en su emulador, siendo el juego que han mostrado Ocarina of Time 3D.

El emulador en si mismo no es un emulador sino un interprete, esto significa que re-intepreta las instrucciones que van hacía los procesadores de 3DS en algo que un PC pueda entender, por lo que la potencia necesaria resulta mucho mayor que le de la potencia que se necesitaría para ejecutar el juego y depende de la implementación de ciertas instrucciones en el interprete, la velocidad de estas puede ir de necesitar unas pocas veces la potencia del sistema interpretado a varias decena de veces la potencia de este.

Ahora bien… ¿Como es que me ha interesado esto? Hace unos 15 años apareció un emulador de N64 llamado UltraHLE que servio para emular Super Mario 64 y Ocarina of Time en PC, dicho emulador no era un emulador sino que al igual que el Citra era un interprete y esto era porque Nintendo en el desarrollo de ambos juegos había utilizado código de “alto nivel”, es decir, no estaban desarrollados a nivel del metal y por tanto no utilizaban ninguna instrucción exótica de la arquitectura. Años más tarde el mismo planteamiento seguiría Microsoft con los juegos de la primera Xbox en Xbox 360, aunque la retrocompatibilidad no sería al 100% debido a que algunos juegos utilizaban algunas instrucciones no documentadas de Nvidia.

¿Que importancia tiene esto? Supongamos que queremos hace una sucesora de 3DS… ¿Con que problemas nos encontraríamos utilizando un interprete para la compatibilidad con los juegos de 3DS en el nuevo sistema?

Para empezar, hay que tener en cuenta que 3DS utiliza una arquitectura cuanto menos exótica si tenemos en cuenta que ciertas secciones de la GPU que tiene, su definición es la de un OpenGL ES 1.1 pero su arquitectura tiene una serie de extensiones en forma de nuevas etapas en el renderizado, las aplicaciones que no utilizan dichas etapas y utilizan el OpenGL ES 1.1 pueden realizar un bypass de dichas etapas. Dicho de otra manera, sí Nintendo quiere hacer un cambio de arquitectura en un futuro sistema portátil y dado que el soporte de OpenGL ES 1.1 es universal el hecho de prescindir del PICA200 para esos juegos no sería un problema.

¿Entonces cuando se convierte en un problema? Pues cuando los juegos utilizan alguno de los efectos visuales que hay en las etapas añadidas por DMP dentro del hardware de la consola:

PICA200Pipeline

Los recuadros anaranjados son las etapas añadidas.

El Primitive Engine podríamos considearlo el equivalente a un  Geometry Engine, es decir, trabaja manipulando los triangulos ya generados por el vertex shader. Su primera función es la de teselación que subidivide los vertices en otros más pequeños pero manteniendo el mismo espacio. Es exactamente el mismo tipo de teselación que tiene el Xenos de Xbox 360 y no la compararía con la de DX11 porque no es programable, pero en todo caso esto va más allá de la especificación del OpenGL ES 1.1 y una emulación de esto requiere una potencia muy grande a o ser que se tenga una unidad similar. En realidad para poder implementar esta funcionalidad en un sistema futuro es necesario el soporte OpenGL ES 3.0 que soporta Geometry Shaders y no solo por el tema de la teselación sino que el Primitive Engine del PICA200 es utilizado para la generación de partículas volumetricas para efectos de nubes,chispas, niebla… Lo que complica aún más su interpretación a nivel de software a no ser que se utilice una GPU que soporte Geometry Shaders.

El segundo elemento a comentar es el que en el diagrama es llamado Per-Fragment Shading.  Tranquilos que no me he saltado el Texture Sampling sino que lo comentare más adelante.

PICA200PseudoShader

 

En OpenGL ES 1.1 la iluminación es por vertice, por lo que la iluminación por textura/fragmento es una función de OpenGL ES 2.0. Es de los elementos añadidos en el PICA200 el que es más fácil de llevar a un sistema futuro por el hecho que un Pixel Shader puede realizar la misma funcionalidad sin problemas ya que su implementación forma parte del estandar OpenGL ES 2.0.

Pero es el llamado Texture Circuit el que tiene también mucha importancia, es lo que en el diagrama de más arriba se llama “Texture Sampling” y tiene dos funciones distintas.

La primera de ellas es la realización de ciertos efectos especiales que requieren dos ciclos por necesitar dos texturas en un solo ciclo. Es decir, efectos como los mapeado de entorno o los mapeados de relieve requieren dos accesos a memoria habitualmente cuando son calculados, en el PICA200 no es necesario y aunque estas funciones están 100% soportadas en todas las GPUs el hecho de tener que acceder a la memoria varias veces recorta la tasa de relleno. ¿Como lo consigue esto? Pues recogiendo las dos muestras necesarias en cada acceso a la memoria en vez de una, dejando cada muestra en su cache correspondiente, esta parte realmente no tiene nada de exótico y es fácilmente realizable en una GPU OpenGL ES 2.0 en adelante.

La combinación de los efectos que requieren dos muestras con el Per-Fragment Lightning es lo que permite en 3DS el nivel visual del Resident Evil Revelations de Capcom.

REREV

Los juegos de Nintendo por otro lado parecen ser mucho más simples visualmente hablando, no parece que utilicen estas funcionalidades en ningún momento. ¿El motivo? Desconozco por completo si para no hacer los juegos tan dependientes de un hardware en concreto o por ser simplemente poco ambiciosos visualmente hablando.

La otra función son las texturas procedurales. El PICA200 puede recibir las texturas de dos maneras: datos o procedural. Se le llama procedural cuando definimos como se ha de crear la textura, la ventaja es que el sistema procedural requiere muy pocos datos por lo que es posible colocar las texturas procedurales en una memoria cercana, la desventaja es que para ello es necesario un componente por hardware que genere la textura para que se pueda trabajar con ella de forma habitual.

029l

 

Aplicar esto en un interprete es bastante más complicado ya que no sabemos realmente cual es el algoritmo utilizado para la generación de las nuevas texturas ya que DMP lo tiene celosamente guardado y aunque tuviésemos la información no hay que olvidar que la implementación a nivel de interprete de todo el sistema de generación de texturas procedurales tiene que necesitar una potencia prohibitiva solo para implementar esta función a nivel de hardware. De todas ellas diría que es la función exclusiva menos utilizada de todas.

¿Que conclusión sacamos de todo esto? Pues el hecho que para que Nintendo realice una sucesora de 3DS que sea plenamente retro-compatible con esta tiene dos opciones distintas, la primera de ellas es una GPU OpenGL ES 3.0 que sea capaz de realizar las funciones gráficas de 3DS y New 3DS sin problemas, la segunda es implementar el hardware de New 3DS en la nueva consola. Dado que históricamente hemos visto como GBA tenía el hardware de GBC, DS el de GBA, 3DS el de DS/DSi… lo más seguro es que con tal de mantener la compatibilidad hacía atrás con la gama 3DS en un futuro sistema Nintendo acabe por colocar el SoC de New 3DS dentro del chip que es lo que ha hecho en toda su historia y siempre les ha funcionado y dadas las especificaciones técnicas de 3DS y los componentes en su interior a simple vista no es muy difícil su integración en un SoC ocupando poco espacio. Más bien el problema está en los 10MB de memoria embebida de New 3DS, recordad que 3DS tiene unos 6MB y estos precisamente no ocupan poco espacio en el procesador:

 

El problema del PICA200 es que no es un Tile Renderer como los PowerVR por lo que necesita un mayor ancho de banda externo que en el caso de 3DS es otorgado a través de la memoria embebida en el chip, si no hubiese memoria embebida entonces haría falta una mayor cantidad de memoria externa, lo que no solo ampliaría el número de chips de memoria en el sistema sino también el número de pines del procesador y con ello el área ocupada por este por lo que si Nintendo implementa el hardware de 3DS para la compatibilidad hacía atrás en su portátil de siguiente generación va a necesitar colocar la memoria embebida de esta si o si dentro del procesador para poder ejecutar los juegos de 3DS en ese futuro sistema manteniendo el 100% la compatibilidad con esta.

Anuncios