| Bug ID | 105333 |
|---|---|
| Summary | [gallium-nine] missing geometry after commit ac: replace ac_b= uild_kill with ac_build_kill_if_false |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | hadack@gmx.de |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 137765 [det=
ails]
Xorg.0.log
Since commit 1ff9e27cbdd1fe770f18e5316c6f32a867e39095 "ac: replace
ac_build_kill with ac_build_kill_if_false" the train engines in the ga=
me
Mashinky under wine with nine are missing. On branch 17.3 everything is fin=
e.
I tried different llvm(5.0.1,release_60 and master), wine and kernel versio=
ns,
makes no difference.
This is on a RX 570.
Created attachment 137=
766 [details]
screenshot with mesa 17.3
Created attachment 1377=
67 [details]
screenshot with mesa git
| What | Removed | Added |
|---|---|---|
| Keywords | bisected, regression |
Would you make and upload an apitrace of the game demonstratin= g the issue? There is an ftp for traces of Gallium Nine, you can ask in Freenode #d3d9 channel for the password, or simply use google drive or other better file sharing. The trace might be kept for future regression testing. (Unless you explicit= ly oppose.) It would be nice if you also open issue at github ixit.Mesa-3D, where most = of Gallium Nine bugs are tracked. Since the bug itself is outside of Nine, it is good that you have it filled here. BTW, since the bug is regression and you've located it, be sure to put the regression and bisected tags/keywords. I just added them. It help developer= s if they know that the mundane and time consuming work has already been done. (I hope.)
Thanks for the infos! I will make a apitrace and upload it, but it will take me some days. I will then also open a report on the github page.
I tried to make an apitrace, but it crashes for me when replay= ing. The apitrace can be downloaded here: https://www.dropbox.com/s/ynr9v7ls561qgdw/Mashinky.6.trace?dl=3D0 I opened a bug at the ixit github side here: https://github.com/i= Xit/Mesa-3D/issues/314
| What | Removed | Added |
|---|---|---|
| Assignee | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |
| QA Contact | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |
| Component | Drivers/Gallium/radeonsi | Gallium/StateTracker/galliumnine |
| What | Removed | Added |
|---|---|---|
| Component | Gallium/StateTracker/galliumnine | Drivers/Gallium/radeonsi |
| Assignee | mesa-dev@lists.freedesktop.org | dri-devel@lists.freedesktop.org |
| CC | maraeo@gmail.com | |
| QA Contact | mesa-dev@lists.freedesktop.org | dri-devel@lists.freedesktop.org |
(In reply to Axel Davy from comment #6) > Given the regression bisect found the issue came= with a radeonsi patch, I > reassign to radeonsi. Maybe the patch introduces a small difference in= the > driver behaviour that regresses nine ? Well you can do that but it's unlikely to be investigated by anyone not interested in gallium-nine which is why I moved it there.
ac_build_kill used an intrinsic that is no longer in LLVM. ac_build_kill_if_false replaced it. The behavior should be identical.
You can try to set glsl_correct_derivatives_after_discard=3Dtr= ue, but I don't know if that works with nine.
(In reply to Marek Ol=C5=A1=C3=A1k from comment #9) > You can try to set glsl_correct_derivatives_afte= r_discard=3Dtrue, but I don't > know if that works with nine. I tried with the env variable set with latest git checkout of llvm and mesa= and the bug is still there.=20 Is there anything else i could try, like getting some logs or so?
(In reply to Marek Ol=C5=A1=C3=A1k from comment #9) > You can try to set glsl_correct_derivatives_afte= r_discard=3Dtrue, but I don't > know if that works with nine. Setting glsl_correct_derivatives_after_discard should work with nine.
It's possible that nine ignores the env var.
I inserted a printf inside the if condition that calls driQuer= yOptionb on this option in si_pipe.c and ran a nine app, and it did print, so the env var is= not ignored.
The app uses both alpha test and kill_if (with some kill_if in= side an if). Maybe an issue combining ifs ? I see old code was doing a min between the k= ill conditions, not sure how it is handled now.
| What | Removed | Added |
|---|---|---|
| CC | davyaxel0@gmail.com |
Created attachment =
141686 [details]
potentially the buggy shader
Here is a shader that may be the buggy one ?
Thanks with iive who was running a trace on his side (r600 doesn't have the
bug), we identified a drawcall where the engine would appear on his side and
not mine (radeonsi).
The draw calls has alpha test disabled, but has stencil test enabled.
I used monolithic shader to ease reading.
It may be a false alarms, as the conditions of the test cannot guarantee th=
is
is really the first moment the two cards have a difference in their renderi=
ng
(which may affect the stencil test for example).
| What | Removed | Added |
|---|---|---|
| Attachment #141686 is obsolete | 1 |
Created attachment 141=
687 [details]
probably the buggy shader
Ok, so we figured out the shader I mentionned in my last message was suppos=
ed
to render on top of a "white" engine which didn't appear on radeo=
nsi.
So here is now the shader that draws (earlier) the "white" engine.
This one has alpha test enabled and stencil test enabled. There are two ver=
sion
of the shader in the log that get compiled (I guess two alpha test set of
parameters), I don't know which is used, thus I put both.
It features on kill_if inside an if. Perhaps something to look at.
My investigation found that the alpha test for this shader alw= ays passes, so we can discard that (I also tried disabling it). As for the stencil test, it is set to always pass, so it's not that either. To play with the shader, I disabled some texkill instructions, and found th= at if I disabled all third texkill (texkill =3D=3D kill_if) instructions in al= l the ps shaders, it would work. Hopefully, this is not due to some interference with some previous shader. The third kill_if instruction in this shader is: DCL IN[4], COLOR[1], COLOR, CENTROID 31: MOV TEMP[1], IN[4].wwww 32: KILL_IF TEMP[1] and if I can extract the ISA correctly: v_interp_p1_f32 v4, v0, attr4.w=20 v_interp_p2_f32 v4, v1, attr4.w=20 v_cmpx_le_f32_e32 vcc, 0, v4=20 (note v_cmpx_le_f32_e32 is v_cmpx_lt_f32_e32 in the attached shader, due to= a test I had done around that, but that doesn't change anything) It doesn't look wrong, I don't understand why it causes this behaviour (it kills too much).
PixWin enables to use ProcessVertices which outputs the vs sha= der outputs. I looked at the output which would give the IN[4].w If found that for llvmpipe (used for ProcessVertices) the vs output is betw= een 0 and 1. However I tried with radeonsi, and... it displays a NaN for that output... I guess one of the input is NaN and llvmpipe clamps it (the vs output is the subtraction between two vs inputs). If that output is really NaN, I guess it can explain the regression. A small change (x < 0 vs 0 > x) will give different result with NaN. I tried to change the order for the test in radeonsi's kil_emit, but the generated isa doesn't change the test order between 0 and x.
Allowing NaN to not be rejected by the kill test by replacing = in radeonsi's kil_emit LLVMRealOGE by LLVMRealUGE works. Is that ok relative to the gl spec ?
Hi, I can confirm that the patch on the mailing list fixes the= bug, thanks a lot! I will close this when the patch lands.