Skip to content

backends/drm: optimize color management

Xaver Hugl requested to merge work/zamundaaa/adjustable-transfer-functions into master

This MR

  • implements min and max luminance levels for transfer functions (see https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/74), which allows apps as well as KWin itself to have a lot more freedom for how to encode color data and opens up a lot of possibilities
  • merges scRGB and linear transfer functions
  • merges "no color management" and "color management" paths completely; night light is now always handled exactly the same
  • drops the shadow buffer down from 16 to 10 bits per color when supported, which should improve performance a bit
  • with color profile set to "built in", removes the shadow buffer entirely
  • with HDR enabled, offloads the gamma 2.2 -> PQ conversion + night light and brightness adjustments to KMS, and removes the shadow buffer entirely on a lot of hardware
  • improves KMS offloading of color operations by combining operations even more than the ColorPipeline already does - for example, transfer function + multiplier + inverse transfer function all gets packed into one LUT, which makes night light offloading work correctly on NVidia too

BUG: 491452

CCBUG: 477223

draft because

  • afaik NVidia's hardware only has CTM+LUT+CTM, instead of LUT+CTM+LUT like the CRTC color management properties suggest... I need to test if this works correctly on the proprietary driver -> we only use a single LUT with this, so it's fine. The actual problem would be direct scanout; if that's broken, it's already broken on master
  • I should test some more with legacy modesetting, and re-allow changing LUTs with legacy, at least outside of direct scanout
  • dropping the shadow buffer down to 10bpc can cause some rounding errors; on my monitor in HDR mode I see slight deviations (one 8 bit lsb) from what the color picker reports vs. the real value of an sRGB color. I think we need some setting for the user to configure what they prioritize more - performance and battery life, or color accuracy, and go with a 16 bpc framebuffer anyways in the latter case. !6028 is also relevant for that --> it's still better than on X11, so I think it's fine for now. We can add such a setting later
  • it contains !6065 (merged) and !6067 (merged) which should be merged first
Edited by Xaver Hugl

Merge request reports