https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #19 from Timothy Arceri ---
Ok here is a piglit test for the original GLSL IR bug:
https://patchwork.freedesktop.org/patch/213332/
The NIR bug is a little harder to test reliably for since it depends on the
order in which optimisat
https://bugs.freedesktop.org/show_bug.cgi?id=105670
i...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #17 from Timothy Arceri ---
We still need to create a piglit test for this but here is the fix for NIR
also:
https://patchwork.freedesktop.org/patch/212882/
It seems once the loop in unrolled NIR then optimises this whole shader do
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #16 from i...@yahoo.com ---
(In reply to Timothy Arceri from comment #15)
> Here is a fix for drivers that use GLSL IR loop unrolling. I'm still looking
> into NIR unrolling it seems there is a different bug in that pass.
>
> https:/
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #15 from Timothy Arceri ---
Here is a fix for drivers that use GLSL IR loop unrolling. I'm still looking
into NIR unrolling it seems there is a different bug in that pass.
https://patchwork.freedesktop.org/patch/212881/
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #14 from almos ---
(In reply to Roland Scheidegger from comment #5)
> (In reply to almos from comment #4)
> > The problem is not loop unrolling. The problem is that userspace code can
> > hang the GPU unrecoverably, and thus bringing
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #13 from Gert Wollny ---
The GLSL spec says that "negative zeros are generated as dictated by IEEE" and
that "==" returns the correct result, which I'd assume means (0.0 == -0.0) is
true.
In any case, I don't see how this is releva
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #12 from i...@yahoo.com ---
(In reply to Gert Wollny from comment #11)
> The if statement can be be true because
> which means at this point R3.w can be zero.
But that's the point in my initial question.
When R3.w=0.0, will "if(+0.
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #11 from Gert Wollny ---
The if statement can be be true because
tmp0.w = (R3.w >= 0.0 ? abs(ps_lc18.w) : abs(ps_lc18.y));
with ps_lc18.y = -1 and ps_lc18.w = 0.0, and then
R3.w = (tmp0.w);
R3.w = (R5.w * R3.w);
which
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #10 from i...@yahoo.com ---
(In reply to Gert Wollny from comment #9)
> Actually,
> if (R3.w != -R3.w)
> will never fail, because R3.w = R0.w = (ps_lc17.y) = 1.0;
You are correct for the "if" with the "break".
However my questio
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #9 from Gert Wollny ---
Actually,
if (R3.w != -R3.w)
will never fail, because R3.w = R0.w = (ps_lc17.y) = 1.0;
The compiler should optimize this away, and in my attempts to create a piglit
it always did so far.
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #8 from i...@yahoo.com ---
Created attachment 138335
--> https://bugs.freedesktop.org/attachment.cgi?id=138335&action=edit
Fragment/Pixel Shader generated by Wine3.3, extracted from lookup of #55251 op
in the trace.
It's quite simp
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #7 from Gert Wollny ---
I tried to create a piglit, but so far i failed. So here is a dumped down
version of the loop contained in the relevant shader:
const vec4 ps_lc21 = vec4(5.e-01, -5.e-01,
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #6 from Timothy Arceri ---
(In reply to Gert Wollny from comment #2)
> I can confirm this on Radeon 6870 HD.
>
> I was able to track the issue to the series beginning with
>
>ab23b759f24 glsl: don't drop instructions from un
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #5 from Roland Scheidegger ---
(In reply to almos from comment #4)
> The problem is not loop unrolling. The problem is that userspace code can
> hang the GPU unrecoverably, and thus bringing down the entire system.
>
> BTW I can con
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #4 from almos ---
The problem is not loop unrolling. The problem is that userspace code can hang
the GPU unrecoverably, and thus bringing down the entire system.
BTW I can confirm this on Pitcairn with radeon drm in linux 4.15.
--
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #3 from Roland Scheidegger ---
(In reply to Gert Wollny from comment #2)
> Regarding bisecting this, after a failure one usually must reboot the
> system, otherwise the graphics card is in a bad state. But given the nature
> of the b
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #2 from Gert Wollny ---
I can confirm this on Radeon 6870 HD.
I was able to track the issue to the series beginning with
ab23b759f24 glsl: don't drop instructions from unreachable
terminators continue branch
https://bugs.freedesktop.org/show_bug.cgi?id=105670
--- Comment #1 from Tapani Pälli ---
Could be related to loop unrolling (?) While playing back trace on i965 I saw
this:
--- 8< ---
glretrace: ../src/compiler/nir/nir_opt_loop_unroll.c:414: complex_unroll:
Assertion `unroll_loc->type == nir_cf_
https://bugs.freedesktop.org/show_bug.cgi?id=105670
Bug ID: 105670
Summary: [regression][hang] Trine1EE hangs GPU after loading
screen on Mesa3D-17.3 and later
Product: Mesa
Version: 17.3
Hardware: Other
OS:
20 matches
Mail list logo
