[blog] MMU mini-series (2/4)
#31
(02-22-2015, 09:45 PM)willkuer Wrote: That's again quite funny. Normally I would say that if you replace all cached stuff by volatile stuff it will still work but will be slower while enabling caching can help increasing performance... You are saying more or less the contrary.
That the whole system is slower if cache is enabled sounds at least possible to me if there is some overhead in implementing the cache. That disabling the cache breaks games on the other hand sounds completely strange.

I haven't ever seen but one game that needs it personally, and I forget what it was. As far as the performance hit, I was going by what it says in the UI "(Slower)"
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply

Sponsored links

#32
* comment deleted as it's pretty much stupid Tongue2 "
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Reply
#33
Don't mix your PC cache and the emulated (or not) EE cache.

As I said, cache contains a copy of a small part of the RAM. PCSX2 doesn't bother with cache emulation because you can get all data directly from the emulated RAM. From a PS2 point of view, it means that all access are uncached. However your PC will do cached access all the times. It is not an issue because PC have big cache. My L3 cache is 20MB whereas the full mem of the PS2 is only 32MB...

Now there are some exception to the rule RAM==CACHE. For example, a volatile memory not declared as volatile. A typical SW bug! It would be possible that data in RAM is different of the cache. A game might rely on this bug/feature, so EE-Cache will need to be emulated. Every time you do a PS2 memory access, you need to update cache (lots of computing). Rules of thumb: more hardware to emulate => slower speed.
Reply
#34
(02-23-2015, 04:20 AM)ssakash Wrote: Did you read Gregory's article ?
You have some problems with courtesy, recently. I don't know what I or others did to you but I apologize for that. I hope you can talk to me in a polite manner in the future.

(02-23-2015, 11:06 AM)gregory Wrote: Rules of thumb: more hardware to emulate => slower speed.

This is clear. That's why I said
Quote:That the whole system is slower if cache is enabled sounds at least possible to me if there is some overhead in implementing the cache.


On the other hand this:
(02-23-2015, 11:06 AM)gregory Wrote: A game might rely on this bug/feature, so EE-Cache will need to be emulated.
is really strange.

If you rely on this method/bug/feature you get unexpected behavior, or? You will never know when the next time the cache is updated. So the feature that accesses a volatile but cached address will yield different results at different times. (sounds a bit like a randomizer function). Whatever the reason for the developers is to use a volatile address in cache...
Again thank you for answering!
Reply
#35
Quote:is really strange.

If you rely on this method/bug/feature you get unexpected behavior, or? You will never know when the next time the cache is updated. So the feature that accesses a volatile but cached address will yield different results at different times. (sounds a bit like a randomizer function). Whatever the reason for the developers is to use a volatile address in cache..
Let's imagine a bug. You don't know the bug exists but you will do test on the real console. There are 2 possibilities
1/ application is bad => debug => fix the bug
2/ application is working like a charm (even with a bug). It is really possible, some hardware delay could make it work.

The emulator has a different set of delay, the previously hidden bug will appears... (note: It could also be a bug in the emulator but I wanted to highligth that you have no guarantee on anything).
Reply
#36
Evil (evil smiley)
Reply




Users browsing this thread: 1 Guest(s)