(08-15-2011 04:10 AM)Squall Leonhart Wrote:  I'm only going on what some of the commenters said in the change comments

i didn't see anyone talk about fake fps with MTVU.
but if they did they're likely using the cycle hacks or they're wrong.

(08-15-2011 04:23 AM)cottonvibes Wrote:  i didn't see anyone talk about fake fps with MTVU.
but if they did they're likely using the cycle hacks or they're wrong.

there were 3 posts regarding fake fps, but it looks like a non issue.

VBA-M

Talk about this blog post on IRC reminded me to come here and take credit for the fake GIF packet idea, which I presented in a slightly more complex form aimed at running more than one VU1 program in parallel (this is even more hacky and would likely not provide an advantage over the three core model in many if not most games).

And as far as the EE cache is concerned, everything cotton said on the subject is correct. I don't know why DOA2 really doesn't work but that's just because it's too far down my todo list to even investigate yet. In the unlikely chance that it really does rely on for example cache persistence when DMA has overwritten the data (or the cache not flushing before DMA reads it), that's when we patch the game on the fly or provide a hack which deals with just this scenario. There is no circumstance which makes attempting to emulate the CPU cache appropriate.

I'm curious about the overlapping of the 2 VU speedhack.
1/ MTVU -> move VU1 into another thread.
2/ VU cycle stealing -> reduce the speed of both vu to reduce EE thread burden.

So if I understand correctly, it is better to enable MTVU (if possible). VU0 is light anyway. In this case VU cycle stealing will have nearly no speed impact but only generate timing issue. Did I understant thing correctly?

(08-16-2011 09:49 PM)gregory Wrote:  I'm curious about the overlapping of the 2 VU speedhack.
1/ MTVU -> move VU1 into another thread.
2/ VU cycle stealing -> reduce the speed of both vu to reduce EE thread burden.

So if I understand correctly, it is better to enable MTVU (if possible). VU0 is light anyway. In this case VU cycle stealing will have nearly no speed impact but only generate timing issue. Did I understant thing correctly?

VU cycle stealing can give you false fps readings or not-smooth animation games (as well as graphic glitches).
So if MTVU is enough to get full speed in your game, then you should just use that.

However using VU cycle stealing + MTVU can give you a massive speed increase in certain games.
If VU cycle stealing isn't causing problems in your specific game, and you need the extra speedup, then there's no reason you shouldn't use it together with MTVU.

and VU cycle stealing doesn't reduce the cycles of VU programs, it adds to EE cycle counter whenever a VU program has been run. I believe by doing this certain games end up having to limit the amount of VU programs that run per-frame, which gives higher frame rates but potentially un-smooth graphics.
however there are a lot of different events that base their timing off EE cycle deltas, so there might be other explanations for the speedups (like instant or more frequent dma transfers).

anyways, the bottom line is MTVU doesn't change the effect of the VU cycle stealing hack and using both together can give you great speedgains. But if you only need one to get full speed, then use MTVU which is less of a hack so it won't cause fake fps reading and etc... in the games it works in.

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

For the linux testing. I try to enable it, I did not see any crash except one during the shutdown of the emulator but that not critical. However I do not have any opengl accelerated drivers [0], so I could only try SDL sw mode of GSdx.

[0] My latest upgrade 2 monthes ago completely broke the drivers and left me only the basic text console. Did not have free time to fix it, so I run with only 2D driver.

Edit: thanks for the answer

I loaded a few games around revision 4868 in Linux with MTVU on, and aside from Baroque, they loaded properly and ran. And you'd said a few games didn't work with it, so I'd assume Baroque was one of those.

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.

i haven't coded any special handling for pcsx2 shutdown with the MTVU thread. maybe i need to handle that to prevent problems on emulation close. i don't fully get how the gui/system/non-emulation related code in pcsx2 works; so its difficult to find the right place to add proper thread shutdown and syncing procedures.

Hum, actually I'm not sure the shutdown issue is related to MTVU. It might be also a race condition between pad/gs when the display is closed.

Is it possible that MTVU could be incompatible with save states from some games?

I tried loading a savestate from Persona 4 with the hack on, and I got an error in console somewhat like this, but I don't remember the exact message: "MTVU: Expected GS PackQueue!". Upon loading it, most of the graphics were corrupted (and things such as cards would be flipped the wrong way), along with lines of texts having their first letter in the line above them.

A weird error, but it seems temporary - I couldn't reproduce it within a different session of PCSX2. I'll upload a video of how the game looked like in case you are interested.