Bug 106595 - [RADV] Rendering distortions only when MSAA is enabled
Summary: [RADV] Rendering distortions only when MSAA is enabled
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/radeon (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: zefkerrigan
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-21 18:43 UTC by zefkerrigan
Modified: 2019-01-18 05:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
WoW corrupted rendering screenshots (20.38 MB, application/x-xz)
2018-05-21 18:43 UTC, zefkerrigan
Details
I mean, some of the rendering distortion has disappeared. That is, I no longer see these distortions: (4.02 MB, image/png)
2018-05-22 10:10 UTC, zefkerrigan
Details
But instead of this now after applying this patch, all the distortions with all modes (MSAAx2, MSAAx4, MSAAx8) look like this: (2.51 MB, image/png)
2018-05-22 10:15 UTC, zefkerrigan
Details
I remind you that if everything is correct then it should look like this: (2.44 MB, image/png)
2018-05-22 10:18 UTC, zefkerrigan
Details
After your fix now with absolutely any graphics settings, the image looks like this (2.16 MB, image/png)
2019-01-10 09:20 UTC, zefkerrigan
Details

Description zefkerrigan 2018-05-21 18:43:39 UTC
Created attachment 139666 [details]
WoW corrupted rendering screenshots

[RADV] Blizzard's World of Warcraft (Wine Staging + DXVK) has a rendering distortions when MSAA is enabled.

Arch Linux, Mesa-git, but this also happens with any stable version of Mesa.
GPU: AMD Radeon HD7770 with the amdgpu Linux kernel driver.
Freshest Wine (git) + Staging patchset (git) + DXVK (git).
Please tell me if you need more info or any logs and how do I do them.

I attached a few screenshots of this issue:
1) Without any AA enabled, and therefore with proper rendering
2) With MSAAx2
3) With MSAAx4
4) And a few screenshots with MSAAx8.

