Cómo funciona técnicamente un emulador

Un emulador consigue que un programa escrito para una máquina funcione en otra que no se le parece en nada. No hay magia, sino traducción constante: el emulador convierte las instrucciones de la CPU original en instrucciones que entiende tu procesador y reproduce la memoria y los dispositivos de la máquina original. La documentación técnica de QEMU sobre el funcionamiento interno de su traductor lo resume en una frase: «cuando se encuentra por primera vez un fragmento de código, lo convierte al juego de instrucciones del anfitrión».

Vamos a abrir el capó con lo que cuentan los propios desarrolladores: QEMU para la CPU, Dolphin para la gráfica, libretro y ares para la latencia y MAME para la preservación. Y de paso verás por qué emular una consola antigua pide un PC mucho más potente que ella.

---

Qué es emular, exactamente

QEMU se presenta como «un emulador y virtualizador de máquinas genérico y de código abierto». En su uso más habitual, la emulación de sistema, ofrece «un modelo virtual de una máquina completa (CPU, memoria y dispositivos emulados)» sobre el que arranca un sistema operativo invitado. Su segundo modo, la emulación en modo usuario, lanza procesos compilados para una CPU sobre otra distinta.

MAME, que se define como «un entorno de emulación multipropósito», lo enfoca desde otro ángulo: documentar el hardware y cómo funciona, hasta el punto de que su propio código fuente hace de documentación. En su caso, emular es describir una máquina con tanto detalle que esa descripción se pueda ejecutar.

La documentación de libretro, por su parte, describe RetroArch como «una interfaz para emuladores, motores de juego y reproductores multimedia». Un emulador adaptado a libretro se convierte en un núcleo (en inglés, core): un único fichero de biblioteca que puede cargar cualquier interfaz compatible, que es la que pone los controladores de vídeo, audio y entrada.

---

Emulación frente a virtualización

QEMU hace las dos cosas y marca bien la frontera. En la emulación de sistema, la CPU «puede emularse por completo o trabajar con un hipervisor como KVM, Xen o Hypervisor.Framework para que el invitado se ejecute directamente en la CPU del anfitrión». En el modo usuario, con procesos compilados para otra CPU, «la CPU siempre se emula».

QEMU llama aceleradores a esos hipervisores y enumera KVM, Xen, MSHV, Hypervisor Framework, Windows Hypervisor Platform y NVMM, además del Tiny Code Generator (TCG), su traductor propio. La clave es que TCG es el modo por defecto y es emulación pura: para aprovechar la virtualización por hardware hay que pedir un acelerador expresamente.

Para ese otro lado tienes nuestra guía para usar máquinas virtuales en Windows. Aquí toca traducir una CPU que no es la tuya.

---

Cómo se ejecuta el código de otra CPU

La FAQ de Dolphin, el emulador de GameCube y Wii, lo baja a tierra: estas consolas no usan un procesador Intel o AMD con instrucciones x86, sino una CPU con instrucciones IBM PowerPC. Cada instrucción básica del juego hay que traducirla a algo que tu PC entienda, y descifrarla y adaptarla puede costar entre dos y cien veces más ciclos de reloj, dependiendo de cuál sea. De ahí que haga falta un procesador de más de 486 MHz para emular una GameCube.

QEMU hace ese trabajo con TCG, que su documentación describe como un JIT (de just in time, «justo a tiempo»): un traductor dinámico que convierte el código sobre la marcha, a medida que lo encuentra, con algunos trucos que lo hacen relativamente fácil de portar sin renunciar a un buen rendimiento.

La pieza básica es el bloque de traducción (TB). Para ganar velocidad, el traductor da por hecho que parte del estado de la CPU virtual no cambia dentro del bloque y lo anota en el propio TB: en x86, por ejemplo, si los segmentos SS, DS y ES tienen base cero, ni siquiera genera la suma de la base del segmento. Si el estado cambia, como el nivel de privilegio, se genera un TB nuevo. El bucle principal busca el siguiente bloque y solo lo traduce si no lo tiene ya en memoria; para no volver al bucle a cada paso, los bloques traducidos se encadenan directamente.

¿Y si QEMU no soporta tu arquitectura? Se puede compilar igualmente con su intérprete de TCG (TCI), pero su página de plataformas de compilación avisa de que es «muy lento y no se recomienda para un uso normal».

---

La gráfica y los tirones al compilar shaders

Con la GPU el problema cambia. La FAQ de Dolphin explica que la gráfica de GameCube no usa sombreadores (shaders): cada efecto se ejecuta directamente en hardware, sin lenguaje de programación intermedio. Como eso no encaja con una gráfica de PC, Dolphin usa shaders en la tuya para reproducir lo que aquella hace por hardware, y todo va mucho más lento.

El equipo de Dolphin lo detalló en su artículo sobre los ubershaders, de julio de 2017. La GPU de GameCube, Flipper, es el chip más grande de la placa y tiene una unidad TEV (Texture EnVironment) programable que trabaja de forma muy parecida a los sombreadores de píxeles. Era tan flexible que se reutilizó, con pocos cambios, como GPU de Wii con el nombre de Hollywood.

El problema son las cuentas: hay unas 5,64 × 10⁵¹¹ configuraciones posibles solo de la unidad TEV, y cada una necesitaría su propio shader. Dolphin traduce cada configuración que usa un juego a un shader especializado y lo compila, lo que lleva tiempo, y mientras tanto frena el hilo de la CPU, lo que en la práctica pausa la consola emulada. Si la compilación dura menos de un fotograma, no te enteras; si dura más, el juego se para. Ese tirón suele durar un par de fotogramas, pero en escenas exigentes puede pasar del segundo. «Hasta que se forma la caché de shaders, Metroid Prime 3 es bastante doloroso», admite el propio artículo.

