PCSX2 for Arch Linux

[josephg]

Hi, link42.

They are not conflicting. It happens that GTK2 is very moody, as it often requires that [extra]/gtk2 be in the same version of [multilib]/lib32-gtk2. See the first line of your error message:

Code:

'pkg-config --modversion gtk+-2.0' returned 2.24.15, but GTK+ (2.24.14)

In order to solve this, the maintainer has to update the lib32-gtk2 to the same version of gtk2. I flagged lib32-gtk2 as out-of-date and now we have to wait. It shouldn't take long.

[link42]

Oh wow so easy.

Thanks for the help josephg, sure beats the couple hours of googling that got me no where .

Regards link42

[pinkeen]

Hello guys.

As my PS2 is gathering dust because I don't have a TV now (and place for it) I decided to check the state of PS2 emulation. And it would be nice not to switch between win and linux all the time just to play some games...

I use Arch Linux x64.
Tried both pcsx2 (1.0) and pcsx2-svn (1.1) from aur.

My hardware:
FX-8350 (8 vishera cores@4GHz)
8 gigs of ram
GTX260

I have installed lib32-nvidia-utils and verified that indeed 32bit opengl apps have hw acceleration.

The problem is:
Menu works perfectly fine in every game but once 3d mode kicks in I get between 20-30fps.

GSdx in software mode works best. Theres no picture in OGL mode - just black screen (but the emulation is running as I can hear sound of intros playing).
Using ZZOgl results in different artifacts on the screen (depends on the game) and it does not improve emulation speed by much (compared to GSdx).

I tried various speed hacks - they don't change a thing. Also tried various games - no luck.
It's quite strange considering my hardware. What's even more strange is that the utilization of any single core doesn't come close to 100%.

I'm no expert, but it seems like a concurrency/synchronization issue. Maybe broken compiler? Maybe the new kernel introduced a problem? Wrong versions of libraries linked?

I'm clueless here.

What's the best way to profile pcsx2 to find the bottleneck? My gut tells me that valgrind is not an option.

[gregory]

The only threading issue is in GSdx SW mode with multiple SW thread. Otherwise PCSX2 only support 2 threads (on linux) so basically 75% of your CPU is useless. Besides AMD fx CPU perform poorly on PCSX2.

PCSX2 is too complex for valgrind (unfortunately). Amd got a profiler tool but I never manage to get it working... => http://developer.amd.com/tools/heterogen...for-linux/

Normally opengl SW must be fine. HW mode was fixed recently for nvidia GPU, but it is far from perfect.

[pinkeen]

The only threading issue is in GSdx SW mode with multiple SW thread. Otherwise PCSX2 only support 2 threads (on linux) so basically 75% of your CPU is useless. Besides AMD fx CPU perform poorly on PCSX2.

I also thought that it might be the CPU. But the thing that's really strange is that no core comes close to 100% utilization. They are <50%. What's more - nothing seems to improve the situation. If it was a HW performance problem then various hacks and changing settings should have an impact I think.

That's the cpu utilization during 3d scene (20fps). No other cpu intensive tasks running. Speed hacks disabled entirely. GSdx with 0 extra rendering threads.

Code:

%Cpu0  : 42.1 us,  1.3 sy,  0.0 ni, 55.5 id,  0.7 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu1  :  1.7 us,  0.0 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 38.9 us,  1.0 sy,  0.0 ni, 60.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.7 us,  0.0 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 26.6 us,  1.0 sy,  0.0 ni, 72.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  1.3 us,  0.0 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  : 50.3 us,  1.0 sy,  0.0 ni, 48.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

PCSX utilizes ~20% of total CPU time spread across 4 cores.

PS What do the percentages in the title bar mean?

--- UPDATE ---
Tested in windows 7:
GSdx in DX9/DX10 mode runs everything I throw at it perfectly. I get > 100fps with frame limiter disabled. (no speedhacks)

When GSdx is switched to software mode it runs slower but if I increase rendering threads to 6 it runs everything at solid 60fps without a hitch.

I don't know what's wrong in linux and I will probably lose a lot of sleep over this.

[DaTankAC]

linux being slow is sadly nothing new. hw mode still has tons of bugs regardless of gpu brand. i too use windows until maybe better drivers are released. for now its just gregory working hard on linux port, but the future looks bright once better gpu drivers are released. i too did an experiment testing extra threads for sw mode in another thread a few months back. i got no speedup either and i dont know why. i wish i knew programming but instead i became an emt and a nurse instead. once linux hw mode is working well enough i can ditch windows. all my other programs and emulators run perfectly in native linux or wine.

