Dolphin, the GameCube and Wii emulator - Forums
Linux compilation - some patches included - Printable Version

+- Dolphin, the GameCube and Wii emulator - Forums (https://forums.dolphin-emu.org)
+-- Forum: Dolphin Emulator Discussion and Support (https://forums.dolphin-emu.org/Forum-dolphin-emulator-discussion-and-support)
+--- Forum: Development Discussion (https://forums.dolphin-emu.org/Forum-development-discussion)
+--- Thread: Linux compilation - some patches included (/Thread-linux-compilation-some-patches-included)



Linux compilation - some patches included - Tub - 08-31-2009

Hi,

Now and then I've been trying to get dolphin to run on linux. Today was the first time I got it both compiling and starting emulation without segfaulting!

Anyway, a couple of patches were needed.

r4108_linux_fixes.patch
Edit: not needed any more, those are fixed in latest trunk


so finally it worked! But when pressing "Stop" during a game, it segfaulted. Valgrind to the rescue! Well, or not.

The valgrind.log said:
Code:
vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x29 0xC6 0x66 0xF
==18815== valgrind: Unrecognised instruction at address 0x1872024e.
and I have no idea how to debug that. However, I fixed another valgrind warning:

r4108_gpfifo_memmove.patch
Code:
Index: Source/Core/Core/Src/HW/GPFifo.cpp
===================================================================
--- Source/Core/Core/Src/HW/GPFifo.cpp    (revision 4108)
+++ Source/Core/Core/Src/HW/GPFifo.cpp    (working copy)
@@ -77,7 +77,8 @@
        m_gatherPipeCount -= GATHER_PIPE_SIZE;
        
        // HyperIris: dunno why, but I use memcpy
-        memcpy(m_gatherPipe, m_gatherPipe + GATHER_PIPE_SIZE, m_gatherPipeCount);
+        // Tub: memcpy is not guaranteed to work if source and destination overlap, memmove is safe.
+        memmove(m_gatherPipe, m_gatherPipe + GATHER_PIPE_SIZE, m_gatherPipeCount);
        
        // increase the CPUWritePointer
        CPeripheralInterface::Fifo_CPUWritePointer += GATHER_PIPE_SIZE;
granted, memcpy() should work fine if your system uses the trivial implementation, but doing it the proper way doesn't hurt.


I'd be happy to see those patches commited to trunk by a dev Smile
I thought it was a little slow, so I tried to compile it with Profile-guided Optimization.


r4108_enable_pgo.patch
Code:
Index: SConstruct
===================================================================
--- SConstruct    (revision 4108)
+++ SConstruct    (working copy)
@@ -120,6 +120,10 @@
                  ignorecase = 2
                  ),
     PathVariable('wxconfig', 'Path to the wxconfig', None),
+    EnumVariable('pgo', 'Profile-Guided Optimization (generate or use)', 'none',
+                allowed_values = ('none', 'generate', 'use'),
+                ignorecase = 2
+                ),
     ('CC', 'The c compiler', 'gcc'),
     ('CXX', 'The c++ compiler', 'g++'),
     )
@@ -193,6 +197,15 @@
elif (flavour == 'release'):
     compileFlags.append('-O3')

+# pgo - Profile Guided Optimization
+if env['pgo']=='generate':
+    compileFlags.append('-fprofile-generate')
+    env['LINKFLAGS']='-fprofile-generate'
+if env['pgo']=='use':
+    compileFlags.append('-fprofile-use')
+    env['LINKFLAGS']='-fprofile-use'
+
+
# more warnings
if env['lint']:
     warnings.append('error')

To create an optimized binary, do this:
  1. scons flavor=release pgo=generate
  2. run the binary, start a game, play a little. It'll run slower than usual, because it's busy generating the profile.
  3. scons flavor=release pgo=use
  4. run the new binary, which is now optimized!

some short tests suggest that PGO yields about ~3% more fps. Yay! \o/


again, feel free to commit this to trunk Smile


RE: Linux compilation - some patches included - Jack Frost - 02-06-2010

Those unhandled instruction bytes might be a valgrind bug (actually, it has been), but your version doesnt look like the one reported there.

It would probably help to know more about this, it might be a JIT Bug.
Which game (or any game, if no specific one does this), and probably a memory image of the process at the time when valgrind throws this (piped thru objdump perhaps, filtered to the reported bytes).
I'm not so sure that this is the complete context where valgrind dies:
Code:
D:\_dev>udcli -x
66 f 29 c6 66 f
0000000000000000 660f29c6         movapd xmm6, xmm0



RE: Linux compilation - some patches included - Cloudef - 02-06-2010

Thank you for these patches! Maybe i should start contributing the Linux build too hmm..