Hilo oficial Dolphin (Emulador GameCube/Wii)

Ubershaders: Una solución ridícula para un problema imposible.

Cuando estás jugando a tu juego favorito en Dolphin con un ordenador potente, las cosas suelen funcionar bien. El juego va a toda velocidad, no hay errores gráficos, y puedes usar tu mando favorito si quieres. Aún así, cada vez que llegas a un área nueva, o cargas un nuevo efecto, hay un pequeño pero notorio "parón". Quitas el limitador de frames para comprobar que tu equipo puede ejecutar el juego incluso más allá del 100% de la velocidad. ¿Qué está pasando?

Las ralentizaciones cuando cargas nuevas áreas, efectos, modelos y más es lo que comúnmente se conoce como "Shader Compilation Stuttering", algo que a los usuarios y los desarrolladores no les gusta. Este problema ha sido parte de Dolphin desde el comienzo, pero sólo nos centramos en él desde hace poco.

Cuando los juegos raramente van bien, un pequeño "tirón" aquí y allá no es un gran problema. Pese a que la emulación se ha ido perfeccionando en muchos títulos, el stuttering se ha mantenido igual con el paso de los años. Desde que sacamos la versión de Dolphin 4.0, los usuarios se han dado cuenta aun más del problema del stuttering por la compilación de shaders. Aunque parte de esto fue debido al aumento de cálculos de íntegros matemáticos requeridos a la GPU, la verdadera causa fue que se notaba más este fallo tras haber solucionado muchos otros.

Hubo mucha frustración e incluso antipatía de los desarrolladores ante el stuttering por la compilación de shaders. Fue algo que se tildó de irreparable y provocó mucha ira y frustración en la comunidad. Irónicamente, odiamos elstuttering más que a nada, pero la pura locura que suponía abordar el problema era suficiente como para mantener a la mayoría de los desarrolladors alejados. A pesar de todo, algunos mantenían en privado un rayo de esperanza. Comenzó como una teoría que supuso ciento sino miles de horas de trabajo sólo para ver si era posible.

Esa esperanza es lo que impulsó un arduo viaje hacia algo aparentemente imposible. Un viaje que le llevaría durante dos años a varios ingenieros de GPU. Todo ello en un esfuerzo de emular toda la gama de flujos proto-programables de Gamecube/Wii sin caer víctima del tan odiado stuttering.

Este es el amanecer de la era de los Ubershaders.


El Problema

Las GPUs modernas son muy flexibles pero a su vez muy complicadas. Nos referimos como shaders a los diversos programas que ejecuta la GPU, del mismo modo que un programa de pc es ejecutado por la CPU. La tarea principal de los shaders es la de programar a la GPU para realizar efectos y técnicas de renderizado complejas.

Los desarrolladores escriben un shader sobre una API (OpenGL, Direct3D, Vulkan…) y el driver de vídeo la compila y la traduce a binario para que la GPU la ejecute. Todo esto conlleva su tiempo y potencia de procesamiento, por lo que los juegos de PC compilan los shaders cuando la tasa de frames no importa, eso se traduce en tiempos de carga ó más recientemente secuencias de carga (Dead Space y el elevador, Tomb Raider…).

Como cada configuración de PC es diferente, es imposible precompilar los shaders para cada GPU, así que la única manera es que el driver de vídeo lo haga en algún punto del juego.

Las consolas son muy distintas. Cuando conoces el hardware de manera precisa, y sabes que éste no va a cambiar, puedes precompilar los programas para la GPU e incluirlos en el disco, obteniendo así tiempos de carga más rápidos y un rendimiento óptimo. Esto es muy importante en consolas antiguas, las cuales no tienen la memoria suficiente o la capacidad de almacenar los shaders en memoria. Flipper, la GPU de Gamecube, es este último caso.

Flipper, la GPU de Gamecube, es el chip más grande de la placa base

Mientras tiene su parte con funciones fijas, Flipper dispone de una unidad programable llamada TEV (Texture EnVironment, entorno de textura) que puede configurarse para realizar una gran variedad de efectos y técnicas de renderizado, tal y como hacen los pixel shaders. De hecho, la unidad TEV tiene capacidades similares al pixel shader de DirectX 8 de la Xbox. Incluso su arquitectura resultó tan flexible que permitió portarla a la GPU de Wii (Hollywood) con unas simples modificaciones.

