Why the low framerate?

[neobrain]

(Not sure if NaturalViolence's stuff is correct, I just decided to write an own explanation from scratch)

swap request = the game tells the hardware to display the contents of a picture buffer in RAM to the TV. (more precisely, the Video Interface gets told to read out the contents of an XFB and display it on the TV).

refresh rate = number of swap requests which the game is doing per second on real hardware. I.e. PAL games will use something like 50 Hz and NTSC something like 60 Hz.

VPS = number of swap requests which our emulated CPU is processing per second. If this the same as the refresh rate, our CPU runs at the same speed as real hardware.

FPS = number of frames drawn per second. This is the number of frames which is actually displayed to the screen (note that swap requests come from the CPU, but frame processing is done on the GPU).

For progressive scanning the FPS should equal the VPS (this is a sign that the GPU thread is fast enough to catch up with the swap requests,.i.e. if the CPU runs as fast as on real hardware and FPS = VPS we can say that the GPU runs at least as fast as on real hardware).

For interlaced scanning FPS should be half of VPS. This is because when a swap request only covers the upper framebuffer fields (like every second swap request does when using interlacing), Dolphin is just skipping it. In fact, Dolphin doesn't emulate interlacing at all right now, and instead just uses progressive scanning at half of the target VPS (it basically just processes every second swap request).

EDIT: I just realized that the stuff I said about interlacing is only partially true; in interlacing is where the VBeam hack is involved. If accurate VBeam emulation is disabled, what I said is true. Otherwise VPS equals FPS (we are still using progressive instead of interlaced scanning though).

[jimisrv]

Thanks for the detailed reply NaturalViolence, very interesting indeed. I guess the source of most of these questions was whether or not I needed a CPU upgrade from Phenom II 550 to fix my own slowdown issues. I bought a new GPU - integrated 4250 to 6670, and while things got better, they are still not to great. I actually get similar performance with my laptop laptop which has an i7@2.7 and 330M GPU.

Regarding your points, what would be the optimal way to identify the bottleneck? Would it involve changing the graphics enhancements, which I assume only affect the emulated GPU?

Now regarding this point:

(02-27-2012, 07:03 AM)NaturalViolence Wrote: If the emulated cpu slows down everything will slow down. Meaning if the vps goes down the fps will go down too since the emulated gpu is dependent on the emulated cpu (the emulated cpu produces the commands that the emulated gpu processes). If the emulated gpu slows down you should also see both the vps and fps go down (keeping them in sync) if dolphin emulated the fifo system accurately, but it doesn't so sometimes only the fps goes down (meaning the vps:fps ratio changes).

The video threads dependency on the vps makes perfect sense, I've never seen fps > vps. However, on my system it is often the case that fps < vps, actually more often than not. This maybe could be a side effect of filtering or the multi-threaded reading of these measurements during actual gameplay?

Edit: I found some other nice threads that go into this in much greater detail, often with posts by the two of you. Thanks for the help, as you can tell I'm a pretty big noob who is still trying to understand things. It seems the SNR of quality board posts can be quite low, with all of the "will my PC run dolphin" threads (I'm a hypocrite on this of course).

Edit: I've found some other threads that seem to go pretty in depth, often with answers from the two of you. So thanks, I'm just a noob trying to get the most out of dolphin, while trying to pick up knowledge during the ride.
I'm not sure I really understand the video thread dependency on the GPU? I assume things like AA and AF are calculations performed by the GPU, whereas maybe native resolution is the cpu thread? Also, are you sure that the vps will try to track fps in real-world emulation situations? It seems like a bad design to have this feedback of vps dependent on fps (I'm sure I'm oversimplifying it). Maybe because the cpu thread has to wait until the video thread is done copying a frame before it can write to output?

