Dolphin, the GameCube and Wii emulator - Forums

D3D will get post processing effects when someone implements it. Simple as that.

Custom Textures in latest builds should be pretty much set for the foreseeable future.

Did anyone think to check if increasing the number of ways in the emulated TLB improves performance? It should be safe since the only time games make any assumption about the TLB hardware is when they perform 64 tlbie ops on consecutive pages as a subtitute for tlbia... increasing the ways wouldn't break that assumption.

(02-05-2015, 10:29 AM)Musou-Enrai Wrote: [ -> ]I've been meaning to ask - when will the D3D plugin get Post-Processing effects and why hasn't it got any so far?
That, and one more thing about Custom Textures. I remember when the feature was implemented. It was incredible! I immediately got on with doing mods. Anyway, why do different Dolphin versions have different dump name for textures? I still haven't uploaded my texmods because I don't know when will be a good time to rename them all with the current dump names so that they're correctly read by the emulator.

Read this:

https://forums.dolphin-emu.org/Thread-ne...ure-format

If you are using latest dev builds you can now safely make and name your textures

Nice. Thanks!

(02-05-2015, 05:45 PM)tueidj Wrote: [ -> ]Did anyone think to check if increasing the number of ways in the emulated TLB improves performance? It should be safe since the only time games make any assumption about the TLB hardware is when they perform 64 tlbie ops on consecutive pages as a subtitute for tlbia... increasing the ways wouldn't break that assumption.

It would probably be worse, since most lookup operations on the TLB take O(Ways) steps. The TLB hit rate is already well over 99% in my limited testing, so the ideal algorithm is probably whatever makes the TLB lookups as fast as possible. The page table walking times basically showed up as rounding errors in my benchmarks.

Maybe that could be improved if the way pointed to by tlbe.recent was checked first (which doesn't seem to be getting updated correctly for cases that return TLB_UPDATE_C).

Is that still true? I thought I fixed that one in one of my MMU patches. Or did I fix it partially, but not set recent correctly?

Way 0 always gets checked first, and the recent index for the set does not get updated at all if TLB_UPDATE_C is returned by LookupTLBPageAddress().

Regarding which gets checked first, I think I remember trying that and I lost a few cycles because the compiler couldn't constant-fold all the accesses anymore (everything depended on recent). Latter sounds like a bug

Something needs an update :