currently save states that are created with MTVU Off and then loaded with MTVU On can be incompatible (or vice-versa).
its also not 100% safe to be switching mtvu On/Off while in game.
i don't have a good solution for solving these problems.
the gif unit works differently for mtvu on/off by design, so whether or not there are problems between the switching depends on the state the gif was in at the time of the saved state (or the switching of mtvu on/off through speedhack dialog)

Great write-up! Didn't finish reading about all the problems but I've learned a lot already. Thanks conttonvibes!

Well, actually, when this corruption happened, the save state was created and loaded with the speedhack on. Even loading it with the speedhack off didn't cause any different result. It must be a rare occurrence, because as I said before, I couldn't replicate it with the same save state on a different session.

Although, a save state is a RAM dump, right? I might be wrong, but how could something in the RAM cause such severe graphical issues and such while keeping the game *playable*?

The video is here, in case you're curious, and all sounds play correctly (I just don't bother to record them):

http://www.youtube.com/watch?v=GRVIq4Tm-gQ

(08-16-2011 11:00 PM)cottonvibes Wrote:  If you use devel builds there should be error messages in the console on games with the behavior that MTVU can't support.
also nice to hear that its working --- if it didn't (due to the signal handling not allocating memory correctly) it would basically crash all games.

It'd just been a few days since I tested it, and I didn't have a chance to reproduce the error when posting. When starting Baroque with MTVU on, I got:

(08-17-2011 10:41 AM)MyDreamName Wrote:  Although, a save state is a RAM dump, right? I might be wrong, but how could something in the RAM cause such severe graphical issues and such while keeping the game *playable*?

a saved state isn't just a RAM dump of ps2's main memory, it saves various pcsx2-statuses and buffers at the time the state was created.
with threads its more difficult to do saved states because of syncing issues and race conditions.

(08-17-2011 12:01 PM)arcum42 Wrote:  It'd just been a few days since I tested it, and I didn't have a chance to reproduce the error when posting. When starting Baroque with MTVU on, I got: [...]

yeh that's the error that you should be getting on unsupported games; so its indeed an expected problem and not a linux-only thing

Hey, I noticed that without the speedhack on, I was using ~30% of my CPU (at EE% maxed out) (4 cores, 4 threads), but with it on I was using 50% (at VU% maxed out) - is one thread maxing out while the others are getting relatively low activity?

it's more or less impossible to max out one thread alone. EE should still count DMA partially. and the GS running data.

for the meters. without the hack the EE meter is EE+VU which is why it maxes. with the hack the EE runs for itself and the VU makes its own thread meter.

as for the 50%. this cause of the MTVU runs VU in parallel to the EE and syncronizing more or less only starts or ends of VU programs with other components. therefor it speeds up the complete VM and CPU usage. you'll reach 100% only if the EE sync and GS data thruput allows it.

this flow charts kinda show exactly what it does. can't attach it. I'm still banned and on a proxy. -_-

http://www.philvaz.com/games/figure_08b.jpg

http://www.philvaz.com/games/figure_09b.jpg

they are about programming for ps2 but this kinda same how mtvu works now.

what's causing the missing 50% of the CPU usage is the stalls when threads waiting for each other to deliver new data.

Quote:Has anyone tested MTVU on linux btw? just want to confirm it actually works.

I can only say for sure that Pcsx2 is able to run in Linux with MTVU option enabled.
If is actually doing something, that I'm not so sure.

First of all, in Windows MTVU is doing a great job, I can see a huge increase in FPS in GOW for example and some other games, so no problems there.

In Linux however (with both gsdx and zzogl), using same settings, same games and same hardware I see...well, nothing.
I spent a lot of time searching for that elusive FPS increase but without luck, it won't budge a single frame faster.
Pretty depressed now because I could use little speed, since the Linux build is already few times slower than Windows one.

Maybe I understood it all wrong and is supposed to work (doing something) only in Windows?

(AMD Phenom II X4 965 - GeForce GTX 470 - 4GB RAM)

You are probably limited by the slow GS plugins available to Linux, thus taking the load off the VU does not help speed since the bottleneck is set by the GS