Desafortunadamente, la unidad TEV está diseñada para que el juego demande un shader en el momento que lo necesite. No existe una precarga de la configuración de la unidad TEV porque no tiene memoria dedicada para ello.

Esta carga instantánea es la fuente de los problemas. Dolphin tiene que traducir cada configuración que cada juego manda a la GPU Flipper/Hollywood en un shader específico para que las GPUs actuales lo ejecute, y estos shaders tienen que ser ejecutados en el momento que el juego lo necesita, sin retardo o demora. Para lidiar con esta disparidad, la única opción de Dolphin es la de retardar el hilo de la CPU mientras que la GPU y el driver de vídeo realizan la compilación – básicamente pausando la emulación. Normalmente la compilación suele llevar un frame hasta que se ha completado, pero cuando le lleva más tiempo, el juego mostrará stuttering (parones o ralentizaciones) hasta que la compilación haya finalizado. Esto es el denominado shader compilation stuttering. Normalmente el stuttering solo conlleva caídas de unos pocos frames, pero en escenas con muchos efectos el stuttering puede traducirse en más de un segundo.

Hasta que el caché de shader se haya creado, Metroid Prime 3 es un suplicio.

Al ser el primero en emular un sistema con una GPU tan programable a toda velocidad, Dolphin tuvo que apañárselas sólo para solucionar este problema. Implementamos el shader caching para que si alguna configuración ocurría una segunda vez no pararía la emulación, pero tener un caché completo de shaders para un juego llevaría horas, incluso un cambio de hardware, de drivers o incluso de versión de Dolphin podría invalidar esa caché y tener que empezar de nuevo. Durante años, parecía que no se podía hacer nada contra el stuttering provocado por la compilación de shaders, y muchos se preguntaban si esto tendría solución algún día…


Solucionando un problema imposible.

De todos los problemas restantes de Dolphin, el stuttering por la compilación de shaders era del que más se quejaban. Miraras en el tracker de problemas, medios sociales, o el IRC, este problema emergía constantemente. Con el paso de los años, la reacción ante el problema iba cambiado. Se suponía que no era un problema en sí, salvo de rendimiento. Hasta que en 2015 se aceptó formalmente como un bug en el tracker de problemas de Dolphin, y concienciarnos en ello.


La soluciones potenciales

Generar todos los shaders posibles

Dolphin es muy rápido generando los shaders que necesita, pero luego compilarlos es un problema. Si pudiéramos de alguna forma generar y compilar todos los shaders para cada única configuración, eso solucionaría el problema, ¿verdad? Desafortunadamente, esto es imposible.

Hay como 5.64 x 10^511 configuraciones potenciales sólo de la unidad TEV, y habría que hacer un shader de cada una para cada configuración única. Además, los vertex shaders son utilizados para emulador la semi-programable transformación por hardware y la unidad de Iluminado, lo que eleva aún más el número de combinaciones posibles.

Como referencia, hay 7.5 x 10^15 granos de arena en la Tierra.

Aunque fuéramos capaces de compilar todo esto, estos shaders sólo serían útiles para la versión de Dolphin con la que fueron generados. Actualizar a una nueva versión requeriría un nuevo set de shaders. Cambiar de tarjeta gráfica o de drivers podría significar recompilar todo de nuevo. Y todo ello suponiendo que el driver tenga un caché de bajo nivel, cosa que no todos los drivers tienen.


Predecir qué shaders necesita el juego

Si pudiéramos generar y compilar los shaders durante los tiempos de carga o donde fuera, no tendríamos stuttering en puntos importantes. Tratar de predecir lo que el juego quiere hacer no es factible para resolver el problema. Las implicaciones en implementación y rendimiento sobre tener a Dolphin “tratando de intuir”, ya fuera por fastforwarding o por la predicción de entradas tendría un coste demasiado grande como para ayudar.

