[SOLVED] Graphics issues on Intel Kaby Lake (HD630) hardware on Linux

Edit: Now fixed in Mesa upstream, V18.0.1 and 17.3.9. See my post below for link to the patch if you're not willing to upgrade and can compile Mesa.

I've been getting the following bug in Xonotic for a while now, since I got this new machine, which was just before 0.8.2 was released (so present with 0.8.1 as well).

I'm using the current drivers in Debian Stretch (Mesa 13.0.6, libdrm 2.4.74, Debian's Linux kernel 4.9.0/4.9.18, all 64 bit). Machine is an Intel Kaby Lake i7-7700 (3.6 Ghz) in a Asus Prime Z270-P board, using the inbuilt Intel HD630 video in the cpu/on board.



This happens when the player model takes up about 1/4th of the screen. If they're further away, they're visible. Same happens if you're looking at them zoomed (at any size). Makes it a bit hard in close combat or when using zoom, as there's so much less visible to act on. It seems to be somewhat related to textures, as reducing the texture size seems to marginally allow me to get closer to a player model before it happens. If I'm free-float spectating, it happens even closer to the player model than if I'm present in-game with a weapon. Turning textures all the way down to the lowest setting however doesn't remove the problem.

One of the other artefacts of the driver issue is that the latest model for mortar is almost completely invisible, even when being held by the player, at all times. The only visible part is the little tiny blue sighting window on top of the mortar, with the rest of the model being invisible. This of course makes it problematic in game play - not being able to see the mortar pickups on the map or one that's been dropped makes it that much harder to play.

Pretty sure this is a video driver problem. So far, the only thing I can say for sure is that it's tied to OpenGL 2.0 shader functions, as disabling OpenGL 2.0 shader functions totally in Xonotic fixes the bug, but at the expense of not being able to see through teleporter/portals (as in the background of the pic). It's not GLSL colour control/gamma related as turning that off doesn't resolve the issue. I've started turning off OpenGL 2.0 shader functions for standard games so I can play properly again, but it's not optimal.

Note: If I have Xonotic set not to use OpenGL 2.0 shader functions, I can push all the other video options to their max (including textures) and still get 60fps easily, so it doesn't seem likely it's a rendering issue or a texture memory problem, unless it's specific to OpenGL 2.0 shader functions.

I've got newer Mesa drivers to try (17.0), but what I'm hoping first is to figure out exactly what OpenGL 2.0 shader function is causing the issue, so I can reliably test the problem (eg: possibly outside Xon) and submit a bug report in Debian to maybe get this fixed. At the very least I'm hoping to get the problem more exposure, especially if upgrading Mesa to the current release doesn't fix the issue.

So, if any dev's have any idea what OpenGL 2.0 shader functions would be commonly used by the engine only between the player model and the mortar, that'd be a nice start. If there is any way to "lock out" certain OpenGL shader functions in the engine, that would definitely allow me to track it down (process of elimination).

Note: So far, I can't reproduce the error outside Xon. I've tried in a few other games, but so far I've not hit any video artefacts at all. I've not yet tried the latest autobuild as this would introduce another variable to the testing, though I can probably do that if this is something that someone else has seen and fixed.

Here's some pics of the mortar bug.
With OpenGL 2.0 shader functions disabled, everything seems to work fine.


With OpenGL 2.0 shader functions enabled, you can only see the sight window on top of the model.

Update: Mesa 17.0.4 doesn't solve the issue.

I'm now digging around with apitrace. Thanks to some help from Mario, I've gotten down the amount of time it takes to show the bug and quit to about 20 secs, which reduces the trace time significantly.

Ok, so here's something I found after a bit of mucking about:

All the models display fine with OpenGL 2.0 Shaders enabled if I turn on r_glsl_skeletal.

So basically:
 "r_glsl_skeletal" "1"

Which is absolutely weird, because most of the comments I've seen about this say it causes video issues if anything.

So seems as though this really is a bug in the Intel video drivers, at least under Linux.

So far, confirmed reports using the following Distro/Hardware/Kernel/Mesa combos:
 Debian Stretch, Intel HD 630 (Kabylake), Kernel 4.9, Mesa 13.0.6 and Mesa 17.1.2 (from experimental)
 Slackware64, Intel HD 620 (Kabylake), Kernel 4.9.31, Mesa 13.0.6
 Manjaro, Intel HD 530 (Skylake), Kernel 4.11, Mesa 17.1.3

FWIW: The same Skylake setup works fine with an Nvidia GTX960 card.

I've now got a reasonably small capture in apitrace (well, 270MB, 140MB compressed) that I'm going to submit as part of the bug report, but having more info to submit on a bug is always a plus.

If other people with Intel hardware could confirm if this issue affects them or not (pls provide above info) when using the built in GPU, it might help me with getting the Intel video driver guys to figure out what the problem is. Older/different Intel hardware definitely a plus, but confirmation of the same hardware on different OS's or Distros (eg: Windows, Ubuntu, Fedora, etc) also useful, particularly if you dual/multi boot.

Easy test:

Run Xonotic and load the map `erbium` (eg: `./xonotic-linux-glx.sh +map erbium`).
In the console, make sure that r_glsl_skeletal is 0:
  r_glsl_skeletal 0
In the console, run the following command to take the viewpoint to the mortar:
 prvm_edictset server 1 fixangle \"1\"; prvm_edictset server 1 angles \"0 0 0\"; prvm_edictset server 1 origin \"1324.64856 -1104.02734 449.284454\"

If you see the mortar, everything is fine. If not, only the tiny "scope" on the mortar will be visible.

Bug now listed at the Mesa project on freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=101408

Just tested a patch from Mesa upstream that seems seems to fix the issue, so HOPEFULLY this will be in the next release of Mesa.

YAY!

Will include more details soon.

I only just encountered this bug when I was forced to render tuhma on my laptop with an onboard intel gpu. Thank you for your persistence!

The fix missed the release of Mesa 18.0.0 and 17.3.8, but it now appears to be definitely in the next releases.

OK, so the patch has now made it into Mesa 17.3.9 and 18.0.1.

Link to the individual patch if you feel like trying to backport it anywhere. 
  https://lists.freedesktop.org/archives/m...90767.html
The location of the actual patched code will change from version to version, but that's fairly trivial to fix. Should definitely apply to the 17.x branch. Haven't tried against 13.x.

Happy hunting!