Skip to content

Handle scRGB and experimental FP16 #11000

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
Open

Handle scRGB and experimental FP16 #11000

wants to merge 13 commits into from

Conversation

UjinT34
Copy link
Contributor

@UjinT34 UjinT34 commented Jul 12, 2025

Describe your PR, what does it fix/add?

  • Handles HLG as HDR
  • Handles windows scRGB and matching formats as HDR. Fixes HDR in Control.
    scRGB can't be used with cm_fs_passthrough. cm_fs_passthrough = 2 should handle this automatically but might fail. cm_fs_passthrough = 0 is a more reliable setting.
  • Restricts monitorv2 sdr settings to SDR -> HDR scenario.
  • Removed some unneeded cm debug checks.
  • Adds experimental:use_fp16 to create internal framebuffers with FP16 format. Requires restart or something else to trigger framebuffer recreation.
  • Some minor debug log fixes.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

If a client provides an fp16 buffer it is passed to the CM shader without modification and this shader can do its math without clamping then fp16 is not required for scRGB -> HDR10 PQ conversion and the issues below can be ignored for now.
Most of the shaders, mirroring and image export stuff aren't ready to deal with FP16. This PR focuses on correct scRGB handling.
Known issues:

  • blur/shadows might have incorrect colors depending on background, color and contrast/brightness settings
  • screenshots are black
  • transparent parts of some overlay layers might turn black (strange one, eww bar renders black on top of fullscreen windows between it's widgets while the widgets themselves aren't rendered)

Easier to test with Cyberpunk 2077. If it's working then PQ HDR and scRGB shouldn't have any noticeable difference. If it doesn't then scRGB should either switch to SDR mode or have obviously incorrect colors.

Is it ready for merging, or does it need work?

Ready (assuming experimental:fp16 issues will be fixed in some other PR #10558)

@vaxerski
Copy link
Member

why would shaders break under FP16? Does it not have an A channel? OpenGL should abstract it away, no?

Also, what about performance? Is there any noticeable impact?

@UjinT34
Copy link
Contributor Author

UjinT34 commented Jul 12, 2025

FP16 can go outside 0.0-1.0 color range and needs explicit clamping if the shader produces values outside this range. Blur produces such values with my config (mostly defaults for blur) and wallpaper. Might not be visible with some other settings and darker wallpapers. I've fixed this for my case, might not be enough for everyone. Shadows and some other stuff might be affected aswell.
I am on rtx 5080, haven't noticed any performance issues. At least with the current implementation, probably some other intermediate buffers need similar changes. Weaker setups should keep this setting off since it doesn't provide any benefits outside some HQ HDR in games.

@vaxerski
Copy link
Member

we should in general provide a setting to skip the entire CM pipelines

@Tom94
Copy link
Contributor

Tom94 commented Jul 18, 2025

By clamping blur to [0, 1] you're essentially disabling HDR and wide color gamuts in blurred regions. Expressing wide color spaces in terms of sRGB primaries actually needs negative values. They should become positive again and only get clamped when in the monitor's final color space.

Ah, nevermind, I just noticed that the blur is happening in the monitor's color space. In that case the clamp makes sense.

The blur really should be done in linear space for best results, though.

@UjinT34
Copy link
Contributor Author

UjinT34 commented Jul 18, 2025

Blur stuff is complicated and should be rewritten. But it'll make some older hw sad. Compositing in general will be easier in linear space but it requires a lot of internal changes and will break some external plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants