The latter's probably what the issue is. IIRC, when compiling 64 bit code, gcc complains more about forceinlines then it does normally. I recall several bug reports that started with un-inlinable functions turning out to be because of not compiling in a 32 bit environment...
Arcum,
I have a cmake question. Is there any hidden reason to use ".h" and ".inl" files in CMakeLists.txt files ? I test to remove them from pcsx2&common. The code is still "compilable" and I could launch a game.
Ok, there's a very good chance PCSX2 should be between 80% and 100% stable with gcc's -O2 optimizations now, as of my commit on r3375. I can't be 100% sure yet because I might have overlooked a C callback from the recompilers somewhere. Testing appreciated.
I'm currently testing it with O3 (CFLAGS="-march=amdfam10 -O3 -pipe"), gcc version 4.4.2 (Gentoo 4.4.2 p1.0) and the speed boost is really nice! About 10fps gain on 3D games and it seems pretty stable, gonna do more tasting later on.
Wingnux,
Can you did 2 things. First remove -fno option of cmake (that desactivate some options) if not already did. And then test the performance with -O2.
Thanks
Yeah, baby steps are appreciated. O2 first, and then if it looks solid, we'll up testing to O3 and see what happens.
(On the bright side, I've heard GCC 4.4 series is much better about O3 than 4.2 and 4.3 anyway. It no longer breaks nearly as much code as it used to, lol)
For me -03 on 4.4 is O'k. But even without optiomizations Dark Cloud are crushed (with race conditions, as it seems). I think it's fglrx issue.
I found some interesting stuff about position independent code (PIC) which is quite a mess.
# Code compile with -fPIC
spu2x code use -fPIC
# Code compile without -fPIC
zzogl (-fPIC cause some regression found by arcum)
libutilies.a (could be added)
libx86emitter.a (code use ebx register in one place (common/include/intrin_x86.h:836), can probably be fix without too much hassle)
Spu2x and zzogl are links against both libutilies.a and libx86emitter.a
-> libspu2x contains a mix of PIC and non-PIC code... Not sure it is good.
-> maybe one reason of the regression on zzogl with -fPIC
Is there any opinion on this subject ?
Is there really any reason to be using -fPIC at all? I mean, do we care if SPU2-X and/or zzogl can be shared across multiple processes? How many people will be running multiple copies of PCSX2 side-by-side, with the same versions of plugins et.al.?
... or is there some other advantage to -fPIC that I'm overlooking?
(07-03-2010, 09:09 AM)gregory Wrote: [ -> ]Wingnux,
Can you did 2 things. First remove -fno option of cmake (that desactivate some options) if not already did. And then test the performance with -O2.
Thanks
I don't know how to remove the -fno option, can you give me more detailed instructions? My system builds with -O2 by default, I've manualy set it to O3 on pcsx2 in order to test it's performance and stability.
Everything seems fine by far.