Bug 96512 - Portal Stories Mel: Player's hands appear black at high shader quality
Summary: Portal Stories Mel: Player's hands appear black at high shader quality
Status: RESOLVED NOTOURBUG
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:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-13 19:13 UTC by robin
Modified: 2016-07-26 19:56 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Example from Portal Stories: Mel. Upper picture: Shader quality "Very high" (or high), Lower picture: Shader quality "medium" (or lower) (4.21 MB, image/png)
2016-06-13 19:13 UTC, robin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robin 2016-06-13 19:13:50 UTC
Created attachment 124512 [details]
Example from Portal Stories: Mel. Upper picture: Shader quality "Very high" (or high), Lower picture:  Shader quality "medium" (or lower)

Hello,

this is my first bug report, so I hope the information provided is sufficient.

In Portal Stories: Mel and Portal 2 (reportedly), the player's arms and hands (and a few other objects, as demonstrated in the attached picture) appear black when the shader quality setting is set to "High" or "Very High", but appears normal if it is medium or lower.

This seems to only happen to a few objects, like the arms. In Portal 2 this is not visible as often, as the player's arms are usually not visible like that.
Not sure if this is a Mesa bug, but it has been pointed out that the reports have so far only been on different versions of Mesa, so.. just thought I'd report it here in case.
I actually wanted to provide apitrace files, but I could not get it to work, sadly.

I sorted this under radeonsi because this is the driver I use, but among the other reports have been Intel systems. Please correct the bug report classification if not accurate.

The bug on Valve's git: https://github.com/ValveSoftware/portal2/issues/255

My system: 
Kubuntu 16.04
Intel i5-2400
8 GB DDR3 RAM
Radeon HD 7950 Boost
(Steam Overlay deactivated)

OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.43.0 / 4.4.0-24-generic, LLVM 3.9.0)
OpenGL core profile version string: 4.2 (Core Profile) Mesa 12.1.0-devel - padoka PPA (git-42624ea)
OpenGL core profile shading language version string: 4.20

Please let me know if there's something else you need
Comment 1 Nicolai Hähnle 2016-06-14 14:44:14 UTC
Hi Robin, thanks for the report. Could you provide an apitrace where the issue appears?
Comment 2 Torbjörn Andersson 2016-06-15 04:32:01 UTC
Since I filed the original bug on Valve's git...

Any tips on how to get an apitrace out out Portal 2? I saw some suggestions about setting the GAME_DEBUGGER environment variable, but I wasn't able to get it to work. Maybe I didn't install all the necessary packages? (I'm using Debian unstable.)
Comment 3 Nicolai Hähnle 2016-06-15 06:41:19 UTC
For me, the most reliable way to get an apitrace out of Steam games tends to be the (actually somewhat discouraged) LD_PRELOAD method: start Steam itself from a terminal with LD_PRELOAD=...apitrace-build-dir/wrappers/glxtrace.so steam

Of course, apitrace must have been built with the correct bitness (32 or 64 bits) depending on the game.

Watch the log for messages about apitrace being loaded.
Comment 4 robin 2016-06-15 14:42:47 UTC
Hi Nicolai, it seems to have worked with self-built 32-bit apitrace; the portal2_linux.trace popped up in the game's folder. 

I tested the trace by replaying it, and it shows the same visual issues like when I run the game itself.
I hope you don't mind it containing the loading screen etc. until the scene actually loads.As it has become rather big (700MB), I had to upload it externally on Google Drive. 
https://drive.google.com/open?id=0B1pv42ci1XWxOXpDRmN5UjR2Qkk
Comment 5 Nicolai Hähnle 2016-06-15 16:55:47 UTC
Thank you. I can reproduce the issue with the trace, this is very helpful.
Comment 6 Torbjörn Andersson 2016-06-16 03:49:04 UTC
Ah, good, you won't be needing my trace then? (It turned out that I did get one after all, I just didn't see it at first.) I was wondering what on earth to do with that 1 GB file... :-)
Comment 7 Torbjörn Andersson 2016-06-22 18:33:34 UTC
Just in case the traces I made are useful in some way after all, I've gzipped them and uploaded to https://drive.google.com/open?id=0B364GtFAb7hUc21ONi15ODdmMTg

There are two files there, but they're just two different playthroughs of the same scene.
Comment 8 Nicolai Hähnle 2016-07-26 19:56:16 UTC
I believe that this is a game bug.

Some of the black objects are rendered in draw calls between 526669 and 526714 of the provided trace. They're using program 2823, which contains fragment shader 2811, which uses a shadow sampling instruction on sampler 15, but the texture bound to texture 15 is a 1x1 GL_SRGB texture.

The GLSL 4.50 spec in the section on Texture Functions says: "If a shadow texture call is made to a sampler that does not represent a depth texture, then results are undefined." -- that is, the game is invoking undefined behaviour, hence this is not our bug.


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.