La predicción a ciegas tampoco funciona: un juego puede elegir ejecutar cualquier configuración cuando quiera sin avisar, y las configuraciones pasadas no dan pistas sobre las siguiente. La única manera de saber qué shader va a necesitar un juego sería ir a través del juego y descubrir cada configuración que podría desear.

Lo que nos lleva a la siguiente propuesta.

Compartir Shaders

Dolphin usa un objecto con “ID Único”, o “UID” para representar una configuración the la GPU emulada, y estos UIDs son convertidos en shaders y entragados al driver de vídeo para su compilación. Como los UIDs están antes de la compilación y no se han adaptado a ninguna GPU de PC específica, son compatibles con muchos ordenadores y pueden en teoría compartirse. Los usuarios se refieren a esto como “sharing shaders” y en teoría si los usuarios comparten los archivos UID, podrían compilar los shaders antes de tiempo y no tener stuttering. De hecho, el motor Vulkan ya tiene esta función para evitar problemas de sombreado en ciertos controladores.

¿Entonces por qué no prosperó esta solución?

Dolphin se está mejorando constantemente, cualquier parche que fuera añadido puede hacer esos UIDs inservibles.

No todos los juegos serán preparados. Mientras los juegos más populares tendrán colección de UIDs completos, la gente que juegue a títulos raros no tendrá ningún soporte.

En las pruebas, hay muy poca coincidencia de UIDs entre juegos. The Legend of Zelda: Wind Waker y The Legend of Zelda: Twilight Princess comparten una pequeña parte (15%) de configuraciones, pero ambos se ejecutan en el mismo motor gráfico. La mayoría de los juegos tendrán aún menos en común entre ellos, así que compartir UIDs de los juegos más populares no ayudará al resto.

Los usuarios pueden perder varios UIDs. Que se pasen el juego al 100% no significa que obtengan todos los shaders del juego.

Los desarrolladores consideraron esta opción, pero construir la infraestructura para albergar y distribuir todos los UIDs provocó más desacuerdos que soluciones. Aunque se podía usar para mejorar el problema, no era una solución funcional en sí.


Compilación de shaders Asíncrona

Famosa por un fork, asynchronous shader compilation (compilación de shaders asíncrona, desde ahora ASC) es una solución creativa para el dilema de la compilación de shaders. Tino se fijó en el problema enfocándolo en cómo los juegos modernos manejaban este hecho teniendo que compilar dinámicamente los nuevos shaders – cuando pasas de un área a otra, algunas veces los objetos nuevos aparecen de repente cuando son cargados en pantalla. Se preguntó si podía hacer algo similar en un emulador y empezó rescribiendo cómo los shaders son manejados en su fork.

El concepto de ASC cambia la manera en la que Dolphin se comporta cuando no hay una caché de shaders para una configuración demandada a Flipper/Hollywood. En vez de pausar el juego y esperar a que el shader sea creado, simplemente se salta el renderizado del objeto. Esto significa que no hay pausas o stuttering, a cosa de que algunos objetos desaparecen durante un tiempo en pantalla hasta que el shader está listo.

Esto funciona bien en muchos juegos. Dependiendo de cómo el motor del juego genera los objetos cuando dibuja el entorno, objetos que se van del campo de visión de la cámara, o sólo cubren unos pixels en pantalla todavía están por renderizar. En ese caso, saltarse el renderizado de esos objetos es casí imperceptible. Sin embargo, dependiendo del juego, esto puede resultar en “pop in” y objetos desaparecidos como decíamos anteriormente.

Ignorar la compilación de shaders puede resultar en “pop in” y errores gráficos. Pero se mantiene suave.

Una de las cosas que se preguntaban los usuarios es por qué Dolphin no implementaba el ASC de Tino como una opción para combatir el stuttering de la compilación de shaders. Al final, se reducía en el hecho de que la gente que podrían haberlo implementado junto con otros desarrolladores estaban en contra de tomarla como una solución. Lo veían como un simple hack que podría causar falsos positivos en el tracker de problemas y provocar errores mayores durante el transcurso del proyecto. Estas preocupaciones fueron fundadas cuando te das cuenta de que algunos juegos necesitan renderizar los objetos en el mismo frame que lo piden. En este caso, las cabezas de los Miis son sólo renderizadas una vez en el framebuffer incorporado. Si la copia del EFB es olvidada por culpa del ASC, las cabezas de los Miis no se mostrarán hasta el final del juego o hasta que se generen.

Un momento, eso no son gominolas…

A pesar de sus defectos, los usuarios del fork de Tino juran por ASC. A pesar de todo lo malo de los shaders asíncronos, ellos han solventado el problema del stuttering por la compilación de shaders a toda costa. Las desventajas eran demasiado grandes como para fusionar esta solución en Dolphin, pero sin duda esta solución hizo que la generación de shaders se considerara un gran problema. El trabajo de Tino dio a conocer cuántos usuarios se preocupaban por este problema, y motivó al equipo a buscar una solución más completa.


La Solución

Escribir un intérprete para el flujo de renderizado de Gamecube/Wii con los shaders y ejecutarlo en el tarjeta gráfica.

A veces, una de las mejores maneras de solventar un problema imposible es cambiar la perspectiva. No importa lo que se haya probado, No hay manera de compilar shaders específicos tan rápido como un juego puede cambiar las configuraciones.

Pero, ¿Y si no tenemos que centrarnos en los shaders específicos? Una idea loca nació para emular el flujo de renderizado en sí mismo con un intérprete que se ejecutara directamente en la GPU como un set de monstruosos shaders flexibles. Si compilamos esos shaders masivos al inicio del juego, cuando un juego configurara a Flipper/Hollywood para renderizar algo, estos “uber shaders”se podrían configurar por sí mismos y renderizarse sin necesidad de nuevos shaders. Teóricamente, esto solventaría los problemas de stuttering al prescindir de la compilación en su totalidad.

Esta idea es una locura, pero fue la primera idea que tuvo el potencial de solucionar por completo este problema imposible. La dificultad de esta solución vino de la cantidad absurda de trabajo y conocimiento necesarios que conllevaba pasa siquiera probarla. Para ponerla en perspectiva, incluso juntando a todos los desarrolladores que trabajan en Dolphin, solo dos o tres como mucho tienen los conocimientos necesarios para no sólo el hardware de Gamecube/Wii, sino también de las GPUs modernas, APIs, y los drivers para escribir, depurar y optimizar los shaders. Por no mencionar que ejecutar un intérprete como una gran cantidad de shaders no era una tarea sencilla para la GPU, y muchos temían que todo este trabajo ni siquiera tendría un buen rendimiento en las tarjetas gráficas de hoy en día.

Cientos, sino miles de horas de mentalmente agotador, repetitivo, además de difícil trabajo fueron necesarias sin garantías de éxito.

Hubo un primer intento en 2015, cuando phire llegó a estar tan frustrado con el stuttering en un nuevo y flamante PC que se propuso a diseñar un marco de trabajo para el Ubershaders. Aunque era consciente de las dificultades, parecía decidido a demostrar que Ubershaders era la solución para este viejo problema. phire fue completamente solo en un intento de enseñar a Dolphin cómo renderizar todo de nuevo.

Ésto no es un filtro gráfico...

Wow, hay muchas cosas mal aquí...

Por su simplicidad, SM64 fue uno de los primeros juegos en renderizar algo en Ubershaders.

Después de moldear la función durante más de un mes, se las arregló para conseguir el Pixel Ubershaders hasta el punto de que algunos juegos empezaron a funcionar. La sorpresa no fue que funcionara, sino que el prototipo de Ubershaders iba a toda velocidad. La primera reacción de phire fue algo así como, ¡Ost**s! Ya funciona a toda velocidad y admitió además que las GPUs no deberían ser capaces de ejecutar esto a velocidades jugables, pero lo hacen. A pesar de las pocas probabilidades que tenían, los prototipos demostraron que los Ubershaders podrían ser la solución al stuttering. Y así, siguió moldeando y comenzó a mejorar la precisión del Ubershaders, solucionar muchos errores e implementar nuevas características.

Al principio, Ubershaders haría a los juegos parecer realidades distorsionadas jamás vistas.

No llevó mucho hacer que las cosas fueran mejor.

Antes de que lo supiéramos, Wind Waker era renderizado con leves errores.

phire fue capaz de que Wind Waker se viera perfecto muy rápido. Desafortunadamente, otros juegos que usan más funciones seguían necesitando mucho más trabajo.

El esfuerzo de llevar a Ubershaders hasta aquí dejó a phire exhausto con el proyecto. Además de esto, phire tuvo que centrarse en una tonelada de trabajo de limpieza de otros proyectos para la versión 5.0 de Dolphin. Los retrasos pasaron factura y provocaron que phire no se preocupara más por Ubershaders, influenciado además por las preocupaciones sobre las limitaciones de los drivers y las APIs para llegar a una solución. A pesar de estar cerca del 90%, el 90% del proyecto quedaba por hacer, incluyendo algunas características clave:

• Finalizar el Vertex Ubershaders.
• Infraestructura/vincular Pixels y Vertex Ubershaders.
• Solucionar problemas de rendimiento en OpenGL y Vulkan.
• Limpieza de códigos, bugs, y hacer el renderizado idéntico a los shaders específicos.
• Opciones en la GUI.
• Opcional – Un modo Híbrido para GPUs integradas / menos potentes.

Verlos en la cúspide del trabajo era doloroso. Pero, no había ningún desarrollador capaz de trabajar en él con la voluntad de asumir un proyecto tan grande. Incluso aquellos que hubieran considerado trajabar en él no estaban preparados para asumir toda la limpieza de código, bugs y el trabajo de la infraestructura. Durante más de un años, Ubershaders decayó en los fondos de una gran lista de características que nunca fueron terminadas, y la esperanzo se desvanecía una vez más.


Ubershaders 2.0

El stuttering por la compilación de shaders es uno de los bugs con más quejas en Dolphin, así que después de que del desarrollo de Ubershaders parara, la gente no olvidó el problema. El hilo del foro de solicitudes siguió teniendo comentarios, e incluso fue mencionado en varios mensajes en los trackers de errores.

Ubershaders había sido la primera esperanza real de eliminar el stuttering, que arraigó en la gente durante meses. En todo caso, el paso del tiempo sólo alimentó el deseo de la comunidad por una solución. Tras muchas súplicas, plegarias y mucho chantaje coacción honesta, Stenzek a regañadientes tomó el mando del proyecto.

Antes de que Stenzek empezara a trabajar en el Ubershaders, el equipo tomó varias decisiones a favor del mantenimiento de los motores gráficos. Una de esas decisiones, buena o mala, fue la de eliminar el motor D3D12. A diferencia de D3D9, no fue debido a un proceso de depreciación; lo quitamos porque nadie lo iba a mantener.

Fue una decisión fortuita después de todo, con la eliminación de este backend además del cambio de rumbo y renacimiento del Ubershaders, cuando Stenzek estaba listo para darle un empujón. Como era el arquitecto del motor Vulkan de Dolphin, él ya estaba más que dispuesto a tomarse este trabajo extra para hacer funcional los Ubershaders en Vulkan.

Cuando Pixel y Vertex Ubershaders fueron finalmente juntados y listos para una ejecución, los testers lo probaron en los peores escenarios. Considerando que ninguna de las soluciones anteriores había funcionado en Metroid Prime 3, éste fue el primero en ser probado.

Metroid Prime 3 fue uno de los únicos juegos en los que el stuttering causó que el juego no fuera jugable. ¡Hasta ahora!

Los primeros test del Ubershaders fueron un éxito rotundo, con el stuttering eliminado en D3D, y sólo unos extraños parones puntuales en OpenGL y Vulkan. El continuo trabajo en Ubershaders hizo que las cosas fueran a mejor en cada motor, con algunas excepciones que comentaremos más tarde. But, sólo ejecutar juegos en el Ubershaders no era el fin del juego; El uso de Ubershaders puro era un gran impacto en el rendimiento de la tarjeta gráfica. Si bien los requisitos de cada juego varían, la tarjeta gráfica se verá afectada en mayor medida cuanto más alta sea la resolución. A 1x de resolución interna (480p) la mayoría de las GPUs no tendrán problemas, con las últimas tarjetas gráficas podrás llegar a resoluciones 1080p con Ubershaders en modo Exclusivo sin impacto en el rendimiento. Desafortunadamente, muchos usuarios no tienen el hardware necesario para ejecutar Ubershaders a la resolución que ellos prefieren, lo que lleva a elegir entre resolución y rendimiento.

