Failed to compile shader (GWLE6L)

[triad]

(07-29-2014, 02:08 PM)triad Wrote: Unfortunately it's not "exactly" playable due to a horrible graphics glitch (see attached). I get loosely similar behavior in other games as well - certain textures with similar effects, or similar effect from bloom shaders washing out large portions of the frame - but this is unusually bad. (Note that the cinematics and menu screen don't show this problem.)

I've made a partial breakthrough... the problem is somewhere in the logic of what WriteFog adds to the shader. If I disable that, things look MUCH better (and not just in this game).

Note that the 'disable fog' option does NOT help!

---

(08-31-2014, 08:56 AM)triad Wrote:

(07-29-2014, 02:08 PM)triad Wrote: Unfortunately it's not "exactly" playable due to a horrible graphics glitch (see attached). I get loosely similar behavior in other games as well - certain textures with similar effects, or similar effect from bloom shaders washing out large portions of the frame - but this is unusually bad. (Note that the cinematics and menu screen don't show this problem.)

I've made a partial breakthrough... the problem is somewhere in the logic of what WriteFog adds to the shader. If I disable that, things look MUCH better (and not just in this game).

Note that the 'disable fog' option does NOT help!

Okay, I may be stuck...

Something is going bonkers at this line:

Code:

int ifog = iround(fog * 256.0);

If I change that to any reasonable value (0 - 255), things work reasonably. Otherwise it's busted. At a guess, 'fog' here is a non-finite number, which is somehow causing the GPU to go screwy when converting it to an int. (And calling clamp() doesn't help.) So the real question is, why is 'fog' a screwy number?

[pauldacheez]

Some previous fog issues in Dolphin have been caused by floating-point rounding errors in the emulated CPU. There's been a *lot* of floating-point work recently – wanna try bisecting it?

[triad]

(09-01-2014, 04:34 AM)pauldacheez Wrote: Some previous fog issues in Dolphin have been caused by floating-point rounding errors in the emulated CPU. There's been a *lot* of floating-point work recently – wanna try bisecting it?

...from when? Any suggestions (i.e. starting tag/SHA)? Also, is this sort of thing going to show up playing with a FIFO or would I have to re-run the actual game?

(It's been like this since circa 7/28 at least, depending on what you mean by "recently"... Also, I've tried and utterly failed to build any of the 4.x 'release branches', which likely limits how far I could go back.)

[pauldacheez]

Sorry for the late reply, I have waaaaay too many useless tabs open.

>...from when? Any suggestions (i.e. starting tag/SHA)?
The range you'd want to bisect through is pretty wide, but bisecting should make that a non-issue. I'd start at 4.0-962, since that was just before the first of the FP changes. (Well, technically the second, but the previous one (merged in 4.0-404) was reverted, IIRC.) Use this page to wrap your head around the version numbers: https://changes.dolphin-emu.org/ If you have to go back further, there are more pages. https://changes.dolphin-emu.org/page.01.html

>Also, is this sort of thing going to show up playing with a FIFO or would I have to re-run the actual game?
You'd have to re-run the actual game. FIFO logs only contain commands sent to the GPU; they don't run the code that originally generated them, so if that code is what screwed up, the FIFO log is irreversibly gonna have the issue too.

>(It's been like this since circa 7/28 at least, depending on what you mean by "recently"...
By recently I usually mean "a few months". Development isn't extremely fast, and I have a pretty decent memory of what variety of changes have been done to some area of the code over the last year or three.

>Also, I've tried and utterly failed to build any of the 4.x 'release branches', which likely limits how far I could go back.)
If it's the kind of issue where your version of gcc is too new, you can likely install an older version alongside your current one and futz with the CMakeLists.txt to force it to use the older gcc. Any system-installed libraries that Dolphin tries and fails to use can be easily worked around by forcing Dolphin to use its preincluded copies, which you'd again want to do in CMakeLists.txt.

Yeah, this is pretty time-consuming, but, hey, with the recent emphasis on CPU/JIT stuff, this kind of bug/regression investigation is valuable. Thanks for spending your time on this. <3

[triad]

(09-04-2014, 05:29 AM)pauldacheez Wrote: Sorry for the late reply, I have waaaaay too many useless tabs open.

Hah! Been there .

(09-04-2014, 05:29 AM)pauldacheez Wrote:

(09-01-2014, 07:02 AM)triad Wrote: ...from when? Any suggestions (i.e. starting tag/SHA)?

The range you'd want to bisect through is pretty wide, but bisecting should make that a non-issue. I'd start at 4.0-962, since that was just before the first of the FP changes.

Okay, starting with f9ed70b... Fortunately it looks like that built okay. And... huh, it also doesn't have the problem that originally started this thread. Or crazy broken fog! So, hopefully bisecting will be useful. (I've run into some problems in the past with long strings of SHA's that don't build, but at least I can confirm that it was good at this point.)

Also... RO8E7D doesn't crash on startup (as it does on master), although RO7E7D, which does run on master, doesn't on 4.0-962 (FIFO 'Unknown Opcode (0x3f)'). Go figure.

Anyway, this might take a while (probably days, not hours), but thanks!

[triad]

(09-04-2014, 05:29 AM)pauldacheez Wrote: The range you'd want to bisect through is pretty wide, but bisecting should make that a non-issue. I'd start at 4.0-962, since that was just before the first of the FP changes.

Okay, starting with f9ed70b... Fortunately it looks like that built okay. And... huh, it also doesn't have the problem that originally started this thread. Or crazy broken fog! So, hopefully bisecting will be useful.
[/quote]

f9ed70b - good
ddce7e9 - bad
5a5e63b - bad
12c2e34 - bad
610a6f9 - good

