The ring buffer is composed of severals read/write by transaction.
Atomic operations are only required at the start/end of the full
transaction. In the middle, you can use normal variable (optimization
opportunity for the compiler)
Use acquire/release semantics on isBusy and vuCycles to remain 100% safe
(relaxed might be doable but better be safe than sorry)
Use dedicated cache line for atomic variable to avoid any conflict between CPU
Write pointer can be relaxed-read from the EE thread
Read pointer can be relaxed-read from the VU thread
Warning: AtomicExchange calls were replaced by release-store
However AtomicExchange generates a memory barrier (at least on linux)
So either it is useless and it will be faster, or it will explode ;)
* Avoid the generation of memory barrier (mfence)
* Based on the fact that it used to work on previous code without any
barrier
v2:
* keep basic code in reset path
* use relaxed access for isBusy. The variable doesn't carry load/store
dependency but is instead an hint to optimize semaphore post
* update missing copyright on
+ plugins/GSdx/config.h
+ pcsx2/MTVU.h
+ plugins/zzogl-pg/opengl/ZZHacks.h
+ plugins/spu2-x/src/DplIIdecoder.cpp
* put a copyright for trivial script file
+ pcsx2/gui/Resources/rebuild.sh
+ tools/bin2app.sh
+ plugins/zzogl-pg/opengl/shaders.sh
* remove autotool from zzogl
* apply the patch for issue 1257. Thanks very much Micove for the hard work.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5154 96395faa-99c1-11dd-bbfe-3dabce05a288
Threading VU1 took a lot of rewrites and new code to make possible (MTGS, microVU, gifUnit...), but we finally got to the point where it was feasible, and now we've done it! (so now everyone can stop complaining that pcsx2 only takes advantages of 2 cores :p).
The speedups in the games that benefit from it are great if you have a cpu with 3+ cores (generally a 10~45% speedup), however games that are GS limited can be a slowdown (especially on dual core cpu's).
The option can be found in the speedhacks section as "MTVU (Multi-Threaded microVU1)". And when enabled it should should show the VU thread-time percentage on the title bar window (Like we currently do for EE/GS/UI threads).
It is listed as a speedhack because in order for threading VU1 to have been a speedup, we need to assume that games will not send gif packets containing Signal/Finish/Label commands from path 1 (vu1's xgkick). The good news is very-few games ever do this, so the compatibility of MTVU is very high (a game that does do this will likely hang).
Note: vs2010 builds and Linux builds need to be updated to include "MTVU.h" and "MTVU.cpp".
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@4865 96395faa-99c1-11dd-bbfe-3dabce05a288
refractionpcsx2