| Summary: | [RADV] Rendering distortions only when MSAA is enabled | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | zefkerrigan |
| Component: | Drivers/Vulkan/radeon | Assignee: | zefkerrigan |
| Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | zefkerrigan |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
WoW corrupted rendering screenshots
I mean, some of the rendering distortion has disappeared. That is, I no longer see these distortions: But instead of this now after applying this patch, all the distortions with all modes (MSAAx2, MSAAx4, MSAAx8) look like this: I remind you that if everything is correct then it should look like this: After your fix now with absolutely any graphics settings, the image looks like this |
||
Do you have https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d in your tree? (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 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. Can you try https://patchwork.freedesktop.org/patch/224584/ then? (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. 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:
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:
Created attachment 139678 [details]
I remind you that if everything is correct then it should look like this:
Can you capture a trace with renderdoc please? (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. 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 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? /tmp/RenderDoc/ (probably something with wine in the name, could be different though. extension should be .rdc) (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 (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. Unfortunately, I can't replay the trace because it's not the same hardware. (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. 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) 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. 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> 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:
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). (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? 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). (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.
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.