(11-23-2014, 01:07 PM)triad Wrote: [ -> ] (11-23-2014, 09:28 AM)zephyrsurfer Wrote: [ -> ]Can you tell me when it used to work??
3.5 is the earliest version of Dolphin I've ever used, and has the same issue. It's been like this for quite some time.
Something else I noticed... after patching the fog code so that the colors aren't so out of whack, take a close look at these two EFB dumps... even in the top half where it hasn't gone completely bonkers, there is a noticeable difference between RAM and Texture...
Try 3.0 tell me is it any different??
(11-23-2014, 01:11 PM)zephyrsurfer Wrote: [ -> ]Try 3.0 tell me is it any different??
Oh, geez... um... okay, finally figured out that per-pixel lighting is just a
bit broken in 3.0. (Nor is that all, but...)
And, no, same "streaking" in 3.0.
(It's a good thing F19 has a 3.0 RPM... I doubt I'd be willing to build that sucker...)
So... something else interesting. I tried dumping the EFB
source (i.e. the read_texture, in TextureCache::TCacheEntry::FromRenderTarget), and the data is already corrupted at that point, which seems to suggest that it isn't TextureCache::TCacheEntry::FromRenderTarget going sideways. However, I can't figure out anywhere else that where Texture vs. RAM would make a difference?
So... I think I just realized what's going on here...
If you look at the source FB, the two screen "halves" have been rendered next to each other in the source FB (either "above" or "below"... I'm not quite sure; in my raw dumps it is "below" but then everything is also upside-down). The game then does a paint operation into the EFB to a region that
overlaps both of these. I'd bet that somehow it's trying to both read and write data from the same GL texture object. (This would explain the behavior I was seeing earlier where flipping back to Texture from RAM visibly degrades over a few frames.) Whereas with RAM, the read operation is reading from a RAM copy that isn't being concurrently overwritten.
triad Wrote:So... I think I just realized what's going on here...
I will have to look at this more attentively when I'm not so tired
But could you tell me the builds that the colours regressed in? What was the first one?
I'll look at this in the morrow.
Loosely related... it occurred to me, I bet there is a rounding error (e.g. a round-up that should rather be round-down, or vice versa) somewhere mapping EFB regions that causes the weird stuff I see at non-native IR. Specifically, I bet the GL viewport when rendering to the EFB is off by one compared to what ends up being "read". (I could be wrong, though, and considering that this only happens with non-native IR, it's both rather excusable and has an easy work-around...)
(11-23-2014, 03:40 PM)zephyrsurfer Wrote: [ -> ]I will have to look at this more attentively when I'm not so tired
Thanks, I would
really love to see this put to bed considering how long it's been around
. What I haven't figured out is, how does the game read from the EFB buffers? I'm guessing that the Texture/RAM must happen automagically based on cache misses or something (?) because only the EFB "write" seems to pay any attention to that setting. If you can tell me where to look for the EFB's going the other direction I may poke around at it more myself.
(11-23-2014, 03:40 PM)zephyrsurfer Wrote: [ -> ]But could you tell me the builds that the colours regressed in?
The color issue was introduced in df94e62. Specifically, this:
Code:
prev.rgb = (prev.rgb * (256 - ifog) + cfogcolor.rgb * ifog) >> 8;
...is wonky on my system. The current theory (which I'll be able to verify once F20 has a new build that includes the relevant patch) is that this is
https://bugs.freedesktop.org/show_bug.cgi?id=85376 (i.e. mesa is compiling the shader incorrectly). See
https://forums.dolphin-emu.org/Thread-failed-to-compile-shader-gwle6l?pid=346960 for details and the patch I'm using locally (basically, does the above separately for each of r, g, b).
triad Wrote:Thanks, I would really love to see this put to bed considering how long it's been around . What I haven't figured out is, how does the game read from the EFB buffers? I'm guessing that the Texture/RAM must happen automagically based on cache misses or something (?) because only the EFB "write" seems to pay any attention to that setting. If you can tell me where to look for the EFB's going the other direction I may poke around at it more myself.
No Idea because I'm so brand new to the scene I haven't even made a PR yet
But this will be on my fix list after I make 3 pull requests soon.
One to fix a regression in WWE and the other will fix Anisotropic Filtering at high IR. The third is a regression in a game that should not affect anything else, it's been around a long time.
These are going be done very soon(a couple days at most) then I'll look at the code with EFB closely for this issue.
Could you make the commit that you mention a link as well, thanks