From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads. Date: Sun, 12 Feb 2017 15:34:55 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1303806883==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id D899E6E31A for ; Sun, 12 Feb 2017 15:34:55 +0000 (UTC) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1303806883== Content-Type: multipart/alternative; boundary="14869136950.f48dcbD0E.20889"; charset="UTF-8" --14869136950.f48dcbD0E.20889 Date: Sun, 12 Feb 2017 15:34:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D99780 Bug ID: 99780 Summary: Flickering artifacts in radeonsi driver with divergent texture reads. Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: dark_sylinc@yahoo.com.ar QA Contact: dri-devel@lists.freedesktop.org Created attachment 129530 --> https://bugs.freedesktop.org/attachment.cgi?id=3D129530&action=3Dedit Sample repro I'm an Ogre3D developer. We noticed after updating to LLVM 4.0 that there were visual glitches: http://imgur.com/43tIuI6 http://imgur.com/iBhxoBj (this glitches tend to flicker over time *even if everything is stationary*) This bug is *NOT* present if using LLVM 3.9.1 This bug happens with radeon open source drivers. Using llvmpipe works as intended. I tried to reproduce this bug in a clean environment but failed. So instead= I stripped down as much as possible to a minimal repro sample out of our code; which I am attaching. We noticed that this flicker happens alongside the difference between the P= SSM splits, but not always: http://imgur.com/130B4mE We added a tint to differentiate the splits. But as you can see there are a= few artifacts that happens within one tint; though the vast majority of the artifacts happens alongside the line. A PSSM split in shader code means this: uniform sampler2DShadow texShadowMap[2]; float fShadow =3D 1.0; vec3 tint =3D vec3( 1, 1, 1 ); if( inPs.depth <=3D pass.pssmSplitPoints0 ) { fShadow =3D getShadow( texShadowMap[0], inPs.posL0, vec4( 0.000488281, 0.000488281, 1, 1 ) ); tint =3D vec3( 0.0, 0, 1 ); } else if( inPs.depth <=3D pass.pssmSplitPoints1 ) { fShadow =3D getShadow( texShadowMap[1], inPs.posL1, vec4( 0.000976562, 0.000976562, 1, 1 ) ); tint =3D vec3(0.0, 1.0, 0.0 ); } Everything from inPs comes from the vertex shader. After stripping down as much as possible, our getShadow declaration is this: float getShadow( sampler2DShadow shadowMap, vec4 psPosLN, vec4 invShadowMap= Size ) { float fDepth =3D psPosLN.z; vec2 uv =3D psPosLN.xy / psPosLN.w; float retVal =3D 0; vec2 fW; vec4 c; retVal +=3D texture( shadowMap, vec3( uv, fDepth ) ).r; return retVal; } I've seen a similar artifact before in the Windows AMD drivers back when I = was experimenting with bindless textures and I purposedly managed to mix textur= es from divergent branches into the same wavefront. Not sure if that's what's happening here though. Just run launchapp.sh; select OpenGL renderer, and click accept. It will la= unch the sample. NOTE: If when running the sample you encounter this problem: Created GL 4.3 context libGL error: failed to create drawable libGL error: failed to create drawable X Error of failed request: 0 Major opcode of failed request: 156 (GLX) Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) Serial number of failed request: 28 Current serial number in output stream: 28 The just run it again. I do not know why this happens, it happens rarely (l= ike 1 in 10 runs) and I haven't yet been able to determine why. It sounds like a race condition inside Mesa (because the bug won't manifest while debugging where loading is significantly slowed down loading all symbols), but I don't have enough evidence to back this up, and it's not the reason of this bug ticket.=20 If you have more issues running the sample let me know, I can provide assistance. This sample needs SDL2 to be installed in your system. I'm using AMD Radeon HD 7770 1GB Ubuntu 16.10 Mesa git 5bc222ebafddd14f2329f5096287b51d798a6431 LLVM 4.0 SVN 293947 Kernel 4.8.0-37-generic --=20 You are receiving this mail because: You are the assignee for the bug.= --14869136950.f48dcbD0E.20889 Date: Sun, 12 Feb 2017 15:34:55 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated
Bug ID 99780
Summary Flickering artifacts in radeonsi driver with divergent textur= e reads.
Product Mesa
Version unspecified
Hardware x86-64 (AMD64)
OS Linux (All)
Status NEW
Severity normal
Priority medium
Component Drivers/Gallium/radeonsi
Assignee dri-devel@lists.freedesktop.org
Reporter dark_sylinc@yahoo.com.ar
QA Contact dri-devel@lists.freedesktop.org