This issue happens only if MSAA is enabled, but does not happen if any other types of AA are enabled.
Comment 1 Samuel Pitoiset 2018-05-21 19:57:38 UTC
Do you have https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d in your tree?
Comment 2 zefkerrigan 2018-05-21 20:52:43 UTC
(In reply to Samuel Pitoiset from comment #1)
> Do you have
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=73df16dcee79e2281c8d8a830dbbe6655359c82d in your tree?

Yes, I have. But this patch, as I understood it, is intended to correct exactly the opposite issue when the distorted rendering occurs if the MSAA is NOT included. But in my case everything is exactly the opposite: I see the distortion of rendering if MSAA is enabled. The fact is that in WoW there are different types of surfaces, and for some of them, MSAA enabling leads to distortion of rendering but at the same time eliminating the distortion of rendering on some other surfaces.

Please watch the video on this link and pay attention to how the character's wings change when I turn the MSAA on and off. It is clear that the mountains are beginning to be correctly rendered when I turn on the MSAA, but at the same time the enabling of MSAA breaks the correct rendering of the wings surface of this character. Perhaps your patch solves the issue of broken mountains rendering in this case, but the rendering of the wings is still broken.
https://mega.nz/#!iVVHFTgL!Yb20wUpRyfLsuNH0JOqJT21zQd-hFxnpwBJcEBD3t00
Comment 3 zefkerrigan 2018-05-21 21:02:37 UTC
https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d
This video I shot before applying this patch, but I believe that the issue of wings rendering is not related to the issue of mountains rendering. But I think that the issue of the surface of the wings can be related to the subject of this bug report.
Comment 4 Samuel Pitoiset 2018-05-22 08:58:17 UTC
Can you try https://patchwork.freedesktop.org/patch/224584/ then?
Comment 5 zefkerrigan 2018-05-22 10:07:46 UTC
(In reply to Samuel Pitoiset from comment #4)
> Can you try https://patchwork.freedesktop.org/patch/224584/ then?

Thank you! This really partially corrected this issue, but unfortunately not completely but only partially.
Comment 6 zefkerrigan 2018-05-22 10:10:00 UTC
Created attachment 139676 [details]
I mean, some of the rendering distortion has disappeared. That is, I no longer see these distortions:

I mean, some of the rendering distortion has disappeared. That is, I no longer see these distortions:
Comment 7 zefkerrigan 2018-05-22 10:15:00 UTC
Created attachment 139677 [details]
But instead of this now after applying this patch, all the distortions with all modes (MSAAx2, MSAAx4, MSAAx8) look like this:
Comment 8 zefkerrigan 2018-05-22 10:18:29 UTC
Created attachment 139678 [details]
I remind you that if everything is correct then it should look like this:
Comment 9 Samuel Pitoiset 2018-06-08 16:28:36 UTC
Can you capture a trace with renderdoc please?
Comment 10 zefkerrigan 2018-06-08 18:59:26 UTC
(In reply to Samuel Pitoiset from comment #9)
> Can you capture a trace with renderdoc please?

Yes, of course, I will do it if you explain it to me in clear words how and what I should do.
Regards.
Comment 11 Samuel Pitoiset 2018-06-11 09:16:09 UTC
You have to grab and build renderdoc from https://github.com/baldurk/renderdoc

Then, you can do "export ENABLE_VULKAN_RENDERDOC_CAPTURE=1", start the game and uses F12 for capturing a trace.
Comment 12 zefkerrigan 2018-06-16 20:36:23 UTC
(In reply to Samuel Pitoiset from comment #11)
> You have to grab and build renderdoc from
> https://github.com/baldurk/renderdoc
> 
> Then, you can do "export ENABLE_VULKAN_RENDERDOC_CAPTURE=1", start the game
> and uses F12 for capturing a trace.

Were I can find the trace files?
Comment 13 Bas Nieuwenhuizen 2018-06-16 22:45:12 UTC
/tmp/RenderDoc/

(probably something with wine in the name, could be different though. extension should be .rdc)
Comment 14 zefkerrigan 2018-06-17 07:53:08 UTC
(In reply to Samuel Pitoiset from comment #11)
> You have to grab and build renderdoc from
> https://github.com/baldurk/renderdoc
> 
> Then, you can do "export ENABLE_VULKAN_RENDERDOC_CAPTURE=1", start the game
> and uses F12 for capturing a trace.

A link to the rdc files:
https://mega.nz/#!qJUnHDaC!QWjCnv_M5UX-B9Qagvt-V0f3VQ2U2IpyQskJpxB63nE
Comment 15 zefkerrigan 2018-06-18 08:01:49 UTC
(In reply to Samuel Pitoiset from comment #11)
> You have to grab and build renderdoc from
> https://github.com/baldurk/renderdoc
> 
> Then, you can do "export ENABLE_VULKAN_RENDERDOC_CAPTURE=1", start the game
> and uses F12 for capturing a trace.

In my previous comment I gave you the rdc trace files.
Did you need any more logs or any other help from me?
Regards.
Comment 16 Samuel Pitoiset 2018-06-18 09:07:20 UTC
Unfortunately, I can't replay the trace because it's not the same hardware.
Comment 17 zefkerrigan 2018-06-18 11:17:01 UTC
(In reply to Samuel Pitoiset from comment #16)
> Unfortunately, I can't replay the trace because it's not the same hardware.

I want to help you, but tell me please how I can do it?
Regards.
Comment 18 Trevor Davenport 2018-06-19 05:20:06 UTC

This may not be a mesa bug.  For me, as soon as I enable MSAA i get asserts in mesa (in a debug build) or get lots of validation layers errors when they are enabled.

The error have to do with the aspectMask unexpectedly being zero for a sub-resources.  I've included output from mesa with asserts and the validation layers.  

Without asserts enabled it continues but might be doing something weird.  If you turn off msaa the validation error stop so that probably needs fixed first to see if there is a remaining MSAA issue or not.

I've got AMD RADV PITCAIRN (LLVM 6.0.0) hardware so not much different.


Mesa assert:
   World of Warcraft\Wow-64.exe: ../src/amd/vulkan/radv_meta_resolve.c:466: radv_CmdResolveImage: Assertion `region->srcSubresource.aspectMask == VK_IMAGE_ASPECT_COLOR_BIT' failed.

Validation layer output(just a sample...it continually spews):
   Validation(ERROR): msg_code: 174066691: Object: VK_NULL_HANDLE (Type = 0) | vkCmdResolveImage: value of pRegions[0].srcSubresource.aspectMask must not be 0. The spec valid usage text states 'aspectMask must not be 0' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageSubresourceLayers-aspectMask-requiredbitmask)
   (null)(ERROR / SPEC): msgNum: 174066691 - vkCmdResolveImage: value of pRegions[0].dstSubresource.aspectMask must not be 0. The spec valid usage text states 'aspectMask must not be 0' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageSubresourceLayers-aspectMask-requiredbitmask)
       Objects: 1
          [0] 0x0, type: 0, name: (null)
   Validation(ERROR): msg_code: 174066691: Object: VK_NULL_HANDLE (Type = 0) | vkCmdResolveImage: value of pRegions[0].dstSubresource.aspectMask must not be 0. The spec valid usage text states 'aspectMask must not be 0' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageSubresourceLayers-aspectMask-requiredbitmask)
   (null)(ERROR / SPEC): msgNum: 169869844 - vkCmdResolveImage: src and dest aspectMasks for each region must specify only VK_IMAGE_ASPECT_COLOR_BIT. The spec valid usage text states 'The aspectMask member of srcSubresource and dstSubresource must only contain VK_IMAGE_ASPECT_COLOR_BIT' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageResolve-aspectMask-00266)
       Objects: 1
          [0] 0x7d539550, type: 6, name: (null)
   Validation(ERROR): msg_code: 169869844: Object: 0x7d539550 (Type = 6) | vkCmdResolveImage: src and dest aspectMasks for each region must specify only VK_IMAGE_ASPECT_COLOR_BIT. The spec valid usage text states 'The aspectMask member of srcSubresource and dstSubresource must only contain VK_IMAGE_ASPECT_COLOR_BIT' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkImageResolve-aspectMask-00266)
   (null)(ERROR / SPEC): msgNum: 15 - Shader requires extension VK_KHR_shader_draw_parameters but is not enabled on the device
       Objects: 1
          [0] 0x0, type: 0, name: (null)
Comment 19 Philip Rebohle 2018-06-25 20:41:24 UTC
The DXVK bug causing the aspect mask to be 0 was introduced on June 12th and was fixed a few days ago, but apparently the issue persists.
Comment 20 Timothy Arceri 2019-01-09 22:18:54 UTC
Should be fixed by:

commit ee8488ea3b99ad0632e5eac6defcef0264d8782c
Author: Rhys Perry <pendingchaos02@gmail.com>
Date:   Wed Jan 9 11:09:33 2019 +0000

    ac/nir,radv,radeonsi/nir: use correct indices for interpolation intrinsics
    
    Fixes artifacts in World of Warcraft when Multi-sample Alpha-Test is
    enabled with DXVK.
    It also fixes artifacts with Fallout 4's god rays with DXVK.
    Various piglit interpolateAt*() tests under NIR are also fixed.
    
    v2: formatting fix
        update commit message to include Fallout 4 and the Fixes tag
    
    Fixes: f4e499ec791 ('radv: add initial non-conformant radv vulkan driver')
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106595
    Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Comment 21 zefkerrigan 2019-01-10 09:20:51 UTC
Created attachment 143054 [details]
After your fix now with absolutely any graphics settings, the image looks like this

Thank you! Yes, now I see some changes, but I disagree with the fact that this bug is now completely fixed, because after your fix now a when I use DXVK with absolutely any graphics settings, the image looks like this:
Comment 22 zefkerrigan 2019-01-10 09:27:16 UTC
Probably it deserves the opening of a separate report bug, but there are some similar graphics distortions when using MMSA Alfa-test with WineD3D (RadeonSI).
Comment 23 Timothy Arceri 2019-01-11 01:17:45 UTC
(In reply to zefkerrigan from comment #21)
> Created attachment 143054 [details]
> After your fix now with absolutely any graphics settings, the image looks
> like this
> 
> Thank you! Yes, now I see some changes, but I disagree with the fact that
> this bug is now completely fixed, because after your fix now a when I use
> DXVK with absolutely any graphics settings, the image looks like this:

Are you saying that commit ee8488ea3b99ad0632 caused a regression? Or is it some other change in git that caused the change?
Comment 24 Rhys Perry 2019-01-11 17:15:11 UTC
I seem to be able to reproduce the problem (alpha-tested geometry not visible) but only when Multi-sample Alpha-Test is enabled and WineD3D is used.
After disabling Multi-sample Alpha-Test or using DXVK, alpha-tested geometry seems to render perfectly.

Are you sure you're using DXVK? If so, are you able to reproduce the problem in the character creation screen (which is what I've been looking at)? Perhaps it only occurs in some areas (such as the one you've been taking screenshots of).
Comment 25 zefkerrigan 2019-01-18 05:49:00 UTC
(In reply to Rhys Perry from comment #24)
> I seem to be able to reproduce the problem (alpha-tested geometry not
> visible) but only when Multi-sample Alpha-Test is enabled and WineD3D is
> used.
> After disabling Multi-sample Alpha-Test or using DXVK, alpha-tested geometry
> seems to render perfectly.
> 
> Are you sure you're using DXVK? If so, are you able to reproduce the problem
> in the character creation screen (which is what I've been looking at)?
> Perhaps it only occurs in some areas (such as the one you've been taking
> screenshots of).

This RADV issue went away with the latest build of Mesa-git. Thank you very much!
But the WineD3D/RadeonSI issue is unfortunately still here.


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.