Areas of interest for new linux developers
#11
Nice. Could you also test gcc 4.9. Don't you have any crash when running?

Could you compare stripped binary? I'm surprise on the size reduction (-DCMAKE_BUILD_STRIP=TRUE)
Reply

Sponsored links

#12
I didn't try gcc 4.9 yet.

Depending on optimizations parameters given, I encounter build errors, or crashs sometimes.

Here are raw conclusions :

On my computer, enabling LTO increase building time from 1m30 to 2m. Size of executable depends on how you pass lto parameters to the compiler. By example, build only pcsx2 with LTO give it a size of 30 mbs, but building whole system (including plugins and tools) reduce pcsx2 size to 12 mbs.

FPS on Ratchet and Clank menu :
On vanilla pcsx2-dev (GSdx - PS2 native resolution)
17-18 fps

On LTO pcsx2-dev executable only
17-18 fps

On LTO GSdx plugin only
17-18 fps

On LTO for whole program
15-16 fps

That's to early for give final conclusions yet, i'll make more tests.
Reply
#13
If you remove symbol, build is much more smaller, around 8MB. I will add an option to strip the binary on the build.sh.

Code:
du -s ./bin/pcsx2-dev ./bin/plugins/*
5.2M    ./bin/pcsx2-dev
8.0K    ./bin/plugins/libCDVDnull.so
16K    ./bin/plugins/libdev9null-0.5.0.so
16K    ./bin/plugins/libFWnull-0.7.0.so
1.4M    ./bin/plugins/libGSdx-0.1.16.so
72K    ./bin/plugins/libonepad-1.1.0.so
504K    ./bin/plugins/libspu2x-2.0.0.so
16K    ./bin/plugins/libUSBnull-0.7.0.so
792K    ./bin/plugins/libzzogl-0.4.0.so
112K    ./bin/plugins/ps2hw.dat
Reply
#14
So, I have updated gcc to 4.9. It broke full LTO build, and results on linker errors... Broken modules are : spu2x and x86emitter.

But, here are some tests on files sizes :

non LTO non stripped
Code:
38M        ./bin/pcsx2-dev
32K        ./bin/plugins/libCDVDnull.so
112K    ./bin/plugins/libdev9null-0.5.0.so
116K    ./bin/plugins/libFWnull-0.7.0.so
19M        ./bin/plugins/libGSdx-0.1.16.so
668K    ./bin/plugins/libonepad-1.1.0.so
3,0M    ./bin/plugins/libspu2x-2.0.0.so
116K    ./bin/plugins/libUSBnull-0.7.0.so
5,6M    ./bin/plugins/libzzogl-0.4.0.so
112K    ./bin/plugins/ps2hw.dat

non LTO stripped
Code:
du -s -h ./bin/pcsx2-dev ./bin/plugins/*
5,2M    ./bin/pcsx2-dev
12K        ./bin/plugins/libCDVDnull.so
20K        ./bin/plugins/libdev9null-0.5.0.so
20K        ./bin/plugins/libFWnull-0.7.0.so
1,4M    ./bin/plugins/libGSdx-0.1.16.so
76K        ./bin/plugins/libonepad-1.1.0.so
500K    ./bin/plugins/libspu2x-2.0.0.so
20K        ./bin/plugins/libUSBnull-0.7.0.so
780K    ./bin/plugins/libzzogl-0.4.0.so
112K    ./bin/plugins/ps2hw.dat

exec LTO non stripped
Code:
du -s -h ./bin/pcsx2-dev ./bin/plugins/*
15M        ./bin/pcsx2-dev
32K        ./bin/plugins/libCDVDnull.so
112K    ./bin/plugins/libdev9null-0.5.0.so
116K    ./bin/plugins/libFWnull-0.7.0.so
19M        ./bin/plugins/libGSdx-0.1.16.so
668K    ./bin/plugins/libonepad-1.1.0.so
3,0M    ./bin/plugins/libspu2x-2.0.0.so
116K    ./bin/plugins/libUSBnull-0.7.0.so
5,6M    ./bin/plugins/libzzogl-0.4.0.so
112K    ./bin/plugins/ps2hw.dat

exec + plugins LTO non stripped
Code:
du -s -h ./bin/pcsx2-dev ./bin/plugins/*
15M        ./bin/pcsx2-dev
24K        ./bin/plugins/libCDVDnull.so
64K        ./bin/plugins/libdev9null-0.5.0.so
64K        ./bin/plugins/libFWnull-0.7.0.so
8,9M    ./bin/plugins/libGSdx-0.1.16.so
392K    ./bin/plugins/libonepad-1.1.0.so
3,0M    ./bin/plugins/libspu2x-2.0.0.so
64K        ./bin/plugins/libUSBnull-0.7.0.so
4,2M    ./bin/plugins/libzzogl-0.4.0.so
112K    ./bin/plugins/ps2hw.dat

exec + plugins LTO stripped
Code:
du -s -h ./bin/pcsx2-dev ./bin/plugins/*
5,1M    ./bin/pcsx2-dev
12K    ./bin/plugins/libCDVDnull.so
20K    ./bin/plugins/libdev9null-0.5.0.so
20K    ./bin/plugins/libFWnull-0.7.0.so
1,3M    ./bin/plugins/libGSdx-0.1.16.so
72K    ./bin/plugins/libonepad-1.1.0.so
500K    ./bin/plugins/libspu2x-2.0.0.so
20K    ./bin/plugins/libUSBnull-0.7.0.so
776K    ./bin/plugins/libzzogl-0.4.0.so
112K    ./bin/plugins/ps2hw.dat

Moreover, i just read that line on GCC manual :
Quote:Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce unexpected results.

Correct me if i'm wrong but debug and devel builds use -g...

You can found my fork here : https://github.com/prudho/pcsx2
Reply
#15
Only Debug builds include -g, so it'd be best to only enable LTO on devel and release. It makes sense, all optimizations are off for debug so there's not much point in turning on LTO.
Reply
#16
Yeah you're right. Misread, my bad.

But then there's a typo on GSdx plugin's CMakeLists :
Code:
# Devel - Build
if(CMAKE_BUILD_TYPE STREQUAL Devel)
    add_definitions(${CommonFlags} ${OptimizationFlags} -D_DEVEL -g)
endif(CMAKE_BUILD_TYPE STREQUAL Devel)
Reply
#17
Hmm. It actually appears that plugins are a bit different than PCSX2/utils/x86emitter as far as flags go. ZZogl defines both -g and optimization flags for devel, same as what you found. I *think* that is intentional, since it looks like devel builds are basically release builds with -g turned on (and maybe extra logging or something), and -g does work with optimization flags, just not as well. Looks like you might have to only enable LTO for release configurations.
Reply
#18
Hi,

I'm new here and after reading and following quietly for some time I thought I jump into the discussion. Since you are trying your best to increase portability with platforms and also compilers I wanted to check how far I would come with compiling on OSX Yosemite and clang 3.5 (I know about the issues with pcsx on 64bit and no OSX support, but why not try...). I work with linux daily and OSX at home meaning I do have my fair share of knowledge with those systems. For building the common-part, cmake tells me to have both wxWidgets and aio.

Code:
-- Skip build of common libraries: miss some dependencies
-- check these libraries -> wxWidgets (>=2.8.10), aio
Stemming from this line in SelectPcsx2Plugins.cmake:
Code:
set(msg_dep_common_libs "check these libraries -> wxWidgets (>=2.8.10), aio")

Going trough the commons-source I cannot find a line where libaio is actually used and it also complys with the cmake check:
Code:
#---------------------------------------
#            Common libs
# requires: -wx
#---------------------------------------
if(wxWidgets_FOUND)
    set(common_libs TRUE)
elseif(NOT EXISTS "${CMAKE_SOURCE_DIR}/common/src")
    set(common_libs FALSE)
else()
    set(common_libs FALSE)
    message(STATUS "Skip build of common libraries: miss some dependencies")
    message(STATUS "${msg_dep_common_libs}")
endif()

So I guess this is just an old remnant that needs to go. Anyway...
Furthermore, the core needs it, I guess. Since aio is linux-only and you have Windows builds as well you could probably just using thread pools? Moving to a common ground, either per std::thread or Boost equivalents will make it portable and me a step closer to successfully compile it here. The codebase is immense and I don't know the special reason why AIO was included in place of pthreads on Linux in the first place, so might be that I'm missing something here. Any enlightenment would be great! Smile
Reply
#19
Please read those thread first Smile
https://github.com/PCSX2/pcsx2/pull/297
https://github.com/PCSX2/pcsx2/labels/OS:OSX

AIO == asynchronous IO which is unrelated to thread management.
Reply
#20
Ahh, alright. According to my search, only AsyncFileReader.h references it but this reference has been actually commented out. So there is no usage of AIO whatsoever in the code. Good to know. I've also now read through your links, thanks for that. The last real updates were mid-September. Was there anything new since then and have the changes been merged back in any way? I'll look into later Smile

EDIT: Oh, it is used. Nvm...
Reply




Users browsing this thread: 1 Guest(s)