Bug 94705

Summary: [radeonsi] blue ground in Company of Heroes 2
Product: Mesa Reporter: Laurent carlier <lordheavym>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: VERIFIED FIXED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=94835
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 94835    
Bug Blocks:    
Attachments: battlefield with some blue ground

Description Laurent carlier 2016-03-25 17:25:35 UTC
Created attachment 122566 [details]
battlefield with some blue ground

* radeon Tonga (was the same with Pitcairn)
* kernel 4.5.0
* mesa-git 511ce29
* llvm-svn r264392

Please note that it isn't a regression, this bug is present since the release of the game for Linux

Here is the link to an apitrace:
https://drive.google.com/file/d/0B1WCo3k21FK3NW9DaGZpR1cxWjA/view?usp=sharing
Comment 1 Nicolai Hähnle 2016-04-05 20:35:12 UTC
Hi Laurent, thanks for the report. I did some digging into the apitrace you provided.

Long story short: The game does not properly deal with the implementation-defined limit on the number of samplers that are available in a fragment shader. Perhaps there is some graphics quality setting that can be reduced to convince the game to use only shaders with fewer samplers as a workaround.

The long story: In the provided apitrace, the artefacts first appear in textures 10884 and 10885, which are terrain colour and normal maps. They are rendered to around call @516614, which is a glLinkProgram call for program 658 that fails because the attached fragment shader 611 has not been compiled. It is evident from the trace leading up to @516933 that the game intends to do rendering using 658 precisely when the artefacts appear, because there are a bunch of (failing) calls to query uniform locations.

Why has shader 611 not been compiled? Well, most likely there is logic in the game that does check for implementation-defined sampler limits, because shader 611 uses 18 samplers and we only expose 16. So probably some part of the game engine notices the limitation and doesn't even try to compile the shader, but this problem is not propagated up to higher layers in the engine.
Comment 2 Edwin Smith (Feral Interactive) 2016-04-05 20:56:19 UTC
This issue is caused by Mesa not exposing more than 16 samplers, once Mesa supports more samplers then Mesa will start to render correctly.

There is no simple way of downgrading the engine to avoid this issue. We have request that the Mesa limitation is removed so Mesa can support more samplers like other drivers.
Comment 3 Edwin Smith (Feral Interactive) 2016-04-05 20:59:09 UTC
Please Note: We can help developers working on this issue with a Steam key and other details as needed.
Comment 4 Nicolai Hähnle 2016-04-05 23:08:10 UTC
I agree that it makes sense to raise the limit for the long run. I'll take a look into that.
Comment 5 Edwin Smith (Feral Interactive) 2016-04-06 07:12:25 UTC
I have logged a specific bug for this request here along with some extra information that might come in handy when implementing this:

https://bugs.freedesktop.org/show_bug.cgi?id=94835

I have also marked this bug as depends on 94835.
Comment 6 Nicolai Hähnle 2016-04-07 18:19:03 UTC
We now support up to 32 samplers in Git master as of commit 2abe4f8d7dcdcff75c28958e1a691ebf6cdee1ac
Comment 7 Edwin Smith (Feral Interactive) 2016-04-08 09:44:03 UTC
Verified as working using the latest git.

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.