Created attachment 129530 =
[details]
Sample repro

I'm an Ogre3D developer.

We noticed after updating to LLVM 4.0 that there were visual glitches:
http://imgur.com/43tIuI6
http://imgur.com/iBhxoBj
(this glitches tend to flicker over time *even if everything is stationary*)
This bug is *NOT* present if using LLVM 3.9.1
This bug happens with radeon open source drivers. Using llvmpipe works as
intended.

I tried to reproduce this bug in a clean environment but failed. So instead=
 I
stripped down as much as possible to a minimal repro sample out of our code;
which I am attaching.

We noticed that this flicker happens alongside the difference between the P=
SSM
splits, but not always:
http://imgur.com/130B4mE
We added a tint to differentiate the splits. But as you can see there are a=
 few
artifacts that happens within one tint; though the vast majority of the
artifacts happens alongside the line.

A PSSM split in shader code means this:
uniform sampler2DShadow texShadowMap[2];
float fShadow =3D 1.0;
vec3 tint =3D vec3( 1, 1, 1 );
if( inPs.depth <=3D pass.pssmSplitPoints0 )
{
    fShadow =3D getShadow( texShadowMap[0], inPs.posL0, vec4( 0.000488281,
0.000488281, 1, 1 ) );
    tint =3D vec3( 0.0, 0, 1 );
}
else if( inPs.depth <=3D pass.pssmSplitPoints1 )
{
    fShadow =3D getShadow( texShadowMap[1], inPs.posL1, vec4( 0.000976562,
0.000976562, 1, 1 ) );
    tint =3D vec3(0.0, 1.0, 0.0 );
}

Everything from inPs comes from the vertex shader.

After stripping down as much as possible, our getShadow declaration is this:
float getShadow( sampler2DShadow shadowMap, vec4 psPosLN, vec4 invShadowMap=
Size
)
{
        float fDepth =3D psPosLN.z;
        vec2 uv =3D psPosLN.xy / psPosLN.w;

        float retVal =3D 0;

        vec2 fW;
        vec4 c;

        retVal +=3D texture( shadowMap, vec3( uv, fDepth ) ).r;

        return retVal;
}


I've seen a similar artifact before in the Windows AMD drivers back when I =
was
experimenting with bindless textures and I purposedly managed to mix textur=
es
from divergent branches into the same wavefront. Not sure if that's what's
happening here though.

Just run launchapp.sh; select OpenGL renderer, and click accept. It will la=
unch
the sample.

NOTE: If when running the sample you encounter this problem:
Created GL 4.3 context
libGL error: failed to create drawable
libGL error: failed to create drawable
X Error of failed request:  0
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  26 (X_GLXMakeContextCurrent)
  Serial number of failed request:  28
  Current serial number in output stream:  28

The just run it again. I do not know why this happens, it happens rarely (l=
ike
1 in 10 runs) and I haven't yet been able to determine why. It sounds like a
race condition inside Mesa (because the bug won't manifest while debugging
where loading is significantly slowed down loading all symbols), but I don't
have enough evidence to back this up, and it's not the reason of this bug
ticket.=20

If you have more issues running the sample let me know, I can provide
assistance. This sample needs SDL2 to be installed in your system.

I'm using AMD Radeon HD 7770 1GB
Ubuntu 16.10
Mesa git 5bc222ebafddd14f2329f5096287b51d798a6431
LLVM 4.0 SVN 293947
Kernel 4.8.0-37-generic


You are receiving this mail because:
  • You are the assignee for the bug.
= --14869136950.f48dcbD0E.20889-- --===============1303806883== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1303806883==--