(09-15-2011 06:48 AM)Purkinje Wrote:  I don't know a whole lot about threading, but that sounds like an interesting way to get around thread synchronization. Is this an optimal solution, or simply a workaround to get MTVU working?

Both
Duplicating VIF1 allows the MTVU thread to not need syncing with VIF1 (since it'll just read from its own copy while pcsx2's main thread writes to another version); eliminating this syncing allows MTVU to be a speedup. If VIF1 wasn't duplicated then MTVU could still run on its own thread, but it would be a slowdown from all the extra syncing.

(09-15-2011 06:22 PM)cottonvibes Wrote:  Both
Duplicating VIF1 allows the MTVU thread to not need syncing with VIF1 (since it'll just read from its own copy while pcsx2's main thread writes to another version); eliminating this syncing allows MTVU to be a speedup. If VIF1 wasn't duplicated then MTVU could still run on its own thread, but it would be a slowdown from all the extra syncing.

Interesting! Does this method of cloning threads to get rid of syncing issues work in general, or only in certain situations?

(09-15-2011 10:47 PM)Purkinje Wrote:  Interesting! Does this method of cloning threads to get rid of syncing issues work in general, or only in certain situations?

i think you made a typo; its not cloning threads, its cloning component states
the technique can be applied to other threading situations, but not all (its not needed in all situations).

a similar thing found in pcsx2, is that the GS thread duplicates some GS register state information, while pcsx2's main thread has its internal copy.
and another example is that the GUI thread duplicates some pcsx2 option/application states, so that when you modify the options in the speedhacks panel for example, its modifying the GUI thread's copy of the options, and then this later gets applied to the emulation's copy. ( at least i think that's what it does D: )

Hello Cotton !))
Thanks for your hard work !)))
I have a question about precision emulation of FPU. Looks like you and Refraction are only specialists here with strong knowledge of EE and VU's.
The question is - what is wrong in Ace Combat series games (Squadron leader, Belkan war, Shattered skies, and e.t.c.) looks like some compute operations are wrong and big airplanes are like ghosts - flying through them, shooting through them and it doesn't make any sense. I've looked all your articles about hardware precision problems and syncing problems, but it looks like a different bug in Ace Combat game engine... FPU bug, or EE operation problem... Maybe it require some additional gamefix or hack.
Setting clamp modes to full doesn't help. MTGS and MTVU are OK here. VU recompilers too (well, I think so...)
P.S. - graphics in these games are allready fixed and works without any problems in GSDX Software mode (mipmapping ON), just like real PS2

Well that question is off topic for this thread about threading VU1.
I don't have any of those games so I haven't seen the bug, but it could be an EE/FPU precision bug like you mentioned.
Sadly finding a way to fix those types of problems when you have no-leads is extremely tedious and time consuming, so the games likely won't be fixed anytime soon. (p.s. in addition to trying different clamp modes, try using different round modes too).

Found a bug.
Timesplitters 2 (PAL) won't load if MTVU is activated, it just stucks in the title screen and no loading bar appears.
Without MTVU, the game loads and works.

That's not a "bug", some games just won't work with it (cotton already explained the cases where this would happen I think) and some others will get glitches/SPS with it (I only know one case of this due to some cycle issues, the game would get the same problem with the "EE timing hack" gamefix). There's a reason why it's a speedhack, but basically it either works with a game or it doesn't and when it works there's other factors that may actually make it a slowdown (if you stop for a second in the speedhack option you can read where it says it's incompatible for some games ).

The games which won't work at all with MTVU are ones which use the "SIGNAL" registers on the GS. These can abort transfers, which isnt possible with MTVU, it has to do all or nothing.

Like our Facebook Page and visit our Facebook Group!

okay I understand. So they're things which aren't possible with a threaded VU1.
Isn't there a workaround for this? a hack which makes it possible without the loss of speed?
How many games which are using the GS's SIGNAL registers are known? is there a list?

one more question:
Is it still possible to turn off MTGS?
Might it speedup VU demanding and less GS demanding games on dualcore processors when using MTVU?

(09-21-2011 07:54 PM)Nexxxus Wrote:  okay I understand. So they're things which aren't possible with a threaded VU1.
Isn't there a workaround for this? a hack which makes it possible without the loss of speed?
How many games which are using the GS's SIGNAL registers are known? is there a list?

one more question:
Is it still possible to turn off MTGS?
Might it speedup VU demanding and less GS demanding games on dualcore processors when using MTVU?

most of those questions have already been answered in the blog and in the thread.
around 95% of games don't use the signal stuff that MTVU breaks with.
there's no quick hack to get the other 5% working with MTVU, and I don't plan to code anything to support them either in order to keep code clean, simple, and fast.
i don't remember the name of the specific games off the top of my head, 5 or so games have been mentioned that break with it.

of course its possible to turn off MTVU. its a speedhack option, and to use it you need to turn it on in the first place. switching the option on/off in-game does work most of the time, its currently not 100% safe though.
It can provide a speedup even on dual cores, if the game is VU heavy and not so GS heavy. This is game and scene specific though, in general its probably best to leave MTVU off if you have a dual core cpu, unless you do some testing and the game you're playing benefits from it.