Daedalus:Emulador N64 (#2)

hkg36e escribió:Hombre pensad que es bueno que no de noticias.Si no da noticias buenas , no sabemos de sus avances, pero si no da noticias malas,significa que sigue ocn el proyecto

TeKKin escribió:wenas ante todo buen trabajo por emulador muy bueno jeje, pero aora me gustaria saver de donde me bajo los rooms

PSPUpdates escribió:DaedalusStrmnNrmn is deadset on letting people know that he is doing his best to improve his N64 emulator, Daedalus. Just last week he let us in on how he's trying to incorporate a dynamic recompiler to his N64 emulator to make it run somewhat at par with the original N64 speed. Today he posts more of the dynarec progress on his blog.

StrmnNrmn has now succeeded in assembling the fragment buffers into a native x86 code and execute it dynamically. At first, he debated as whether to target MIPS or Intel initially. He ended up initially debugging the code generation on the PC rather than doing it on the PSP. It turned out to be a wise decision.

"I'm glad I started with the PC as it allowed me to fix a number of hairy problems without going down the torturous path of debugging self modifying code on the PSP with just a few printf() statements to help track down any problems," StrmnNrmn says.

Converting the fragment simulator loop directly into assembly was the first thing StrmnNrmn did to start with the x86 code generation. Each instruction in the fragment had the following generated code:

set current pc
set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler

This generated code produced a lot of assembly (i.e. 200KB of N64 instructions will produce 4MB of x86 assembly, which means an expansion of around 2000%). This didn't bother StrmnNrmn. All he was concerned with at that time was preserving the behavior of the fragment simulator as much as possible.

The full article awaits after the jump!

StrnmNrnm escribió:Just a quick update on the dynarec status, as I know a lot of people are more interested in this than the grizly details of branch delay instructions

Last weekend (13/14 May) I managed to assemble the fragment buffers into native x86 code, and execute this dynamically. I spent some time debating whether to target MIPS or Intel initially, but I decided that it would be a lot easier for me to debug the code generation on the PC than it would be to debug code gen on the PSP.

In the end I'm glad I started with the PC as it allowed me to fix a number of hairy problems without going down the torturous path of debugging self modifying code on the PSP with just a few printf() statements to help track down any problems.

To start with on the x86 code generation, all I did was convert my fragment simulator loop directly into assembly. So the generated code for each instruction in the fragment looked something like this:


set current pc
set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler



So a fragment with 100 instructions in would have this block repeated 100 times (with different pc, delay flag constants etc).

This generated a lot of assembly (i.e. 200KB or so of N64 instructions would generate over 4MB of x86 assembly, i.e. an expansion of around 2000%). At this point I wasn't interested in performance though - I wanted to make sure that I was preserving the behaviour of the fragment simulator as much as possible. The exception and branch handlers mentioned in the pseudo code above warrant more detailed description, but I'll leave that for another post.

At this point I spent a few hours debugging, but generally everything was working pretty well. The emulator was currently running around the same speed with 'dynarec' enabled as with it disabled (I use quotes because there isn't really much 'dynamic' about this code yet).

I spent the rest of the weekend and the early part of last week trying to optimise the generated assembly and see what I could get away with removing. One of the first things to go was setting the program counter before executing each instruction. The only instructions that need to know this tend to be branching instructions (which are relative and need to know the current PC to work out their target address) and other instructions that can potentially fire exceptions. The vast majority of instructions don't need to know the current PC though (e.g. arithmetic ops, logical ops etc).

Next I had a look at reworking things so I only needed to explicitly set the branch delay flag if a branch delay slot was actually active. I made the precondition that the branch delay slot was always clear, and explicitly set/cleared it when I knew the state needed to change.

Finally I removed exception handling from all the instructions I knew to be safe. For instance, I know ANDI (and immediate) can never throw an exception. As I only perform counter updates at the end of the block, an exception can never be fired when executing this instruction.

After all these changes I had an instruction execution block which looked something like this:


if ( pc needed ) set current pc
if ( branch delay instruction )set branch delay flag
get op code in ECX
call handler for specified op code (from R4300.cpp)
if ( can throw exception and exception set ) exit to exception handler
if ( branch instruction and branch taken ) exit to branch handler


This meant that the vast majority of instructions looked as follows:


get op code in ECX
call handler for specified op code (from R4300.cpp)


So I had nice big fragments like this:


...
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
get op code in ECX
call handler for specified op code (from R4300.cpp)
...


Essentially I removed the vast majority of the instruction fetch/decoding overhead from the emulation.

With this version of the dynarec, 200KB of N64 code was now generating just 2MB of x86 assembly (i.e. an expansion ratio of around 1000%). The PC version was running around 60% faster with dynarec enabled than with it disabled, which is a pretty significant speedup (although this is still very early in the process).

What's also important is that this is before I've done any real optimisation of the generated code. For each instruction I'm still calling the generic instruction handler which has the overhead of figuring out which source registers to use, which register is the destination etc. The *real* speedup comes from generating code to handle op codes explicitly, as you remove all this decoding overhead along with the overhead of jumping to another function. Once you've removed most of the generic instruction handling you can start looking at caching register values to minimise the amount of memory that's being moved around.

With the PC version up and running fairly successfully, I've spent this weekend getting the PSP code generation working. I don't want to go into too many details (as I want to go into more depth in future posts), but I know people are keen to hear some news about how this is going.

I got the basic code generation working on Saturday morning (thankfully I'd already resolved most of the tricky issues in developing the x86 version the previous weekend). I spent most of Saturday afternoon fixing some really horrible instruction cache related bugs. I'm still not 100% sure I've fixed them, but it seems very stable at the moment. At the moment I'm at the same stage with the PSP version of the dynarec that I was with the PC version last weekend - the code generation is running fine (and executing on the PSP without crashing more importantly but I've only just started looking at optimising things. It's still too early to speculate on numbers for the performance improvement it will give. Currently it's running around 10% faster with dynarec enabled, but it's still very early days.

More soon.

-StrmnNrmn

pochi escribió:Joder,pues en un solo dia un 10% mas.....ya es,esperemos 10 dias y entonces 100% jejejejeje ,ojala.

El 100% de 6Fps son.... a ver que piense.... 12fps ohhh.

Fran_Teruel escribió:
El 100% de 6Fps son.... a ver que piense.... 12fps ohhh.

Me parece que tendremos que esperar 100días.

Natsu escribió:
Estas seguro??? yo creo qe el 100% de 6fps son 6fps

Xenogears escribió:Donde se pueden ver las ultimas noticias?

Porque alomejor estamos esperando todos a que diga alguien algo y nadie lo mira...

TeKKin escribió:pero a todo esto aun no e podido probar el emulador devido a ke no tengo ningun juego ke mal aver si alguien me aconseja de algo por ke kiero yo tambien probarlo joer!!!!

saludos

Deku escribió:La gente dice q cuando la cosa ande a 30 fps la cosa sera jugable... estais de coña no???

Incluso a 50 fps es 1 coñazo. No hay nada mas askerosamente desesperante q un juego q se ralentiza, aunq sea unos pokillos frames

Y si no mirad el emu de SNES, q alguna vez se ralentiza de 60 a 30 o 40 fps y te toca mucho los cojones

Deku escribió:La gente dice q cuando la cosa ande a 30 fps la cosa sera jugable... estais de coña no???

Incluso a 50 fps es 1 coñazo. No hay nada mas askerosamente desesperante q un juego q se ralentiza, aunq sea unos pokillos frames

Y si no mirad el emu de SNES, q alguna vez se ralentiza de 60 a 30 o 40 fps y te toca mucho los cojones

de la versión R5 nada de nada nop?¿

que ha conseguido aumentar la velocidad un 100%(no que los juegos vayan al cien por cien ojo!!)