| Bug ID | 111241 |
|---|---|
| Summary | Shadertoy shader causing hang |
| Product | Mesa |
| Version | 19.1 |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | mail@felix-potthast.de |
| QA Contact | dri-devel@lists.freedesktop.org |
When opening https://www.shadertoy.com/view/3lsXDB on my Desktop PC with Radeon HD 7870 Graphics card (Pitcairn) i get a freeze. It works fine on my Laptop with Intel Graphics. Both systems use Mesa 19.1.3
I could reproduce the issue on a Raven Ridge and a Navi10. But when using NIR (radeonsi_enable_nir=3Dtrue env variable) the shader is perfectly usable.
RX 580 / NIR amd-staging-drm-next Mesa git Firefox 68.0.1 [42489.228053] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 [42494.348053] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,= but soft recovered [42508.171689] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [42513.035801] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,= but soft recovered [42556.811021] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 [42561.418927] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,= but soft recovered [42571.658863] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,= but soft recovered
Here's my understanding of the issue.
This shader uses 2 passes:
- the first pass has BufferA as input and output and does:
if (first frame)
// init bufferA content
else
// do something useful
- the 2nd pass has BufferA as input and does:
N =3D texelFetch(bufferA)
for(i=3D0; i < N; i++)
// do something
The problem here is the "// init bufferA content": it fails to in=
itialize the
buffer content properly, leading to an infinite loop in the 2nd pass.
The exact code is:
if (iFrame=3D=3D0) { O -=3D O; return; }
If one replaces this line with:
if (iFrame=3D=3D0) { O =3D vec4(0.0f); return; }
The shader works fine (you can test the modified version here:
https://www.shadertoy.com=
/view/wtSXzw ).
Created attachment 14=
4993 [details]
tgsi version of the shader
Created attachment 144994 [d=
etails]
nir version
I've created a different shadertoy showing the problem: https://www.shadertoy.com= /view/Wt2SW1 (but this one doesn't hang the GPU). The shader for "Buffer A" is: 0: MOV TEMP[0], SV[0] 1: MAD TEMP[0].y, SV[0], CONST[0][2].xxxx, CONST[0][2].yyyy 2: MOV OUT[0], IMM[0].xxxx 3: USEQ TEMP[1].x, CONST[0][1].xxxx, IMM[1].xxxx 4: UIF TEMP[1].xxxx 5: ADD TEMP[2], TEMP[2], -TEMP[2] 6: ELSE [...] 13: MOV OUT[0], TEMP[2] 14: END TEMP[2] is used before being assigned a value, so I suppose that's what all= ows LLVM to turn line 5 in: v_mov_b32_e32 v3, 0x7fc00000 v_mov_b32_e32 v2, 0x7fc00000 v_mov_b32_e32 v1, 0x7fc00000 v_mov_b32_e32 v0, 0x7fc00000 (ie: output is NaN) A possible way to fix this is to transform "dst =3D x - x" operat= ions in "dst =3D 0" which is what nir does in its nir_opt_algebraic pass. I've open a MR to fix/discuss this issue: ht= tps://gitlab.freedesktop.org/mesa/mesa/merge_requests/1681
Works for me with commit # glsl: replace 'x + (-x)' with constant 0 https://cgit.freedesktop.org/mesa/mesa/commit= /?id=3D47cc660d9c19572e5ef2dce7c8ae1766a2ac9885 Thanks Pierre-Eric!
BTW Pierre-Eric can you look into this Shadertoy shader corruption, too? https://www.shadertoy.com= /view/Xt3cWS I get it with Konqueror 5.0.97 KDE Frameworks 5.61.0 Qt 5.13.0 And Firefox 68.0.1
Created attachmen=
t 145215 [details]
Shadertoy-EOT-Grid-scene-2.png
(In reply to Dieter N=C3=BCtzel from comment #9) > Created attachment 145215 [details] > Shadertoy-EOT-Grid-scene-2.png Saw it first @ 2. November 2018
(In reply to Dieter N=C3=BCtzel from comment #8) > BTW >=20 > Pierre-Eric can you look into this >=20 > Shadertoy shader corruption, too? > https://www.shaderto= y.com/view/Xt3cWS > The "Buffer A" shader doesn't write fragColor when uv.y is < 0= .1 or > 0.9. So the content is undefined and may be black on some platform or random. radeonsi is correct here, but we might want to replace undef values with 0x= 0 to get a default value instead of random.
(In reply to Pierre-Eric Pelloux-Prayer from comment #11) > (In reply to Dieter N=C3=BCtzel from comment #8) > > BTW > >=20 > > Pierre-Eric can you look into this > >=20 > > Shadertoy shader corruption, too? > > https://www.sha= dertoy.com/view/Xt3cWS > > >=20 > The "Buffer A" shader doesn't write fragColor when uv.y is &= lt; 0.1 or > 0.9. >=20 > So the content is undefined and may be black on some platform or rando= m. >=20 > radeonsi is correct here, but we might want to replace undef values wi= th 0x0 > to get a default value instead of random. Cool to have you around for bug hunting...;-) Any hints where I shoud change 'undef values with 0x0' for testing? And sorry that I 'hijacked' this thread - should I open a new ticket?
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
(In reply to Dieter N=C3=BCtzel from comment #12) > (In reply to Pierre-Eric Pelloux-Prayer from comment #11) > > (In reply to Dieter N=C3=BCtzel from comment #8) > > > BTW > > >=20 > > > Pierre-Eric can you look into this > > >=20 > > > Shadertoy shader corruption, too? > > > https://ww= w.shadertoy.com/view/Xt3cWS > > > > >=20 > > The "Buffer A" shader doesn't write fragColor when uv.y= is < 0.1 or > 0.9. > >=20 > > So the content is undefined and may be black on some platform or = random. > >=20 > > radeonsi is correct here, but we might want to replace undef valu= es with 0x0 > > to get a default value instead of random. >=20 > Cool to have you around for bug hunting...;-) >=20 > Any hints where I shoud change 'undef values with 0x0' for testing? >=20 > And sorry that I 'hijacked' this thread - should I open a new ticket?<= /span > I don't think you need to open a bug for it at all. As its not a bug in Mesa its a shader bug. Closing this bug report as it should be fixed by: commit 47cc660d9c19572e5ef2dce7c8ae1766a2ac9885 glsl: replace 'x + (-x)' with constant 0 This fixes a hang in shadertoy for radeonsi where a buffer was initializ= ed with: value -=3D value with value being undefined. In this case LLVM replace the operation with an assignment to NaN. Cc: 19.1 19.2 <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.= cgi?id=3D111241 Reviewed-by: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com>
> > And sorry that I 'hijacked' th=
is thread - should I open a new ticket?
>=20
> I don't think you need to open a bug for it at all. As its not a bug i=
n Mesa
> its a shader bug.
>
It's not a bug in Mesa but if adopting the same behavior than other drivers=
is
cheap performance-wise I think we should consider it.
For instance, adding a prolog to PS that always initializes v0, v1, v2 to 0
could do the trick... maybe there are other/better ways though.