https://bugs.freedesktop.org/show_bug.cgi?id=85376
Bug ID: 85376 Summary: Dolphin emulator has bad colors Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: ghallberg+bugzilla@gmail.com
Created attachment 108308 --> https://bugs.freedesktop.org/attachment.cgi?id=108308&action=edit Fifo-file which displays the discoloration
When using recent versions of dolphin-emulator with open source amd drivers, the graphics are tinted blue.
An example can be seen in this link: http://imgur.com/eLqLMdW
The example image was created when running the attached fifo-file in dolphin.
This is using the latest version of dolphin from the git-repo: 4.0.r3771.ce3a039-1 built with gcc 4.9.1-2 from the arch repositories
mesa is the 10.3.1 from the arch repositories and seems to be built with clang.
I'm running on an AMD A6-6400K APU.
I've tested the same versions of the software on my intel-based laptop, and the discoloration is not present there.
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #1 from ghallberg+bugzilla@gmail.com --- Here's a discussion thread on the dolphin forums:
https://forums.dolphin-emu.org/Thread-everything-is-the-wrong-color-on-linux...
And the change in dolphin which probably caused the behaviour to change: https://github.com/dolphin-emu/dolphin/commit/a9a8c730748b8c8a2e83feb4c38626...
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #2 from ghallberg+bugzilla@gmail.com --- Created attachment 109230 --> https://bugs.freedesktop.org/attachment.cgi?id=109230&action=edit Apitrace of the faulty fifo
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #3 from ghallberg+bugzilla@gmail.com --- Created attachment 109231 --> https://bugs.freedesktop.org/attachment.cgi?id=109231&action=edit Result of R600_DEBUG=ps,fs apitrace replay dolphin-emu.2.trace
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #4 from Markus Wick wickmarkus@web.de --- The affected shader seems to be the #22 one, but it's hard to guess what's wrong with the shader http://pastie.org/private/ccwhydvtgzw0rc1t8xdeoq
As abstract of this dolphin commit, it's basicly a rewrite of our fragment shaders with integer math, so I doubt it's useful to debug in this direction :/
About this shader, I see two uncommon features: We write to gl_FragDepth and we use a bitshift with an offset from an integer ubo. Maybe I'm lucky ...
About the issue itself, it only happens on *some* GPUs, so maybe a kind of shader compilation issue?
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #5 from ghallberg+bugzilla@gmail.com --- Created attachment 109239 --> https://bugs.freedesktop.org/attachment.cgi?id=109239&action=edit apitrace with MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #6 from ghallberg+bugzilla@gmail.com --- Created attachment 109245 --> https://bugs.freedesktop.org/attachment.cgi?id=109245&action=edit rsps_edit6
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #7 from ghallberg+bugzilla@gmail.com --- Created attachment 109247 --> https://bugs.freedesktop.org/attachment.cgi?id=109247&action=edit psfs4
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #8 from ghallberg+bugzilla@gmail.com --- Created attachment 109289 --> https://bugs.freedesktop.org/attachment.cgi?id=109289&action=edit psfs results of edit7
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #9 from ghallberg+bugzilla@gmail.com --- Created attachment 109303 --> https://bugs.freedesktop.org/attachment.cgi?id=109303&action=edit psfs results of edit9
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #10 from Ilia Mirkin imirkin@alum.mit.edu --- Some observations (from IRC, edited):
In shader 21 (from attachment 109303), we see the following:
<imirkin_> MULLO_INT R5.x, [0x00000046 9.80909e-44].x, PV.x <imirkin_> MULLO_INT R5.y, [0x00000078 1.68156e-43].x, PV.x <imirkin_> that seems wrong <imirkin_> the second PV.x uses the newly computed R5.x, no? <imirkin_> instead of the previous R5.x before the mul happened <imirkin_> so the 2nd and 3rd components get the compounded multiplication factor of .x and the respective .y and .z factor <tstellar> Starting with the R5.x value returned by the ADD_INT, the caluclation is: R5.y = ((R5.x *46) * 78); R5.z = (R5.x * 46) * 0xc8 <imirkin_> 6: UMUL TEMP[1].xyz, IMM[0].yzww, TEMP[1].xxxx <imirkin_> i'm guessing the thing that splits it up into 3 instructions forgets that it's overwriting the source <imirkin_> cayman_mul_int_instr <imirkin_> cayman-specific, and doesn't do the tmp register dance
vs the "regular" umul implementation (op2_trans) which will use a temp register if the dst mask has multiple dests. I wonder if all the cayman_* emit functions need this treatment.
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #11 from Glenn Kennard glenn.kennard@gmail.com --- Created attachment 109308 --> https://bugs.freedesktop.org/attachment.cgi?id=109308&action=edit Proposed fix
Does the attached patch fix the issue?
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #12 from ghallberg+bugzilla@gmail.com --- Created attachment 109371 --> https://bugs.freedesktop.org/attachment.cgi?id=109371&action=edit psfs output on edit9 with glennks patch
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #13 from ghallberg+bugzilla@gmail.com --- The attached patch did not help :(
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #14 from Dave Airlie airlied@freedesktop.org --- Created attachment 109650 --> https://bugs.freedesktop.org/attachment.cgi?id=109650&action=edit patch to hopefully fix
https://bugs.freedesktop.org/show_bug.cgi?id=85376
Matthew Woehlke mw_triad@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mw_triad@users.sourceforge. | |net
--- Comment #15 from Matthew Woehlke mw_triad@users.sourceforge.net --- Not sure if this is fixed or not, but I was able to isolate the GLSL where things go sideways.
This is broken:
prev.rgb = (prev.rgb * (256 - ifog) + cfogcolor.rgb * ifog) >> 8;
The above apparently should have the same effect as the following, which works correctly:
prev.r = (prev.r * (256 - ifog) + cfogcolor.r * ifog) >> 8; prev.g = (prev.g * (256 - ifog) + cfogcolor.g * ifog) >> 8; prev.b = (prev.b * (256 - ifog) + cfogcolor.b * ifog) >> 8;
So something is going sideways distributing the above operations across vector components. Seems reasonable to suspect code generation.
I tried splitting just the bitshift step with no effect, so my guess is that at least multiplying an int3 by an int is doing something wrong.
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #16 from ghallberg+bugzilla@gmail.com --- After some patches, dolphin is no segfaulting instead of showing the wong colors. I'm uploading a gdb-log and an apitrace.
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #17 from ghallberg+bugzilla@gmail.com --- Created attachment 109838 --> https://bugs.freedesktop.org/attachment.cgi?id=109838&action=edit Apitrace of dolphin crashing while running the fifo posted above
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #18 from ghallberg+bugzilla@gmail.com --- Created attachment 109839 --> https://bugs.freedesktop.org/attachment.cgi?id=109839&action=edit gdb output from crash in dolphin
https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #19 from ghallberg+bugzilla@gmail.com --- The crash was due to bad build options on my part. Fix seems to be good!
https://bugs.freedesktop.org/show_bug.cgi?id=85376
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #20 from Michel Dänzer michel@daenzer.net --- Resolving per comment #19 (you can do this yourself BTW :).
dri-devel@lists.freedesktop.org