StrmnNrmn new R6 info

[monaco]

Deciding what to optimise

Whenever I start to answer questions on the comment pages I always end up going into too much detail for a quick response and end up deciding to put up a new post instead. I hope this isn't too annoying

In response to Plans for R6 xiringu and ukcuf16 had a couple of interesting suggestions for performance improvements.

First up, from xiringu:


instead of working with a 300x200 screen, work with only half height 150x200 and then display an empty line every other line to get the final 300x200.


That's an interesting idea - it's a trick that's been used by demo coders for years to get a few extra fps. I'm not sure this is going to provide all that much of a speedup to Daedalus though The reason for this is that currently rendering only contributes a small amount to the overall cost of each frame, so even if rendering time was totally eliminated, the framerate wouldn't change much. As an example, let's take something like Zelda which currently runs at around 4 fps. At 4fps it means each frame takes 1000/4 = 250 milliseconds to render each frame, which is broken down something like this:

CPU emulation: 200 ms
Display list parsing: 40 ms
Rendering: 10 ms
Total: 200 + 40 + 10 = 250 ms (i.e. 1000/250 = 4fps)

Assuming that we could totally eliminate the rendering time, this would now look like:

CPU emulation: 200 ms
Display list parsing: 40 ms
Rendering: 0 ms (no cost)
Total: 200 + 40 = 240 ms (i.e. 1000/240 = 4.17fps)

So the very best we could hope for in this case would be a .17fps improvement in the framerate

ukcuf16 wrote:


Just wanted to ask if there is ever going to be frame skip in later versions


What ukcuf16 is suggesting is that the emulator renders one frame, then skips the next. Alternating frames like this should halve the cost of rendering, at the cost of making the framerate a little less smooth.

Again, this is an interesting idea, but I don't really see this having much impact on the framerate as things stand at the moment. Working out the potential speedup is a little more complicated, as we have to take the average time over two frames. The numbers look something like this:

Frame1 CPU emulation: 200 ms
Frame1 Display list parsing: 40 ms
Frame1 Rendering: 10 ms
Frame2 CPU emulation: 200 ms
Frame2 Display list parsing: 0 ms (skipped)
Frame2 Rendering: 0 ms (skipped)
Total: 200 + 40 + 10 + 200 = 450 ms
Average: 450 / 2 = 225 ms (i.e. 1000/225 = 4.44fps)

So even implementing a frame skip mechanism would only give a tiny 0.5fps speedup.

To take this example to its ultimate conclusion, let's assume that I could somehow eliminate the entire cost of display list parsing and rendering:

CPU emulation: 200 ms
Display list parsing: 0 ms (no cost)
Rendering: 0 ms (no cost)
Total: 200 ms (i.e. 1000/200 = 5fps)

Even if I could somehow (magically) reduce the cost of rendering to 0 milliseconds, we'd still only see a 1fps speedup. However, if I can halve the cost of CPU emulation (which is much more likely given the speedups already seen with the new dynarec engine) this is what the calculations look like:

CPU emulation: 100 ms (now twice as fast)
Display list parsing: 40 ms
Rendering: 10 ms
Total: 100 + 40 + 10 = 150 ms (i.e. 1000/150 = 6.66fps)

At the moment I feel that there are more gains to come from optimising the CPU emulation, which is why I've been concentrating on this area recently. As the cost of CPU emulation falls relative to rendering then the ideas suggested by xiringu and ukcug16 will start to become more attractive.

-StrmnNrmn

link: http://www.strmnnrmn.blogspot.com/

[Mister Chief]

I can't wait.

This emu is making such progress.

[FLai]

Can't you just hard code it to run 1 game? Then we could play mario at a really decent speed and you could concentrate on getting other games working.

[soccerPMN]

Originally Posted by FLai

Can't you just hard code it to run 1 game? Then we could play mario at a really decent speed and you could concentrate on getting other games working.

That would be so... inefficient. If he did it that way, he would literally have to optimize it for every single game, which would make the size of the executable huge IMO. Its better to just do what he's doing, for better compatibility.

[djvu]

if StrmnNrmn can pull his n64 emu off and it works at full speed with most n64 games,i wont really care 2 much about downgrading because n64 games have decent graphics and there between 7-30mb...or i could downgrade with much better graphics and play psp iso's at a download size of 340mb-950mb

now i dont really know about the rest of the world but i cant download that much and get all the iso's i want and not have no complaints with my network (tiscali broadband)

besides if ive figured this out right on the average of a 1mb broadband network....

this is to show how many roms for nintendo 64 you could download before downloading
a psp iso,this also explains the time it takes for 1 iso on a 1mb broadband

n64 rom size on this table is 15mb
psp iso size is 500mb

n64 roms | psp iso's
---------------------------------
1 | 0 (looking for seeds)
2 | (found seeds and starting)
3 | (3% downloaded)
4 | (5% downloaded)
5 | (7% downloaded)
6 | (10% downloaded)
7 | (14% downloaded)
8 | (19% downloaded)
9 | (21% downloaded)
10 | (24% downloaded)
15 | (33% downloaded)
25 | (57% downloaded)
35 | (80% downloaded)
45 | (97% downloaded)
55 | 1 game (finally)

what would you pick over playing 55 n64 roms or 1 iso which has gd grafix???

i dunno about you guys but i'd pick the 55 n64 roms...

::btw the psp iso is an example of a download off sumat like bitlord::