I guess where I'm trying to go with this is to figure out how to change the settings to identify exactly where your system is weak. The more important question then becomes: would my system run better with a radeon 69xx? Probably, but that money would be better spent on a new CPU. I guess in most cases this is obvious, such as someone with a 2.0 GHz Core Duo, but for me with a 3.2GHz Phenom, it's a little harder to discern if it's worth it to spend $400 on a new CPU + Mobo.

(unrelated side note) I just attached a low profile 30 dollar heatsink from newegg, and lowered my max cpu temp from 65c to 40c. I then unlocked a 3rd core, and upped the multiplier to go from 3.2 to 3.9 GHz. Seems to have done the trick, SMG runs a lot smoother!

---

Thanks to you for the reply.

(02-27-2012, 09:12 AM)neobrain Wrote: FPS = number of frames drawn per second. This is the number of frames which is actually displayed to the screen (note that swap requests come from the CPU, but frame processing is done on the GPU).

So this answers my previous question of the fps dependency on the CPU? The GPU thread must have the CPU move the data from RAM to the GPU? Maybe the CPU also does some of the scaling like internal resolution? I would hope if you have set "lock thread to core", the clock speed of the CPU shouldn't matter much, since this doesn't seem like a demanding task. Maybe it is more architecture dependent than speed dependent?

[NaturalViolence]

Quote:Regarding your points, what would be the optimal way to identify the bottleneck? Would it involve changing the graphics enhancements, which I assume only affect the emulated GPU?

http://forums.dolphin-emu.org/showthread.php?tid=20712

Quote:This maybe could be a side effect of filtering or the multi-threaded reading of these measurements during actual gameplay?

No. The readings are accurate. Both me and neobrain discussed why fps can be less than vps but not the other way around.

Quote:It seems the SNR of quality board posts can be quite low, with all of the "will my PC run dolphin" threads

I like that analogy.

Quote:I'm not sure I really understand the video thread dependency on the GPU? I assume things like AA and AF are calculations performed by the GPU,

Yes.

Quote:whereas maybe native resolution is the cpu thread?

No. That makes no sense.

Quote: Also, are you sure that the vps will try to track fps in real-world emulation situations?

What? I don't understand what you're trying to say here. VPS isn't software, it's a measurement, it can't track fps.

Your sentence is the equivalent of "Are you sure that the kilometers will try to track liters?".

Quote:It seems like a bad design to have this feedback of vps dependent on fps (I'm sure I'm oversimplifying it). Maybe because the cpu thread has to wait until the video thread is done copying a frame before it can write to output?

1. VPS is not always dependent on fps.
2. Dolphin does whatever the game wants it to do. VPS and FPS are usually synced by the game on the real hardware therefore they are synced in dolphin.

Quote:I guess where I'm trying to go with this is to figure out how to change the settings to identify exactly where your system is weak. The more important question then becomes: would my system run better with a radeon 69xx? Probably, but that money would be better spent on a new CPU. I guess in most cases this is obvious, such as someone with a 2.0 GHz Core Duo, but for me with a 3.2GHz Phenom, it's a little harder to discern if it's worth it to spend $400 on a new CPU + Mobo.

Read the link I posted above. It's more important for you to upgrade your cpu.

Quote:So this answers my previous question of the fps dependency on the CPU? The GPU thread must have the CPU move the data from RAM to the GPU?

......what?

1. Please use the terminology "cpu" (referring to your cpu), "cpu thread" (the thread in dolphin that emulates the GC/Wii cpu), and "emulated cpu" (the virtual GC/Wii cpu that dolphin "creates", essentially the same thing as the cpu thread) to differentiate between them.
2. Same thing with the gpu. There is a difference between gpu, video thread (also called fifo player thread), and emulated gpu.
3. Yes the video thread needs to copy data between main memory and video memory, every pc game on the planet needs to do this. This doesn't significantly impact performance except in some games that use a lot of efb copies when using efb copy to ram.

Quote:Maybe the CPU also does some of the scaling like internal resolution?

