This repository was archived by the owner on Sep 15, 2025. It is now read-only.
Fix implementation of VK_EXT_depth_clamp_control #183
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementation does not respect the following line from the extension description:
Instead the driver currently implements this extension as a global override of the viewport depth range, which incorrectly does affect the viewport transform.
The implementation is also not consistent with the definition in the Vulkan specification section 30.10.1, which specifies that depth clamp control only overrides the
minDepth
andmaxDepth
of the viewport for the purposes of clamping the depth value.To implement the extension correctly the registers for the viewport transform and the depth clamp need to be set separately. To achieve this the PR moves the
depthClampOverride
member from XGL to thePAL::ViewportParams
struct in the Platform Abstraction Layer.Additionally, the depth clamp override was previously treated as a global all-gpu parameter which seems to be incorrect for a device extension. Thus the new implementation now treats it as a per-gpu parameter.
Depends on the following PAL PR: GPUOpen-Drivers/pal#110
I've also submitted an additional conformance test to cover this case: KhronosGroup/VK-GL-CTS#532
Closes issue #182