Bugzilla – Bug 1030338
X.org / gallium / amdgpu / "Hexagonal" bug in libllvm version
Last modified: 2018-04-17 11:22:28 UTC
It seems that the libllvm used for gallium in openSUSE Leap 42.2 and also in the current development version of Leap 42.3 has a bug which is described here: https://bugs.freedesktop.org/show_bug.cgi?id=98984#c3 I don't now if this is the right place to tell, but please consider to update the libllvm used by gallium for openSUSE Leap 42.3.
Reassigning to maintainer.
Tested it now with the release version of Leap 42.3. Unfortunately the bug still exists with a Polaris 10 graphics card because it seems libllvm isn't updated (still version 3.8.0) in comparison to Leap 42.2.
Created attachment 738358 [details] Picture of the light glitches
Unfortunately we can not change the llvm version in 42.3 and it is not known which change fixed it between 3.8 and 4.0, so we have nothing to backport. In theory it could be bisected, but since building llvm is quite a pain, it may not be worth the effort. The hexagonal shapes around lights are from deferred lighting. Cities Skylines is using that method to render many small lights at once. In that model each point light has a radius beyond which it is too weak to affect anything. A simplified shape (hexagon in this case) is rendered around each light and a fragment shader may for example discard every fragment beyond the radius, or it returns zero alpha or something like that. For some reason it fails here, maybe the alpha value wraps, or some control flow is compiled badly. Even with this insight, I can't find a commit that may have fixed it. OpenSUSE Tumbleweed/Factory has LLVM4 (and soon it will have LLVM5 too), would you be fine with using Mesa and LLVM packages from Tumbleweed, or upgrading to Tumbleweed completely?
The best solution for me would be a fix in the Leap 42.3 version. But unfortunately, I see also that it is difficult to make a back-port, if it is not known which changes in the original source are fixing the problem. I don't want to switch completely to Tumbleweed, because I normally don't need the newest software and I don't like frequent updates. That is the reason I'm choosing Leap. And I'm at the moment really happy with Leap 42.3, besides that problem. ;-) Is it possible, only use libllvm from Factory or Tumbleweed? I installed a libllvm 4 version from OBS parallel to the 3.8 version, but howto tell Mesa to use this? Or must I replace at least X/Mesa too with the Factory or Tumbleweed version? This wouldn't be the best solution but better than no solution. And maybe I can live with that till the next Leap version comes out and the problem is hopefully fixed.
It is not possible to use Mesa from Tumbleweed on openUSE Leap 42.3. It breaks to many dependencies. The Mesa in this repository: http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Leap_42.3/ Unfortunately uses the old libLLVM Version too. At least I hope the new Mesa 18 in Leap 15 uses a newer libLLVM and fixes this bug. It seems that this is the case, but I can't test it yet.
Leap 15 has Mesa built with LLVM 5. Tumbleweed has Mesa built with LLVM 6. For Leap 42.3 you can use Mesa from X11:XOrg. It is built against LLVM 6 and is also built against Leap 42.3 repositories. I am closing this bug since it is fixed in newer version, and while we can not tell what could be backported to Leap 42.3, it is possible to use the newer package in Leap 42.3.