Scaling and rendering are done on the gpu. Keep in mind internal resolution is not a scale filter, it sets the resolution that the scene is rendered at.

Quote:I would hope if you have set "lock thread to core", the clock speed of the CPU shouldn't matter much, since this doesn't seem like a demanding task.

What doesn't seem like a demanding task? Why would turning on lock threads to cores make cpu clock speed completely irrelevant towards performance? That makes no sense.

Quote: Maybe it is more architecture dependent than speed dependent?

Is what more architecture dependent? What architecture are you talking about (cpu, gpu, etc.)? Architecture affects speed so I have no idea what you're trying to say.

[neobrain]

(02-27-2012, 12:48 PM)jimisrv Wrote:

(02-27-2012, 09:12 AM)neobrain Wrote: FPS = number of frames drawn per second. This is the number of frames which is actually displayed to the screen (note that swap requests come from the CPU, but frame processing is done on the GPU).

So this answers my previous question of the fps dependency on the CPU? The GPU thread must have the CPU move the data from RAM to the GPU? Maybe the CPU also does some of the scaling like internal resolution? I would hope if you have set "lock thread to core", the clock speed of the CPU shouldn't matter much, since this doesn't seem like a demanding task. Maybe it is more architecture dependent than speed dependent?

No. It seems like you think swap requests require the CPU "move the data from RAM to the GPU". This is NOT the case. A swap request basically is just a matter of making the emulated CPU change one of the emulated GPU's registers (that is: change a single byte).
Dolphin's FPS dependency on the CPU comes from the fact that if the emulated CPU only manages to process X swap requests per second, the emulated GPU can only render as many frames per second. In other words, the emulated GPU can only do whatever the emulated CPU has already told it to; however, the emulated GPU can't do something NOW which the emulated CPU is going to tell it in 5 milliseconds.

Note that the CPU dependency doesn't solely come from the CPU thread; the CPU also needs to do quite some work on the GPU thread. That means that a slow CPU will slow down the GPU thread and thus the number of frames which get rendered per frame.

(02-29-2012, 10:30 AM)NaturalViolence Wrote: video thread (also called fifo player thread)

No, the fifo player thread is something completely unrelated. When running games in Dolphin, fifo player isn't involved at all. There only is a fifo player thread when you chose to play back a previously recorded fifo player file. In this case, the fifo player thread replaces the CPU thread.

(02-29-2012, 10:30 AM)NaturalViolence Wrote: 3. Yes the video thread needs to copy data between main memory and video memory, every pc game on the planet needs to do this. This doesn't significantly impact performance except in some games that use a lot of efb copies when using efb copy to ram.

Heh, you couldn't be more wrong with that one. RAM->VRAM transfers are one of the main sources of slow GPU thread performance. Remember, ALL kind of data that can be pushed to the GPU (vertex data, textures, display lists, ...) are stored in the emulated RAM and can be changed whenever the CPU feels like doing so. There's no way we could easily find out when they change, so we need to re-upload them to VRAM each time they're used. For textures we can get away with only updating them every now and then, but for vertex data we don't even try to cache anything.
Funnily enough, the Wii also uploads all of this data to the GPU whenever it's requested; this shows how ridiculously faster the Wii's RAM->GPU bandwidth is compared to conventional PC hardware.

[NaturalViolence]

Quote:this shows how ridiculously faster the Wii's RAM->GPU bandwidth is compared to conventional PC hardware.

2.7 GB/s is fast?

[neobrain]

Fast enough to make stuff work fast

I doubt it's the raw bandwidth that counts here, but otoh I don't really know why the Wii can do stuff that fast.

[NaturalViolence]

Bandwidth is awful compared to a modern desktop PC. But latencies for GC/Wii mem are way better (usually 1 cycle) than DDR3, GDDR3, or GDDR5 memory.

But considering framebuffers and vertex buffers are very large data structures you would think that would be totally bandwidth dependent.