-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
base: main
Are you sure you want to change the base?
Conversation
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? |
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. |
we should in general provide a setting to skip the entire CM pipelines |
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. |
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. |
Describe your PR, what does it fix/add?
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.experimental:use_fp16
to create internal framebuffers with FP16 format. Requires restart or something else to trigger framebuffer recreation.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:
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)