PCSX2 1.0 released!

[Starscream]

Congrats on the release guys.

[rama]

In theory: Yes giving each component its own core would probably bring performance increases.

In practice: Not a chance, some units are so tightly linked, the overhead of the threading code and amount of sync work we would have to do to make it function correctly would probably slow it down considerably. This is one reason the VU1 got threaded and not VU0. Plus VU1 generally does a lot of work and really needs its own thread

GS, EE, VU0, VU1 - these are the units that do the most work in the emulator, if possible it would be good to put all these on a seperate core each, then have 1 core for SPU2, IOP, VIF etc. However as stated in practice this isnt feasable.

And I think MTVU only became significantly faster by also doing the VIF unpacks attached to VU1 on the same thread.

[abdo123]

well i think on an another "theory" that not all components need a single core as stated by refraction above the SPU-2 thread will be inactive as the GUI thread

like VU0 activity is quite low most of the time and well VU1 got they're own core now

not feeling that the amount of load splited will win against the complexity of the codes and funky new rewrites

[pseudonym]

In practice: Not a chance, some units are so tightly linked, the overhead of the threading code and amount of sync work we would have to do to make it function correctly would probably slow it down considerably. This is one reason the VU1 got threaded and not VU0. Plus VU1 generally does a lot of work and really needs its own thread

Actually the reason the VU1 got threaded and not the VU0 is that the main use of the VU1 is transformation and lighting followed by direct transfer of data to the GIF from VU1. Because we keep a queue of GIF data, we can insert a placeholder for potential data from a VU1 program which the queue reader will stall on until the program is completed and let the program run its own thread. For the most part there is no VU1->EE traffic so we just insert a GIF placeholder, queue the vif1 data on the MTVU thread and say "okay, done, next!" to the EE. None of this works with VU0 because only VU1 has a GIF path.

As far the IOP is concerned, it mostly doesn't work independently from the EE apart from some music engines. Most modules just do finite tasks on demand by RPC and high IOP load is almost always because of bad programming (busy waiting).

The GS is already threaded as mentioned.

SPU2 programming is very low level and requires tight sync. The SPU2 clock runs at 48kHz and potentially interacts with the IOP every tick. On top of that, SPU2 load isn't very big in the first place.

...really there isn't much room for more threading. Multiple VU1 threads is theoretically possible but of questionable benefit.

[refraction]

Actually the reason the VU1 got threaded and not the VU0 is that the main use of the VU1 is transformation and lighting followed by direct transfer of data to the GIF from VU1.

I was actually doing the "Dumbing it down for people who don't know how to program or the PS2 hardware" rather than going in to specifics You has now confused idiots everywhere!

Have a cookie

[pseudonym]

I was actually doing the "Dumbing it down for people who don't know how to program or the PS2 hardware" rather than going in to specifics You has now confused idiots everywhere!

Sorry, threading discussions bring this out in me

We need to automatically detect that someone's trying to post a threading proposal and display a notice that we put a lot of thought into how to improve performance whenever we're not busy with something else and if we haven't done something it's either not a good idea or is on our todo lists.

[NEOAethyr]

Congrats on the ver 1.0 .
It's actually come a long way, it runs great.

A few small issues to be expect, at this stage emu is not 100%, more like 95% maybe?
I'de like to mention the shadows on xenosaga 1.
And likely disabled post processing effects in for ex. gtasa and so on to make those games more playable.
Those are small details that might end up taking alot more work, I don't know.
All my games play fine, if they play.
Good speed.

Only real game that seems to hurt performance wise is gt4.
My 460se can't keep up with the upscale with hardware mode.
It only used to work in software mode...


Anyways, you guys are talking about theory's and performance stuffs...
How much mem can pcsx2 allocate and would it make a difference in performance if it could allocate more or in larger blocks?

32bit stock kernel limit is 2gig pages.
64bit kernel limit is 4gig pages, large addy aware...
32bit modded kernel limit is 4 gigs, large addy aware.

Some programs are large address aware and are able to access memory in 4gig pages.
Regardless of kernel unless it's the stock 32bit one.

Some programs are aware of large mem pages in 64bit, but likely cannot use them anyways... ?
In 32bit modded, they act as in stock 32bit.
Bitspirit is the only example I know of.

Some programs, can access 100% of the mem in 64bit.
And 2gigs in 32bit stock.
And 100% of the mem in 32bit modded.
Ex. s&m's mem test (setting userva to 8192 was the final step in getting this working).

And some progs are like wtf on a modded 32bit kernel...
Intelburn test as an ex and maybe y cruncher I don't remember.

I know because I've done so on my system.
I got 8gigs of mem usable for the most part in my win7 32bit.

Anyways I have noticed in general in the 32bit modded os, each little thing can access up to 4 gigs of mem if it's written right.
Like the vga driver for example, it's allocated it's self 4 gigs... I had to mess with that rendering/buffer thingy at some time or another but that's a diff story (pcie oc'ing).

So here's the ? again.
Would it make any difference if it could access more mem?
And what would be the limit currently?, I haven't checked with taskmgr... I'm on win8 messing with that right now (hacking/tweaking the rtm).

My win8 isn't modded and it's 32bit so... not completely usable right now until I can hack the kernel.
Possible, but with tons of results with 50% give or take for opcode matches to patch... 2 addys, gonna take time

I ramble to much...

[abdo123]

accessing more RAM wont increase performance Emulation require processing not Storing

and if the devs didn't code the 64-bit version the same as last time we shouldn't see any performance gain too

[refraction]

Unless something goes epicly wrong or a game bugs out (which happens occasionally on GSDX, especially with high custom resolutions), the emulator should never use more than 2gb of ram. In fact in most cases it will be 512-1024 at most in a majority of cases. Considering the total memory of the original machine was 64mb, there shouldnt be too much overhead. The only reason we use as much as we do is for storing all the functions and the game code in memory, plus we cache all the textures from the game files for a period of time to save having to reswizzle them etc, effectively bypassing the 4mb videoram problem the PS2 has.

[Squall Leonhart]

Congrats on the ver 1.0 .
It's actually come a long way, it runs great.

A few small issues to be expect, at this stage emu is not 100%, more like 95% maybe?
I'de like to mention the shadows on xenosaga 1.

mention what, about the shadows on xenosaga 1?

the only possible problem with them, is caused by using internal resolution scaling.

a simple work around is to use a custom resolution of

nvidia: 1510(up to 1520)x whatever number
AMD: 1024x whatever number)