Bug 95530

Summary: Stellaris - colored overlay of sectors doesn't render on i965
Product: Mesa Reporter: eyecreate+fd
Component: Drivers/DRI/i965Assignee: Ian Romanick <idr>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: jajcus, jlp.bugs, kai.huuhko, mboquien
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: broken game render

Description eyecreate+fd 2016-05-23 02:29:06 UTC
Created attachment 123974 [details]
broken game render

While using Oibaf's Mesa PPA on Ubuntu 14.04, I have noticed an issue with the game Stellaris on the i915 driver.(specifically, an Intel i5 5200U) When using software/llvmpipe (or Nvidia proprietary driver on another machine), this rendering glitch does not happen. Attached are the screenshots of a working render and broken render. Both of these correspond to frame 610 in this trace:
https://drive.google.com/file/d/0B1fMMW8H2fLfLVNHUHVLTHlvYjA/view?usp=sharing
Comment 1 Jacek Konieczny 2016-06-06 07:21:50 UTC
I have the same problem with Intel HD Graphics 4600 and Mesa 12.0.0-rc1. The problem seems to affect other Mesa drivers too, as reported on various forums:

https://forum.paradoxplaza.com/forum/index.php?threads/borders-empire-colors-not-visible.927717/
https://steamcommunity.com/app/281990/discussions/0/357285562492711302/
Comment 2 Jacek Konieczny 2016-06-06 07:26:10 UTC
The known workaround is to open game console (in Ironman mode it needs to be done in the main menu, before creating/loading the game) with '~' and enter:

tweakergui borders.usemesh

Then click the checkbox in the window that apperas and close both the window and the console. This needs to be repeated each time Stellaris is started.
Comment 3 Jacek Konieczny 2016-06-12 15:38:19 UTC
My mistake, I have not actually tested it on Mesa 12.0.0-rc1, as I have not noticed Stellaris is 32-bit and my 32-bit Mesa libraries were older.

I have now tested it with 32-bit Mesa 12.0.0-rc2 and the borders are displayed properly.

It seems the problem is fixed for Mesa 12.0.
Comment 4 eyecreate+fd 2016-06-14 02:07:08 UTC
Can you give more details on what you did? I just installed the rc2 and my borders look the same. I have checked and I have the libgl from mesa for both 32 and 64 bit as 12.0-rc2. Was the mesa code all you changed?
Comment 5 eyecreate+fd 2016-06-14 03:32:55 UTC
Nevermind, I have no idea what I witnessed before. After doing nothing but leave the computer on for an hour, booting the game back up shows borders.(did it have to recompile shaders or something the first time?)

Also to note: my original trace was from before a big patch(1.1). In that trace, I still don't see borders on, but the current game does have them.

I'll mark this as resolved unless I come across something I missed.
Comment 6 Jacek Konieczny 2016-06-14 07:09:56 UTC
For me the upgrade to 12.0.0-rc2 fixed the problem on my Haswell laptop, but when I did the same on my daughter's PC (Skylake) it didn't work – the borders are there, but all grey and hardly visible.

There is still something wrong, within the game or the driver.

I tried to force OpenGL 4.3 on Haswell and OpenGL 3.3 on Skylake (to make sure I test with the same version), but in both cases setting the MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE environment variables caused the game to crash on startup.
Comment 7 Christopher James Halse Rogers 2016-06-30 05:04:46 UTC
Confirmed broken on my Haswell as of mesa g5921f37. I likewise have a trace at https://cooperteam.net/stellaris.trace ; this plays back correctly on radeon and llvmpipe but doesn't show the empire colours on my Iris Pro 5200 i965.
Comment 8 Pierre Moreau 2016-11-22 00:00:26 UTC
(In reply to Jacek Konieczny from comment #6)
> For me the upgrade to 12.0.0-rc2 fixed the problem on my Haswell laptop, but
> when I did the same on my daughter's PC (Skylake) it didn't work – the
> borders are there, but all grey and hardly visible.
> 
> There is still something wrong, within the game or the driver.
> 
> I tried to force OpenGL 4.3 on Haswell and OpenGL 3.3 on Skylake (to make
> sure I test with the same version), but in both cases setting the
> MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE environment
> variables caused the game to crash on startup.

The game is using OpenGL 2.1:ish according to the developers, so forcing to anything above OpenGL 3.1 will result in the creation of a core profile, which is incompatible with OpenGL <= 3.0.

Tested with Mesa 13.0.0, 13.0.1 and bf75ef3: I can’t seem to reproduce the error when running the game, even if I was able to 10 days ago (on an Haswell Iris Pro 5200). I reverted back to the version of Mesa and Stellaris I assume I was running at the time, but it still worked. Replaying both traces linked to this bug report do produce the artefacts, even with the latest HEAD (bf75ef3).

(In reply to Christopher James Halse Rogers from comment #7)
> Confirmed broken on my Haswell as of mesa g5921f37. I likewise have a trace
> at https://cooperteam.net/stellaris.trace ; this plays back correctly on
> radeon and llvmpipe but doesn't show the empire colours on my Iris Pro 5200
> i965.

Does it still happen with Mesa 12.x or 13.0.x?
Comment 9 Jakub Szuppe 2017-04-10 12:14:44 UTC
We are working on this issue at StreamComputing. The issue still occurs on i965 driver (using the recent Mesa version from git). Other Mesa drivers (llvmpipe and radeonsi) work correctly.
Comment 10 higuita 2017-05-25 23:10:44 UTC
Any update on this? do mesa 17.1 help in anyway?
Comment 11 Jakub Szuppe 2017-06-08 08:54:19 UTC
Sectors have "noisy" borders and very low transparency on i965 driver (Mesa 17.1.0-devel (git-d5ee55f)). Other Mesa drivers (llvmpipe and radeonsi) work correctly.

How it looks like on i965:
https://drive.google.com/open?id=0B1fY17pW39ZeWUoxVXJWUU42dFk

How it should:
https://drive.google.com/open?id=0B1fY17pW39ZeUGhQdmRTUS1UVWc

These overlays are rendered using render-to-texture in the call 2149486:
https://drive.google.com/open?id=0B1fY17pW39ZedlFDREwwSFB6Nzg

The program 706 (a fragment shader 708, created in 911931) uses two textures with

glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_NEAREST)
glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST)

These textures also have GL_TEXTURE_MAX_ANISOTROPY_EXT set to 16:

glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAX_ANISOTROPY_EXT, param = 16)

Setting GL_TEXTURE_MAX_ANISOTROPY_EXT to 1 for both textures fixes the issue:
https://drive.google.com/open?id=0B1fY17pW39Zec2pMa3dIN0Nobjg

I.e., GL_TEXTURE_MAX_ANISOTROPY_EXT disables GL_NEAREST, and because the shader highly depends on exact texel values (it calculates sums, maximum of values of the first texture, uses the second texture as a look-up table), the results have such a big difference.

Here the code that disables GL_NEAREST in this case:
https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_sampler_state.c#n454

We've found one issue with a proposed patch here: https://bugs.freedesktop.org/show_bug.cgi?id=91786

The patched driver produces correct results for both traces.

Kind regards,
Stream HPC Team
https://streamhpc.com/
Comment 12 Dylan Baker 2017-06-16 20:48:25 UTC
I have verified the patch above and sent it to the list:
https://patchwork.freedesktop.org/patch/162171/
Comment 13 Dylan Baker 2017-06-20 20:09:03 UTC
fixed by 6a7c5257cac23cd9767aa4bc8fdab68925b11157

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.