Created attachment 142689 [details] Screenshot of one of the possible outcomes of starting the game Issue: Vega hardware not working with Parkitect. The game is based on Unity. Lots of artifacts, particularly with ambient occlusion turned up in game's settings Steps to reproduce: Start a game in parkitect with Vega hardware. Turn the graphics settings to max and you will experience issues. Sometimes it's playable, but always with artifacts Happy to provide logs and feedback. Some notes: https://www.reddit.com/r/ThemeParkitect/comments/a0oboe/black_screen_on_linux_with_rx_vega_56/ Tested this with Mesa 18.2.4 and 18.3 in Fedora 29 (also had issues in Fedora 28). Happy to donate a copy of the game to a known dev.
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
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.