Ehrm, some EFB to Ram issues may be due to this:
http://code.google.com/p/dolphin-emu/source/detail?r=6625
According to skid return hash; should be return GetHash64(dest_ptr,size_in_bytes,g_ActiveConfig.iSafeTextureCache_ColorSamples);
Neobrain never changed it after all this time. This was causing an issue with Prince of Persia Forgotten Sands with EFB to Ram where the drawing of textures was lagging producing a blurry/blotchy mess. Changing it to what skid suggested for both DX9 and OGL fixed this issue and likely other issues.
I reported it in a comment to a specific commit that I thought was causing issues. I will open an issue if needed, but I think my reply in this thread should suffice.
(02-11-2011, 07:41 AM)Xtreme2damax Wrote: [ -> ]Neobrain never changed it after all this time. This was causing an issue with Prince of Persia Forgotten Sands
gnick79 fixed it eventually in
r6760.
Also the neobrain effectively allowed my EFB to RAM optimisation to be enabled/disabled by using the "Enable Cache" checkbox. So if you really are having issues with the optimisation (I doubt it, because it is logically sound), you can turn it off with the checkbox.
(02-11-2011, 09:24 AM)skid Wrote: [ -> ] (02-11-2011, 07:41 AM)Xtreme2damax Wrote: [ -> ]Neobrain never changed it after all this time. This was causing an issue with Prince of Persia Forgotten Sands
gnick79 fixed it eventually in r6760.
That wasn't the same fix you suggested though.
You suggested to change:
return hash;
to
return GetHash64(dest_ptr,size_in_bytes,g_ActiveConfig.iSafeTextureCache_ColorSamples);
The problem with PoP:FS with EFB to Ram occurred regardless whether or not the cache was enabled.
You can see the issue with PoP:FS by enabling EFB to Ram, then change that line and it should fix the issue.
Hmm, maybe the commit of gnick's you pointed out wasn't correct? I noticed the cache doesn't work after changing the line I pointed out, it's always enabled but gnick's seems to cause problems with PoP:FS?
(02-11-2011, 09:44 AM)Xtreme2damax Wrote: [ -> ]That wasn't the same fix you suggested though.
It does the same thing. Two different ways to write the same function. That was the reason why I +1'd gnick79's commit.
(02-11-2011, 09:44 AM)Xtreme2damax Wrote: [ -> ]Hmm, maybe the commit of gnick's you pointed out wasn't correct? I noticed the cache doesn't work after changing the line I pointed out, it's always enabled but gnick's seems to cause problems with PoP:FS?
I don't have an explanation for what you are seeing here. I don't know.
Clearly the issue with PoP:FS is due to the new efb to ram code, by changing the line I pointed out the issue is resolved but I can't disable the cache.
It's gnick's code in TextureConverter.cpp thats causing it or the fact that return hash; needs to be changed to what you suggested otherwise it causes problems in PoP:FS with EFB to Ram.
That enable-efb-to-ram-cache thing is a nice speedup hack, but heavily depends on the ATC setting since the EFB hash is affected by this setting. If you only use an "unsafe" ATC you'll end up missing some texture updates, which is why that cache results in the same behavior as EFB to texture in nsmbw (unless you set ATC to safe, which kinda defeats the purpose of the hack).
If you disable the hack, you right now end up reloading the RAM data each time into the texture which is kinda slow. Additionally due to some bad code design we're doing an almost totally useless EFB copy to texture which makes the EFB copy to RAM implementation even slower than before... Instead of that EFB copy cache option we should actually have "EFB to RAM", "Hybrid EFB to RAM" and "EFB to texture" as options, which would be a lot cleaner. That's on my TODO list but I havent got around implementing it, yet.
Quote: Instead of that EFB copy cache option we should actually have "EFB to RAM", "Hybrid EFB to RAM" and "EFB to texture" as options, which would be a lot cleaner. That's on my TODO list but I havent got around implementing it, yet.
I remember suggesting this back when hybrid efb to ram was first introduced. But I was shot down by everyone (including you) because it was said that hybrid efb to ram was just as accurate as real efb to ram but significantly faster, so their was no point. Has something changed since then?
Back then I didn't know that Hybrid EFB copies depend on ATC and thus would be error-prone. I'd need to look again how that stuff was implemented before skid's optimization, but IIRC I only thought of that problem after that...