Experimental FP16

[UjinT34]

Describe your PR, what does it fix/add?

• Adds 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:

• 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)

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

WIP needs fixes described in #10558

[vaxerski]

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]

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]

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

[Tom94]

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]

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.

[PlaidCat]

Hi,
This is not really my area of expertise, but I'd like to make myself available to help.

I've built this branch into my system and Horizion: Forbidden West runs without the srcRGB issues with gamescope.

Specs
AMD 9950x
AMD 7900xtx
"HDR" mini led monitor (I don't usually use the HDR since its zones aren't great)

$ hyprctl version
Hyprland 0.50.0 built from branch  at commit 7a3f5ddb509130a463aa6e42803db18ba8fb8048  (fix rebase).
Date: Sat Aug 2 15:55:40 2025
Tag: v0.50.0-71-g7a3f5ddb5, commits: 6350
built against:
 aquamarine 0.9.2
 hyprlang 0.6.3
 hyprutils 0.8.2
 hyprcursor 0.1.13
 hyprgraphics 0.1.5


no flags were set

If I will not be any help, I'll step away. but I appreciate someone taking up the scRGB issue,
Thank You

[UjinT34]

Moved the good stuff to #11499