Las gráficas integradas de Intel apenas pueden ejecutar shaders específicos de Dolphin a altas resoluciones y no tienen ninguna oportunidad contra Ubershaders.

Una gran porción de los usuarios de Dolphin están utilizando gráficas integradas. En nuestros tests, las soluciones integradas como mucho pueden llegar al 50% de velocidad con Ubershaders a 1x IR en un juego 3D. Los desarrolladores sentían que ignorar a un grupo tan grande de usuarios de Dolphin sería un error y haría de Ubershaders una victoria parcial. Así el trabajo continuó para dar una solución más robusta que curaría estos punts débiles del funcionamiento de una vez por todas.
 

Ubershaders en modo Híbrido

El Hybrid Mode Ubershaders (Ubershaders en modo Híbrido) es un matrimonio entre Ubershaders y ASC en una bella solución que hace las mejores partes de ambos sin ninguno de sus debilidades. Debido a que el modo Híbrido reduce notoriamente el coste de rendimiento de Ubershaders, suponemos que será el modo más utilizado.

Bajo el modo Híbrido, siempre que una nueva petición de configuración aparezca, Dolphin usará los shaders ya compilados por Ubershaders para al instante renderizar el efecto sin stuttering mientras que sigue compilandos el shader específico en segundo plano. Una vez que este último está hecho, Dolphin entonces pasará los objetos renderizados por Ubershaders a través de los nuevos shaders específicos generados.

Suponiendo que los drivers las APIs se comporten de la manera que queremos, esta solución es perfecta. Debido a que los Ubershaders sólo se ejecutan en una fracción de los objetos en una escena y sólo por frames a la vez, el golpe en rendimiento es casi nulo y se elimina el parpadeo. Desafortunadamente, los drivers y las APIs no son perfectas, limitando la efectividad del modo Híbrido en algunas configuraciones. Lo que nos lleva a…


El Salón de la vergüenza de API y Driver de Ubershaders

Los equipos de desarrollo de drivers de GPU tienen un trabajo duro exprimiendo tanta potencia como sea posible de sus productos a la vez que proporcionan una experiencia estable para sus usuarios. No queremos faltar al respeto a nadie que trabaje en estos drivers, pero uno de los obstáculos más grandes para este proyecto ha sido un ridículo número de peculiaridades en los drivers y APIs que forzaron soluciones y otros cambios en la funcionalidad.

Sacando esto a la luz, esperamos captar su atención. Quizás alguien fuera del proyecto nos puede llegar con una solución o al menos monitorizarla en caso de que una futura actualización de driver/API arregle el problema mencionado.


Generación de variantes de Shader

Los drivers pueden hacer cosas de manera que nosotros no esperamos ni podemos controlar. Cuando tenemos que generar un nuevo flujo para una diferente mezcla o estado profundo, algunos drivers no son lo suficientemente listos como para compartir los shaders entre flujos. Esto causará un pequeño parpadeo la primera vez que un nuevo modo de mezcla es usado. La mayor parte del tiempo las variantes que un juego usará son generadas durante los primeros minutos de juego, pero pueden seguir siendo frustrantes cuando buscas la perfección.

Por suerte, algunos drivers son los suficientemente listos como para compartir shaders entre flujos, como el driver Mesa, y no parece haber parpadeo adicional. Los demás drivers disponibles parecen sufrir algo de parpadeo durante la generación de variantes. Ya que nosotros actualmente no podemos hacer nada sobre esto, Esperamos que a medida que los drivers de Vulkan maduren, asumirán el comportamiento más favorable de Mesa.


Shader de NVIDIA bloqueado en OpenGL y Vulkan

