protonscr

Artifacts in Munch and JanusVR with radv

steamvrclosed
ValveSoftware/SteamVR-for-Linux#88 · opened 2018-01-06 by ChristophHaag · updated 2018-01-20 · 8 comments · github
1 matching comments, n / p to jump
CChristophHaag 2018-01-06 github

RX 480, latest mesa/radv git.

At first I saw it only in Munch and attributed it to it being on the old unity engine:
screenshot_20180106_151324

But then I also saw it in JanusVR which has its own renderer
screenshot_20180106_150959

There are no artifacts on the companion/preview window, only on the SteamVR compositor and on the Headset Mirror.
screenshot_20180106_152016

This is a regression but I don't know when it happened and whether SteamVR or radv is to blame.

Kkisak-valve maintainer 2018-01-06 github

Hello @ChristophHaag,

With llvm 5.0.1 and a Polaris10, Munch VR demo bisects to:

commit 44fcf5874454dc5b68596c4eceeb9067bbe6527f
Author: Bas Nieuwenhuizen <[email protected]>
Date:   Thu Dec 28 02:54:10 2017 +0100

    radv: Disable DCC for GENERAL layout and compute transfer dest.
    
    Apps can use this for render feedback loops, where things are
    defined if they render each pixel only once. However, DCC fails
    here, as the level of coherence is a block not a pixel, so disable it.
    
    This is also going to help implementing other stuff.
    
    Even if we optimize this later to only happen if there actually is
    a loop (if possible at all ...), then the machinery is still useful
    to exclude images accessible by the SDMA queue when that is implemented.
    
    Reviewed-by: Dave Airlie <[email protected]>
    Tested-by: Dieter Nützel <[email protected]>
Kkisak-valve maintainer 2018-01-09 github

I'm also seeing the artifacting with Dota 2 (VR Mode).

TTTimo 2018-01-10 github

Yep seeing this as well on UE4 Vulkan

BBNieuwenhuizen 2018-01-11 github

So I tried this with dota2 since I don't have munch, and it regressed on the given commit alright.

It looks like the issue is that the vr compositor does the initial layout transition of the shared image from VK_IMAGE_LAYOUT_PREINITIALIZED . All the rendering and usage after that seems to happen in the GENERAL layout, which is not optimal but works.

In the GENERAL layout our auxiliary data needs to be in the fully decompressed state, as we still use the metadata during shader sampling. We (wrongly?) assume that PREINITIALIZED has been compressed and do a DCC decompress. However, as there has not been a layout transition before that the data in memory is random, and it seems the DCC decompress is not capable going from invalid encodings to a decompressed state in some cases.

I think the fix here should be on the side of SteamVR, using VK_IMAGE_LAYOUT_UNDEFINED for the first layout transition, as PREINITIALIZED does not make sense at all for tiled images, and by using it for them you've essentially promised that you know the internal format and initialized it correctly.

(I think it also makes sense to alias VK_IMAGE_LAYOUT_UNDEFINED and VK_IMAGE_LAYOUT_PREINITIALIZED for tiled images on radv, as the continuing render corruption after the layout change does not sound like conforming to spec, but PREINITIALIZED is definitely not what you want here)

A temporary workaround would be RADV_DEBUG=zerovram on the process creating and exporting the images (dota2 in my case).

BBNieuwenhuizen 2018-01-11 github

Discussed this with Dave a bit, and it looks like the history could actually be that the PREINITIALIZED is actually to preserve contents, in which case the client (i.e. dota) not doing any initial layout transition is wrong and using PREINITIALIZED is wrong.

PPlagman 2018-01-20 github

The next SteamVR Beta update will also have a fix for the unpatched scenario, thanks.

Launch options