such is the case with xenosaga 2 lol
And GTA:Vice city stories,
There is a video with the developers oh DeadNation and SuperStardust HD on multithreading game codet hat I've seen that might be of some use for ideas going forward. The developer talks about using states which he's up calling dirty and non dirty to keep track of dependencies and building his own stack. It goes into enough detail that it could be useful but not enough detail to basically hand you the code of how they achieved this. It consisted of threads and fibers. Fibers which are a handbuilt class to mimic threads but with faster switching.
(08-14-2011, 01:06 PM)rodiablo Wrote: [ -> ]Cottonvibes, do you (or anyone else on the team) intends to finalize the new DMAC Jake left incomplete? Just out of curiosity. Sorry, I do not recall having read anything about that in my relatively recent visits to the pcsx2's GoogleCode page.
Probably not.
The code had some bugs which nobody could figure out.
For me its easier to rewrite stuff from scratch than to use other people's code (especially if its broken).
(08-14-2011, 03:24 PM)Game Wrote: [ -> ]Hey,can make such expert explanation why MTVU1 gives boost on 2 core CPUs?
Its not always a speedup on dual cores. There is extra overhead involved with uploading data to the MTVU ring buffer, and syncing the threads.
In the games it 'is' a speedup on, its due to having enough free core activity.
For example, if the GS thread does little work in a certain game, and there's a lot of VU1 work, threading VU1 would have the OS run some VU1 code on the same core that the GS thread is running, which would likely be a speedup.
But if a game was already using the GS and EE threads a lot, then threading VU1 would likely be a slowdown on dual cores because theres not enough free cpu power for an extra thread to be worthwhile (and then you get the additional overhead of running the thread which gives you the slowdown).
(08-14-2011, 03:33 PM)Squall Leonhart Wrote: [ -> ]if the game uses GS heavily, the boost is either faking the fps, faking the fps and running slower, or just running slower with dual core cpu's.
Games that are running faster, are probably lighter on the GS thread that mtvu is sharing a core with.....
so yeah, seconding what miseru said.
using MTVU will not give fake FPS readings.
That only happens when you use the cycle hacks because it modifies EE's cycle timing.
(08-14-2011, 01:45 PM)aaa801 Wrote: [ -> ]good read, now port the ee cache over to recompiler 
EE-cache support most-likely isn't needed accurate emulation; the reason the interpreter option for EE-cache can help some games is likely due to random luck.
And a recompiler by design is not good for emulating something like a cpu cache.
You would have to know how a recompiler works to understand why.
(08-14-2011, 06:52 PM)Game Wrote: [ -> ]And GTA:Vice city stories,
Heh, it still has problems, but has actually seemed to gotten faster since the r4600 release.
(08-14-2011, 11:00 PM)cottonvibes Wrote: [ -> ]EE-cache support most-likely isn't needed accurate emulation; the reason the interpreter option for EE-cache can help some games is likely due to random luck.
And a recompiler by design is not good for emulating something like a cpu cache.
You would have to know how a recompiler works to understand why.
itd get doa2 working tho ;D
(08-15-2011, 01:35 AM)aaa801 Wrote: [ -> ]itd get doa2 working tho ;D
All we need is an emulator called "bps2" that is 100 times more CPU-intensive than this emulator.
Should do the trick.
(08-14-2011, 10:50 PM)cottonvibes Wrote: [ -> ]Probably not.
The code had some bugs which nobody could figure out.
For me its easier to rewrite stuff from scratch than to use other people's code (especially if its broken).
Its not always a speedup on dual cores. There is extra overhead involved with uploading data to the MTVU ring buffer, and syncing the threads.
In the games it 'is' a speedup on, its due to having enough free core activity.
For example, if the GS thread does little work in a certain game, and there's a lot of VU1 work, threading VU1 would have the OS run some VU1 code on the same core that the GS thread is running, which would likely be a speedup.
But if a game was already using the GS and EE threads a lot, then threading VU1 would likely be a slowdown on dual cores because theres not enough free cpu power for an extra thread to be worthwhile (and then you get the additional overhead of running the thread which gives you the slowdown).
using MTVU will not give fake FPS readings.
That only happens when you use the cycle hacks because it modifies EE's cycle timing.
I'm only going on what some of the commenters said in the change comments
(08-15-2011, 01:35 AM)aaa801 Wrote: [ -> ]itd get doa2 working tho ;D
as i said its likely luck that the game works with it.
you probably just need to modify some cycles here and there and then it'll work on the recompilers too.
the ee-cache in the interpreters almost surely is not correct. true cache implementation would modify the pipeline of the EE as well as modify the pipeline when calling COP2 (vu macro mode) instructions.
its very complex and pcsx2 isn't in the shape to do it correctly.
also because cache pipeline stalls are unreliable, good ps2 code can't depend on cache implementation or else it would be unstable on the real ps2. that's why you shouldn't need it implemented.
furthermore, unlike VU programs which require pipeline emulation due to hand-coded asm programs, EE code is almost always C/C++ code with the asm generated by a compiler. Compilers aren't stupid enough to rely on cache timing differences.