07-22-2009, 10:27 AM (This post was last modified: 07-22-2009, 10:28 AM by refraction.)
actually 1545 is more correct. If you look at the graphcs, the emulator itself is running on the left hand graph (core 0), so its using as much as it can to get the most speed it can, this will always be 100% optimally. the right hand graph (core 1) is only GSDX (as you are using MTGS). If you look at the top of the GSDX window, it says its using 12% of the cpu, which looks to be accurately reflected within your task manager. The older one however is hovering around 50-70% on both cores, which is obviously completely incorrect.
Your CPU usage total is the same in both pictures. 57% and 58% respectively. Your GSDX performance readouts are the same. Your avg fps are the same. The only thing that differs is the dispersal pattern across the two cores. This could affect the temperature of your cores, but means nothing for performance.
The truth is: the bug in cpudetect never affected dual core machines in any negative way. It only affected cpus with more than 2 cores, typically by disabling core 3 (which meant there were still 3 cores for use, and since PCSX2 only uses 2 cores it still didn't acctually result in any performance lost). You do not have a core 3 to be disabled, so it shouldn't have mattered.
What's more likely happening is that changing thread affinity is "turning off" some kind of load balancing mechanism that's built into your copy of XP. An operating system has the ability to load-balance across multiple cores in order to reduce overall heat generation, and for some odd reason the new cpudetect "fools" it and turns that feature off. The odd part is that most of the time I've not seen that sort of load balancing happening for myself or our other users. As Refraction points out, your unmodded graph is more in line with what the rest of us are used to seeing since forever. The fact that your machine has been auto-balancing the load across both CPUs at all is the unusual thing in this report.
Still, technically speaking load balancing is better since it does reduce heat gen and has no negative impact in performance. I'm really not sure of a way to fix that off-hand though. I have a hunch that the problem will get magically solved by the new wxgui branch I'm working on, since it will run the GUI in its own thread which will isolate the cpudetect's modification of thread affinity away from the emulator core. That should leave load balancing features for your computer intact on the threads that matter.
Performance not a matter between "1368/1502 vs 1367",
but "heat" is more, power consume is more after more heat product.
On my E8400@3.6G (33~34C in room)
core0 100% is 51C,
core1 < 20% is 44C.
svn 1549 + 1367 MOD
(07-22-2009, 11:02 AM)Air Wrote: Still, technically speaking load balancing is better since it does reduce heat gen and has no negative impact in performance. I'm really not sure of a way to fix that off-hand though. I have a hunch that the problem will get magically solved by the new wxgui branch I'm working on, since it will run the GUI in its own thread which will isolate the cpudetect's modification of thread affinity away from the emulator core. That should leave load balancing features for your computer intact on the threads that matter.
My odd findings in the subject:
I treid different pcsx2 versions (vsync always off.)
0.9.6 - even, balanced core usage, core0 is not constatntly at 100%, the line is dynamic, colse to the top.
r1474 & r1614 & r1640 (saem for the three) - After the emultaion has started, core0 is constantly on 100%. Means it is a completeley straight line adhered to the top.
BUT. Then I change pcsx2.exe's affinity to only the second core, core0 turned off. Performance naturally drops in pcsx2. Then I enable core0 once again, and what happens ? Afther that it acts exactly as it did in 0.9.6. dynamic line CLOSE to the top. Performance in pcsx2 is exactly same as before (judged both objectively and subjectively), when the cpu usage was constant 100%.
So what the hell ? That definately a bug. Unnecessarily constant 100%, for no reason really.