La caché de shaders evita repetir un tirón ya visto, pero hacían falta horas de juego para tener una fiable, y cambiar de gráfica, actualizar el controlador o estrenar versión de Dolphin la invalidaba. Además, de un juego a otro se comparte poco: The Legend of Zelda: The Wind Waker y Twilight Princess solo comparten un 15 % de configuraciones, y eso que usan el mismo motor base. La compilación asíncrona, que se salta el dibujo del objeto hasta tener su shader, quita el tirón, pero algunos objetos desaparecen de la vista hasta que el shader está listo.

---

Ubershaders: un intérprete dentro de la gráfica

La solución fue darle la vuelta al problema: emular la propia cadena de renderizado con un intérprete que se ejecuta directamente en la GPU, en forma de shaders enormes y flexibles. Estos ubershaders, shaders gigantes y todoterreno, se compilan al arrancar el juego y, cada vez que este configura Flipper o Hollywood para dibujar algo, se configuran solos y lo dibujan sin necesitar shaders nuevos. Se intentó por primera vez en 2015, y fue un camino de dos años con varios ingenieros de GPU.

El precio lo paga tu gráfica: los ubershaders puros son, en palabras del equipo, «un lastre enorme para el rendimiento». A resolución interna 1x (480p) la mayoría de gráficas dedicadas pueden con ellos, pero las integradas rondaban, en sus pruebas, como mucho el 50 % de velocidad en un juego 3D típico. La salida práctica es el modo híbrido: ante una configuración nueva, Dolphin la dibuja al momento con los ubershaders mientras compila en segundo plano el shader especializado, y cuando está listo le pasa el relevo.

---

Precisión frente a velocidad

«Una de las partes más difíciles de ser un emulador es equilibrar precisión, rendimiento y presentación», reconoce el blog de Dolphin. Y su FAQ responde a la pregunta del millón, «¿por qué necesito un ordenador potente para emular una consola antigua?», con razones de hardware: en GameCube y Wii la CPU y la GPU comparten memoria, su RAM es SRAM, más pequeña pero más rápida que la SDRAM de un ordenador convencional, y los juegos corren directamente sobre el hardware, sin sistema operativo de por medio.

Además, algunos juegos piden un método de emulación más preciso, que a su vez exige más rendimiento. Y no basta con echarle núcleos: en Dolphin solo se paralelizan bien la CPU, la GPU y el DSP, y trocearlo más probablemente lo haría más lento. Por eso usa solo tres núcleos y depende de las instrucciones por ciclo (IPC) y de la frecuencia.

ares, un emulador multisistema de código abierto centrado en la precisión y la preservación, lo ilustra con su historia. Nació el 14 de octubre de 2004 como bsnes, un emulador de Super Famicom; pasó a llamarse higan en 2012, y el 25 de marzo de 2020 surgió ares como bifurcación de higan para añadir sistemas más modernos, como Nintendo 64 y PlayStation, que, como explica su página de presentación, «sencillamente no se pueden emular con el modelo de precisión al ciclo de higan». bsnes, por su parte, revivió para volver a centrarse en Super Famicom y recibir mejoras de rendimiento que no encajaban con el espíritu de higan.

---

La latencia y el run-ahead

Queda el retardo. Todo juego trae uno de serie, según la documentación de libretro sobre el run-ahead: algunos reaccionan en el siguiente fotograma y otros tardan 2, 3 o más en mostrar en pantalla lo que has pulsado en el mando.

El run-ahead («ir por delante») calcula fotogramas lo más rápido posible en segundo plano para «rebobinar» la acción y acercarla todo lo posible al momento de la pulsación. Para ello se apoya en los estados guardados, que deben ser limpios y rápidos: si un núcleo no los admite, no funciona. Y como muchos núcleos dejan zumbidos en el audio al cargar un estado, existe un modo de dos instancias en el que el núcleo principal no carga ninguno.

La factura vuelve a pagarla tu CPU: cuantos más fotogramas por delante, más exigencia. ares también presume de reducir el retardo teniendo en cuenta los retrasos de procesamiento internos de los juegos originales, hasta lograr «menos latencia de la que es posible en el hardware real usando un CRT», es decir, una pantalla de tubo.

---

La preservación como objetivo

¿Y para qué tanto esfuerzo? La documentación de MAME es clara: su propósito es preservar décadas de historia del software y evitar que desaparezca para siempre cuando deje de funcionar el hardware en el que corre. Poder usarlo es, en sus palabras, «un efecto secundario agradable», aunque también es la prueba de que la documentación es exacta: «¿de qué otra forma puedes demostrar que has recreado fielmente el hardware?».

MAME, que nació como Multiple Arcade Machine Emulator, absorbió proyectos hermanos como MESS y AGEMAME, y hoy documenta ordenadores, consolas, calculadoras y máquinas de apuestas, además de las recreativas con las que empezó. ares va en la misma línea, con un código fuente pensado para ser lo más legible y autodocumentado posible.

Nada de esto se resuelve de una vez: el proyecto de los ubershaders llevó dos años, y bsnes volvió precisamente para ganar rendimiento. Los emuladores mejoran a base de optimizaciones, y a veces dan saltos que merecen titular, como el del emulador cuya mejora de rendimiento contamos en esta noticia.

---

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.