Algunos usuarios han reportado que en OpenGL y Vulkan (en concreto en el modo Híbrido) hay un leve parpadeo cuando los shaders son compilados. Como no sabemos qué está mal exactamente, ya que esto no sucede en D3D, estamos casi seguros de que es alguna peculiaridad del driver de NVIDIA más que un fallo en cómo Dolphin maneja las cosas. Basándonos en nuestros tests, parece que es algo aparte de la generación de variantes.


La compilación de Shaders de NVIDIA en OpenGL y Vulkan son más lentas que en D3D.

Esto en particular es muy frustrante y no hay manera para nosotros de depurarlo. Estamos proporciando los mismos shaders a la GPU en OpenGL, Vulkan y D3D, sin embargo, D3D termina los shaders mucho más rápido que los otros dos motores. Esto significa que en una GTX760, sólo obtendrás 1x de resolución interna en algún juego bajo OpenGL o Vulkan, pero en D3D, serás capaz de alcanzar el doble o incluso el triple antes de apreciar ralentizaciones.

Dado que NVIDIA no nos permite desensamblar shaders a pesar de que a los fabricantes de GPUs de PC sí, no tenemos manera de depurar o darnos cuenta de por qué el código compilado es mucho más eficiente en D3D. Pensad en lo ridículo que suena: queremos hacer que Dolphin funcione mejor en NVIDIA y ellos no nos proporcionan las herramientas para tan siquiera intentarlo. Es una decisión desconcertante que esperamos sea rectificada en el futuro. Sin las herramientas de desensamblado de shaders proporcionadas por otros vendedores, reparar varios bugs habría sido mucho más difícil.

Lo triste es que las herramientas existen…si eres un gran estudio de videojuegos. Editado: NVIDIA nos informó de que la única herramienta de desensamblado de shaders disponible es de Direct3D 12 (bajo NDA*), y no la hay para otras APIs independientes del NDA. Esperemos que las herramientas para otras APIs estén disponibles en el futuro.
NDA: Non Disclosure Agreement, Acuerdo de no divulgación.


Drivers Vulkan de AMD siguen sin soportar caché de shaders

Durante la edición de este artículo, ¡nuestros deseos fueron respondidos! El driver Vulkan de AMD ahora soporta caché de shaders. Esto mejora gratamente lo que era una situación precaria con Ubershaders, ya que siginificaba que tendríamos que recompilar los Ubershaders en cada nuevo inicio. También mejora el parpadeo mencionado antes.


Los drivers gráficos de macOS son terribles

Como con cada excitante función, los usuarios de macOS estén esperando por el inevitable “pero en macOS…” y aquí está. El desfasado e ineficiente driver OpenGL 4.1 de macOS simplemente no es capaz de adoptar Ubershaders de ninguna manera. El modo Híbrido reducirá el parpadeo, pero, el modo Exclusivo es muy lento. Además, macOS siguen sin soportar caché de shaders bajo ningún driver.
 

Configuración recomendada para Ubershaders

Con todos problemas de drivers anteriores, no es una sorpresa que algunas tarjetas gráficas funcionen mejor en algunos motores y ajustes. Hemos descrito configuraciones recomendadas generales basadas en varias tarjetas de vídeo. Dependiendo de tu preferencia o tu tarjeta gráfica en particular, puedes desviarte de las recomendaciones. Daros cuenta de que cambiar ciertos ajustes mientras se ejecuta un juego, como per-pixel lighting (iluminación por píxel) y en nivel de anti-aliasing, requerirá compilar diferentes Ubershaders y pueden provocar una pausa larga mientras esto se realiza. Recordad además que Ubershaders requiere más potencia de GPU, así que los mismos ajustes requerirán una tarjeta gráfica más potente.

• Intel en Windows
  
  - Usar D3D para el modo Híbrido. El modo Exclusivo funciona, pero las GPUs de Intel no son tan potentes actualmente como para ejecutarlo al 100% ni en resolución nativa.
  - El Driver genera variantes con OpenGL, o sea stuttering.
  - Vulkan sólo soporta Skylake+, y está demasiado roto como para usarlo hoy en día.
  
  
