Created attachment 137765 [details] Xorg.0.log Since commit 1ff9e27cbdd1fe770f18e5316c6f32a867e39095 "ac: replace ac_build_kill with ac_build_kill_if_false" the train engines in the game Mashinky under wine with nine are missing. On branch 17.3 everything is fine. I tried different llvm(5.0.1,release_60 and master), wine and kernel versions, makes no difference. This is on a RX 570.
Created attachment 137766 [details] screenshot with mesa 17.3
Created attachment 137767 [details] screenshot with mesa git
Would you make and upload an apitrace of the game demonstrating 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 explicitly 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 developers 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 replaying. The apitrace can be downloaded here: https://www.dropbox.com/s/ynr9v7ls561qgdw/Mashinky.6.trace?dl=0 I opened a bug at the ixit github side here: https://github.com/iXit/Mesa-3D/issues/314
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 ?
(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=true, but I don't know if that works with nine.
(In reply to Marek Olšák from comment #9) > You can try to set glsl_correct_derivatives_after_discard=true, 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. Is there anything else i could try, like getting some logs or so?
(In reply to Marek Olšák from comment #9) > You can try to set glsl_correct_derivatives_after_discard=true, 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 driQueryOptionb 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 inside an if). Maybe an issue combining ifs ? I see old code was doing a min between the kill conditions, not sure how it is handled now.
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 this is really the first moment the two cards have a difference in their rendering (which may affect the stencil test for example).
Created attachment 141687 [details] probably the buggy shader Ok, so we figured out the shader I mentionned in my last message was supposed to render on top of a "white" engine which didn't appear on radeonsi. 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 version 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 always 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 that if I disabled all third texkill (texkill == kill_if) instructions in all 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 v_interp_p2_f32 v4, v1, attr4.w v_cmpx_le_f32_e32 vcc, 0, v4 (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 shader 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 between 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 ?
It's fine with me.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.