Bug 109599

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...