When running Alien Isolation with the sb optimizer it locks up in Mission 10, in the beginning of the area "Gemini Exoplanet Solutions". With R600_DEBUG=nosb the problem can be alleviated.
My first hunch was that the problem lies in sb does not always ending an ALU clause after a KILL instruction (which according to the HW documentation should be the case, but after trying to force this I'm not so sure any more, because this kind of wrong scheduling happens also earlier in the game, even in the start-up screen.
Graphics card: 6870 HD (barts).
Mesa-version: git 8045f01e2 + some patches to glsl_to_tgsi regarding register and array merging that should have no influence on r600/sb.
It also locks up if the KILL instruction is not issued at all, so it's scheduling should not be the problem.
Actually, the GPU lockups also happen without sb, only not to the point that one has to kill the program. It is likely that #104665 is actually a duplicate of this.
Now, considering that compute shaders don't use sb there are likely two issues at hand here. Without sb AI hangs quite often for a second or so (especially when opening the map), and it completely hung like reported. Without sb it has a lot less issues and never to the point that the program needs to be killed.
Created attachment 136842 [details] [review]
This change is taken from Dave Airlie CS WIP tree and is one of the hacks that didn't make it into the final patch. It seems to reduce the GPU lockups in AI. There is still at least one reproducible lockup when Alt-Tabbing out of the game. It doesn't do anything for #104665 though.
Created attachment 136871 [details]
dmesg after reboot shoing the GPU lockups
The proposed patch is actually useless. Given the way the games provides saves I didn't initially test it with the specific scene that had the lockup, and I didn't see any further lockups so far. However, going back I the bug is still there.
Running the game with
also doesn't have an influence on the GPU lockup in the described scene, so it shouldn't be related to compute shaders at all. Even though the shader TGSI dump still reports some COMP shaders getting processed, but apparently they are just compiled but not run, because the scene shows visible artifacts that are not there when the compute shaders are enabled.
> but apparently they are just compiled but not run, because the scene shows visible artifacts that are not there when the compute shaders are enabled
Does it looks like on screenshot in bug 105213 by any chance?
Maybe this helps.
Every "older" feral port has it's own "shader warmer".
Disable it in the prefereces file in ~/.local/share/feral-interactive/AlienIsolation like below...
<value name="EnableShaderWarmer" type="integer">0</value>
That's exactly the type of visual artefacts that I see when compute shaders are disabled. In any case for this bug it is not important, I only wanted to see whether this bug and  are related (which they are not)
@Darius Spitznagel: This flag doesn't change anything.
Created attachment 137570 [details] [review]
Prelimiary fix, needs testing
The problem is actually not directly with sb: in the translation from TGSI the jump offsets are not correctly evaluated when the last CF slot is ALU_EXT. I have a patch ready, only need to test whether there are any piglit regressions.
This has been fixed in git as of