Color management is not precalculated

[easyaspi314]

Hyprland version

HEAD 0.51.0 559024c with unrelated modifications for libstdc++ 14
Void Linux

Regression

No

Describe the bug

Color management does expensive color space conversions on the GPU, which roughly doubles GPU utilization on potatoes like Intel UHD 620.

I believe that the main culprits are doColorManagement calling primaries2xyz which contains a lot of multiplications and an expensive matrix inverse, as well as doColorManagement being called on borders and shadows which, if I am not mistaken, can be done once with the main color management pass.

As much as possible should be performed on the CPU and passed as uniforms.

Reproduction steps

For this, I did echo 1150 | sudo tee /sys/class/drm/card0/gt_min_freq_mhz to ensure my iGPU runs at a stable GPU frequency.

I used the following config:

# wide color management is not native on my display and needs a shader
bind = CTRL ALT, A, exec, hyprctl keyword monitor ,preferred,auto,1,cm,wide
bind = CTRL ALT, B, exec, hyprctl keyword monitor ,preferred,auto,1,cm,srgb
monitor = ,preferred,auto,1,cm,srgb

bind = CTRL ALT, Delete, exec, hyprctl dispatch exit 0
# disable power saving stuff for consistent reproducible utilization
misc {
   vfr = false
}
debug {
   damage_tracking = 0
}
exec-once = kitty nvtop
exec-once = kitty

With two kitty windows open, GPU usage went from 9% to 18%. This is made worse when you use complicated configs; with some fancy blurs and opacity, it goes from 22% when repainting to 52%.

System info and config

hyprctllog.txt

[vaxerski]

@UjinT34 IIRC you moved some logic to the cpu, can we do more?

debug {
   damage_tracking = 0
}

???? that would indeed rack up gpu usage for no reason...

[easyaspi314]

I'm doing it to get a consistent reading. The GPU usage spike is reproducible with damage tracking enabled but it is just harder to track at the small levels of a minimal config.

Otherwise, that 10% is well within margin of error. With optimizations turned off it clearly shows a flat graph, which goes between 9% and 18% when I toggle color management

[easyaspi314]

As for things to offload to the CPU, primaries2xyz is called with a uniform value as the only input (passed to doColorManagement), and it contains an entire matrix inversion, which is a rather complicated operation.

[easyaspi314]

For a similar effect that has the downside of wasting CPU usage, here are screenshots from kitty running xxd /dev/urandom for a continuous stream of screen updates.

Same config, except I added a screenshot shortcut and commented out damage_tracking = 0

Color management on

Color management off

(I forgot to lock the GPU frequency but it was at a reasonably consistent frequency so the difference is still clear).

[UjinT34]

Are you sure that it's caused by primaries2xyz? Might be the CM shader in general. Can't test it because I'm out of potatoes %) Intel 155H sits at 1-2% regardless of damage tracking and primaries calculation.
Try #11741