• Intel en Linux
  
  - Usar Vulkan en modo Híbrido. El modo Exclusivo funcionará, pero no obtendrás velocidad total.
  - El driver Anv es fantástico y debería tener todos los beneficios de Ubershaders.
  - El driver i965 de Intel no comparte shaders OpenGL entre hilos, lo que se traduce en stuttering. El modo Exclusivo, aunque lento, funciona perfectamente pero el modo Híbrido dará stuttering.
  
  
  
  
  
  
• AMD en Windows
  
  - Usa D3D en modo Híbrido.
  - Usa D3D o Vulkan en modo Exclusivo.
  - El driver OpenGL de AMD es lento en general.
  
  
• AMD en Linux
  
  - Usa Vulkan para los modos Exclusivo o Híbrido.
  - Radv es muy parecido a anv y funciona muy bien.
  
  
  
  
  
  
• NVIDIA en Windows
  
  -Usa D3D o OpenGL en modo Híbrido.
  - Usa D3D, OpenGL o Vulkan para el modo Exclusivo. Los Ubershaders de D3D tienden a ser más eficientes que OpenGL y Vulkan, dando mejor rendimiento en GPUs más antiguas.
  
  
• NVIDIA en Linux
  
  - Usa OpenGL en modo Híbrido.
  - Usa OpenGL o Vulkan en modo Exclusivo. El rendimiento puede variar según qué motor sea más rápido para cada juego. Tener en cuenta que Vulkan dará stuttering mientras se generan las variantes de flujo, lo que puede causar uno o dos pequeñísimos parones al principio de la sesión de juego.
  
  
• NVIDIA en Android
  
  - Usar OpenGL en modo Híbrido.
  - Usar OpenGL o Vulkan en modo Exclusivo. Esto puede llegar a velocidad completa en juegos muy básicos en la NVIDIA Shield TV.
  
  
  
  
  
  
• PoweVR en Android
  
  - No recomendado. Mientras se ejecuta Ubershaders hay errores gráficos por los errores de compilación de shaders, pero se corrigen por sí solos en modo Híbrido así como los shaders específicos compilados. Demasiado lento como para ser útil en el hardware actual.
  
  
• Adreno en Android
  
  - No recomendado. El modo Híbrido fallará y el modo Exclusivo mostrará errores gráfivos graves. Demasiado lento como para ser útil en el hardware actual.
  
  
• Mali en Android
  
  - No se ha probado. Aun así podemos decir con seguridad que no funcionará bien.

Conclusiones

Resulta extraño estar hablando del proyecto Ubershaders en pasado ahora mismo. Está completo, está fusionado y lo puedes usar ahora mismo en la última build de desarrollo. Aunque haya ciertos lastres aquí y allá, por fin tenemos una solución al stuttering por la compilación de shaders. Ubershaders será mejor con el paso de los años así como las tarjetas gráficas serán más potentes y el modo Exclusivo tendrá un mayor uso. El modo Híbrido también debería mejorar, así como los drivers de Vulkan maduren y otras peculiaridades sean solventadas. Y, por supuesto, seguiremos trabajando por nuestra parte mejorando la emulacion.

Aunque el stuttering por la compilación de shaders está solucionado, Dolphin sigue necesitando de un ordenador potente para emular el juego. Además, hay ciertos lastres en el JIT que pueden causar ralentizaciones. Actualmente, el JIT con soporte de branching de Dolphin tiene serios problemas en juegos que usan un JIT (como los juegos de la VC de Nintendo 64), causando un stuttering similares a los de la compilación de shaders, pero esto es otra cosa. Mientras esperamos solventar este problema, es probable que incluyamos una opción para desactivar el branching del JIT si no lo podemos corregir, por lo que los usuarios tendrán la opción de desactivarlo para títulos problemáticos.

Debido a este gigantesco artículo, no vamos a hacer un informe de progreso este mes. Tendremos los grandes cambios de julio en el informe de progreso de agosto. Va a ser de los grandes, así que ¡os esperamos! Hasta entonces, disfrutad.

Puedes continuar la conversación en el hilo del foro de este artículo.