Bug 96391

Summary:	Payday: The Heist has rendering issues when anti-aliasing enabled
Product:	Mesa	Reporter:	Béla Gyebrószki <gyebro69>
Component:	Drivers/DRI/nouveau	Assignee:	Nouveau Project <nouveau>
Status:	RESOLVED MOVED	QA Contact:	Nouveau Project <nouveau>
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	screenshot, comparison (nouveau vs. nvidia, AA enabled)

Description Béla Gyebrószki 2016-06-05 16:52:52 UTC

Created attachment 124335 [details]
screenshot, comparison (nouveau vs. nvidia, AA enabled)

When I launch Payday: The Heist in Wine, everything looks fine in the menus. The problem arises when I start a mission: the loading screen becomes way too dark so hardly anything can be seen. When the actual mission is loaded the screen looks as if it was rendered with some special effect applied. 
I'm attaching a screenshot here to demonstrate what the game looks like with nouveau and nvidia 340.xx

If I disable in-game anti-aliasing then the game renders properly, except for the loading screen which still remains so dark (maybe the game always uses AA on the loading screen, or it is a different issue).

If I start the game with the software renderer (LIBGL_ALWAYS_SOFTWARE=1) then both the loading screen and the actual game are rendered properly.

Trace created with apitrace (uncompressed 185M):
https://drive.google.com/open?id=0B-tTbLKBl-tOOG9fNklaYzZUekE

Fedora 23 32-bit
Linux kernel: 4.6
Libdrm 2.4.68
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV92
OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.1.0-devel (git-fd6bbc2)
OpenGL core profile shading language version string: 3.30

Comment 1 Ilia Mirkin 2016-06-05 17:07:17 UTC

Reproduces on GT215 but not GK208. Kinda looks like one of those control flow fail situations, or potentially one of the "loop stopped running" situations that I never figured out. NV50_PROG_OPTIMIZE=0 had no effect, which it usually would in those situations (not to fix it, but just to alter how things look). Interesting.

I *am* aware of an issue in using glReadPixels()/glDrawPixels() with a MSAA winsys framebuffer, but ... let's hope they don't do that. And those issues would be the same on the GK208.

Comment 2 Ilia Mirkin 2016-06-05 19:18:37 UTC

Some draw calls that show differences (retracediff.py is *awesome*).

118175
118182
134311
134322
138829

I looked at the shader ... doesn't do anything fancy. Very odd. I suspect some sort of resource management failure =/

Comment 3 Ilia Mirkin 2016-06-05 19:20:58 UTC

OTOH every time we use program 90, there's a failure. Coincidence?

Comment 4 GitLab Migration User 2019-09-18 20:42:42 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1105.

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.