Dolphin, the GameCube and Wii emulator - Forums

Weird. FPS is lower but VPS is higher. Which means the cpu thread is running faster. And this behavior is the same with lock threads to cores on and off?

Do you have any programs running in the background? Did you try setting the affinity to just core 1 (not 0)?

(02-05-2012, 09:32 AM)NaturalViolence Wrote: [ -> ]Weird. FPS is lower but VPS is higher. Which means the cpu thread is running faster. And this behavior is the same with lock threads to cores on and off?

Do you have any programs running in the background? Did you try setting the affinity to just core 1 (not 0)?

Hang on, let me check that...

EDIT:
Okay, screenshots (and testing) were done with Lock threads to cores ON.

With Locking OFF, I get this:
Two Cores: 20FPS, 84% speed
Only Core 0: 14FPS, 98-100% speed
Only Core 1: 14FPS, 96-100% speed

I have nothing significant running in the background except for Antivirus and SpeedFan, and now I have Google Chrome running in the background as well. Idle state for my CPU means 0-1% use. Disabling or shutting down my antivirus program (Which could take some processor time) had no effect on this test. I do however have OpenMP enabled, so let me check if that could be it...

OpenMP Off, Thread Locking Off:
Two cores: 20FPS, 84-86% speed. Both core use is 100%
One Core: 14FPS, 98-100% speed. Core with Dolphin is 100%, other core is 5~10%

Edit 2: Just for reference, the Normal FPS of this particular game (RBIP99) is 25.

That still doesn't make any sense.....weird....I cannot reproduce this with any of my games. Perhaps some sort of temperature throttling is occurring when two cores are active? Keep cpuz open in the background and check your clock rates in both scenarios, if that isn't it then I'm officially out of ideas.

(02-05-2012, 01:17 PM)NaturalViolence Wrote: [ -> ]Perhaps some sort of temperature throttling is occurring when two cores are active?

Clock speed stays put at 3.604 GHz...

(02-05-2012, 01:17 PM)NaturalViolence Wrote: [ -> ]if that isn't it then I'm officially out of ideas.

