02-08-2012, 02:46 PM
Quote: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.
Create an issue report and figure out what revision this started with.
Quote: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:
Code:
if (_CoreParameter.bLockThreads)
Common::SetCurrentThreadAffinity(1); // Force to first core
to:
Code:
if (_CoreParameter.bLockThreads)
{
Common::SetCurrentThreadAffinity(1); // Force to first core
// I know: Bad Idea, raising Thread priority! So Only do it when Locking Threads
SetThreadPriority("FIFO player thread", THREAD_PRIORITY_HIGHEST);
}
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)
Very interesting. I would not think that increasing the video (fifo player) thread priority would improve performance for most games. Would you mind testing some other games to see if this is only faster for this game or in general?
Quote:Of course, this will fail if Dual-core mode isn't enabled, because the Thread would get another name.
If I'm not mistaken that code should not even run if dual core mode isn't enabled. So it should work fine.
Quote: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.
Yes and no. I think you're getting your terminology mixed up a bit.
Physical cores = physical processors (hardware) on that die that process instructions independently and simultaneously
Hardware threads = frontends for the cores, they act as destinations for the OS to schedule software (logical) threads to. The number of hardware threads represents the number of logical threads that can be run simultaneously at any one time.
Logical cores = A layer of abstraction created by the OS that acts as an interface between hardware threads and software threads.
Virtual cores = "Fake" cores hidden behind a layer of abstraction in a VM.
Logical threads = software threads. The threads that software processes like dolphin.exe spawn. They are streams of instructions that can be assigned an affinity. The affinity is a logical core(s).
Technically it's impossible to map a software thread to a physical core.
For some reason some people seem to think that the core i7 cpus have 4 physical or "real" cores and 4 virtual or "fake" cores. Such people do not understand the terminology properly.
Your cpu has 4 physical cores and 8 hardware threads (2 hardware threads per core instead of 1, that's essentially what HT is). The OS creates 8 virtual cores which applications can assign threads to and the OS manages scheduling between the logical (software threads) of the applications and the hardware threads of the cpu, essentially acting as a middle man to hide all of the super complex hardware level threading stuff from the application programmers so that they don't have to deal with it.
Dolphin has 1-3 major threads depending on your settings and a dozen or so minor threads. Your processor and OS are capable of running 8 threads simultaneously even though you only have 4 physical cores.
In older revisions lock threads to cores would lock the affinity of the major threads to the first available logical core(s), 1, 2, and 3. However we quickly discovered that if you map the two major threads to core 1, and core 2 (keep in mind these are logical cores, sometimes called OS cores) the OS would schedule those two to the first two hardware threads, which were processed by the same physical core. So only one physical core was used even though the OS showed activity being split between two cores (because logical and physical cores are different). By changing the affinity of the second major thread from 2 to 4 we fixed that.
Here, I made this quick drawing (excuse the quality) to show you what I'm talking about:
![[Image: threadstuff.png]](http://i112.photobucket.com/albums/n189/NaturalViolence/threadstuff.png)
Quote: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.
Skid recently made a commit that sped up LLE audio pretty significantly, you should check it out.