pcsx2-x64 will not build on linux

[Shoegzer]

As of commit 56f2d307bcbb53e71362833aa82daf917e2177f5, pcsx2 x64 build will not compile on linux. The cmake log complains about missing dependencies, notably:

-- Skip build of pcsx2 core: missing dependencies:check these libraries -> wxWidgets (>=3.0), gtk2, zlib (>=1.2.4), pcsx2 common libs

However as the compile log shows, wxwidgets and zlib deps are found (and the reference to "pcsx2 common libs" is too vague to tell what's needed).

Note that removing the -DwxWidgets_CONFIG_EXECUTABLE=/usr/lib/x86_64-linux-gnu/wx/config/gtk3-unicode-3.0 from cmake doesn't have any positive impact.

System is linux mint 20 x64, kernel 5.4 and gcc 9.3.0

@beaumanvienna Hoping you might have some ideas to offer here? Thanks.

[beaumanvienna]

Comment out line 300 in common/src/x86emitter/cpudetect.cpp //if ((xgetbv(0) & 6) == 6)

For Ubuntu 20.04 / Mint 20

sudo apt install cmake debhelper dpkg-dev libaio-dev libasound2-dev libgl1-mesa-dev libglu1-mesa-dev liblzma-dev libpcap0.8-dev libpng-dev libpulse-dev libsdl2-dev libsoundtouch-dev libwxbase3.0-dev libwxgtk3.0-gtk3-dev libgtk-3-dev libxml2-dev libx11-dev locales portaudio19-dev zlib1g-dev libudev-dev git build-essential libx11-xcb-dev

Somehow, -DCMAKE_BUILD_TYPE=Release didn't work for me on Mint 20. A release version would be faster. W/o the Release option the app has debug code that is slowing it down. It worked on Arch. though. Not sure what the difference is.

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DXDG_STD=TRUE -DGTK3_API=TRUE   -DDISABLE_ADVANCE_SIMD=TRUE \
-DPACKAGE_MODE=TRUE -DGSDX_LEGACY=TRUE ..
make -j8
cp plugins/dev9ghzdrk/libdev9ghzdrk-0.4.so plugins/FWnull/libFWnull-0.7.0.so plugins/dev9null/libdev9null-0.5.0.so plugins/onepad/libonepad.so plugins/spu2-x/src/libspu2x-2.0.0.so plugins/CDVDnull/libCDVDnull.so plugins/cdvdGigaherz/src/libcdvdGigaherz.so plugins/GSdx/libGSdx-SSE4.so plugins/GSdx/libGSdx-AVX2.so plugins/GSdx/libGSdx.so plugins/USBnull/libUSBnull-0.7.0.so plugins/onepad_legacy/libonepad-legacy.so plugins/
mv ~/.config/PCSX2 ~/.config/PCSX2-backup
./pcsx2/PCSX2

For Arch, Ubuntu 18.04, Elementary OS 5.1

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DXDG_STD=TRUE -DDISABLE_ADVANCE_SIMD=TRUE \
-DPACKAGE_MODE=TRUE -DGSDX_LEGACY=TRUE ..
make -j8
cp plugins/dev9ghzdrk/libdev9ghzdrk-0.4.so plugins/FWnull/libFWnull-0.7.0.so plugins/dev9null/libdev9null-0.5.0.so plugins/onepad/libonepad.so plugins/spu2-x/src/libspu2x-2.0.0.so plugins/CDVDnull/libCDVDnull.so plugins/cdvdGigaherz/src/libcdvdGigaherz.so plugins/GSdx/libGSdx-SSE4.so plugins/GSdx/libGSdx-AVX2.so plugins/GSdx/libGSdx.so plugins/USBnull/libUSBnull-0.7.0.so plugins/onepad_legacy/libonepad-legacy.so plugins/
mv ~/.config/PCSX2 ~/.config/PCSX2-backup
./pcsx2/PCSX2

[beaumanvienna]

Comment out line 300 in common/src/x86emitter/cpudetect.cpp //if ((xgetbv(0) & 6) == 6)

[Shoegzer]

@beaumanvienna Thanks. I missed your note about hand-editing cpudetect.cpp initially (why is that needed?) but after doing that the compile works fine. I have Mint 20 and was able to get PCSX2 to compile and run with -DCMAKE_BUILD_TYPE=Release, perhaps it's something with your install? Also what is DPACKAGE_MODE=TRUE and why is that not needed for Mint 20?

[beaumanvienna]

ok, that's good. Is it actually working for you on Mint?

BTW, Tellow just created an PR to fix this
https://github.com/PCSX2/pcsx2/pull/3650

[Shoegzer]

Yes, it launches at least. Haven't tried running a game yet.

[beaumanvienna]

go ahead try it

[beaumanvienna]

If you look at the debug window, do you get

x86 Features Detected:
    SSE2.. SSE3.. SSSE3.. SSE4.1.. SSE4.2.. AVX.. AVX2.. FMA
    Pcsx2 was compiled as 64-bits.

?
I do get it under Arch, but not under Mint...

[Shoegzer]

Thanks and I will soon, got pulled away for something else. Also what are -DCMAKE_BUILD_STRIP=FALSE and DPACKAGE_MODE=TRUE and are they needed for Mint?

[beaumanvienna]

-DCMAKE_BUILD_STRIP=FALSE means the -s option for gcc is omitted. The app will keep it's debug symbols. It helps to evaluate stack traces. Might affect performance.

PACKACKE_MODE=TRUE has to do with default settings.

[Shoegzer]

Thanks. Do you mean to say that setting -DCMAKE_BUILD_STRIP=FALSE could negatively impact performance, or the other way around? Also are you saying DPACKAGE_MODE=TRUE isn't needed because it's true by default? Trying to understand whether I should use that for Mint.

[beaumanvienna]

Yes, negatively. The debug symbols might slow it down. Package mode is about safe user settings. Just check the options, which speed hacks you want, etc. and you should be good. Can't hurt to set this option.

There is one new feature, not sure if you have seen it. Under file you can check "fast boot" and it will skip the Bios. I like it. If you confirm that your Mint 20 build works, we can close this issue.

[beaumanvienna]

It works for me under Mint 20. Stupid me had cloned the wrong repository. All good. I'd say the x64 PRs are pulled in successfully.

[guoyunhe]

Is here any performance impact with -DDISABLE_ADVANCE_SIMD=TRUE? What does it do?

[beaumanvienna]

Is here any performance impact with -DDISABLE_ADVANCE_SIMD=TRUE? What does it do?

I believe there is. I did a bunch of different tests here: https://github.com/PCSX2/pcsx2/pull/3451#issuecomment-670322977

Compare case 4 and case 6

@gregory38 Greg can explain what this option is doing and why we're using it in the Debian package built

[gregory38]

This option allows only sse2 instructions. Everything modern is disabled. Besides it compiles gsdx 3 times (sse2/sse4.1/avx2). Nice for old CPU, not nice for anything modern (10y old CPU but phenom2).8

[guoyunhe]

Then we cannot use it... I can build it locally on my i5-8550u laptop. But fail to build on build farm nodes (I don't know their instruction set).

[gregory38]

I don't understand why can't you use it ? Never have any issue with it.

[guoyunhe]

Maybe I got it wrong. If set -DDISABLE_ADVANCE_SIMD=TRUE, performance on modern CPU will be better or worse?

[gregory38]

Worst as you limit yourself to sse2.

[Shoegzer]

Okay it compiles and runs well now. Fantastic job x64 team, compiling is finally a breeze on modern linux, and performance seems comparable if not slightly better than x86.

I'm happy to close this out, but a few observations/questions first:

1. Getting back to your question @beaumanvienna: Yes, I do get the "x86 Features Detected" message in the console exactly as you posted, though from your follow-up I assume you've since observed the same in Mint 20.

2. Can someone suggest a set of ideal cmake options for normal (release-based) use with a modern cpu (i7-7820HK in this case)? Right now compiling with:

   -DCMAKE_BUILD_TYPE=Release
   -DGTK3_API=TRUE 
   -DPACKAGE_MODE=TRUE
   -DXDG_STD=TRUE
   

3. What is -DGSDX_LEGACY=TRUE? Specifying that causes cmake to indicate that it's not used in the project.

4. What is -DXDG_STD=TRUE?

5. As you said @gregory38, without -DDISABLE_ADVANCE_SIMD=TRUE you only get a "libGSdx.so" without separate AVX2 and SSE4 plugins. Should I assume that libGSDx.so has the AVX2/SSE4 features included? Incidentally the plugin reports itself as GSdx 64-bit (GCC 9.3.0 AVX/AVX) 1.2.0 [libGSdx] in the pcsx2 UI (shouldn't that read AVX/AVX2?)

6. I noticed there's no way to save changes to the SPU2 plugin settings as there's no "OK" button in the UI. I'm guessing that's unrelated to the x64 build, and if so, should I open a new issue for it or is this known?

[RedDevilus]

1. It got purged recently with 1.7 dev 162 (https://github.com/PCSX2/pcsx2/pull/3611) which is basically 1.4.0 plugins it wasn't used much to begin with.

[lightningterror]

I noticed there's no way to save changes to the SPU2 plugin settings as there's no "OK" button in the UI. I'm guessing that's unrelated to the x64 build, and if so, should I open a new issue for it or is this known?

@arcum42 Can you take a look at it?

[arcum42]

Closing the dialog for spu2-x saves the changes automatically.

[Shoegzer]

You're right @arcum42. It wasn't doing this for me when I tested earlier for some reason but now it is. I have no explanation. Still would be nice to have the "Apply | Cancel | OK" buttons so it's more intuitive and consistent with the other plugins, but I'll take it.

[Shoegzer]

Update: Actually @arcum42, the SPU2 changes appear to be saved but when pcsx2 is closed and restarted, they aren't. All other plugin settings are saved.

[dener3id]

As of commit 56f2d30, pcsx2 x64 build will not compile on linux. The cmake log complains about missing dependencies, notably:

-- Skip build of pcsx2 core: missing dependencies:check these libraries -> wxWidgets (>=3.0), gtk2, zlib (>=1.2.4), pcsx2 common libs

However as the compile log shows, wxwidgets and zlib deps are found (and the reference to "pcsx2 common libs" is too vague to tell what's needed).

Note that removing the -DwxWidgets_CONFIG_EXECUTABLE=/usr/lib/x86_64-linux-gnu/wx/config/gtk3-unicode-3.0 from cmake doesn't have any positive impact.

System is linux mint 20 x64, kernel 5.4 and gcc 9.3.0

@beaumanvienna Hoping you might have some ideas to offer here? Thanks.

anyone build 32 bit? I couldn't ether.

[beaumanvienna]

@dener3id https://launchpad.net/~pcsx2-team/+archive/ubuntu/pcsx2-daily

[arcum42]

Update: Actually @arcum42, the SPU2 changes _appear_ to be saved but when pcsx2 is closed and restarted, they aren't. All other plugin settings are saved.
Yeah, did some testing and it's three settings I saw in spu2-x that aren't being saved. The others are, unless I missed something. The config's a bit convoluted, unfortunately. I've fixed two of them locally, and am still working on the third, though that'll probably be more like next weekend's project...

[mrdeathjr28]

@dener3id https://launchpad.net/~pcsx2-team/+archive/ubuntu/pcsx2-daily

still show 32bit builds only

[Shoegzer]

Thanks @arcum42. Interesting that it saves select settings. I'm guessing "Audio Expansion Mode" is one of the three you mention as that's the one I found. Happy to know it's not just on my end at least.

[Shoegzer]

Getting back to my post above regarding cmake options before I close this issue. I've put together some notes based on the helpful list @beaumanvienna provided in his first post above and thoughts others have shared, would appreciate any changes or additions that might help document a solid and well-understood list for release purposes.

• -DCMAKE_BUILD_STRIP=FALSE: Helpful for debugging/stack trace analysis but not recommended for release builds for performance reasons

• -DCMAKE_BUILD_TYPE=Release: Recommended for release builds as name implies

• -DDISABLE_ADVANCE_SIMD=TRUE: Builds three separate gsdx plugins (SSE2, SSE4.1 and AVX2). Compiling without this option builds a single "libGSdx.so" plugin which includes support for AVX2 etc. built in, and is therefore recommended for modern processors.

• -DGSDX_LEGACY=TRUE: No longer used or needed

• -DGTK3_API=TRUE: Needed for experimental GTK3 support as pcsx2 defaults to GTK2 (I've noticed cases of the UI hanging if certain options such as speedhacks are changed ingame, not sure if this can be traced to the "experimental" status or not).

• -DPACKAGE_MODE=TRUE: Uses "safe" default settings and is recommended for release builds

• -DXDG_STD=TRUE: Not sure what this does, can someone explain?

Any other options I'm missing that might be useful to support a release build on a modern proc/gpu for normal use-cases?

[arcum42]

Thanks @arcum42. Interesting that it saves select settings. I'm guessing "Audio Expansion Mode" is one of the three you mention as that's the one I found. Happy to know it's not just on my end at least.
Yeah, that's one of the two I already fixed locally. What happened with that one is that that option was just completely missing from the gtk version of the dialog box, so I added it, but forgot that it needed to be added to the ini code as well. With the other ones, the wrong variables were being set, and one of them isn't cooperating with me. Those settings are usually ones you want kept on the default anyways, though.

XDG_STD switches around what paths pcsx2 uses. It says "Use XDG standard path instead of the standard PCSX2 path".
Main place it changes anything is here:

    // Fetches the path location for user-consumable documents -- stuff users are likely to want to
    // share with other programs: screenshots, memory cards, and savestates.
    wxDirName GetDocuments( DocsModeType mode )
    {
        switch( mode )
        {
#ifdef XDG_STD
            // Move all user data file into central configuration directory (XDG_CONFIG_DIR)
            case DocsFolder_User:   return GetUserLocalDataDir();
#else
            case DocsFolder_User:   return (wxDirName)Path::Combine( wxStandardPaths::Get().GetDocumentsDir(), pxGetAppName() );
#endif
            case DocsFolder_Custom: return CustomDocumentsFolder;

            jNO_DEFAULT
        }

        return wxDirName();
    }

If you look at build.sh, most of the main options are in there as arguments that can be passed...

[Shoegzer]

Yeah, that's one of the two I already fixed locally. What happened with that one is that that option was just completely missing from the gtk version of the dialog box, so I added it, but forgot that it needed to be added to the ini code as well. With the other ones, the wrong variables were being set, and one of them isn't cooperating with me. Those settings are usually ones you want kept on the default anyways, though.

Thanks, that makes sense. And yes most of those options are typically fine to leave as default.

XDG_STD switches around what paths pcsx2 uses. It says "Use XDG standard path instead of the standard PCSX2 path".

Interesting and a handy option, I'll continue to use and recommend it. Regarding directories is there any chance the gamedb file location could be made user-configurable as well? I'm currently assuming pcsx2 is hard-coded to look for it in /usr/local/share/games/PCSX2.

If you look at build.sh, most of the main options are in there as arguments that can be passed...

Ah yes I see that now, thanks! I'll do some tinkering.

[arcum42]

@Shoegzer Yeah, the particular ones that are broken are the subpulldowns of sdl and portaudio, and the chances of not wanting to use the top item are low.

If you look over at:
https://github.com/PCSX2/pcsx2/blob/master/cmake/BuildParameters.cmake

It has a note at the top suggesting hardcoding it, but line 17 tells you what to set to change it.

And no problem. I usually build with build.sh when developing, honestly.

[Shoegzer]

@Shoegzer Yeah, the particular ones that are broken are the subpulldowns of sdl and portaudio, and the chances of not wanting to use the top item are low.

Agreed, I've always used sdl and it's been fine by me.

It has a note at the top suggesting hardcoding it, but line 17 tells you what to set to change it.

Oh gosh I hope that changes. Ideally imo all directories could be user-configurable via UI, or at least in a runtime config file. Having options for most but not all dirs seems a bit inconsistent - for example if bios and plugins can be set to ~/.config/PCSX2, why not gamedb? There are also uncommon use cases such as portable installs where you wouldn't want anything hardcoded to a system dir. In the case of the gamedb at least a more technical user can change the cmake build params if/when they compile, kindof a pain but at least the option exists. Thanks for pointing that out!

Update: I just tested your SPU2 config fix @arcum42, works great! Changes to the audio expansion mode now survive a restart. Let me know if you'd like me to test anything else. Thanks again.

[arcum42]

@Shoegzer Yeah, I was the one who pushed to have it default to sdl instead of portaudio, since portaudio really didn't seem like it was working as well.

Glad the fix is working for you. When I looked back at the one I was having trouble with, I figured out that searching wxStrings didn't work quite the way I'd assumed, so I was able to get that squared away.

No real strong feelings one way or the other on being able to move gamedb, but I'm generally in favor of more configuration, and given the paths are all highly using wx, I suspect that code will be rewritten at some point...

[Shoegzer]

@arcum42 Glad you were able to find the other spu2 outlier, sounds like it's in pretty good shape now thanks to your efforts.

WIth that, I'm closing this as the original issue has been resolved and related threads addressed. Hopefully any useful bits not covered in other places can be documented in the pcsx2-wiki (and I'm happy to help if needed).