Bug 99484 - Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly
Summary: Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL: https://bugs.llvm.org/show_bug.cgi?id...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-21 17:27 UTC by xicronical
Modified: 2017-03-15 13:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Picture showcasing issue. Bars should always be rectangles. (759.37 KB, image/png)
2017-01-21 17:27 UTC, xicronical
Details

Description xicronical 2017-01-21 17:27:42 UTC
Created attachment 129084 [details]
Picture showcasing issue. Bars should always be rectangles.

In game there are often bars to represent loading percentage, unit morale, etc. They render fine at 100%, but once combat or sieging drops them to a lower value, they begin rendering insanely and it is impossible to tell how full the bar actually is just by looking at it. Picture attached showcasing issue. The game renders correctly in AMDGPU-PRO.
Comment 1 Samuel Pitoiset 2017-01-23 10:54:49 UTC
Can you try recording an apitrace which reproduces the issue? Thanks!
Comment 2 Timothy Arceri 2017-02-09 06:13:28 UTC
You can see the issue in the progress bar on the main loading screen:

https://drive.google.com/open?id=0B-f68fD4PtpBZmx0M2VPUU1oRms
Comment 3 Timothy Arceri 2017-02-09 11:04:29 UTC
The game requests a compatibility profile but its using OpenGL features from 3.1+. Overriding the version doesn't fix the issue, so may be related, may not.
Comment 4 Timothy Arceri 2017-02-14 05:12:52 UTC
(In reply to Timothy Arceri from comment #3)
> The game requests a compatibility profile but its using OpenGL features from
> 3.1+. Overriding the version doesn't fix the issue, so may be related, may
> not.

Umm. I'm not sure what made me think this is using 3.1+ but I don't think that is correct.

Also running the trace on i965 produces correct output.
Comment 5 Timothy Arceri 2017-02-14 11:51:13 UTC
Running Mesa master with llvm 3.8 (instead of 5.0 from git) resolves the problem.
Comment 6 Andreas Boll 2017-02-14 12:14:04 UTC
(In reply to Timothy Arceri from comment #5)
> Running Mesa master with llvm 3.8 (instead of 5.0 from git) resolves the
> problem.

Be aware that llvm 3.8 degrades OpenGL support for radeonsi. Just check your glxinfo output.
Comment 7 Timothy Arceri 2017-02-17 03:03:31 UTC
Bisected the llvm regression to a change in llvm 4.0

  commit f991e38d156c4c10c609ca8425a7c31b951ecbed
  Author: James Molloy <james.molloy@arm.com>
  Date:   Thu Sep 1 10:44:35 2016 +0000

    [SimplifyCFG] Change the algorithm in SinkThenElseCodeToEnd

However the output from R600_DEBUG=vs,fs is identical apart from the value of code_size reported for one of the shaders.
Comment 8 Timothy Arceri 2017-02-18 11:41:04 UTC
Adding llvm bug report.
Comment 9 Samuel Pitoiset 2017-03-04 15:45:43 UTC
A possible fix here https://reviews.llvm.org/D30609.
Comment 10 Samuel Pitoiset 2017-03-15 13:33:15 UTC
Just pushed a workaround for this issue in Mesa.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=7751ed39e40e08e5aa0633d018c9f25ad17f9bb0


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.