-
Fix depth bias calculations · 0aca3ca9Nicolas Capens authored
We were simply adding the constant depth bias to the z coordinate, instead of interpreting it as relative to the minimum resolvable difference. In the legacy OpenGL ES code stack we're multiplying it by 2^-23, but this assumes a 32-bit floating-point depth format, while Vulkan must also support 16-bit integer depth, and doesn't take the exponent of the z values of the polygon into account. This change fixes the issue for both integer depth formats, which have a constant minimum resolvable difference, and floating-point depth formats, where the maximum exponent of the z values is used to determine the minimum resolvable difference per polygon. The viewport's depth range transform was corrected to be performed before the depth bias offset. Also the depth bias clamp operation was corrected to be performed only on the bias value, not the polygon's z value for vertex 0. We were also converting scalars to vectors a bit earlier than necessary, so this was refactored to happen later to simplify the calculations. The bias is added per fragment, after z interpolation, instead of being added to the 'C' factor of the plane equation. That's because we compute 'y * B + C' per row, and then add 'x * A' per fragment. When the bias is included in 'C', the additions cause loss of precision greater than the minimum resolvable difference, and dEQP-GLES3.functional.polygon_offset fails because it uses a 'units' depth bias of 1. Note this change is intentionally unoptimized, to serve as a spec- compliant reference implementation. dEQP has poor test coverage for this functionality so we need to start off with something that is easy to reference against the spec. Bug: b/139341727 Fixes: b/160463658 Change-Id: Ief1dd609d8ac974e76b1b785a924b09b448297a2 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48629 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
0aca3ca9
×