PBS: honour non-sRGB colour targets in the pass hash - #584
Open
steffen-roemer wants to merge 2 commits into
Open
PBS: honour non-sRGB colour targets in the pass hash#584steffen-roemer wants to merge 2 commits into
steffen-roemer wants to merge 2 commits into
Conversation
preparePassHash hardcodes hw_gamma_write=1, assuming every colour target is sRGB. On a UNORM swapchain the linear lighting result then lands raw in the target and displays gamma-crushed (a mid-albedo surface under a zenith sun reads ~0.03 instead of ~0.5). Derive the property from the current pass descriptor's first colour target instead: sRGB targets keep hardware conversion exactly as before, and non-sRGB targets engage the existing !hw_gamma_write template path, whose shader-side encode was already written for this case but unreachable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
HlmsPbs::preparePassHashhardcodeshw_gamma_write=1, assuming the colour target is always sRGB. When an app renders to a UNORM (non-sRGB) swapchain, PBS writes its linear lighting result raw into the target, and the image displays gamma-crushed — a mid-albedo surface under the zenith sun reads ~0.03 instead of ~0.5, and night/indoor scenes collapse to black.This PR derives the property from the live pass descriptor instead: if the first colour target's format is sRGB, hardware conversion is used exactly as today; otherwise
hw_gamma_writeis 0 and the existing!hw_gamma_writetemplate path gamma-encodes in the shader — that path was already written for this case but was unreachable with the hardcoded property.Why not just use an sRGB swapchain?
Engines mixing PBS 3D with byte-exact 2D/UI pipelines (or matching a legacy renderer pixel-for-pixel) legitimately run UNORM swapchains. The template code says this configuration was meant to work; only the pass-hash property disagreed.
How tested
macOS 15 / Apple Silicon, Metal RS, static build via vcpkg at master ef2e8f3: measured readback of a mid-grey PBS reference under a known directional light on a UNORM swapchain — ~0.19 before, ~0.43 after (the sqrt-encode expectation); sRGB-target rendering byte-identical before/after (property still 1 there). Soaked through an engine's full desktop suite (789 green) including an Hlms-Unlit 2D parity pixel test that stays byte-identical.