Well, the only thing I can think of right now is that when I use both my cores the CPU thread gets drowned somehow? I do reach 100% speed in the smaller areas (Like inside the house) and when that happens, core 0 is at about 60-70% load, while the other stays at 100%, So I assume the CPU thread runs on core 0 with Locking enabled (please correct me if I'm wrong).

I've tried to set the affinity of every other process which compete for at least 1% of CPU time on my system to just core 1, but that didn't work.

IDK on which core(s) Dolphin locks its other 18 threads, but would this setup do any good (in case this isn't the current situation):
-CPU thread: Lock to core 0, Realtime (or Highest if Realtime would mess up things too much) priority
-GPU thread: Lock to core 1, Normal priority
-OpenMP threads: anywhere but core 0, normal priority
-Other threads: Lock to core 2 (if not available, lock them to 1), normal priority

Essentially dedicating core 0 to the CPU thread, and let other cores handle the rest. If this is a valid setup as opposed to what Dolphin does now, this would be a nice way to implement it IMHO:
[attachment=7339]

Quote:when that happens, core 0 is at about 60-70% load, while the other stays at 100%, So I assume the CPU thread runs on core 0 with Locking enabled (please correct me if I'm wrong).

Let me find the code where the thread affinity is set.

CPU thread:

Video thread:

So the video thread should be running on cpu 0 and the cpu thread on cpu 1 with lock threads to cores. Which makes sense because you said:

Quote:core 0 is at about 60-70% load, while the other stays at 100%,

And the video thread should have a lighter load in most situations.

It shouldn't make any difference but have you tried turning off openMP and turning on openCL?

Quote:-CPU thread: Lock to core 0, Realtime (or Highest if Realtime would mess up things too much) priority
-GPU thread: Lock to core 1, Normal priority
-OpenMP threads: anywhere but core 0, normal priority
-Other threads: Lock to core 2 (if not available, lock them to 1), normal priority

It's a really bad idea to change the thread priorities because that could cause the application to hang.

If you're interested in testing some of this stuff you can find the source code that you need to change here: http://code.google.com/p/dolphin-emu/source/browse/Source/Core/Core/Src/Core.cpp

Line 286 controls the affinity if dual core mode is off and lock threads to cores is on.

Line 315 controls the affinity of the video thread in dual core mode.

Line 342 controls the affinity of the cpu thread in dual core mode for cpus with 3 or less cores.

Line 340 controls the affinity of the cpu thread in dual core mode for cpus with 4 or more cores.

Well, since I got Delphi running on my Laptop after upgrading it to W7 x64 (finally), I'll try Visual Studio on this machine. I have virtually no knowledge of C or C++, but the code from core.cpp kinda looks like Visual Basic actually. I'll try messing around with affinity and priority a bit: I don't mind crashing a lot of test runs.

If I manage to get something worth mentioning, I'll report back here.

B.t.w., thanks for setting me straight (you too StarScream). I tend to switch into know-it-all-mode sometimes...

Quote:I have virtually no knowledge of C or C++, but the code from core.cpp kinda looks like Visual Basic actually.

Quote:during the 15 years I've been building systems, scripting large scaled software operations and developing business class applications...

You write large scale software using visual basic? I'm going to assume you're familiar with other languages/frameworks that you use for that because if you use visual basic for that you're insane.

Just an FYI for you multithreading nuts out there, a commit by skidau last night has significantly improved the DSP LLE on thread option.

http://code.google.com/p/dolphin-emu/source/detail?r=8f83a89416c6e13f23af19c5b329acbd271ef596

Games where I was just barely below 100% speed (e.g. I was at 86%, 75%, etc) are now usually up right around full speed. It seems to have helped significantly. At this point, it's not about mindlessly adding more threads, but making the code/logic more efficient. That has been addressed numerous times in this topic. Dunno why it's so hard for some people to grasp that.

The developers are constantly updating and improving this project, and they're doing an amazing job with it. It's already possible to play many GameCube and Wii games at full speed on faster processors. If that's not a feat in and of itself, then I haven't a clue what is.

(02-06-2012, 09:07 AM)NaturalViolence Wrote: [ -> ]You write large scale software using visual basic? I'm going to assume you're familiar with other languages/frameworks that you use for that because if you use visual basic for that you're insane.

Nope, I usually write everything in Delphi: from simple Database front-ends and small tools to large multi-user packages. But, due to lack of Delphi programmers at my company, they kinda forced me to use Visual Basic and CScript instead (Basically, I'm stuck using access DB's with a huge front end programmed solely in VB. Ugh...), in case I would be incapacitated in any way... Wasn't my call, or I'd have them learn Delphi, or I would have started learning C/C++, which was on my soon-to-do list. For a long time I was just to busy to get in to it, but now I guess is a good time to pick it up.

BTW, the Guide for compiling using Visual Studio 2010 on the main Wiki needs additions. I'll post them later on.

EDIT: Posted the Wiki info on the Wiki page itself as comment. Following the current Wiki results in various errors without these additions.

I also managed to get 100% speed when affinity is set to both my cores, without the frame skipping. Speed still drops to 90-95% sometimes, but compared to the 75-85% it was before it's still an improvement.

In Fifo_Player_Thread() I changed:

to:


Of course, this will fail if Dual-core mode isn't enabled, because the Thread would get another name. I'll fix that later (Personally, I never use single-core mode anyway, and I have no intention to make my builds publicly available ATM). Thus far, I haven't had any stability issues yet, but I haven't really played that much either.

Switching just the affinity code around didn't work. I fact, it caused both threads to "get it on" on my 2nd core, until I opened up task-manager to confirm Dolphin's affinity, which was set to ALL, so I clicked OK and suddenly both my cores were used again (Checked it twice, I probably switched something wrong)

Also, I noticed some texture artifacts (some textures blinking every 10 frames or so) in 3.0-415-dirty which I didn't have in the 3.0-370-dirty Lectrode Build. They also apprear if I download the pre-build from here.

A quick question, does the Lock Threads to Cores option lock to physical cores only? I honestly can't remember, but I've noticed the emulator much slower when the affinity is set to use the virtual threads instead of physical cores.

Semi-offtopic: I hope that eventually the emulator will be as fast as it was around 1000 - 2000 revisions ago and graphical issues that popped up in recent revisions will be fixed. Maybe a pip dream but it would also be nice to see LLE audio become nearly as fast as HLE audio.