Bug 108919

Created attachment 142690 [details]
Another artifact example

I am the creator of the reddit post mentioned in the opening comment of the issue. The 3 images (1 on the reddit post, and the 2 attachments posted) show exactly what I get when I start the game, depending on what settings are used. I cannot get it to any playable state though.

I'm running Arch Linux 4.19.4, mesa 18.2.5-1 (along with the same lib32 version),  and running on i3 (Xorg) with xf86-video-amdgpu 18.1.0-1.

Here are also some logs from when I started the game: https://paste.ubuntu.com/p/fRt54ftVD4/

Similar issue with black flickering reported here on an RX480 with Mesa 18.2.2 and ambient occlusion turned on: https://old.reddit.com/r/ThemeParkitect/comments/a1mt60/graphics_issue_black_flickering_all_over_the_place/

I am using an RX580 and also have this issue. Forcing OpenGL 4.2(4.3 and above causes the issue) with the mesa environment variable allows the game to run without artifacts but some shaders do not work, such as ambient occlusion.

Can somebody try to get an apitrace of the issue [1]? Thanks.

[1] https://github.com/apitrace/apitrace/wiki/Steam

Created attachment 142771 [details]
Apitrace

(In reply to Timothy Arceri from comment #5)
> Can somebody try to get an apitrace of the issue [1]? Thanks.
> 
> [1] https://github.com/apitrace/apitrace/wiki/Steam

Never used that tool before but I uploaded a trace that shows it immediately visible on the main menu.

Lots of these in the console if they're relevant:
apitrace: warning: _gl_param_size: unknown GLenum 0x8267
apitrace: warning: _gl_param_size: unknown GLenum 0x92F5

(In reply to Alexander Walker from comment #7)
> (In reply to Timothy Arceri from comment #5)
> > Can somebody try to get an apitrace of the issue [1]? Thanks.
> > 
> > [1] https://github.com/apitrace/apitrace/wiki/Steam
> 
> Never used that tool before but I uploaded a trace that shows it immediately
> visible on the main menu.
> 
> Lots of these in the console if they're relevant:
> apitrace: warning: _gl_param_size: unknown GLenum 0x8267
> apitrace: warning: _gl_param_size: unknown GLenum 0x92F5

I'm not sure, I don't see these when replying the trace. Aside from some calls to unsupported debug functions I don't see any obvious issues in the trace.

Do you think you could try grabbing a capture in renderdoc [1]? Once you unzip it somewhere you can add the following to the launch options for the game in steam:

LD_PRELOAD=/your path to renderdoc here/renderdoc_1.2/lib/librenderdoc.so %command%

When you lanuch the game you should see some text overlayed at the top of the screen saying you can create a capture by pressing F12. Once you have a capture you can find it in a folder in the /tmp/ directory. 

[1] https://renderdoc.org/

Created attachment 142775 [details]
renderdoc capture

(In reply to Timothy Arceri from comment #8)
> Do you think you could try grabbing a capture in renderdoc [1]? Once you
> unzip it somewhere you can add the following to the launch options for the
> game in steam:
> 
> LD_PRELOAD=/your path to renderdoc here/renderdoc_1.2/lib/librenderdoc.so
> %command%
> 
> When you lanuch the game you should see some text overlayed at the top of
> the screen saying you can create a capture by pressing F12. Once you have a
> capture you can find it in a folder in the /tmp/ directory. 
> 
> [1] https://renderdoc.org/

I've attached a capture. It's a flickering issue so hopefully it was captured in that 1 frame.

Created attachment 142776 [details]
renderdoc black screen from toggling vsync

Just adding this same bug affects Tonga based GPUs as well.

I thought I'd try this one out as I always loved Bullfrog's Theme Park back on my AMIGA 500+

-- Parkitect 1.3 --

I've captured a more up-to-date trace: (1.8GB)
https://drive.google.com/open?id=1DaekuBy9fBdQr4ceqskx_5w2m5BDt_CV

> Debian Testing
> Linux-drm-fixes-5.1
> Mesa 19.1.0 (4e802089) https://tinyurl.com/mesacommit
> Device: AMD Radeon R9 200 Series (TONGA, DRM 3.30.0, 5.1.0-rc1+, LLVM 8.0.0)
The game appears to be quite playable now. 
Ambient occlusion appears to be the main cause of some heavy graphical glitches - which I've shown in my trace by lowering the slider.
Alien Isolation is another game that suffers from glitches with HDAO enabled but otherwise works fine with it turned off.

Found two more games with the same problem:

Classic Racers: https://youtu.be/LQ3E3QWjKco

Two points hospital: https://youtu.be/zf-xgQTQ4TM

(sorry for the outdated versions of Mesa in both cases).

Not sure if this can help, but the dev of Classic Racers mentioned this:

"At the first glance, it seems that this is an incompatible AO shader from Unity with Radeon cards. I use Unity 2018.3.2 and the 2.1.3 Post Processing effects. I'm suspecting this version of the PostProcessing Shaders with the "optimised" AO (MultiScaleVolumetricObscurance) to be not compatible with Radeon and Linux.

To fix the problem, I have 2 solutions.
-Switching from Multiscale method to Scalable Obscurance. But there will be a big impact on low end hardwares.
- Updating to the newest Post Processing package. But i'm not sure about the result.
"

By the way, tested both games with a HD 520 and the bug is not present (used the same version of Mesa in all the cases).

https://steamcommunity.com/linkfilter/?url=﷒0﷓

My system specs:

GPU: RX 580 8Gb
Mesa: 19.0 (I'll try to run with 19.2)
LLVM: 8.0.0
Kernel: 4.18.0-17-generic

Renderdoc of the ambient occlusion problem in Classic Racers [1]. For some reason the ambient occlusion compute shader causes the bad rendering.

[1] https://drive.google.com/open?id=19ISfXSZtNF2XIsGddl0exkpd9rss1EGX

*** Bug 109319 has been marked as a duplicate of this bug. ***

I can't reproduce it here.

Can you disable HyperZ (HTILE)?
Can you disable DCC?
Can you insert memory barriers before and after the compute shader?

(In reply to Marek Olšák from comment #17)
> I can't reproduce it here.
> 
> Can you disable HyperZ (HTILE)?
> Can you disable DCC?
> Can you insert memory barriers before and after the compute shader?

The issue goes away with:

AMD_DEBUG=nodcc

More specifically disabling this hunk seems to resolve the issue:

		/* Shared textures must always set up DCC here.
		 * If it's not present, it will be disabled by
		 * apply_opaque_metadata later.
		 */
		if (tex->surface.dcc_size &&
		    (buf || !(sscreen->debug_flags & DBG(NO_DCC))) &&
		    (sscreen->info.use_display_dcc_unaligned ||
		     sscreen->info.use_display_dcc_with_retile_blit ||
		     !(tex->surface.flags & RADEON_SURF_SCANOUT))) {
			/* Add space for the DCC buffer. */
			tex->dcc_offset = align64(tex->size, tex->surface.dcc_alignment);
			tex->size = tex->dcc_offset + tex->surface.dcc_size;

			if (sscreen->info.chip_class >= GFX9 &&
			    tex->surface.u.gfx9.dcc_retile_num_elements) {
				/* Add space for the displayable DCC buffer. */
				tex->display_dcc_offset =
					align64(tex->size, tex->surface.u.gfx9.display_dcc_alignment);
				tex->size = tex->display_dcc_offset +
					    tex->surface.u.gfx9.display_dcc_size;

				/* Add space for the DCC retile buffer. (16-bit or 32-bit elements) */
				tex->dcc_retile_map_offset =
					align64(tex->size, sscreen->info.tcc_cache_line_size);

				if (tex->surface.u.gfx9.dcc_retile_use_uint16) {
					tex->size = tex->dcc_retile_map_offset +
						    tex->surface.u.gfx9.dcc_retile_num_elements * 2;
				} else {
					tex->size = tex->dcc_retile_map_offset +
						    tex->surface.u.gfx9.dcc_retile_num_elements * 4;
				}
			}
		}

*** Bug 110924 has been marked as a duplicate of this bug. ***

Issue moved to:

https://gitlab.freedesktop.org/mesa/mesa/issues/1345

Issue moved to:

https://gitlab.freedesktop.org/mesa/mesa/issues/1345