Bug 110636 - [radv] DOOM 2016 particle artifacting
Summary: [radv] DOOM 2016 particle artifacting
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/radeon (show other bugs)
Version: 19.0
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-07 18:40 UTC by Franc[e]sco
Modified: 2019-05-09 09:57 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
gif showing the artifacting (1.38 MB, image/gif)
2019-05-07 18:40 UTC, Franc[e]sco
Details
system info at the time of the renderdoc capture (1.93 KB, text/plain)
2019-05-07 18:40 UTC, Franc[e]sco
Details

Description Franc[e]sco 2019-05-07 18:40:24 UTC
Created attachment 144189 [details]
gif showing the artifacting

since mesa 19 (using 19.0.2 at the moment), I've been experiencing artifacting / incorrect rendering of particles in DOOM 2016 running on a r9 270x with the amdgpu driver.

this happens with both vulkan and opengl renderers.

I have attached a gif that shows the artifacts. I also uploaded a renderdoc capture to mega (it's almost 1 gig, so I felt like it would be too much to add as a normal attachment): https://mega.nz/#!EV53mC5Q!vAugOwDn2iKqGaQ-KYNvfXg7oDNlhB3i74DvSnwdYD4

this doesn't happen on mesa 18.3.5

the game is running through proton 3.7-8 on steam. newer proton versions don't help

how to reproduce:

play any map that contains ambient particles, for example "kagindir sanctum" on arcade or story mode should have them right at the start

I don't have a renderdoc of particles working as intended but i will get one when i downgrade to mesa 18 again. you can look up videos of those maps on youtube to see that it's definitely not supposed to look like that. it feels like the intensity and speed of the particles is way higher than it should

my system info at the time of capture is also attached
Comment 1 Franc[e]sco 2019-05-07 18:40:52 UTC
Created attachment 144190 [details]
system info at the time of the renderdoc capture
Comment 2 Timothy Arceri 2019-05-08 08:06:49 UTC
It's not clear to me what the issue is. Can you get a before and after screenshot? 

I've run "kagindir sanctum" on both 19.0 and 18.3 and I didn't really notice any difference.

It also seemed pretty much the same as: https://www.youtube.com/watch?v=D0KV9s6Chjs
Comment 3 Samuel Pitoiset 2019-05-08 10:47:38 UTC
Can you try with LLVM 7 please?
Comment 4 Samuel Pitoiset 2019-05-08 11:56:44 UTC
This looks like a LLVM 8 regression to me.
Comment 5 Franc[e]sco 2019-05-08 13:34:49 UTC
Timothy: see the gif attached in the OP. it's not sped up. the particles are spazzing out that fast. I will capture better hi-res video of the before and after for better reference when I can

Samuel:
I just noticed my distro switched from llvm7 to llvm8 with mesa 19, nice guess.

I can't seem to build mesa 19.0.2 against llvm7, it complains about not having "llvm/Support/VirtualFileSystem.h". I could maybe try with 19.0.1 or even 18.3.5 and see if just changing llvm version breaks the particles

I'll test this in a couple of hours and let you know
Comment 6 Samuel Pitoiset 2019-05-08 15:31:35 UTC
a12681683a5de5b433ad99212e860c13a3478ebf is the first bad commit
commit a12681683a5de5b433ad99212e860c13a3478ebf
Author: Alexander Timofeev <Alexander.Timofeev@amd.com>
Date:   Fri Sep 21 10:31:22 2018 +0000

        [AMDGPU] Divergence driven instruction selection. Part 1.
    
        Summary: This change is the first part of the AMDGPU target description
        change. The aim of it is the effective splitting the vector and scalar
        flows at the selection stage. Selection uses predicate functions based
        on the framework implemented earlier - https://reviews.llvm.org/D35267
    
        Differential revision: https://reviews.llvm.org/D52019
    
        Reviewers: rampitec
    
    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@342719 91177308-0d34-0410-b5e6-96231b3b80d8

:040000 040000 202bb2e2ff19d86b67d7f891b81fb3c4fc016ef6 6c959ec368ad7a539823ad33c11ea5fdbac73381 M	lib
:040000 040000 97eb807e54bb01456e23744ec6b29c1bc1215266 f7af4dc9e4b78429c4b4190ff2d985a89fec0e4c M	test
Comment 7 Samuel Pitoiset 2019-05-09 09:57:18 UTC
Fixed with LLVM r360293, I'm not sure if the fix will be backported to LLVM 8, but it's fixed with master now.

Note that if you want to use LLVM master, you need https://reviews.llvm.org/D60457 to workaround a recent regression affecting SI. That one should be pushed soon too.

Thanks for reporting.


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.