How it looks with radv: https://abload.de/img/screenshot_20190209_1sjj21.png amdvlk: https://abload.de/img/screenshot_20190209_1vkk9s.png Take a look at the hedges or other small plants: With radv, some leaves don't draw shadows, which they do with amdvlk (and on Windows with native D3D11). The renderdoc capture of this report should be valid for this issue as well: https://bugs.freedesktop.org/show_bug.cgi?id=109394 mesa-git 19.1.0_devel.107387.55e00a2ea8b llvm-svn 9 build on February, 5th dxvk-git 0.96.r26.g8543f964
And once again, I forgot explicitly mentioning the GPU (it's on the screenshots though): It's a Polaris RX 580 card.
The hedges look quite awful with the latest git changes. :)
Created attachment 143379 [details] broken hedges
What do you mean?
A few days ago, it looked like in my first comment of this ticket (not perfect due to the partially missing shadows, but bearable): https://abload.de/img/screenshot_20190209_1sjj21.png With one of the recent commits, it now looks like this: https://bugs.freedesktop.org/attachment.cgi?id=143379 Please take a look at the vegetation, especially the hedges. It looks like they are missing some detail texture or specular reflections.
Can you bisect? And eventually upload a renderdoc capture?
I'll try to do that. I'd be grateful though if there also was a solution for the missing shadows of small objects bug (initial bugreport), which hopefully the renderdoc capture of the linked issue is already helpful for. :)
Regarding the "hedges regression": Sorry, false alarm. It looks the same on Windows DX11, the game developer apparently has recently downgraded the game's visuals.
Updated screenshots with the latest game update including its content change: radv-git (some small shadows missing): https://abload.de/img/screenshot_20190313_1esjw0.png amdvlk (no shadows missing): https://abload.de/img/screenshot_20190313_18djlz.png
Can you record a fresh renderdoc capture please?
Created attachment 143650 [details] new renderdoc capture part 1
Created attachment 143651 [details] new renderdoc capture part 2
Created attachment 143652 [details] new renderdoc capture part 3
Sure, no problem. Upload is complete now.
It seems this is not limited to a single game, but a general issue. I could reproduce the behavior in Hitman 2, there are again some shadows missing with radv. radv: https://abload.de/img/dxvk7gkpp.png amdvlk: https://abload.de/img/amdvlk1gk33.png
I changed the ticket title accordingly. Would a renderdoc capture for Hitman be desirable? If you're really mean (which I'm of course not, issue is hardly noticeable) you could say that radv doesn't render lots of games correctly, so would an update regarding the matter be possible? ;)
Yes, please attach a new trace.
Compressing and uploading the capture is on its way. Here are current screenshots showing the issue with latest mesa-git. When you switch between the images, you can clearly see some shadows missing with radv vs. amdvlk at the fence and at the trees in the background. This is completely reproducible, such as the issue in HotS. https://abload.de/img/amdvlk86jjt.png https://abload.de/img/radvikk6c.png
Created attachment 144110 [details] hitman 2 renderdoc capture 1
Created attachment 144111 [details] hitman 2 renderdoc capture 2
Created attachment 144112 [details] hitman 2 renderdoc capture 3
Created attachment 144113 [details] hitman 2 renderdoc capture 4
Created attachment 144114 [details] hitman 2 renderdoc capture 5
Created attachment 144115 [details] hitman 2 renderdoc capture 6/6
Upload complete.
Created attachment 144120 [details] [review] bias change Can you try with this change applied?
Yey, it seems it is fixed without any drawbacks, as far as I can tell. :) HotS: amdvlk: https://abload.de/img/amdvlkbjjv9.png radv old: https://abload.de/img/radvoldl3kd3.png radv new: https://abload.de/img/radvnewd8k1o.png Hitman 2: amdvlk: https://abload.de/img/amdvlkbyjub.png radv old: https://abload.de/img/radvopjos.png radv new: https://abload.de/img/radvnewy2ks5.png Once again: Thanks big time! :)
Would it be possible to ship this with one of the 19.1-rcs?
No because it's not a bug. Per the Vulkan spec "26.11.3. Depth Bias": "depthBiasSlopeFactor scales the maximum depth slope of the polygon, and depthBiasConstantFactor scales an implementation-dependent constant that relates to the usable resolution of the depth buffer." and, "The minimum resolvable difference r is an implementation-dependent parameter that depends on the depth buffer representation." That means, it might render differently based on that implementation-dependent parameter. Note that it likely renders something different with NVIDIA as well. Closing as we can't do anything. Thanks for the report!
Frankly I don't know if the offset scaling makes any sense. IMHO using the formula for fixed-point depth buffers d3d10 requires (luckily at least for float formats everybody (gl, vulkan, d3d10) agrees on the exact formula) would be way less trouble for everybody (pretty sure that would correspond to offset_scale of 1.0), although I'm not entirely sure it would actually fit the guarantee (of both gl and vulkan) that fragments always be distinguishable if they only differ by the implementation-defined r...
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.