Documentation/gpu/rfc/color_pipeline.rst

Source file repositories/reference/linux-study-clean/Documentation/gpu/rfc/color_pipeline.rst

File Facts

System
Linux kernel
Corpus path
Documentation/gpu/rfc/color_pipeline.rst
Extension
.rst
Size
14870 bytes
Lines
378
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

========================
Linux Color Pipeline API
========================

What problem are we solving?
============================

We would like to support pre-, and post-blending complex color
transformations in display controller hardware in order to allow for
HW-supported HDR use-cases, as well as to provide support to
color-managed applications, such as video or image editors.

It is possible to support an HDR output on HW supporting the Colorspace
and HDR Metadata drm_connector properties, but that requires the
compositor or application to render and compose the content into one
final buffer intended for display. Doing so is costly.

Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other
operations to support color transformations. These operations are often
implemented in fixed-function HW and therefore much more power efficient than
performing similar operations via shaders or CPU.

We would like to make use of this HW functionality to support complex color
transformations with no, or minimal CPU or shader load. The switch between HW
fixed-function blocks and shaders/CPU must be seamless with no visible
difference when fallback to shaders/CPU is neceesary at any time.


How are other OSes solving this problem?
========================================

The most widely supported use-cases regard HDR content, whether video or
gaming.

Most OSes will specify the source content format (color gamut, encoding transfer
function, and other metadata, such as max and average light levels) to a driver.
Drivers will then program their fixed-function HW accordingly to map from a
source content buffer's space to a display's space.

When fixed-function HW is not available the compositor will assemble a shader to
ask the GPU to perform the transformation from the source content format to the
display's format.

A compositor's mapping function and a driver's mapping function are usually
entirely separate concepts. On OSes where a HW vendor has no insight into
closed-source compositor code such a vendor will tune their color management
code to visually match the compositor's. On other OSes, where both mapping
functions are open to an implementer they will ensure both mappings match.

This results in mapping algorithm lock-in, meaning that no-one alone can
experiment with or introduce new mapping algorithms and achieve
consistent results regardless of which implementation path is taken.

Why is Linux different?
=======================

Unlike other OSes, where there is one compositor for one or more drivers, on
Linux we have a many-to-many relationship. Many compositors; many drivers.
In addition each compositor vendor or community has their own view of how
color management should be done. This is what makes Linux so beautiful.

This means that a HW vendor can now no longer tune their driver to one
compositor, as tuning it to one could make it look fairly different from
another compositor's color mapping.

We need a better solution.

Annotation

Implementation Notes