[pinkeen]

linux being slow is sadly nothing new.

We need to find the problem. I think that the OGL hardware acceleration support (or lack thereof) is not the main problem.

I did some tests. On windows I get full speed in software mode so it should be the same on linux assuming perfect conditions.

I haven't looked at C++ code for some time and understanding even a tiny bit of such big and complicated codebase would take me weeks. I did a lot of C/C++ few years back so I gave it a shot and briefly examined the GSdx threading code. I found nothing suspicious in the GSdx itself (I don't know how it is used by other components of the emulator). There are barely two locks if I count right and none of them should cause problems. I saw nothing that would prevent it from running on more than one core.

I ran GSdx with incremental thread counts and seen a tiny bit of improvement up to some point where the GSdx ceased to be the bottleneck. I verified by switching to Null video and indeed the emulation speed seems to be topping at ~40fps no matter what.

Oh and GSdx is really running with the selected thread count - I can see them in `top -H`.

Apart from the GSdx (MTGS) threads I can see two EE Core threads and one MTVU thread if MTVU is enabled. Enabling MTVU doesn't seem to improve emulation speed at all.

I narrowed it down to VU1. Switching VU0 to interpreter mode doesn't change the speed at all whereas switching VU1 to interpreter mode lowers the performance drastically (to 1-2fps).

So VU1 seems to be the bottleneck.
Waiting for better OpenGL support won't help in this case.

Dynamic recompilation is way out of my league so I won't even try find the culprit.

Nevertheless we can narrow it down further by answering some questions, specifically:
- Can anybody achieve full speed on linux with similar hardware?
If so - what hardware - AMD/Intel? Which distro, which kernel?

If the core VU1 code does not differ between linux and windows then I suspect the the problem lies within the kernel or userspace libraries. It maybe that this software problem manifests itself on certain hardware (Bulldozer/Vishera) but it is still a software problem. If it wasn't then it would be present on windows too.

PS @Devs: Really great works guys. Being a dev myself I can appreciate the vast amount of work you put into this. Such a feat is a marvell in itself. Keep up the good work.

linux being slow is sadly nothing new.i too did an experiment testing extra threads for sw mode in another thread a few months back. i got no speedup either and i dont know why.

Thats because GSdx seems not to be the bottleneck.

but the future looks bright once better gpu drivers are released

I don't think that it will help, at least not in my case.

i wish i knew programming but instead i became an emt and a nurse instead.

Just an anecdote - as far as I remember Con Colivas is an anaesthetistwith no formal background in programming and he's a kernel hacker (pretty good at that too).

[gregory]

VU0 is barely used on games. VU1 is intensive that why MTVU hack exists. Dynarec is bare X86 (intel optimized), I don't think we got any speed difference between MS/linux. The only impact could be PGO in my opinion.

GSnull isn't fully empty. Do you what is the speed of the emulator on Windows with GSnull? FYI, it is possible to replay GSdx in standalone mode, I can explain it to you if you want to test.

[pinkeen]

GSnull isn't fully empty.

But there should be a difference between GSnull and software? Because I see none.

Do you what is the speed of the emulator on Windows with GSnull?

I'll check and report back.

--- UPDATE ---

On windows I get:
Tested in Tekken 4 in-fight options screen, so the screen remains static so we can have good comparison.
Direct3d 9/10 (Software) (6 threads) - ~90fps
Direct3d 9/10 (Hardware) - ~105fps
Direct3d 9/10 (Null) - ~108fps
Null (Null) - ~110fps
Null (Software) - ~95fps

FYI, it is possible to replay GSdx in standalone mode, I can explain it to you if you want to test.

What do you mean by 'replay GSdx in standalone mode'? I'm eager to try if it will provide any insight.

I'm convinced that the bottleneck is in the VU because I see no difference in performance between GS null, GS software and ZZ OGL.

[gregory]

An heavy ressource consumption is the transfer of data and register access. But yes me too I would expect GSnull to be faster but that not so easy.

GSdx -> CTRL + SHIFT + the key to do snapshot (F7 or F8 don't remember). Keep CTRL pressed. Warning, it will record a big .gs file in snaps ! You can replay the .gs file with the following executable pcsx2_GSReplayLoader (IIRC, build on debug/dev target).
If you don't use XDG path, you need to give it the ini_dir.

Code:

pcsx2_GSReplayLoader ~/.config/pcsx2/inis ~/.config/pcsx2/snaps/gsdx_20120613131350.gs

I'm convinced that the bottleneck is in the VU because I see no difference in performance between GS null, GS software and ZZ OGL.

Did you try several games or only one ?