3d0116e... is good, and I poked it a little harder than the others for variety... RO7E7D runs there, and doesn't have the horrid blown-out bloom effects as can be seen in the screen shots I posted to [1]. So that's definitely the same issue. And... I won't know for sure until I check on master again, but it seems like the opening movies are less choppy also.

0238a56... I'm not sure. I don't get any of the blown-out garbage, but I am getting the original issue that started this thread, and I'm not sure I'm getting any of the effects that the FPU glitch affects, so I'm not sure if the FPU bits are working or just not being tickled.

That's all for tonight. I'll poke at it more later.

1: https://forums.dolphin-emu.org/Thread-efb-to-texture-problems (note that the EFB issue described here is totally unrelated; still seen in 3d0116e as it was in 3.5)

[triad]

(09-04-2014, 03:39 PM)triad Wrote: f9ed70b - good
ddce7e9 - bad
5a5e63b - bad
12c2e34 - bad
610a6f9 - good

3d0116e... is good, and I poked it a little harder than the others for variety... RO7E7D runs there, and doesn't have the horrid blown-out bloom effects as can be seen in the screen shots I posted to [1]. So that's definitely the same issue. And... I won't know for sure until I check on master again, but it seems like the opening movies are less choppy also.

0238a56... I'm not sure. I don't get any of the blown-out garbage, but I am getting the original issue that started this thread, and I'm not sure I'm getting any of the effects that the FPU glitch affects, so I'm not sure if the FPU bits are working or just not being tickled.

22c989d - good
3a63899 - bad
e7a42d8 - good
0238a56 - don't know
c13a5c3 - don't know
ec60aca - don't know
df94e62 - don't know
21eb482 - good
68e91f0 - bad

...that's using GWLE6L as the benchmark. There's a series in there (all the "don't know") where I don't get any fog that makes it hard to tell.

Okay... RO7E7D takes longer to get to a test point, but let's try that...

df94e62 - good?
68e91f0 - um... shader compile errors and no graphics at all... so, don't know...
0238a56 - likewise? (at the wii 'allow adequate room' screen anyway; takes too long to try to get into a game)
c13a5c3 - likewise
ec60aca - good?

I'm seeing good bloom effects at least in RO7E7D, in ec60aca and df94e62, so that much at least was working as of those commits. Could be that whatever is currently broken with fog is also working there, but since I don't get fog I can't verify that. Nor can I verify that whatever's causing the blown bloom effects, assuming it's the same change, is present in 68e91f0 for similar reasons; they aren't present in 68e91f0 (along with any other graphics in RO7E7D ).

However, things went wrong, for GWLE6L at least, somewhere between 21eb482 and 68e91f0 (which is only five commits).

Given what's happening in that commit range, I'm now less confident this is a "regression" in the FPU logic as opposed to replacing "wrong" floating point math in the shaders with "more correct" integer math where the latter never worked correctly in the first place.

[triad]

Eureka! It is *definitely* df94e62 that is busted. If I "revert" that, stuff is no longer broken.

Here's the exact patch:

Code:

diff --git a/Source/Core/VideoCommon/PixelShaderGen.cpp b/Source/Core/VideoCommon/PixelShaderGen.cpp
index 0f03fc0..bd16dae 100644
--- a/Source/Core/VideoCommon/PixelShaderGen.cpp
+++ b/Source/Core/VideoCommon/PixelShaderGen.cpp
@@ -1052,8 +1052,7 @@ static inline void WriteFog(T& out, pixel_shader_uid_data* uid_data)
                        WARN_LOG(VIDEO, "Unknown Fog Type! %08x", bpmem.fog.c_proj_fsel.fsel);
        }

-       out.Write("\tint ifog = iround(fog * 256.0);\n");
-       out.Write("\tprev.rgb = (prev.rgb * (256 - ifog) + " I_FOGCOLOR".rgb * ifog) >> 8;\n");
+       out.Write("\tprev.rgb = int3(round(lerp(float3(prev.rgb), " I_FOGCOLOR".rgb, fog)));\n");
}

void GetPixelShaderUid(PixelShaderUid& object, DSTALPHA_MODE dstAlphaMode, API_TYPE ApiType, u32 components)

Now, I'm not saying that this should be committed, just that the math change in df94e62 is wrong.

[triad]

Hrm... well... this fixes it:

Code:

diff --git a/Source/Core/VideoCommon/PixelShaderGen.cpp b/Source/Core/VideoCommon/PixelShaderGen.cpp
index 0f03fc0..cbf5b52 100644
--- a/Source/Core/VideoCommon/PixelShaderGen.cpp
+++ b/Source/Core/VideoCommon/PixelShaderGen.cpp
@@ -1053,7 +1053,9 @@ static inline void WriteFog(T& out, pixel_shader_uid_data* uid_data)
        }

        out.Write("\tint ifog = iround(fog * 256.0);\n");
-       out.Write("\tprev.rgb = (prev.rgb * (256 - ifog) + " I_FOGCOLOR".rgb * ifog) >> 8;\n");
+       out.Write("\tprev.r = (prev.r * (256 - ifog) + " I_FOGCOLOR".r * ifog) >> 8;\n");
+       out.Write("\tprev.g = (prev.g * (256 - ifog) + " I_FOGCOLOR".g * ifog) >> 8;\n");
+       out.Write("\tprev.b = (prev.b * (256 - ifog) + " I_FOGCOLOR".b * ifog) >> 8;\n");
}

void GetPixelShaderUid(PixelShaderUid& object, DSTALPHA_MODE dstAlphaMode, API_TYPE ApiType, u32 components)

...but makes me wonder if there's something wrong with mesa, here...

[degasus]

I guess it's this bug here: https://bugs.freedesktop.org/show_bug.cgi?id=85376

What happens if you use laster mesa git?