Dolphin, the GameCube and Wii emulator - Forums

i7-4790k 4.2Ghz
gtx 980 1.4Ghz
16GB@1866MHz
Win7pro

This is to say, there are times I will start a game and everything will be fine, but somewhere during the same emulation I will get slowdown in places I don't normally. So I would check this by holding tab, and I will see in Task Manager that dolphin is only using about 17% CPU(2 threads, hyperthreading). During those times when I don't see slowdown, turbo will show the full 25%(2 of 8). I could not find a pattern for this, only guesses.

Issue with hyperthreading?
Windows instruction assignment(everything I have set to use all threads)?
Load imbalance between CPU and GPU thread(Not sure on this one, I will be in the same areas in games with and without the chop)

I have been using 4.0-8057 due to it being the actual last one I could find without the 'memory stride too small' issue in Metroid Prime, but I see the issue in at least one newer version also(8258). I am also using OpenGL due to the fact that D3D prevents some objects from being scanned in Metroid Prime 2. The issue does not appear to occur under D3D at all. It remains that under OpenGL the issue is not constant; there are times it doesn't occur but when it does it's in basically the same circumstances that were noted to cause slowdown for everyone(accessing the map, splashing water on one's face, certain rooms). In these instances the CPU usage does increase a LOT still, but it is sometimes allowed to go up to 100% of 2 threads, sometimes not and is limited to about 2/3 of that.

Any ideas to correct or even confirmed observation of this for others, I would be thankful. Really is amazing what has been achieved so far with this program.

https://dolphin-emu.org/docs/faq/#couldn...-go-faster

Dolphin FAQ Wrote:Couldn't Dolphin use more of my CPU cores to go faster?

CPUs do not work that way.

Every core on a CPU runs in parallel. Two tasks can run very well in parallel if they don't need to communicate often or to run at the exact same speed. For example, compressing files can be run on separate cores because compressing one file and compressing another file are two completely independent tasks, which do not need to communicate.

In Dolphin, the only demanding tasks that can run well in parallel are the CPU, the GPU and the DSP. Breaking up any of these tasks into smaller tasks just to run it on more cores is very likely to make the program slower. That's why Dolphin only runs on 3 cores and won't use all of your 4 or 6 cores CPU.

I should rename myself to "FAQbot". ^ᴗ^

So yeah people say I'm too wordy sometimes. I get that. But nowhere in there did I say I wanted to use more than 2 threads. Just all of those 2. And I am trying to figure out why it sometimes refuses to by including as much context as I could that I believed was relevant.

At least you didn't yell at me.

Well… Dolphin will only use as much CPU time as it's needed. If it doesn't need to use 100% for both threads, it won't. And it's rare that both threads are maxed out. Instead, what you are describing seems to be stuttering caused by shader compilation.

um. no.

https://www.youtube.com/watch?v=YQ6lk0-rgdM

Any chop in the video at 100%, ignore, that's the recorder. Just look at the numbers upper-left. Shoulda did this first I guess. Also, don't pay too much mind to the opengl vs. directx thing. As I said, there are points where even under opengl it will run to full potential, just as under direct3d. But I don't have a ton of time right now to try over and over until it works correctly. But clearly at less than 100% VPS, it needs to use more, and doesn't. Except when it does. And yes there are more areas besides the map(though this was stated to be resolved). It's just the one I picked.

If the CPU is waiting on the GPU thread, the CPU thread will stall. If the GPU thread is waiting on the CPU thread, the GPU thread will stall. And the GPU thread can also be waiting on the GPU itself, in which case it -- and perhaps the CPU thread too -- can also stall.

Dolphin always uses as much of your CPU as it can. If it's going slow, there may be a good reason, but there's no magical way to "make it use more of your CPU to go faster"; one has to actually find the real thing making it slow and fix it. The emulator can only go as fast as its slowest component.

Yes, got it. So I postulated it was possibly one of the CPU or GPU thread going slowly, maybe related to OpenGL, maybe not. I don't have more accurate ways of telling than what I've shown already. Or maybe hyperthreading or how windows assigns instructions, aka something on my end. But that it only does it sometimes is curious. fwiw, gpu usage is constant and has headroom, at least so say gpu-z. I get that may or may not mean much. Was hoping this was something widely observed. To help find the issue and maybe learn something at the same time. I haven't changed anything yet, like disabling HT, thread pinning, etc. Wanted to check here first. If I notice a change with one of those I'll mention it.

Given it's Metroid and it goes slow when you pull up the map, I'm going to guess it's EFB2RAM.

If you're getting full speed or near full speed then why do you care whether or not it utilize full core/threads?

Because of the points where I don't. Plainly stated above. In fact if this happened all the time(slowdown+underutilization), I wouldn't even have posted anything, assuming it was normal. But there's some variable here.