Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
After svn 1367, only 1 core running.....
#1
Hi all,

svn 1367, all core running smooth.

svn 1368, change to 1 core to detect rdtsc counter.
from this building, running FFX will only using 1 core. (usually is Core0 100%, Core1 < 5%)

svn 1502, attempt to fix 1368 bug.
but not fixed at all.
FFX, FF12 running Core0 is 100%, Core1 < 15%

/trunk/pcsx2/x86/ix86_cpudetect.cpp has still need to fix.

svn 1367's ix86_cpudetect.cpp is correct using all core.
FFX, FF12 --> Core0 about 50~70%, Core1 about 50~70%
Reply

Sponsored links

#2
[Image: 3745651892_5ede89785b_o.jpg]



MOD => replace "ix86_cpudetect.cpp" from svn 1549 to svn 1367
[Image: 3744855211_5154eecd01_o.jpg]
Reply
#3
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.
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#4
thank reply.

but I don't understand if push Core0 to limit will actually speed-up?

i mean, 3.6G single core FPS > 3.0G dual core FPS??
Reply
#5
Turn off frame limiter and see if it's giving you any speed difference between the 2 Tongue

Both look like using about the same cpu% so there shouldnt be a difference in speed at all.
Core i5 3570k -- Geforce GTX 670  --  Windows 7 x64
Reply
#6
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. Smile

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.
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply
#7
Oh! Something else also occurred to me after reading Shadow Lady's response:

If you've enabled v-sync in GSdx, this could also cause the load balancing effect to be lost.
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply
#8
thanks reply.

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)
svn 1549
core0 100% is 51C,
core1 < 20% is 44C.

svn 1549 + 1367 MOD
both 44~46C

(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.

That's great news.

I can't wait wxgui on trunk.....Tongue



thanks all.
Reply
#9
(07-22-2009, 11:20 AM)Air Wrote: Oh! Something else also occurred to me after reading Shadow Lady's response:

If you've enabled v-sync in GSdx, this could also cause the load balancing effect to be lost.

even with vsync off it goes 100/13 or so on faster pcs (let's face it, mine's ALWAYS at 100/100) it's been happening since about 1480, that's what I've checked so far

here's 2 pics from svr09, r1607, still not fixed. and task manager lies


(settings for confirm were badly hacked, byt no vsync involved, I just pushed it VERY ugly)

gsdx
Code:
[Settings]
ModeWidth=0
ModeHeight=0
ModeRefreshRate=0
Renderer=3
PixelShaderVersion2=-65024
Interlace=0
AspectRatio=1
filter=2
vsync=0
logz=0
fba=1
aa1=0
blur=0
nativeres=0
resx=256
resy=256
swthreads=1
windowed=1
paltex=0

pcsx2
Code:
[Cpu]
Options=1137
sseMXCSR=65472
sseVUMXCSR=65472
eeOptions=1
vuOptions=1
SpeedHacks=9
VUCycleHack=1
[Hacks]
EECycleRate=1
IOPCycleDouble=enabled
WaitCycleExt=disabled
INTCSTATSlow=disabled
VUCycleSteal=2
IdleLoopFF=disabled
ESCExits=disabled
vuFlagHack1=disabled
vuFlagHack2=disabled
vuMinMax=disabled
vuFlagHack=disabled


Attached Files Thumbnail(s)
       
Reply
#10
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.
Reply




Users browsing this thread: 1 Guest(s)