| Summary: | Portal Stories Mel: Player's hands appear black at high shader quality | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | robin |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | daniel, eriknospam |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| 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) | ||
|
Description
robin
2016-06-13 19:13:50 UTC
Hi Robin, thanks for the report. Could you provide an apitrace where the issue appears? 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.) 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. 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 Thank you. I can reproduce the issue with the trace, this is very helpful. 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... :-) 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. 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.