(05-10-2010, 09:28 PM)arcum42 Wrote: [ -> ]Its likely. My original codeblock project file for zzogl generated a version of the plugin that crashed all the time, and I had to go over the list of flags very carefully to fix it.
If in doubt on that one, refer to the automake file, since that's been working properly longer then the codeblock file...
Well I have looked into Makefile.am to create the cmake. But now I saw it had been more clever to also look at configure.ac to see the missing option (-fno-regmove)...
Anyway except a symbol that dissapear on spu2x when enabling optimization, the cmake port is functional now.
Gotcha. Found the issue for spu2x
The missing symbol "MemProtect(...." was caused by a dependancy between the 2 static libaries (Utilities x86emitter). This symbol is only used by x86emitter. If gcc links libutilies first, memprotect is unused so it strips it. Then it links x86emitter unfortunately the useful symbol disappear...
I swap the x86emitter and Utilies in the cmake file and it works with x86emitter first. To be more robust maybe we could add 2 times target_link_libraries see below.
Extract of the cmake doc. Section:
target_link_libraries
The library dependency graph is normally acyclic (a DAG), but in the case of mutually-dependent STATIC libraries
CMake allows the graph to contain cycles (strongly connected components). When another target links to one of the
libraries CMake repeats the entire connected component. For example, the code
add_library(A STATIC a.c)
add_library(B STATIC b.c)
target_link_libraries(A B)
target_link_libraries(B A)
add_executable(main main.c)
target_link_libraries(main A)
links 'main' to 'A B A B'. (While one repetition is usually sufficient, pathological object file and symbol
arrangements can require more. One may handle such cases by manually repeating the component in the last tar-
get_link_libraries call. However, if two archives are really so interdependent they should probably be combined
into a single archive.)
I think you may have just explained several hours of frustration I had with the codeblocks project for spu2-x one day.
To be honest it also took me several hours. objdump and nm are really nice tools for digging into binary
Anyway it was a good lesson for me: order during the link have a big impact on the executable.
It 'seems' also to compile with -O2 option in the spu2x plugins. Therefore there is another dependency in the reverse order. So we can not just swap the order. I use the following line to compile it : target_link_libraries(${spu2xName} Utilities x86emitter Utilities)
To be complete, it did not crash but unfortunately I have no sound with the optimization... A reason could also be that I using my distribution liba52 library.
I am not sure that Utilies depends on x86emitter is really usefull.
grep -ir x86emitter common/src/Utilities
./Linux/LnxThreads.cpp: #include "x86emitter/tools.h"
./Windows/WinThreads.cpp:#include "x86emitter/tools.h"
It is really not clear (for me) why the include is needed. On linux is more or less a stub than do nothing (maybe in your big todo list), include are probably a copy/paste of windows version. Maybe the windows version needs it but I do not know where. In a previous version they using LogicalCores cpuinfo but it was delete and probably include was not updated. Maybe a good idea to ask a windows guys (jake ?). Bazooka solution comment and see if it still compile on windows
It is on the to-do list, but given that the information the functions report is used, IIRC, on something else that's also on the to-do list, I've felt safe in ignoring it for the moment.
The include could probably be nuked for the moment, but spu2-x is going to eventually need x86emitter anyways. Spu2-x normally checks if your cpu can handle sse2, and the cpu identification code is in x86emitter. That code just happens to be ifdeffed out for Linux right now, as it was something I was going to get back to.
And in some tests a day or two ago, I was getting sound even with all the code that uses liba52 commented out, so the no sound issue is probably unrelated...
Yes I saw that spu2x will need x86emitter. I see no problem that spu2x depends on both x86emitter and utilies. However I see no reason to make utilies depends on x86emitter. Inter-dependancy between lib for no reason, is not a good idea in my opinion. It is more to avoid strange behavior in the future and also broke the circular dependancy for free. X86emitter will still depends on utilities in all cases.
Well for the nosound problem, I need to figure out how it is working then find what it is doing wrong in my computer. I will probably compare the non-optimized and the optimized version, it just a question of time. Fortunately I have plenty of free time.
Just for information. The gcc optimization that broke the sound (at least in my computer) is the strict aliasing (I use -fno-strict-aliasing to disable it and its works).
Not sure it worth changing the code to include it. The log seems to point out the function MulShr32 however no guarantee that it is really this function.
Here a log extract of the current warning about strict aliasing:
./plugins/spu2-x/src/Decoder.cpp: In function ‘s32 stoi(sample_t)’:
./plugins/spu2-x/src/Decoder.cpp:126: warning: dereferencing type-punned pointer will break strict-aliasing rules
./plugins/spu2-x/src/Mixer.cpp: In function ‘s32 MulShr32(s32, s32)’:
./plugins/spu2-x/src/Mixer.cpp:58: warning: dereferencing pointer ‘’ does break strict-aliasing rules
./plugins/spu2-x/src/ReadInput.cpp: In member function ‘StereoOut32 V_Core::ReadInput_HiFi()’:
./plugins/spu2-x/src/ReadInput.cpp:43: warning: dereferencing type-punned pointer will break strict-aliasing rules
./plugins/spu2-x/src/ReadInput.cpp:44: warning: dereferencing type-punned pointer will break strict-aliasing rules
Edit: I do not know if it a good idea. But the function MulShr32 can probably be replaced with some inline asm without too much difficulty. In term of performace we gain the inlining and probably some minor move.
Edit2: For what it is worth. I was trying to convert into asm.
1/ I confirm it is the MulShr32 function that cause some problem.
2/ The inlining is still not possible unfortunately. Force it with some macro break the code... There is something I do not understand somewhere. Problem comes from functions that call it. I try to investigate a little more.
Well inlining stuff are too black magic.
I still attached a patch to convert the function MulShr32 in asm. It will be probably faster but I do not know how much. I do not know if there are something to properly benchmark it. As you will see the asm it is shorter and easier than the C. Can probably be ported to windows.
I used the AT&T syntax (I try intel but I failed with some problem in the size of operand). The instruction is 'imul' (unsigned multiplication) + a second 'l' (to force it in long). 'g' constraint allow both register and memory (so you must tell the size and so the second 'l').
It fix also the problem of strict aliasing. Now I have sound with -O2.
I thinks it is equivalent to C (at least what I have understand). Do A (32b) * B (32b) -> result (64 bits) and keep only high 32 bits of results.
Well, cutting it down to one instruction's probably a good thing. And if that takes out the issues with strict aliasing, I probably ought to go with that, unless Jake points out any problems with it...