[DAEDALUS] - R10 Plan of Action

Nuestro querido amigo strmnnrmn vuelve a pronunciarse para hablar de los puntos en los que se centrará para la release R10 de su emulador de N64.

Copio y pego de su blog:

Before I went away on holiday I asked you what you thought I should look at working on for the next release of Daedalus. Over 200 of you replied, and I've greatly enjoyed reading what you've had to say. There were some brilliant suggestions, so many thanks for your contributions.

It seems pretty clear to me that speed is the single biggest issue that most people want to see addressed. Many people also mentioned compatibility and savestate or save game support, but in nowhere near the same kind of numbers as those wanting speed improvements.

Based on your feedback my current plan is to release Daedalus R10 at the end of March, focusing mostly on speed improvements. If I can fit in any easy compatibility fixes, I'll do this too*.

Several people have asked what possibilities remain for optimisation. Here's a short list of things I know need more work:
In many games, a lot of the time spent executing dynamically recompiled code is doing things which can potentially be emulated at a high level. For instance, over 5% of the time spent executing dynarec code in Mario64 is just converting matrices from floating point to fixed point format. Another 4-5% of the time is spent in a loop invalidating areas of the data cache (which is irrelevent in an emulator.)

Some of the most expensive fragments are those which branch to themselves (i.e. those doing many loops). I can optimise for this to avoid loading and flushing cached registers on each iteration through the loop.

I can implement a frameskip option (I had intended to implement this for R9, but forgot!)
I can make use of the Media Engine (as Exophase suggested in conversation, as the ME can't access VRAM, it might make more sense to execute Audio and Display Lists on the main CPU, and run the N64 CPU emulation on the PSP ME)
There are certain situations where I fail to create fragments in the dynamic recompiler - for instance if the code being recompiled writes to a hardware register, this triggers an interrupt and causes fragment generation to be aborted. I should be able to deal with situations such as this more gracefully.

The fragment generator can do a lot more to improve register caching, and eliminating redundant 64-bit operations.
There are many situations where N64 roms busy wait. I detect very simple occurances of this, but not all of them. If I manually identify more complex examples I can have the fragment generator optimise them away.
Some roms are causing the dynarec fragment cache to be repeatedly dumped and recreated (I think Banjo Kazooie is one example of this). Fixing this may just involve tweaking a couple of magic numbers.

I currently optimise memory accesses under the assumption that most accesses are in the range 0x80000000 - 0x80800000, which is incorrect in the case of roms that make heavy use of virtual memory, or access RAM through the mirrored range at 0xa0000000. I can improve the trace recorder to collect information on which range a memory access fell in, and generate code to speculatively optimise for this.
Now that the dynarec engine is producing much better code, the cost of display list processing is becoming more significant, and may finally be worth profiling and optimising.
That's quite a big list, so I doubt I'll be able to work on these things before the end of March, but I think it shows there's still a lot of scope for further optimisation.

-StrmnNrmn

*Just this morning, I figured out why the Expansion Pak support was broken, so Majora's Mask and a couple of other games relying on this are booting correctly now

FUENTE

Traducción:
(Ojo: Las palabras entrecomilladas no llegué a pillar que significaban, asi que antes de arriesgarme a cometer una atrocidad, preferí ponerlo tal cual )

Antes de que me fuera de vacaciones os pregunté en que deberia centrarme para la siguiente release de Daedalus. Alrededor de 200 respondieron, y he disfrutado leyendo lo que habéis dicho.
Había algunas sugerencias brillantes, así que muchas gracias por vuestra colaboración.

Parece bastante claro que la velocidad es el principal tema que la mayoría de gente quiere que me centre. Mucha gente tambien mencionó la compatibilidad y los savestates o soporte para guardado, pero nada comparado con el número de gente que quería mejoras en la velocidad.

Mi plan es sacar la release de Daedalus R10 por finales de Marzo, centrándome en mejoras en la velocidad. Si puedo agregarle algún arreglo de compatibilidad, haré esto también.*

Bastante gente ha preguntado que posibilidades quedan de optimización. Esta es una pequeña lista de cosas que necesitan ser más trabajadas:
En muchos juegos, gran parte del tiempo en el que se ejecuta codigo dinamicamente recompilado se están haciendo cosas que pueden ser potencialmente emuladas a alto nivel. Por ejemplo, sobre el 5% del tiempo en el que se ejecuta código dynarec en Mario64 se está solamente convertiendo matrices desde un punto flotante a un formato de punto fixed (fixed point format). Otro 4-5% del tiempo está en un bucle deshabilitando areas del cache de datos (cosa irrelevante en un emulador)

Algunos de los más fragmentos más caros són aquellos que se “branch” a ellos mismos (ej: esos hacen demasiados bucles). Para optimizar esto puedo evitar cargas y “flushing” registros del caché en cada paso del bucle.

Puedo implementar la opción frameskip (Lo tenía que haber implementado en la R9, pero se me olvidó!)
Puedo hacer uso del Media Engine (tal y como Exophase me sugirió en una conversación, ya que el ME no puede acceder a la VRAM, esto haría más sensato ejecutar las listas de Audio y Display en la CPU, y así emular la CPU de N64 en la PSP ME)

Hay algunas situaciones donde falla en crear fragmentos en el recompilador dinamico – por ejemplo si el codigo recompilado escribe en un registro del hardware, esto activa una interrupción y hace que la generación del fragmento se aborte. Debería ser capaz de tratar mejor con estas situaciones.

El generador de fragmentos puede hacer mucho más para mejorar el “caching” del registro, y eliminanar las operaciones de 64-bit redundantes.
Hay muchas situaciones donde las roms de N64 se quedan paradas esperando. He detectado algunos casos de esto, pero no todos. Si puedo identificar ejemplos más complejos puedo hacer que el generador de fragmentos los optimize.

Algunas roms hacen que el cache del dynarec esté repetidamente “dumped and recreated” (Creo que el Banjo Kazooie es una de ellas). Arreglar esto puede comportar una mejora.

Estoy optimizando los accesos a la memoria ya que la mayoria estan en el rango 0x80000000 - 0x80800000, el qual es incorrecto para las roms que hacen mucho uso de la memoria virtual o acceden a la RAM a traves del rango 0xa0000000

Puedo mejorar el “trace recorder” para saber en que rango de memoria accede, y generar codigo para optimizar esto.
Ahora que el motor dynarec produce código mucho mejor, el coste del “display list processing” es más importante, con lo que tambien se puede optimizar esto.
Es una lista bastante grande, así que dudo que vaya a ser capaz de trabajar en todas estas cosas antes de finales de Marzo, pero creo que demuestra que aún hay mucho para optimizar.

-StrmnNrmn

*Justo esta mañana, he descubierto porque el soporte al Expansion Pak estaba roto, así que el Majora’s Mask y un par de otros juegos similares ya cargan correctamente