removal of lazy memory allocation
#11
You mean those 2 caches?
Code:
Micro VU0 Recompiler Cache       @ 0x5C000000 -> 0x60000000 [64mb]
    Micro VU1 Recompiler Cache       @ 0x60000000 -> 0x64000000 [64mb]

Do you have some logs of when it is happening? I don't see anything in the code Sad

We have 5 memory zones:
1/ EE
=> Dedicated class for spatial array
2/ MVU
=> Potentially a tricky mechanism for resize
3/ SVU
=> not important
4/ IOP
=> no trick here yet, that strange Tongue2
5/ VIF
=> VIF vs SSE VIF

So far only 2 memories in EE requires the SpatialArray class. I'm in favor to drop it.
Code:
R5900 RAM copy                   @ 0xE22FF000 -> 0xE42FF000 [32mb]
R5900 RAM LUT                    @ 0xDFEBF000 -> 0xE22FF000 [36mb]
Games are around 7MB (check one actually). So basically 14MB is used on the 68MB pool. So it would increase physical memory by 55MB (virtual memory remains unchanged). In practice, in case of memory pressure, the kernel will likely put those useless page in swap.

I need to check it but other memories might just need an extension of RecompiledCodeReserve class.
Reply

Sponsored links

#12
That's fine, remove that Smile Although some way of the user increasing it manually would be good if possible, maybe an ini setting? Just in case there's one game which decides to be a memory hog and we haven't thought of that specific scenario.

I know VIF dynamically grows, I can't remember if mVU does, I had a feeling it does, pretty sure superVU does, but you already said that Tongue
[Image: ref-sig-anim.gif]

Reply
#13
Well those 2 memory are based on the size of the RAM/ROM of the PS2. So no need to increase them Wink

I don't know for VIF but it seems for me that the lazy allocation part. Initially you reserve the virtual space let's say 32MB but you don't allocate it (therefore 0MB in RAM). Every time you hit a new page (segmentation fault), a new page will be allocated (+4KB in RAM). Beside there is an extra mechanism to reset the page to a defined value. I think recompiler buffer have a fixed size (but could be extended in the ini).
Reply
#14
I discussed with a co-worker and I'm not sure this lazy allocation is useful.
1/ There is a high probability that kernel will do a lazy allocation by default
2/ Beside, in case of memory pressure, unused page will go in the swap. Worst case is 300MB of swap so potentially a slower start time.

Now remains to understand this "grow itself capability"
Reply
#15
Many games suffer from Gif Unit - GS packet size exceeded VU memory size!

Any idea what causes it and how it can be fixed/avoided ?
Reply
#16
That is a VU error, it hasn't finished the GS packet correctly so it tries to indefinitely send data to the GS, of course we have put a limit on this (the VU memory size, it can never be bigger), which is why you get that error.
[Image: ref-sig-anim.gif]

Reply
#17
Just try not to bug up sVU if the changes happen, some games (not many though) still use sVU more effectively than mVU
Reply
#18
(11-03-2015, 11:13 PM)Saiki Wrote: Just try not to bug up sVU if the changes happen, some games (not many though) still use sVU more effectively than mVU

Do you know of specific ones? Even though this discussion is dead, it could be useful: http://forums.pcsx2.net/Thread-Keep-or-drop-superVU
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply
#19
(11-03-2015, 11:13 PM)Saiki Wrote: Just try not to bug up sVU if the changes happen, some games (not many though) still use sVU more effectively than mVU

No impact normally.
Reply
#20
(11-02-2015, 08:14 AM)gregory Wrote: It would only be enabled on machines that have at least 4GB. And also after the future 1.4 release.

So the code will be more complicated. Is this mainly for making debugging easier?
Reply




Users browsing this thread: 1 Guest(s)