Fix depth bias calculations
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>
Showing
Please
register
or
sign in
to comment