Dolphin, the GameCube and Wii emulator - Forums

Hello, i've read the monthly report of march about Casper scare school and i'm throwing an idea on how to solve this issue.


If i remember correctly dolphin emulated CPU read from and write to memory in chunks,

and you have a problem when programs try to invalidate the cache because it is already written to memory


the solution I propose is to have a skeleton of cache running in parallel to the main read/write function of the CPU


Basically: i run the cache on another thread


-When the CPU write something to memory, the thread to write to cache(from CPU) is called:

-I DON't need to know the value of the chunk, it's already written to memory by the normal write function, i just need to know the chunk is modified


-When the CPU read from memory,the thread to write to cache(from memory) is called. I don't need the value immediately, i just need to :

-allocate the chunk as new in the cache

-read the value before it's overwritten by the CPU main write function

-know the chunk's address in the memory


-When the CPU modify enough chunks that the cache would be written to memory, you just discard (or invalidate) the chunk values, because they are already written to memory


-When you have to flush the cache to memory, you can discard all values


-When the cache need to be invalided, you have to finish the thread execution up to this point,which i hope should be fast, and overwrite all non-discarded chunk values back to memory

This can generate a bottleneck if it is too slow to catch up to the CPU during long period of read or write, but that needs testing




A basic structure can be a memory the size of the biggest (real) cache, and to manipulate only addresses and "states of chunks"(new or modified) in the (virtual) skeleton cache.

Then hook the read and write function of the CPU with calls to the virtual cache.

Maybe also with a buffer, you never know .


This is only possible because you don't need the cache value except when you REALLY don't (ie invalidate cache).



I'm writing this because 1. I'm curious if my knowledge of dolphin is exact and if I made any mistakes


2. i'm curious if my idea is even implementable, because seriously, i'm talking about implementing a cache emulation for four games that already works


3. if it's not, i just hope that it will give you some ways to think outside the box.

I feel this will be killed by the host processor's cache - 'sharing' data between cores requires the cache line to be evicted from the l1 of CORE1 then read in to the l1 of CORE2. This is relatively expensive - often in the order of hundreds of cycles (depending on topology, implementation details and where in the cache the contended data currently is).

Doing this at every memory read or write will likely make it slower than just running the cache logic on the same CPU as running the JIT itself - which is how the current cache code is implemented.

Part of the problem is actually getting proper cache support. The other part of the problem is making it fast enough to be usable in the games that need it.