* [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
This is how a typical display color hardware pipeline looks like:
+-------------------------------------------+
| RAM |
| +------+ +---------+ +---------+ |
| | FB 1 | | FB 2 | | FB N | |
| +------+ +---------+ +---------+ |
+-------------------------------------------+
| Plane Color Hardware Block |
+--------------------------------------------+
| +---v-----+ +---v-------+ +---v------+ |
| | Plane A | | Plane B | | Plane N | |
| | DeGamma | | Degamma | | Degamma | |
| +---+-----+ +---+-------+ +---+------+ |
| | | | |
| +---v-----+ +---v-------+ +---v------+ |
| |Plane A | | Plane B | | Plane N | |
| |CSC/CTM | | CSC/CTM | | CSC/CTM | |
| +---+-----+ +----+------+ +----+-----+ |
| | | | |
| +---v-----+ +----v------+ +----v-----+ |
| | Plane A | | Plane B | | Plane N | |
| | Gamma | | Gamma | | Gamma | |
| +---+-----+ +----+------+ +----+-----+ |
| | | | |
+--------------------------------------------+
+------v--------------v---------------v-------|
|| ||
|| Pipe Blender ||
+--------------------+------------------------+
| | |
| +-----------v----------+ |
| | Pipe DeGamma | |
| | | |
| +-----------+----------+ |
| | Pipe Color |
| +-----------v----------+ Hardware |
| | Pipe CSC/CTM | |
| | | |
| +-----------+----------+ |
| | |
| +-----------v----------+ |
| | Pipe Gamma | |
| | | |
| +-----------+----------+ |
| | |
+---------------------------------------------+
|
v
Pipe Output
This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data and CSC used for gamut
conversion. It also includes Gamma support used to again non-linearize
data as per panel supported color space. These can be utilize by user
space to convert planes from one format to another, one color space to
another etc.
Userspace can take smart blending decisions and utilize these hardware
supported plane color features to get accurate color profile. The same
can help in consistent color quality from source to panel taking
advantage of advanced color features in hardware.
These patches add the property interfaces and enable helper functions.
This series adds Intel's XE_LPD hw specific plane gamma feature. We
can build up and add other platform/hardware specific implementation
on top of this series.
Credits: Special mention and credits to Ville Syrjala for coming up
with a design for this feature and inputs. This series is based on
his original design and idea.
Note: Userspace support for this new UAPI will be done on Chrome in
alignment with weston and general opensource community.
Discussion ongoing with Harry Wentland, Pekka and community on color
pipeline and UAPI design. Harry's RFC below:
https://patchwork.freedesktop.org/series/89506/
We need to converge on a common UAPI interface which caters to
all the modern color hardware pipelines.
ToDo: State readout for this feature will be added next.
v2: Added UAPI description and added change in the rfc section of
kernel Documentation folder
Uma Shankar (22):
drm: RFC for Plane Color Hardware Pipeline
drm: Add Enhanced Gamma and color lut range attributes
drm: Add Plane Degamma Mode property
drm: Add Plane Degamma Lut property
drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
drm/i915/xelpd: Add register definitions for Plane Degamma
drm/i915/xelpd: Enable plane color features
drm/i915/xelpd: Add color capabilities of SDR planes
drm/i915/xelpd: Program Plane Degamma Registers
drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
drm/i915/xelpd: Initialize plane color features
drm/i915/xelpd: Load plane color luts from atomic flip
drm: Add Plane CTM property
drm: Add helper to attach Plane ctm property
drm/i915/xelpd: Define Plane CSC Registers
drm/i915/xelpd: Enable Plane CSC
drm: Add Plane Gamma Mode property
drm: Add Plane Gamma Lut property
drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
drm/i915/xelpd: Add register definitions for Plane Gamma
drm/i915/xelpd: Program Plane Gamma Registers
drm/i915/xelpd: Enable plane gamma
Documentation/gpu/drm-kms.rst | 90 +++
Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
.../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
.../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
drivers/gpu/drm/i915/display/intel_color.h | 2 +
.../drm/i915/display/skl_universal_plane.c | 15 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
include/drm/drm_mode_object.h | 2 +-
include/drm/drm_plane.h | 81 +++
include/uapi/drm/drm_mode.h | 58 ++
16 files changed, 1337 insertions(+), 6 deletions(-)
create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
--
2.26.2
^ permalink raw reply [flat|nested] 154+ messages in thread* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add Support for Plane Color Lut and CSC features (rev2)
2021-09-06 21:38 ` Uma Shankar
(?)
@ 2021-09-06 21:26 ` Patchwork
-1 siblings, 0 replies; 154+ messages in thread
From: Patchwork @ 2021-09-06 21:26 UTC (permalink / raw)
To: Shankar, Uma; +Cc: intel-gfx
== Series Details ==
Series: Add Support for Plane Color Lut and CSC features (rev2)
URL : https://patchwork.freedesktop.org/series/90825/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0bd5f1aa34e1 drm: RFC for Plane Color Hardware Pipeline
-:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#18:
new file mode 100644
-:23: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1
#23: FILE: Documentation/gpu/rfc/drm_color_pipeline.rst:1:
+==================================================
-:99: ERROR:TRAILING_WHITESPACE: trailing whitespace
#99: FILE: Documentation/gpu/rfc/drm_color_pipeline.rst:77:
+^I$
-:133: ERROR:TRAILING_WHITESPACE: trailing whitespace
#133: FILE: Documentation/gpu/rfc/drm_color_pipeline.rst:111:
+^I$
total: 2 errors, 2 warnings, 0 checks, 167 lines checked
1e2ce83e3017 drm: Add Enhanced Gamma and color lut range attributes
39feb4a85cab drm: Add Plane Degamma Mode property
e54bf9c1c858 drm: Add Plane Degamma Lut property
-:45: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#45: FILE: drivers/gpu/drm/drm_atomic_uapi.c:603:
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->degamma_lut,
total: 0 errors, 0 warnings, 1 checks, 101 lines checked
d92433346e40 drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
df616ff808c3 drm/i915/xelpd: Add register definitions for Plane Degamma
-:37: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#37: FILE: drivers/gpu/drm/i915/i915_reg.h:11407:
+#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
-:49: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#49: FILE: drivers/gpu/drm/i915/i915_reg.h:11419:
+#define PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe))
-:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#61: FILE: drivers/gpu/drm/i915/i915_reg.h:11431:
+#define PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_2(pipe))
-:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#73: FILE: drivers/gpu/drm/i915/i915_reg.h:11443:
+#define PLANE_PRE_CSC_GAMC_DATA(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_2(pipe))
total: 0 errors, 0 warnings, 4 checks, 64 lines checked
3a31d402f88a drm/i915/xelpd: Enable plane color features
790f94f18205 drm/i915/xelpd: Add color capabilities of SDR planes
853f0116ea83 drm/i915/xelpd: Program Plane Degamma Registers
-:68: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#68: FILE: drivers/gpu/drm/i915/display/intel_color.c:2242:
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
-:74: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#74: FILE: drivers/gpu/drm/i915/display/intel_color.c:2248:
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
-:80: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#80: FILE: drivers/gpu/drm/i915/display/intel_color.c:2254:
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
-:84: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#84: FILE: drivers/gpu/drm/i915/display/intel_color.c:2258:
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
-:114: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#114: FILE: drivers/gpu/drm/i915/display/intel_color.c:2288:
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0), v);
total: 0 errors, 5 warnings, 0 checks, 148 lines checked
d64e7e814400 drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
a66cbbe88e63 drm/i915/xelpd: Initialize plane color features
7b01dd73b025 drm/i915/xelpd: Load plane color luts from atomic flip
9a0a55da5520 drm: Add Plane CTM property
-:41: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#41: FILE: drivers/gpu/drm/drm_atomic_uapi.c:610:
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ctm,
total: 0 errors, 0 warnings, 1 checks, 87 lines checked
cccf197af1b9 drm: Add helper to attach Plane ctm property
5c841e35f0e7 drm/i915/xelpd: Define Plane CSC Registers
-:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#29: FILE: drivers/gpu/drm/i915/i915_reg.h:7480:
+#define PLANE_CSC_COEFF(pipe, plane, index) _MMIO_PLANE(plane, \
+ _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \
+ _PLANE_CSC_RY_GY_2(pipe) + (index) * 4)
-:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible side-effects?
#29: FILE: drivers/gpu/drm/i915/i915_reg.h:7480:
+#define PLANE_CSC_COEFF(pipe, plane, index) _MMIO_PLANE(plane, \
+ _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \
+ _PLANE_CSC_RY_GY_2(pipe) + (index) * 4)
-:30: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#30: FILE: drivers/gpu/drm/i915/i915_reg.h:7481:
+ _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \
-:43: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#43: FILE: drivers/gpu/drm/i915/i915_reg.h:7494:
+#define PLANE_CSC_PREOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_PREOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_PREOFF_HI_2(pipe) + \
+ (index) * 4)
-:43: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible side-effects?
#43: FILE: drivers/gpu/drm/i915/i915_reg.h:7494:
+#define PLANE_CSC_PREOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_PREOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_PREOFF_HI_2(pipe) + \
+ (index) * 4)
-:44: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#44: FILE: drivers/gpu/drm/i915/i915_reg.h:7495:
+ (index) * 4, _PLANE_CSC_PREOFF_HI_2(pipe) + \
-:57: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#57: FILE: drivers/gpu/drm/i915/i915_reg.h:7508:
+#define PLANE_CSC_POSTOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_POSTOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_POSTOFF_HI_2(pipe) + \
+ (index) * 4)
-:57: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible side-effects?
#57: FILE: drivers/gpu/drm/i915/i915_reg.h:7508:
+#define PLANE_CSC_POSTOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_POSTOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_POSTOFF_HI_2(pipe) + \
+ (index) * 4)
-:58: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#58: FILE: drivers/gpu/drm/i915/i915_reg.h:7509:
+ (index) * 4, _PLANE_CSC_POSTOFF_HI_2(pipe) + \
total: 0 errors, 3 warnings, 6 checks, 49 lines checked
c80670d0ba61 drm/i915/xelpd: Enable Plane CSC
ec7dd2be1f37 drm: Add Plane Gamma Mode property
a3fc5412d19d drm: Add Plane Gamma Lut property
-:41: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#41: FILE: drivers/gpu/drm/drm_atomic_uapi.c:620:
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->gamma_lut,
total: 0 errors, 0 warnings, 1 checks, 99 lines checked
757106bc29dd drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
-:129: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#129: FILE: drivers/gpu/drm/i915/display/intel_color.c:2492:
+ sizeof(d13_gamma_degamma_sdr),
-:136: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#136: FILE: drivers/gpu/drm/i915/display/intel_color.c:2499:
+ sizeof(d13_gamma_degamma_sdr),
total: 0 errors, 2 warnings, 0 checks, 138 lines checked
e8c016461e9a drm/i915/xelpd: Add register definitions for Plane Gamma
-:23: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#23: FILE: drivers/gpu/drm/i915/i915_reg.h:11498:
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A, \
-:25: WARNING:LONG_LINE: line length of 110 exceeds 100 columns
#25: FILE: drivers/gpu/drm/i915/i915_reg.h:11500:
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A, \
-:27: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#27: FILE: drivers/gpu/drm/i915/i915_reg.h:11502:
+#define PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe))
-:35: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#35: FILE: drivers/gpu/drm/i915/i915_reg.h:11510:
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A, \
-:37: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#37: FILE: drivers/gpu/drm/i915/i915_reg.h:11512:
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A, \
-:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#39: FILE: drivers/gpu/drm/i915/i915_reg.h:11514:
+#define PLANE_POST_CSC_GAMC_SEG0_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe))
-:51: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#51: FILE: drivers/gpu/drm/i915/i915_reg.h:11526:
+#define PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe))
-:63: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#63: FILE: drivers/gpu/drm/i915/i915_reg.h:11538:
+#define PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe))
-:75: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#75: FILE: drivers/gpu/drm/i915/i915_reg.h:11550:
+#define PLANE_POST_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_2(pipe))
-:87: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects?
#87: FILE: drivers/gpu/drm/i915/i915_reg.h:11562:
+#define PLANE_POST_CSC_GAMC_DATA(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_2(pipe))
total: 0 errors, 4 warnings, 6 checks, 79 lines checked
f8a38f97382c drm/i915/xelpd: Program Plane Gamma Registers
-:47: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/display/intel_color.c:2457:
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
-:53: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#53: FILE: drivers/gpu/drm/i915/display/intel_color.c:2463:
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
-:61: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#61: FILE: drivers/gpu/drm/i915/display/intel_color.c:2471:
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
-:65: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#65: FILE: drivers/gpu/drm/i915/display/intel_color.c:2475:
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
-:94: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#94: FILE: drivers/gpu/drm/i915/display/intel_color.c:2504:
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0), v);
total: 0 errors, 5 warnings, 0 checks, 126 lines checked
7336f1126135 drm/i915/xelpd: Enable plane gamma
^ permalink raw reply [flat|nested] 154+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Support for Plane Color Lut and CSC features (rev2)
2021-09-06 21:38 ` Uma Shankar
(?)
(?)
@ 2021-09-06 21:30 ` Patchwork
-1 siblings, 0 replies; 154+ messages in thread
From: Patchwork @ 2021-09-06 21:30 UTC (permalink / raw)
To: Shankar, Uma; +Cc: intel-gfx
== Series Details ==
Series: Add Support for Plane Color Lut and CSC features (rev2)
URL : https://patchwork.freedesktop.org/series/90825/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1345:25: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1345:25: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1345:25: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1346:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1346:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1346:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1405:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1405:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1405:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:354:16: error: incompatible types in comparison expression (different type sizes):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:354:16: unsigned long *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:354:16: unsigned long long *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4483:31: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4483:31: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4483:31: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4485:33: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4485:33: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4485:33: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:294:25: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:294:25: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:294:25: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:295:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:295:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:295:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:344:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:344:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:344:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c:37:6: warning: symbol 'amdgpu_kms_compat_ioctl' was not declared. Should it be static?
+drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:117:1: warning: no newline at end of file
+drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.h:123:51: error: marked inline, but without a definition
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg
^ permalink raw reply [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
This is a RFC proposal for plane color hardware blocks.
It exposes the property interface to userspace and calls
out the details or interfaces created and the intended
purpose.
Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++
1 file changed, 167 insertions(+)
create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst
new file mode 100644
index 000000000000..0d1ca858783b
--- /dev/null
+++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
@@ -0,0 +1,167 @@
+==================================================
+Display Color Pipeline: Proposed DRM Properties
+==================================================
+
+This is how a typical display color hardware pipeline looks like:
+ +-------------------------------------------+
+ | RAM |
+ | +------+ +---------+ +---------+ |
+ | | FB 1 | | FB 2 | | FB N | |
+ | +------+ +---------+ +---------+ |
+ +-------------------------------------------+
+ | Plane Color Hardware Block |
+ +--------------------------------------------+
+ | +---v-----+ +---v-------+ +---v------+ |
+ | | Plane A | | Plane B | | Plane N | |
+ | | DeGamma | | Degamma | | Degamma | |
+ | +---+-----+ +---+-------+ +---+------+ |
+ | | | | |
+ | +---v-----+ +---v-------+ +---v------+ |
+ | |Plane A | | Plane B | | Plane N | |
+ | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
+ | +---+-----+ +----+------+ +----+-----+ |
+ | | | | |
+ | +---v-----+ +----v------+ +----v-----+ |
+ | | Plane A | | Plane B | | Plane N | |
+ | | Gamma | | Gamma | | Gamma | |
+ | +---+-----+ +----+------+ +----+-----+ |
+ | | | | |
+ +--------------------------------------------+
++------v--------------v---------------v-------|
+|| ||
+|| Pipe Blender ||
++--------------------+------------------------+
+| | |
+| +-----------v----------+ |
+| | Pipe DeGamma | |
+| | | |
+| +-----------+----------+ |
+| | Pipe Color |
+| +-----------v----------+ Hardware |
+| | Pipe CSC/CTM | |
+| | | |
+| +-----------+----------+ |
+| | |
+| +-----------v----------+ |
+| | Pipe Gamma | |
+| | | |
+| +-----------+----------+ |
+| | |
++---------------------------------------------+
+ |
+ v
+ Pipe Output
+
+Proposal is to have below properties for a plane:
+
+* Plane Degamma or Pre-Curve:
+ * This will be used to linearize the input framebuffer data.
+ * It will apply the reverse of the color transfer function.
+ * It can be a degamma curve or OETF for HDR.
+ * This linear data can be further acted on by the following
+ * color hardware blocks in the display hardware pipeline
+
+UAPI Name: PLANE_DEGAMMA_MODE
+Description: Enum property with values as blob_id's which advertizes the
+ possible degamma modes and lut ranges supported by the platform.
+ This allows userspace to query and get the plane degamma color
+ caps and choose the appropriate degamma mode and create lut values
+ accordingly.
+
+UAPI Name: PLANE_DEGAMMA_LUT
+Description: Blob property which allows a userspace to provide LUT values
+ to apply degamma curve using the h/w plane degamma processing
+ engine, thereby making the content as linear for further color
+ processing. Userspace gets the size of LUT and precision etc
+ from PLANE_DEGAMA_MODE_PROPERTY
+
+* Plane CTM
+ * This is a Property to program the color transformation matrix.
+ * This can be used to perform a color space conversion like
+ * BT2020 to BT709 or BT601 etc.
+ * This block is generally kept after the degamma unit so that
+ * linear data can be fed to it for conversion.
+
+UAPI Name: PLANE_CTM
+Description: Blob property which allows a userspace to provide CTM coefficients
+ to do color space conversion or any other enhancement by doing a
+ matrix multiplication using the h/w CTM processing engine
+
+* Plane Gamma or Post-Curve
+ * This can be used to perform 2 operations:
+ * non-lineralize the framebuffer data. Can be used for
+ * non linear blending. It can be a gamma curve or EOTF
+ * for HDR.
+ * Perform Tone Mapping operation. This is an operation
+ * done when blending is done with HDR and SDR content.
+
+UAPI Name: PLANE_GAMMA_MODE
+Description: Enum property with values as blob_id's which advertizes the
+ possible gamma modes and lut ranges supported by the platform.
+ This allows userspace to query and get the plane gamma color
+ caps and choose the appropriate gamma mode and create lut values
+ accordingly.
+
+UAPI Name: PLANE_GAMMA_LUT
+Description: Blob property which allows a userspace to provide LUT values
+ to apply gamma curve or perform tone mapping using the h/w plane
+ gamma processing engine, thereby making the content as linear
+ for further color processing. Userspace gets the size of LUT and
+ precision etc from PLANE_GAMA_MODE_PROPERTY
+
+This is part of one plane engine. Data from multiple planes will be
+then fed to pipe where it will get blended. There is a similar set of
+properties available at crtc level which acts on this blended data.
+
+Below is a sample usecase:
+
+ ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
+ │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
+ │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
+ │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone Mapping├────────┐
+ └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
+ │
+ ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
+ │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
+ │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR ├─────┐ │
+ │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
+ └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
+ │ │
+ ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
+ │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
+ │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data in├───┐ │ │
+ │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
+ └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │
+ │ │ │
+ │ │ │
+ │ │ │
+┌───────────────────────────────────────────────────────────────────────────────┴─┴──┘
+│
+│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
+│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
+└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────► TO Port
+ │ data linear │ │ Color Space │ │ Mapping/apply │
+ │ after blend │ │ Conversion │ │ transfer func │
+ └─────────────┘ └─────────────┘ └───────────────┘
+
+
+This patch series adds properties for plane color features. It adds
+properties for degamma used to linearize data and CSC used for gamut
+conversion. It also includes Gamma support used to again non-linearize
+data as per panel supported color space. These can be utilize by user
+space to convert planes from one format to another, one color space to
+another etc.
+
+Userspace can take smart blending decisions and utilize these hardware
+supported plane color features to get accurate color profile. The same
+can help in consistent color quality from source to panel taking
+advantage of advanced color features in hardware.
+
+These patches add the property interfaces and enable helper functions.
+This series adds Intel's XE_LPD hw specific plane gamma feature. We
+can build up and add other platform/hardware specific implementation
+on top of this series.
+
+Credits: Special mention and credits to Ville Syrjala for coming up
+with a design for this feature and inputs. This series is based on
+his original design and idea.
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
This is a RFC proposal for plane color hardware blocks.
It exposes the property interface to userspace and calls
out the details or interfaces created and the intended
purpose.
Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++
1 file changed, 167 insertions(+)
create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst
new file mode 100644
index 000000000000..0d1ca858783b
--- /dev/null
+++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
@@ -0,0 +1,167 @@
+==================================================
+Display Color Pipeline: Proposed DRM Properties
+==================================================
+
+This is how a typical display color hardware pipeline looks like:
+ +-------------------------------------------+
+ | RAM |
+ | +------+ +---------+ +---------+ |
+ | | FB 1 | | FB 2 | | FB N | |
+ | +------+ +---------+ +---------+ |
+ +-------------------------------------------+
+ | Plane Color Hardware Block |
+ +--------------------------------------------+
+ | +---v-----+ +---v-------+ +---v------+ |
+ | | Plane A | | Plane B | | Plane N | |
+ | | DeGamma | | Degamma | | Degamma | |
+ | +---+-----+ +---+-------+ +---+------+ |
+ | | | | |
+ | +---v-----+ +---v-------+ +---v------+ |
+ | |Plane A | | Plane B | | Plane N | |
+ | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
+ | +---+-----+ +----+------+ +----+-----+ |
+ | | | | |
+ | +---v-----+ +----v------+ +----v-----+ |
+ | | Plane A | | Plane B | | Plane N | |
+ | | Gamma | | Gamma | | Gamma | |
+ | +---+-----+ +----+------+ +----+-----+ |
+ | | | | |
+ +--------------------------------------------+
++------v--------------v---------------v-------|
+|| ||
+|| Pipe Blender ||
++--------------------+------------------------+
+| | |
+| +-----------v----------+ |
+| | Pipe DeGamma | |
+| | | |
+| +-----------+----------+ |
+| | Pipe Color |
+| +-----------v----------+ Hardware |
+| | Pipe CSC/CTM | |
+| | | |
+| +-----------+----------+ |
+| | |
+| +-----------v----------+ |
+| | Pipe Gamma | |
+| | | |
+| +-----------+----------+ |
+| | |
++---------------------------------------------+
+ |
+ v
+ Pipe Output
+
+Proposal is to have below properties for a plane:
+
+* Plane Degamma or Pre-Curve:
+ * This will be used to linearize the input framebuffer data.
+ * It will apply the reverse of the color transfer function.
+ * It can be a degamma curve or OETF for HDR.
+ * This linear data can be further acted on by the following
+ * color hardware blocks in the display hardware pipeline
+
+UAPI Name: PLANE_DEGAMMA_MODE
+Description: Enum property with values as blob_id's which advertizes the
+ possible degamma modes and lut ranges supported by the platform.
+ This allows userspace to query and get the plane degamma color
+ caps and choose the appropriate degamma mode and create lut values
+ accordingly.
+
+UAPI Name: PLANE_DEGAMMA_LUT
+Description: Blob property which allows a userspace to provide LUT values
+ to apply degamma curve using the h/w plane degamma processing
+ engine, thereby making the content as linear for further color
+ processing. Userspace gets the size of LUT and precision etc
+ from PLANE_DEGAMA_MODE_PROPERTY
+
+* Plane CTM
+ * This is a Property to program the color transformation matrix.
+ * This can be used to perform a color space conversion like
+ * BT2020 to BT709 or BT601 etc.
+ * This block is generally kept after the degamma unit so that
+ * linear data can be fed to it for conversion.
+
+UAPI Name: PLANE_CTM
+Description: Blob property which allows a userspace to provide CTM coefficients
+ to do color space conversion or any other enhancement by doing a
+ matrix multiplication using the h/w CTM processing engine
+
+* Plane Gamma or Post-Curve
+ * This can be used to perform 2 operations:
+ * non-lineralize the framebuffer data. Can be used for
+ * non linear blending. It can be a gamma curve or EOTF
+ * for HDR.
+ * Perform Tone Mapping operation. This is an operation
+ * done when blending is done with HDR and SDR content.
+
+UAPI Name: PLANE_GAMMA_MODE
+Description: Enum property with values as blob_id's which advertizes the
+ possible gamma modes and lut ranges supported by the platform.
+ This allows userspace to query and get the plane gamma color
+ caps and choose the appropriate gamma mode and create lut values
+ accordingly.
+
+UAPI Name: PLANE_GAMMA_LUT
+Description: Blob property which allows a userspace to provide LUT values
+ to apply gamma curve or perform tone mapping using the h/w plane
+ gamma processing engine, thereby making the content as linear
+ for further color processing. Userspace gets the size of LUT and
+ precision etc from PLANE_GAMA_MODE_PROPERTY
+
+This is part of one plane engine. Data from multiple planes will be
+then fed to pipe where it will get blended. There is a similar set of
+properties available at crtc level which acts on this blended data.
+
+Below is a sample usecase:
+
+ ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
+ │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
+ │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
+ │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone Mapping├────────┐
+ └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
+ │
+ ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
+ │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
+ │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR ├─────┐ │
+ │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
+ └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
+ │ │
+ ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
+ │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
+ │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data in├───┐ │ │
+ │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
+ └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │
+ │ │ │
+ │ │ │
+ │ │ │
+┌───────────────────────────────────────────────────────────────────────────────┴─┴──┘
+│
+│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
+│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
+└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────► TO Port
+ │ data linear │ │ Color Space │ │ Mapping/apply │
+ │ after blend │ │ Conversion │ │ transfer func │
+ └─────────────┘ └─────────────┘ └───────────────┘
+
+
+This patch series adds properties for plane color features. It adds
+properties for degamma used to linearize data and CSC used for gamut
+conversion. It also includes Gamma support used to again non-linearize
+data as per panel supported color space. These can be utilize by user
+space to convert planes from one format to another, one color space to
+another etc.
+
+Userspace can take smart blending decisions and utilize these hardware
+supported plane color features to get accurate color profile. The same
+can help in consistent color quality from source to panel taking
+advantage of advanced color features in hardware.
+
+These patches add the property interfaces and enable helper functions.
+This series adds Intel's XE_LPD hw specific plane gamma feature. We
+can build up and add other platform/hardware specific implementation
+on top of this series.
+
+Credits: Special mention and credits to Ville Syrjala for coming up
+with a design for this feature and inputs. This series is based on
+his original design and idea.
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-09-06 21:38 ` Uma Shankar
@ 2021-10-12 10:30 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 10:30 UTC (permalink / raw)
To: Uma Shankar
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 16251 bytes --]
On Tue, 7 Sep 2021 03:08:43 +0530
Uma Shankar <uma.shankar@intel.com> wrote:
> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls
> out the details or interfaces created and the intended
> purpose.
>
> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++
> 1 file changed, 167 insertions(+)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst
> new file mode 100644
> index 000000000000..0d1ca858783b
> --- /dev/null
> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> @@ -0,0 +1,167 @@
> +==================================================
> +Display Color Pipeline: Proposed DRM Properties
Hi,
is there a practise of landing proposal documents in the kernel? How
does that work, will a kernel tree carry the patch files?
Or should this document be worded like documentation for an accepted
feature, and then the patches either land or don't?
> +==================================================
> +
> +This is how a typical display color hardware pipeline looks like:
Typical, or should we say that this is the abstract color pipeline that
KMS assumes?
Then drivers map this to pieces of hardware the best they can and
reject or do not expose the parts they cannot.
> + +-------------------------------------------+
> + | RAM |
> + | +------+ +---------+ +---------+ |
> + | | FB 1 | | FB 2 | | FB N | |
> + | +------+ +---------+ +---------+ |
> + +-------------------------------------------+
> + | Plane Color Hardware Block |
> + +--------------------------------------------+
> + | +---v-----+ +---v-------+ +---v------+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | DeGamma | | Degamma | | Degamma | |
> + | +---+-----+ +---+-------+ +---+------+ |
> + | | | | |
> + | +---v-----+ +---v-------+ +---v------+ |
> + | |Plane A | | Plane B | | Plane N | |
> + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + | +---v-----+ +----v------+ +----v-----+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | Gamma | | Gamma | | Gamma | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + +--------------------------------------------+
> ++------v--------------v---------------v-------|
> +|| ||
> +|| Pipe Blender ||
> ++--------------------+------------------------+
> +| | |
> +| +-----------v----------+ |
> +| | Pipe DeGamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | Pipe Color |
> +| +-----------v----------+ Hardware |
> +| | Pipe CSC/CTM | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> +| +-----------v----------+ |
> +| | Pipe Gamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> ++---------------------------------------------+
> + |
> + v
> + Pipe Output
> +
> +Proposal is to have below properties for a plane:
> +
> +* Plane Degamma or Pre-Curve:
> + * This will be used to linearize the input framebuffer data.
> + * It will apply the reverse of the color transfer function.
> + * It can be a degamma curve or OETF for HDR.
As you want to produce light-linear values, you use EOTF or inverse
OETF.
The term OETF has a built-in assumption that that happens in a camera:
it takes in light and produces and electrical signal. Lately I have
personally started talking about non-linear encoding of color values,
since EOTF is often associated with displays if nothing else is said
(taking in an electrical signal and producing light).
So this would be decoding the color values into light-linear color
values. That is what an EOTF does, yes, but I feel there is a nuanced
difference. A piece of equipment implements an EOTF by turning an
electrical signal into light, hence EOTF often refers to specific
equipment. You could talk about content EOTF to denote content value
encoding, as opposed to output or display EOTF, but that might be
confusing if you look at e.g. the diagrams in BT.2100: is it the EOTF
or is it the inverse OETF? Is the (inverse?) OOTF included?
So I try to side-step those questions by talking about encoding.
> + * This linear data can be further acted on by the following
> + * color hardware blocks in the display hardware pipeline
I think this and the above description ties the intended use down too
much. This is one possible way to use degamma, yes, but there may be
others. Particularly if CTM can be replaced with a 3D LUT, then the
degamma is more likely a shaper (non-linear adjustment to 3D LUT tap
positions).
I would prefer the name pre-curve to underline that this can be
whatever one wants it to be, but I understand that people may be more
familiar with the name degamma.
> +
> +UAPI Name: PLANE_DEGAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes
> the
Is enum with blob id values even a thing?
> + possible degamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane degamma color
> + caps and choose the appropriate degamma mode and create lut values
> + accordingly.
I agree that some sort of "mode" switch is necessary, and advertisement
of capabilities as well.
> +
> +UAPI Name: PLANE_DEGAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply degamma curve using the h/w plane degamma processing
> + engine, thereby making the content as linear for further color
> + processing. Userspace gets the size of LUT and precision etc
> + from PLANE_DEGAMA_MODE_PROPERTY
So all degamma modes will always be some kind of LUT? That may be a bit
restrictive, as I understand AMD may have predefined or parameterised
curves that are not LUTs. So there should be room for an arbitrary
structure of parameters, which can be passed in as a blob id, and the
contents defined by the degamma mode.
LUT size, precision, and other details of each degamma mode would be
good to expose somehow. I kind of expected those would have been
exposed through the above mentioned "enum with blob id values" where
each blob content structure is defined by the respective enum value.
> +
> +* Plane CTM
> + * This is a Property to program the color transformation matrix.
No mode property here? Is there any hardware with something else than a
matrix at this point?
Should we assume there will be hardware with something else, and have a
CSC mode property with only a single enum value defined so far:
"matrix"? Or do we say PLANE_CTM is a matrix and if you have something
else in hardware, then invent a new property for it?
> + * This can be used to perform a color space conversion like
> + * BT2020 to BT709 or BT601 etc.
> + * This block is generally kept after the degamma unit so that
Not "generally". If blocks can change places, then it becomes
intractable for generic userspace to program.
> + * linear data can be fed to it for conversion.
> +
> +UAPI Name: PLANE_CTM
> +Description: Blob property which allows a userspace to provide CTM coefficients
> + to do color space conversion or any other enhancement by doing a
> + matrix multiplication using the h/w CTM processing engine
> +
Speaking of color space conversions, we should probably define what
happens to out-of-range color values. Converting color into smaller
gamut or smaller dynamic range always has the risk of ending up with
out-of-range values. I suppose those get simply clipped independently
on each color channel, right?
Such clipping can change hue, so userspace would be better avoid
triggering clipping at all, but we still need to know what would happen
with out-of-range values.
We would also need to know when clipping will happen. If FP16
(half-float) FB produces out-of-range values and degamma stage is not
used, will the CTM see original or clipped values? Or is that something
we have to define as hardware-specific?
Generic userspace will try hard to avoid triggering hardware-specific
behaviour, so you can expect such behaviour to go unused.
> +* Plane Gamma or Post-Curve
> + * This can be used to perform 2 operations:
> + * non-lineralize the framebuffer data. Can be used for
> + * non linear blending. It can be a gamma curve or EOTF
> + * for HDR.
> + * Perform Tone Mapping operation. This is an operation
> + * done when blending is done with HDR and SDR content.
I like this wording better than the wording for pre-curve: "can", not
"will". It leaves room for creative use of this processing block.
Tone-mapping is needed always when dynamic range differs, so also for
HDR to HDR, not just SDR to/from HDR.
> +
> +UAPI Name: PLANE_GAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes the
> + possible gamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane gamma color
> + caps and choose the appropriate gamma mode and create lut values
> + accordingly.
> +
> +UAPI Name: PLANE_GAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply gamma curve or perform tone mapping using the h/w plane
> + gamma processing engine, thereby making the content as linear
> + for further color processing. Userspace gets the size of LUT and
> + precision etc from PLANE_GAMA_MODE_PROPERTY
The same comments here as with DEGAMMA.
> +
> +This is part of one plane engine. Data from multiple planes will be
> +then fed to pipe where it will get blended. There is a similar set of
> +properties available at crtc level which acts on this blended data.
> +
> +Below is a sample usecase:
> +
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
> + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone Mapping├────────┐
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
> + │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
> + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR ├─────┐ │
> + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
> + │ │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
> + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data in├───┐ │ │
> + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │
EOTF, not OETF, since it is converting E to O, electrical to optical.
> + │ │ │
> + │ │ │
> + │ │ │
> +┌───────────────────────────────────────────────────────────────────────────────┴─┴──┘
> +│
> +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────► TO Port
> + │ data linear │ │ Color Space │ │ Mapping/apply │
> + │ after blend │ │ Conversion │ │ transfer func │
> + └─────────────┘ └─────────────┘ └───────────────┘
Blending does not change whether the data is linear or not. I suppose
in this example, CRTC degamma and CTM would be passthrough, and gamma
would be the inverse display EOTF for encoding color values into what
the monitor expects.
> +
> +
> +This patch series adds properties for plane color features. It adds
> +properties for degamma used to linearize data and CSC used for gamut
> +conversion. It also includes Gamma support used to again non-linearize
> +data as per panel supported color space. These can be utilize by user
> +space to convert planes from one format to another, one color space to
> +another etc.
FWIW, this is exactly the structure I have assumed in the Weston CM&HDR
work.
> +
> +Userspace can take smart blending decisions and utilize these hardware
> +supported plane color features to get accurate color profile. The same
> +can help in consistent color quality from source to panel taking
> +advantage of advanced color features in hardware.
> +
> +These patches add the property interfaces and enable helper functions.
> +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> +can build up and add other platform/hardware specific implementation
> +on top of this series.
> +
> +Credits: Special mention and credits to Ville Syrjala for coming up
> +with a design for this feature and inputs. This series is based on
> +his original design and idea.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-12 10:30 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 10:30 UTC (permalink / raw)
To: Uma Shankar
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 16251 bytes --]
On Tue, 7 Sep 2021 03:08:43 +0530
Uma Shankar <uma.shankar@intel.com> wrote:
> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls
> out the details or interfaces created and the intended
> purpose.
>
> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++
> 1 file changed, 167 insertions(+)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst
> new file mode 100644
> index 000000000000..0d1ca858783b
> --- /dev/null
> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> @@ -0,0 +1,167 @@
> +==================================================
> +Display Color Pipeline: Proposed DRM Properties
Hi,
is there a practise of landing proposal documents in the kernel? How
does that work, will a kernel tree carry the patch files?
Or should this document be worded like documentation for an accepted
feature, and then the patches either land or don't?
> +==================================================
> +
> +This is how a typical display color hardware pipeline looks like:
Typical, or should we say that this is the abstract color pipeline that
KMS assumes?
Then drivers map this to pieces of hardware the best they can and
reject or do not expose the parts they cannot.
> + +-------------------------------------------+
> + | RAM |
> + | +------+ +---------+ +---------+ |
> + | | FB 1 | | FB 2 | | FB N | |
> + | +------+ +---------+ +---------+ |
> + +-------------------------------------------+
> + | Plane Color Hardware Block |
> + +--------------------------------------------+
> + | +---v-----+ +---v-------+ +---v------+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | DeGamma | | Degamma | | Degamma | |
> + | +---+-----+ +---+-------+ +---+------+ |
> + | | | | |
> + | +---v-----+ +---v-------+ +---v------+ |
> + | |Plane A | | Plane B | | Plane N | |
> + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + | +---v-----+ +----v------+ +----v-----+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | Gamma | | Gamma | | Gamma | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + +--------------------------------------------+
> ++------v--------------v---------------v-------|
> +|| ||
> +|| Pipe Blender ||
> ++--------------------+------------------------+
> +| | |
> +| +-----------v----------+ |
> +| | Pipe DeGamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | Pipe Color |
> +| +-----------v----------+ Hardware |
> +| | Pipe CSC/CTM | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> +| +-----------v----------+ |
> +| | Pipe Gamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> ++---------------------------------------------+
> + |
> + v
> + Pipe Output
> +
> +Proposal is to have below properties for a plane:
> +
> +* Plane Degamma or Pre-Curve:
> + * This will be used to linearize the input framebuffer data.
> + * It will apply the reverse of the color transfer function.
> + * It can be a degamma curve or OETF for HDR.
As you want to produce light-linear values, you use EOTF or inverse
OETF.
The term OETF has a built-in assumption that that happens in a camera:
it takes in light and produces and electrical signal. Lately I have
personally started talking about non-linear encoding of color values,
since EOTF is often associated with displays if nothing else is said
(taking in an electrical signal and producing light).
So this would be decoding the color values into light-linear color
values. That is what an EOTF does, yes, but I feel there is a nuanced
difference. A piece of equipment implements an EOTF by turning an
electrical signal into light, hence EOTF often refers to specific
equipment. You could talk about content EOTF to denote content value
encoding, as opposed to output or display EOTF, but that might be
confusing if you look at e.g. the diagrams in BT.2100: is it the EOTF
or is it the inverse OETF? Is the (inverse?) OOTF included?
So I try to side-step those questions by talking about encoding.
> + * This linear data can be further acted on by the following
> + * color hardware blocks in the display hardware pipeline
I think this and the above description ties the intended use down too
much. This is one possible way to use degamma, yes, but there may be
others. Particularly if CTM can be replaced with a 3D LUT, then the
degamma is more likely a shaper (non-linear adjustment to 3D LUT tap
positions).
I would prefer the name pre-curve to underline that this can be
whatever one wants it to be, but I understand that people may be more
familiar with the name degamma.
> +
> +UAPI Name: PLANE_DEGAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes
> the
Is enum with blob id values even a thing?
> + possible degamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane degamma color
> + caps and choose the appropriate degamma mode and create lut values
> + accordingly.
I agree that some sort of "mode" switch is necessary, and advertisement
of capabilities as well.
> +
> +UAPI Name: PLANE_DEGAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply degamma curve using the h/w plane degamma processing
> + engine, thereby making the content as linear for further color
> + processing. Userspace gets the size of LUT and precision etc
> + from PLANE_DEGAMA_MODE_PROPERTY
So all degamma modes will always be some kind of LUT? That may be a bit
restrictive, as I understand AMD may have predefined or parameterised
curves that are not LUTs. So there should be room for an arbitrary
structure of parameters, which can be passed in as a blob id, and the
contents defined by the degamma mode.
LUT size, precision, and other details of each degamma mode would be
good to expose somehow. I kind of expected those would have been
exposed through the above mentioned "enum with blob id values" where
each blob content structure is defined by the respective enum value.
> +
> +* Plane CTM
> + * This is a Property to program the color transformation matrix.
No mode property here? Is there any hardware with something else than a
matrix at this point?
Should we assume there will be hardware with something else, and have a
CSC mode property with only a single enum value defined so far:
"matrix"? Or do we say PLANE_CTM is a matrix and if you have something
else in hardware, then invent a new property for it?
> + * This can be used to perform a color space conversion like
> + * BT2020 to BT709 or BT601 etc.
> + * This block is generally kept after the degamma unit so that
Not "generally". If blocks can change places, then it becomes
intractable for generic userspace to program.
> + * linear data can be fed to it for conversion.
> +
> +UAPI Name: PLANE_CTM
> +Description: Blob property which allows a userspace to provide CTM coefficients
> + to do color space conversion or any other enhancement by doing a
> + matrix multiplication using the h/w CTM processing engine
> +
Speaking of color space conversions, we should probably define what
happens to out-of-range color values. Converting color into smaller
gamut or smaller dynamic range always has the risk of ending up with
out-of-range values. I suppose those get simply clipped independently
on each color channel, right?
Such clipping can change hue, so userspace would be better avoid
triggering clipping at all, but we still need to know what would happen
with out-of-range values.
We would also need to know when clipping will happen. If FP16
(half-float) FB produces out-of-range values and degamma stage is not
used, will the CTM see original or clipped values? Or is that something
we have to define as hardware-specific?
Generic userspace will try hard to avoid triggering hardware-specific
behaviour, so you can expect such behaviour to go unused.
> +* Plane Gamma or Post-Curve
> + * This can be used to perform 2 operations:
> + * non-lineralize the framebuffer data. Can be used for
> + * non linear blending. It can be a gamma curve or EOTF
> + * for HDR.
> + * Perform Tone Mapping operation. This is an operation
> + * done when blending is done with HDR and SDR content.
I like this wording better than the wording for pre-curve: "can", not
"will". It leaves room for creative use of this processing block.
Tone-mapping is needed always when dynamic range differs, so also for
HDR to HDR, not just SDR to/from HDR.
> +
> +UAPI Name: PLANE_GAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes the
> + possible gamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane gamma color
> + caps and choose the appropriate gamma mode and create lut values
> + accordingly.
> +
> +UAPI Name: PLANE_GAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply gamma curve or perform tone mapping using the h/w plane
> + gamma processing engine, thereby making the content as linear
> + for further color processing. Userspace gets the size of LUT and
> + precision etc from PLANE_GAMA_MODE_PROPERTY
The same comments here as with DEGAMMA.
> +
> +This is part of one plane engine. Data from multiple planes will be
> +then fed to pipe where it will get blended. There is a similar set of
> +properties available at crtc level which acts on this blended data.
> +
> +Below is a sample usecase:
> +
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
> + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone Mapping├────────┐
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
> + │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
> + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR ├─────┐ │
> + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
> + │ │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
> + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data in├───┐ │ │
> + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │
EOTF, not OETF, since it is converting E to O, electrical to optical.
> + │ │ │
> + │ │ │
> + │ │ │
> +┌───────────────────────────────────────────────────────────────────────────────┴─┴──┘
> +│
> +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────► TO Port
> + │ data linear │ │ Color Space │ │ Mapping/apply │
> + │ after blend │ │ Conversion │ │ transfer func │
> + └─────────────┘ └─────────────┘ └───────────────┘
Blending does not change whether the data is linear or not. I suppose
in this example, CRTC degamma and CTM would be passthrough, and gamma
would be the inverse display EOTF for encoding color values into what
the monitor expects.
> +
> +
> +This patch series adds properties for plane color features. It adds
> +properties for degamma used to linearize data and CSC used for gamut
> +conversion. It also includes Gamma support used to again non-linearize
> +data as per panel supported color space. These can be utilize by user
> +space to convert planes from one format to another, one color space to
> +another etc.
FWIW, this is exactly the structure I have assumed in the Weston CM&HDR
work.
> +
> +Userspace can take smart blending decisions and utilize these hardware
> +supported plane color features to get accurate color profile. The same
> +can help in consistent color quality from source to panel taking
> +advantage of advanced color features in hardware.
> +
> +These patches add the property interfaces and enable helper functions.
> +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> +can build up and add other platform/hardware specific implementation
> +on top of this series.
> +
> +Credits: Special mention and credits to Ville Syrjala for coming up
> +with a design for this feature and inputs. This series is based on
> +his original design and idea.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 10:30 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-12 10:35 ` Simon Ser
-1 siblings, 0 replies; 154+ messages in thread
From: Simon Ser @ 2021-10-12 10:35 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Uma Shankar, intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> is there a practise of landing proposal documents in the kernel? How
> does that work, will a kernel tree carry the patch files?
> Or should this document be worded like documentation for an accepted
> feature, and then the patches either land or don't?
Once everyone agrees, the RFC can land. I don't think a kernel tree is
necessary. See:
https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-12 10:35 ` Simon Ser
0 siblings, 0 replies; 154+ messages in thread
From: Simon Ser @ 2021-10-12 10:35 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Uma Shankar, intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> is there a practise of landing proposal documents in the kernel? How
> does that work, will a kernel tree carry the patch files?
> Or should this document be worded like documentation for an accepted
> feature, and then the patches either land or don't?
Once everyone agrees, the RFC can land. I don't think a kernel tree is
necessary. See:
https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 10:35 ` [Intel-gfx] " Simon Ser
@ 2021-10-12 12:00 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 12:00 UTC (permalink / raw)
To: Simon Ser
Cc: Uma Shankar, intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
On Tue, 12 Oct 2021 10:35:37 +0000
Simon Ser <contact@emersion.fr> wrote:
> On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> > is there a practise of landing proposal documents in the kernel? How
> > does that work, will a kernel tree carry the patch files?
> > Or should this document be worded like documentation for an accepted
> > feature, and then the patches either land or don't?
>
> Once everyone agrees, the RFC can land. I don't think a kernel tree is
> necessary. See:
>
> https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
Does this mean the RFC doc patch will land, but the code patches will
remain in the review cycles waiting for userspace proving vehicles?
Rather than e.g. committed as files that people would need to apply
themselves? Or how does one find the code patches corresponding to RFC
docs?
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-12 12:00 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 12:00 UTC (permalink / raw)
To: Simon Ser
Cc: Uma Shankar, intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
On Tue, 12 Oct 2021 10:35:37 +0000
Simon Ser <contact@emersion.fr> wrote:
> On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> > is there a practise of landing proposal documents in the kernel? How
> > does that work, will a kernel tree carry the patch files?
> > Or should this document be worded like documentation for an accepted
> > feature, and then the patches either land or don't?
>
> Once everyone agrees, the RFC can land. I don't think a kernel tree is
> necessary. See:
>
> https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
Does this mean the RFC doc patch will land, but the code patches will
remain in the review cycles waiting for userspace proving vehicles?
Rather than e.g. committed as files that people would need to apply
themselves? Or how does one find the code patches corresponding to RFC
docs?
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 12:00 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-12 19:11 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 19:11 UTC (permalink / raw)
To: Pekka Paalanen, Simon Ser, daniel.vetter
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 5:30 PM
> To: Simon Ser <contact@emersion.fr>
> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org; harry.wentland@amd.com;
> ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 12 Oct 2021 10:35:37 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
> > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> <ppaalanen@gmail.com> wrote:
> >
> > > is there a practise of landing proposal documents in the kernel? How
> > > does that work, will a kernel tree carry the patch files?
> > > Or should this document be worded like documentation for an accepted
> > > feature, and then the patches either land or don't?
> >
> > Once everyone agrees, the RFC can land. I don't think a kernel tree is
> > necessary. See:
> >
> > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
>
> Does this mean the RFC doc patch will land, but the code patches will remain in the
> review cycles waiting for userspace proving vehicles?
> Rather than e.g. committed as files that people would need to apply themselves? Or
> how does one find the code patches corresponding to RFC docs?
As I understand, this section was added to finalize the design and debate on the UAPI,
structures, headers and design etc. Once a general agreement is in place with all the
stakeholders, we can have ack on design and approach and get it merged. This hence
serves as an approved reference for the UAPI, accepted and agreed by community at large.
Once the code lands, all the documentation will be added to the right driver sections and
helpers, like it's been done currently.
@daniel.vetter@ffwll.ch Hope this is the right understanding.
Thanks & Regards,
Uma Shankar
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-12 19:11 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 19:11 UTC (permalink / raw)
To: Pekka Paalanen, Simon Ser, daniel.vetter
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 5:30 PM
> To: Simon Ser <contact@emersion.fr>
> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org; harry.wentland@amd.com;
> ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 12 Oct 2021 10:35:37 +0000
> Simon Ser <contact@emersion.fr> wrote:
>
> > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> <ppaalanen@gmail.com> wrote:
> >
> > > is there a practise of landing proposal documents in the kernel? How
> > > does that work, will a kernel tree carry the patch files?
> > > Or should this document be worded like documentation for an accepted
> > > feature, and then the patches either land or don't?
> >
> > Once everyone agrees, the RFC can land. I don't think a kernel tree is
> > necessary. See:
> >
> > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
>
> Does this mean the RFC doc patch will land, but the code patches will remain in the
> review cycles waiting for userspace proving vehicles?
> Rather than e.g. committed as files that people would need to apply themselves? Or
> how does one find the code patches corresponding to RFC docs?
As I understand, this section was added to finalize the design and debate on the UAPI,
structures, headers and design etc. Once a general agreement is in place with all the
stakeholders, we can have ack on design and approach and get it merged. This hence
serves as an approved reference for the UAPI, accepted and agreed by community at large.
Once the code lands, all the documentation will be added to the right driver sections and
helpers, like it's been done currently.
@daniel.vetter@ffwll.ch Hope this is the right understanding.
Thanks & Regards,
Uma Shankar
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 19:11 ` [Intel-gfx] " Shankar, Uma
@ 2021-10-13 7:25 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-13 7:25 UTC (permalink / raw)
To: Shankar, Uma
Cc: Simon Ser, daniel.vetter, intel-gfx, dri-devel, harry.wentland,
ville.syrjala, brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]
On Tue, 12 Oct 2021 19:11:29 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Pekka Paalanen <ppaalanen@gmail.com>
> > Sent: Tuesday, October 12, 2021 5:30 PM
> > To: Simon Ser <contact@emersion.fr>
> > Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> > devel@lists.freedesktop.org; harry.wentland@amd.com;
> > ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> > On Tue, 12 Oct 2021 10:35:37 +0000
> > Simon Ser <contact@emersion.fr> wrote:
> >
> > > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> > <ppaalanen@gmail.com> wrote:
> > >
> > > > is there a practise of landing proposal documents in the kernel? How
> > > > does that work, will a kernel tree carry the patch files?
> > > > Or should this document be worded like documentation for an accepted
> > > > feature, and then the patches either land or don't?
> > >
> > > Once everyone agrees, the RFC can land. I don't think a kernel tree is
> > > necessary. See:
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
> >
> > Does this mean the RFC doc patch will land, but the code patches will remain in the
> > review cycles waiting for userspace proving vehicles?
> > Rather than e.g. committed as files that people would need to apply themselves? Or
> > how does one find the code patches corresponding to RFC docs?
>
> As I understand, this section was added to finalize the design and debate on the UAPI,
> structures, headers and design etc. Once a general agreement is in place with all the
> stakeholders, we can have ack on design and approach and get it merged. This hence
> serves as an approved reference for the UAPI, accepted and agreed by community at large.
>
> Once the code lands, all the documentation will be added to the right driver sections and
> helpers, like it's been done currently.
I'm just wondering: someone browses a kernel tree, and discovers this
RFC doc in there. They want to see or test the latest (WIP) kernel
implementation of it. How will they find the code / patches?
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-13 7:25 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-13 7:25 UTC (permalink / raw)
To: Shankar, Uma
Cc: Simon Ser, daniel.vetter, intel-gfx, dri-devel, harry.wentland,
ville.syrjala, brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]
On Tue, 12 Oct 2021 19:11:29 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Pekka Paalanen <ppaalanen@gmail.com>
> > Sent: Tuesday, October 12, 2021 5:30 PM
> > To: Simon Ser <contact@emersion.fr>
> > Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> > devel@lists.freedesktop.org; harry.wentland@amd.com;
> > ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> > On Tue, 12 Oct 2021 10:35:37 +0000
> > Simon Ser <contact@emersion.fr> wrote:
> >
> > > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> > <ppaalanen@gmail.com> wrote:
> > >
> > > > is there a practise of landing proposal documents in the kernel? How
> > > > does that work, will a kernel tree carry the patch files?
> > > > Or should this document be worded like documentation for an accepted
> > > > feature, and then the patches either land or don't?
> > >
> > > Once everyone agrees, the RFC can land. I don't think a kernel tree is
> > > necessary. See:
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
> >
> > Does this mean the RFC doc patch will land, but the code patches will remain in the
> > review cycles waiting for userspace proving vehicles?
> > Rather than e.g. committed as files that people would need to apply themselves? Or
> > how does one find the code patches corresponding to RFC docs?
>
> As I understand, this section was added to finalize the design and debate on the UAPI,
> structures, headers and design etc. Once a general agreement is in place with all the
> stakeholders, we can have ack on design and approach and get it merged. This hence
> serves as an approved reference for the UAPI, accepted and agreed by community at large.
>
> Once the code lands, all the documentation will be added to the right driver sections and
> helpers, like it's been done currently.
I'm just wondering: someone browses a kernel tree, and discovers this
RFC doc in there. They want to see or test the latest (WIP) kernel
implementation of it. How will they find the code / patches?
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-13 7:25 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-14 19:46 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-14 19:46 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Simon Ser, daniel.vetter, intel-gfx, dri-devel, harry.wentland,
ville.syrjala, brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Wednesday, October 13, 2021 12:56 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: Simon Ser <contact@emersion.fr>; daniel.vetter@ffwll.ch; intel-
> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 12 Oct 2021 19:11:29 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Pekka Paalanen <ppaalanen@gmail.com>
> > > Sent: Tuesday, October 12, 2021 5:30 PM
> > > To: Simon Ser <contact@emersion.fr>
> > > Cc: Shankar, Uma <uma.shankar@intel.com>;
> > > intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
> > > harry.wentland@amd.com; ville.syrjala@linux.intel.com;
> > > brian.starkey@arm.com; sebastian@sebastianwick.net;
> > > Shashank.Sharma@amd.com
> > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
> > > Pipeline
> > >
> > > On Tue, 12 Oct 2021 10:35:37 +0000
> > > Simon Ser <contact@emersion.fr> wrote:
> > >
> > > > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> > > <ppaalanen@gmail.com> wrote:
> > > >
> > > > > is there a practise of landing proposal documents in the kernel?
> > > > > How does that work, will a kernel tree carry the patch files?
> > > > > Or should this document be worded like documentation for an
> > > > > accepted feature, and then the patches either land or don't?
> > > >
> > > > Once everyone agrees, the RFC can land. I don't think a kernel
> > > > tree is necessary. See:
> > > >
> > > > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
> > >
> > > Does this mean the RFC doc patch will land, but the code patches
> > > will remain in the review cycles waiting for userspace proving vehicles?
> > > Rather than e.g. committed as files that people would need to apply
> > > themselves? Or how does one find the code patches corresponding to RFC docs?
> >
> > As I understand, this section was added to finalize the design and
> > debate on the UAPI, structures, headers and design etc. Once a general
> > agreement is in place with all the stakeholders, we can have ack on
> > design and approach and get it merged. This hence serves as an approved
> reference for the UAPI, accepted and agreed by community at large.
> >
> > Once the code lands, all the documentation will be added to the right
> > driver sections and helpers, like it's been done currently.
>
> I'm just wondering: someone browses a kernel tree, and discovers this RFC doc in
> there. They want to see or test the latest (WIP) kernel implementation of it. How will
> they find the code / patches?
Maybe we could include the WIP links here to help with getting the pieces, this may include
the driver patches and also the userspace efforts as well.
Regards,
Uma Shankar
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-14 19:46 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-14 19:46 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Simon Ser, daniel.vetter, intel-gfx, dri-devel, harry.wentland,
ville.syrjala, brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Wednesday, October 13, 2021 12:56 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: Simon Ser <contact@emersion.fr>; daniel.vetter@ffwll.ch; intel-
> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 12 Oct 2021 19:11:29 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Pekka Paalanen <ppaalanen@gmail.com>
> > > Sent: Tuesday, October 12, 2021 5:30 PM
> > > To: Simon Ser <contact@emersion.fr>
> > > Cc: Shankar, Uma <uma.shankar@intel.com>;
> > > intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
> > > harry.wentland@amd.com; ville.syrjala@linux.intel.com;
> > > brian.starkey@arm.com; sebastian@sebastianwick.net;
> > > Shashank.Sharma@amd.com
> > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
> > > Pipeline
> > >
> > > On Tue, 12 Oct 2021 10:35:37 +0000
> > > Simon Ser <contact@emersion.fr> wrote:
> > >
> > > > On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> > > <ppaalanen@gmail.com> wrote:
> > > >
> > > > > is there a practise of landing proposal documents in the kernel?
> > > > > How does that work, will a kernel tree carry the patch files?
> > > > > Or should this document be worded like documentation for an
> > > > > accepted feature, and then the patches either land or don't?
> > > >
> > > > Once everyone agrees, the RFC can land. I don't think a kernel
> > > > tree is necessary. See:
> > > >
> > > > https://dri.freedesktop.org/docs/drm/gpu/rfc/index.html
> > >
> > > Does this mean the RFC doc patch will land, but the code patches
> > > will remain in the review cycles waiting for userspace proving vehicles?
> > > Rather than e.g. committed as files that people would need to apply
> > > themselves? Or how does one find the code patches corresponding to RFC docs?
> >
> > As I understand, this section was added to finalize the design and
> > debate on the UAPI, structures, headers and design etc. Once a general
> > agreement is in place with all the stakeholders, we can have ack on
> > design and approach and get it merged. This hence serves as an approved
> reference for the UAPI, accepted and agreed by community at large.
> >
> > Once the code lands, all the documentation will be added to the right
> > driver sections and helpers, like it's been done currently.
>
> I'm just wondering: someone browses a kernel tree, and discovers this RFC doc in
> there. They want to see or test the latest (WIP) kernel implementation of it. How will
> they find the code / patches?
Maybe we could include the WIP links here to help with getting the pieces, this may include
the driver patches and also the userspace efforts as well.
Regards,
Uma Shankar
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 10:30 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-12 20:58 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 20:58 UTC (permalink / raw)
To: Pekka Paalanen, harry.wentland, ville.syrjala
Cc: intel-gfx, dri-devel, brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 4:01 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com;
> brian.starkey@arm.com; sebastian@sebastianwick.net;
> Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 7 Sep 2021 03:08:43 +0530
> Uma Shankar <uma.shankar@intel.com> wrote:
>
> > This is a RFC proposal for plane color hardware blocks.
> > It exposes the property interface to userspace and calls out the
> > details or interfaces created and the intended purpose.
> >
> > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > +++++++++++++++++++
> > 1 file changed, 167 insertions(+)
> > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
> > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > new file mode 100644
> > index 000000000000..0d1ca858783b
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > @@ -0,0 +1,167 @@
> > +==================================================
> > +Display Color Pipeline: Proposed DRM Properties
>
> Hi,
> is there a practise of landing proposal documents in the kernel? How
> does that work, will a kernel tree carry the patch files?
> Or should this document be worded like documentation for an accepted
> feature, and then the patches either land or don't?
>
A thread is forked for this query, we will conclude there.
> > +==================================================
> > +
> > +This is how a typical display color hardware pipeline looks like:
>
> Typical, or should we say that this is the abstract color pipeline that KMS assumes?
>
> Then drivers map this to pieces of hardware the best they can and
> reject or do not expose the parts they cannot.
Yeah sure Pekka, I will reword this to be clear.
> > + +-------------------------------------------+
> > + | RAM |
> > + | +------+ +---------+ +---------+ |
> > + | | FB 1 | | FB 2 | | FB N | |
> > + | +------+ +---------+ +---------+ |
> > + +-------------------------------------------+
> > + | Plane Color Hardware Block |
> > + +--------------------------------------------+
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | DeGamma | | Degamma | | Degamma | |
> > + | +---+-----+ +---+-------+ +---+------+ |
> > + | | | | |
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | |Plane A | | Plane B | | Plane N | |
> > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + | +---v-----+ +----v------+ +----v-----+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | Gamma | | Gamma | | Gamma | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + +--------------------------------------------+
> > ++------v--------------v---------------v-------|
> > +|| ||
> > +|| Pipe Blender ||
> > ++--------------------+------------------------+
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe DeGamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | Pipe Color |
> > +| +-----------v----------+ Hardware |
> > +| | Pipe CSC/CTM | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe Gamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > ++---------------------------------------------+
> > + |
> > + v
> > + Pipe Output
> > +
> > +Proposal is to have below properties for a plane:
> > +
> > +* Plane Degamma or Pre-Curve:
> > + * This will be used to linearize the input framebuffer data.
> > + * It will apply the reverse of the color transfer function.
> > + * It can be a degamma curve or OETF for HDR.
>
> As you want to produce light-linear values, you use EOTF or inverse OETF.
>
> The term OETF has a built-in assumption that that happens in a camera:
> it takes in light and produces and electrical signal. Lately I have
> personally started talking about non-linear encoding of color values,
> since EOTF is often associated with displays if nothing else is said (taking in an electrical signal and producing light).
>
> So this would be decoding the color values into light-linear color
> values. That is what an EOTF does, yes, but I feel there is a nuanced
> difference. A piece of equipment implements an EOTF by turning an
> electrical signal into light, hence EOTF often refers to specific
> equipment. You could talk about content EOTF to denote content value
> encoding, as opposed to output or display EOTF, but that might be
> confusing if you look at e.g. the diagrams in BT.2100: is it the EOTF or is it the inverse OETF? Is the (inverse?) OOTF included?
>
> So I try to side-step those questions by talking about encoding.
The idea here is that frame buffer presented to display plane engine will be non-linear.
So output of a media decode should result in content with EOTF applied.
Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
To make it linear, we should apply the OETF. Confusion is whether OETF is equivalent to
inverse EOTF, we could check this one out to confirm.
Here since the values for the pre-curve (or degamma as we have called it in past),
accepts programmable lut values which makes it flexible enough to accommodate any values.
This will hold for HDR as well as traditional gamma encoded SRGB data as well.
> > + * This linear data can be further acted on by the following
> > + * color hardware blocks in the display hardware pipeline
>
> I think this and the above description ties the intended use down too
> much. This is one possible way to use degamma, yes, but there may be
> others. Particularly if CTM can be replaced with a 3D LUT, then the
> degamma is more likely a shaper (non-linear adjustment to 3D LUT tap positions).
Yeah agree, this is just one of the usecases. Its just a lut table which can be used for
other purposes as well and is not just limited to a linearization operation. I will update this.
> I would prefer the name pre-curve to underline that this can be
> whatever one wants it to be, but I understand that people may be more familiar with the name degamma.
I feel pre-curve should be fine but yeah it deviates from naming of legacy crtc/pipe color properties.
May be we can stay with legacy naming with more documentation to have its usecases clearly called out.
> > +
> > +UAPI Name: PLANE_DEGAMMA_MODE
> > +Description: Enum property with values as blob_id's which
> > +advertizes
> > the
>
> Is enum with blob id values even a thing?
Yeah we could have. This is a dynamic enum created with blobs. Each entry contains
the data structure to extract the full color capabilities of the hardware. It’s a very
interesting play with blobs (@ville.syrjala@linux.intel.com brainchild)
> > + possible degamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane degamma color
> > + caps and choose the appropriate degamma mode and create lut values
> > + accordingly.
>
> I agree that some sort of "mode" switch is necessary, and
> advertisement of capabilities as well.
>
This enum with blob id's is an interesting way to advertise segmented lut tables.
> > +
> > +UAPI Name: PLANE_DEGAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply degamma curve using the h/w plane degamma processing
> > + engine, thereby making the content as linear for further color
> > + processing. Userspace gets the size of LUT and precision etc
> > + from PLANE_DEGAMA_MODE_PROPERTY
>
> So all degamma modes will always be some kind of LUT? That may be a
> bit restrictive, as I understand AMD may have predefined or
> parameterised curves that are not LUTs. So there should be room for an
> arbitrary structure of parameters, which can be passed in as a blob
> id, and the contents defined by the degamma mode.
For Intel's hardware these are luts but yeah AMD hardware seems to have these
as fixed function units. We should think of a way to have this option as well in the
UAPI. We could extend the DEGAMMA_MODE property to have all the info, and
DEGAMMA_LUT_PROPERTY may not be needed based on some of the attributes
passed via DEGAMMA_MODE. This can be one way to have room for both.
@harry.wentland@amd.com thoughts ?
>
> LUT size, precision, and other details of each degamma mode would be
> good to expose somehow. I kind of expected those would have been
> exposed through the above mentioned "enum with blob id values" where
> each blob content structure is defined by the respective enum value.
Yes, you are spot on here.
> > +
> > +* Plane CTM
> > + * This is a Property to program the color transformation matrix.
>
> No mode property here? Is there any hardware with something else than
> a matrix at this point?
Not that I am aware of.
> Should we assume there will be hardware with something else, and have
> a CSC mode property with only a single enum value defined so far:
> "matrix"? Or do we say PLANE_CTM is a matrix and if you have something
> else in hardware, then invent a new property for it?
I think this should be good as we have this for crtc with no one complaining.
There may be hardware with fixed function operation for the CSC but then
its not a matrix and it would be pretty hardware dependent, so we can leave
that from a generic UAPI.
> > + * This can be used to perform a color space conversion like
> > + * BT2020 to BT709 or BT601 etc.
> > + * This block is generally kept after the degamma unit so that
>
> Not "generally". If blocks can change places, then it becomes
> intractable for generic userspace to program.
Sure, will drop this wording here. But one open will still remain for userspace,
as to how it gets the pipeline dynamically for a respective hardware.
Currently we have assumed that this would be the logical fixed order of
hardware units.
> > + * linear data can be fed to it for conversion.
> > +
> > +UAPI Name: PLANE_CTM
> > +Description: Blob property which allows a userspace to provide CTM coefficients
> > + to do color space conversion or any other enhancement by doing a
> > + matrix multiplication using the h/w CTM processing engine
> > +
>
> Speaking of color space conversions, we should probably define what
> happens to out-of-range color values. Converting color into smaller
> gamut or smaller dynamic range always has the risk of ending up with
> out-of-range values. I suppose those get simply clipped independently on each color channel, right?
We have standard matrix to convert colorspaces. This is just the property of the colorspace,
I guess clipping will be the only option here (irrespective of hardware)
> Such clipping can change hue, so userspace would be better avoid
> triggering clipping at all, but we still need to know what would happen with out-of-range values.
>
> We would also need to know when clipping will happen. If FP16
> (half-float) FB produces out-of-range values and degamma stage is not
> used, will the CTM see original or clipped values? Or is that
> something we have to define as hardware-specific?
>
> Generic userspace will try hard to avoid triggering hardware-specific
> behaviour, so you can expect such behaviour to go unused.
Here hardware should just operate on the matrix values programmed. This should
be the limitation of the color space conversion operation and hardware may not have
any role to play apart from just honoring the matrix values and producing the
resultant output.
> > +* Plane Gamma or Post-Curve
> > + * This can be used to perform 2 operations:
> > + * non-lineralize the framebuffer data. Can be used for
> > + * non linear blending. It can be a gamma curve or EOTF
> > + * for HDR.
> > + * Perform Tone Mapping operation. This is an operation
> > + * done when blending is done with HDR and SDR content.
>
> I like this wording better than the wording for pre-curve: "can", not
> "will". It leaves room for creative use of this processing block.
Ok thanks, will update pre-curve section as well.
>
> Tone-mapping is needed always when dynamic range differs, so also for
> HDR to HDR, not just SDR to/from HDR.
Yes correct, will update.
> > +
> > +UAPI Name: PLANE_GAMMA_MODE
> > +Description: Enum property with values as blob_id's which advertizes the
> > + possible gamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane gamma color
> > + caps and choose the appropriate gamma mode and create lut values
> > + accordingly.
> > +
> > +UAPI Name: PLANE_GAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply gamma curve or perform tone mapping using the h/w plane
> > + gamma processing engine, thereby making the content as linear
> > + for further color processing. Userspace gets the size of LUT and
> > + precision etc from PLANE_GAMA_MODE_PROPERTY
>
> The same comments here as with DEGAMMA.
Noted.
> > +
> > +This is part of one plane engine. Data from multiple planes will be
> > +then fed to pipe where it will get blended. There is a similar set
> > +of properties available at crtc level which acts on this blended data.
> > +
> > +Below is a sample usecase:
> > +
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐
> > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> Mapping├────────┐
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │
> > + │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │
> > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> ├─────┐ │
> > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │
> > + │ │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │ │
> > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> in├───┐ │ │
> > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │ │
>
> EOTF, not OETF, since it is converting E to O, electrical to optical.
I think media decode would have given a EOTF applied data to be directly consumed by display
sink (in case we have chosen a display pass through). Not sure here though, it’s a bit confusing.
> > +
> > + │ │ │
> > +
> > + │ │ │
> > +
> > +│ │ │
> >
> +┌──────────────────────────────────────────────────────────────────
> ──
> > +───────────┴─┴──┘
> > +│
> > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────►
> TO Port
> > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > + │ after blend │ │ Conversion │ │ transfer func │
> > + └─────────────┘ └─────────────┘ └───────────────┘
>
> Blending does not change whether the data is linear or not. I suppose
> in this example, CRTC degamma and CTM would be passthrough, and gamma
> would be the inverse display EOTF for encoding color values into what the monitor expects.
Yeah, will update this to make it clear.
> > +
> > +
> > +This patch series adds properties for plane color features. It adds
> > +properties for degamma used to linearize data and CSC used for
> > +gamut conversion. It also includes Gamma support used to again
> > +non-linearize data as per panel supported color space. These can be
> > +utilize by user space to convert planes from one format to another,
> > +one color space to another etc.
>
> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
This is great to hear that we are aligned wrt how the pipeline should work.
Thanks Pekka for taking time out and providing the feedback.
@harry.wentland@amd.com We can work together and build our design to accommodate
both Intel and AMD's hardware needs. This will also make things generic enough for any
other hardware vendor as well.
Thanks & Regards,
Uma Shankar
> > +
> > +Userspace can take smart blending decisions and utilize these
> > +hardware supported plane color features to get accurate color
> > +profile. The same can help in consistent color quality from source
> > +to panel taking advantage of advanced color features in hardware.
> > +
> > +These patches add the property interfaces and enable helper functions.
> > +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > +can build up and add other platform/hardware specific
> > +implementation on top of this series.
> > +
> > +Credits: Special mention and credits to Ville Syrjala for coming up
> > +with a design for this feature and inputs. This series is based on
> > +his original design and idea.
>
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-12 20:58 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 20:58 UTC (permalink / raw)
To: Pekka Paalanen, harry.wentland, ville.syrjala
Cc: intel-gfx, dri-devel, brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 4:01 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com;
> brian.starkey@arm.com; sebastian@sebastianwick.net;
> Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 7 Sep 2021 03:08:43 +0530
> Uma Shankar <uma.shankar@intel.com> wrote:
>
> > This is a RFC proposal for plane color hardware blocks.
> > It exposes the property interface to userspace and calls out the
> > details or interfaces created and the intended purpose.
> >
> > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > +++++++++++++++++++
> > 1 file changed, 167 insertions(+)
> > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
> > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > new file mode 100644
> > index 000000000000..0d1ca858783b
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > @@ -0,0 +1,167 @@
> > +==================================================
> > +Display Color Pipeline: Proposed DRM Properties
>
> Hi,
> is there a practise of landing proposal documents in the kernel? How
> does that work, will a kernel tree carry the patch files?
> Or should this document be worded like documentation for an accepted
> feature, and then the patches either land or don't?
>
A thread is forked for this query, we will conclude there.
> > +==================================================
> > +
> > +This is how a typical display color hardware pipeline looks like:
>
> Typical, or should we say that this is the abstract color pipeline that KMS assumes?
>
> Then drivers map this to pieces of hardware the best they can and
> reject or do not expose the parts they cannot.
Yeah sure Pekka, I will reword this to be clear.
> > + +-------------------------------------------+
> > + | RAM |
> > + | +------+ +---------+ +---------+ |
> > + | | FB 1 | | FB 2 | | FB N | |
> > + | +------+ +---------+ +---------+ |
> > + +-------------------------------------------+
> > + | Plane Color Hardware Block |
> > + +--------------------------------------------+
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | DeGamma | | Degamma | | Degamma | |
> > + | +---+-----+ +---+-------+ +---+------+ |
> > + | | | | |
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | |Plane A | | Plane B | | Plane N | |
> > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + | +---v-----+ +----v------+ +----v-----+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | Gamma | | Gamma | | Gamma | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + +--------------------------------------------+
> > ++------v--------------v---------------v-------|
> > +|| ||
> > +|| Pipe Blender ||
> > ++--------------------+------------------------+
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe DeGamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | Pipe Color |
> > +| +-----------v----------+ Hardware |
> > +| | Pipe CSC/CTM | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe Gamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > ++---------------------------------------------+
> > + |
> > + v
> > + Pipe Output
> > +
> > +Proposal is to have below properties for a plane:
> > +
> > +* Plane Degamma or Pre-Curve:
> > + * This will be used to linearize the input framebuffer data.
> > + * It will apply the reverse of the color transfer function.
> > + * It can be a degamma curve or OETF for HDR.
>
> As you want to produce light-linear values, you use EOTF or inverse OETF.
>
> The term OETF has a built-in assumption that that happens in a camera:
> it takes in light and produces and electrical signal. Lately I have
> personally started talking about non-linear encoding of color values,
> since EOTF is often associated with displays if nothing else is said (taking in an electrical signal and producing light).
>
> So this would be decoding the color values into light-linear color
> values. That is what an EOTF does, yes, but I feel there is a nuanced
> difference. A piece of equipment implements an EOTF by turning an
> electrical signal into light, hence EOTF often refers to specific
> equipment. You could talk about content EOTF to denote content value
> encoding, as opposed to output or display EOTF, but that might be
> confusing if you look at e.g. the diagrams in BT.2100: is it the EOTF or is it the inverse OETF? Is the (inverse?) OOTF included?
>
> So I try to side-step those questions by talking about encoding.
The idea here is that frame buffer presented to display plane engine will be non-linear.
So output of a media decode should result in content with EOTF applied.
Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
To make it linear, we should apply the OETF. Confusion is whether OETF is equivalent to
inverse EOTF, we could check this one out to confirm.
Here since the values for the pre-curve (or degamma as we have called it in past),
accepts programmable lut values which makes it flexible enough to accommodate any values.
This will hold for HDR as well as traditional gamma encoded SRGB data as well.
> > + * This linear data can be further acted on by the following
> > + * color hardware blocks in the display hardware pipeline
>
> I think this and the above description ties the intended use down too
> much. This is one possible way to use degamma, yes, but there may be
> others. Particularly if CTM can be replaced with a 3D LUT, then the
> degamma is more likely a shaper (non-linear adjustment to 3D LUT tap positions).
Yeah agree, this is just one of the usecases. Its just a lut table which can be used for
other purposes as well and is not just limited to a linearization operation. I will update this.
> I would prefer the name pre-curve to underline that this can be
> whatever one wants it to be, but I understand that people may be more familiar with the name degamma.
I feel pre-curve should be fine but yeah it deviates from naming of legacy crtc/pipe color properties.
May be we can stay with legacy naming with more documentation to have its usecases clearly called out.
> > +
> > +UAPI Name: PLANE_DEGAMMA_MODE
> > +Description: Enum property with values as blob_id's which
> > +advertizes
> > the
>
> Is enum with blob id values even a thing?
Yeah we could have. This is a dynamic enum created with blobs. Each entry contains
the data structure to extract the full color capabilities of the hardware. It’s a very
interesting play with blobs (@ville.syrjala@linux.intel.com brainchild)
> > + possible degamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane degamma color
> > + caps and choose the appropriate degamma mode and create lut values
> > + accordingly.
>
> I agree that some sort of "mode" switch is necessary, and
> advertisement of capabilities as well.
>
This enum with blob id's is an interesting way to advertise segmented lut tables.
> > +
> > +UAPI Name: PLANE_DEGAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply degamma curve using the h/w plane degamma processing
> > + engine, thereby making the content as linear for further color
> > + processing. Userspace gets the size of LUT and precision etc
> > + from PLANE_DEGAMA_MODE_PROPERTY
>
> So all degamma modes will always be some kind of LUT? That may be a
> bit restrictive, as I understand AMD may have predefined or
> parameterised curves that are not LUTs. So there should be room for an
> arbitrary structure of parameters, which can be passed in as a blob
> id, and the contents defined by the degamma mode.
For Intel's hardware these are luts but yeah AMD hardware seems to have these
as fixed function units. We should think of a way to have this option as well in the
UAPI. We could extend the DEGAMMA_MODE property to have all the info, and
DEGAMMA_LUT_PROPERTY may not be needed based on some of the attributes
passed via DEGAMMA_MODE. This can be one way to have room for both.
@harry.wentland@amd.com thoughts ?
>
> LUT size, precision, and other details of each degamma mode would be
> good to expose somehow. I kind of expected those would have been
> exposed through the above mentioned "enum with blob id values" where
> each blob content structure is defined by the respective enum value.
Yes, you are spot on here.
> > +
> > +* Plane CTM
> > + * This is a Property to program the color transformation matrix.
>
> No mode property here? Is there any hardware with something else than
> a matrix at this point?
Not that I am aware of.
> Should we assume there will be hardware with something else, and have
> a CSC mode property with only a single enum value defined so far:
> "matrix"? Or do we say PLANE_CTM is a matrix and if you have something
> else in hardware, then invent a new property for it?
I think this should be good as we have this for crtc with no one complaining.
There may be hardware with fixed function operation for the CSC but then
its not a matrix and it would be pretty hardware dependent, so we can leave
that from a generic UAPI.
> > + * This can be used to perform a color space conversion like
> > + * BT2020 to BT709 or BT601 etc.
> > + * This block is generally kept after the degamma unit so that
>
> Not "generally". If blocks can change places, then it becomes
> intractable for generic userspace to program.
Sure, will drop this wording here. But one open will still remain for userspace,
as to how it gets the pipeline dynamically for a respective hardware.
Currently we have assumed that this would be the logical fixed order of
hardware units.
> > + * linear data can be fed to it for conversion.
> > +
> > +UAPI Name: PLANE_CTM
> > +Description: Blob property which allows a userspace to provide CTM coefficients
> > + to do color space conversion or any other enhancement by doing a
> > + matrix multiplication using the h/w CTM processing engine
> > +
>
> Speaking of color space conversions, we should probably define what
> happens to out-of-range color values. Converting color into smaller
> gamut or smaller dynamic range always has the risk of ending up with
> out-of-range values. I suppose those get simply clipped independently on each color channel, right?
We have standard matrix to convert colorspaces. This is just the property of the colorspace,
I guess clipping will be the only option here (irrespective of hardware)
> Such clipping can change hue, so userspace would be better avoid
> triggering clipping at all, but we still need to know what would happen with out-of-range values.
>
> We would also need to know when clipping will happen. If FP16
> (half-float) FB produces out-of-range values and degamma stage is not
> used, will the CTM see original or clipped values? Or is that
> something we have to define as hardware-specific?
>
> Generic userspace will try hard to avoid triggering hardware-specific
> behaviour, so you can expect such behaviour to go unused.
Here hardware should just operate on the matrix values programmed. This should
be the limitation of the color space conversion operation and hardware may not have
any role to play apart from just honoring the matrix values and producing the
resultant output.
> > +* Plane Gamma or Post-Curve
> > + * This can be used to perform 2 operations:
> > + * non-lineralize the framebuffer data. Can be used for
> > + * non linear blending. It can be a gamma curve or EOTF
> > + * for HDR.
> > + * Perform Tone Mapping operation. This is an operation
> > + * done when blending is done with HDR and SDR content.
>
> I like this wording better than the wording for pre-curve: "can", not
> "will". It leaves room for creative use of this processing block.
Ok thanks, will update pre-curve section as well.
>
> Tone-mapping is needed always when dynamic range differs, so also for
> HDR to HDR, not just SDR to/from HDR.
Yes correct, will update.
> > +
> > +UAPI Name: PLANE_GAMMA_MODE
> > +Description: Enum property with values as blob_id's which advertizes the
> > + possible gamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane gamma color
> > + caps and choose the appropriate gamma mode and create lut values
> > + accordingly.
> > +
> > +UAPI Name: PLANE_GAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply gamma curve or perform tone mapping using the h/w plane
> > + gamma processing engine, thereby making the content as linear
> > + for further color processing. Userspace gets the size of LUT and
> > + precision etc from PLANE_GAMA_MODE_PROPERTY
>
> The same comments here as with DEGAMMA.
Noted.
> > +
> > +This is part of one plane engine. Data from multiple planes will be
> > +then fed to pipe where it will get blended. There is a similar set
> > +of properties available at crtc level which acts on this blended data.
> > +
> > +Below is a sample usecase:
> > +
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐
> > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> Mapping├────────┐
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │
> > + │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │
> > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> ├─────┐ │
> > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │
> > + │ │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │ │
> > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> in├───┐ │ │
> > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │ │
>
> EOTF, not OETF, since it is converting E to O, electrical to optical.
I think media decode would have given a EOTF applied data to be directly consumed by display
sink (in case we have chosen a display pass through). Not sure here though, it’s a bit confusing.
> > +
> > + │ │ │
> > +
> > + │ │ │
> > +
> > +│ │ │
> >
> +┌──────────────────────────────────────────────────────────────────
> ──
> > +───────────┴─┴──┘
> > +│
> > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────►
> TO Port
> > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > + │ after blend │ │ Conversion │ │ transfer func │
> > + └─────────────┘ └─────────────┘ └───────────────┘
>
> Blending does not change whether the data is linear or not. I suppose
> in this example, CRTC degamma and CTM would be passthrough, and gamma
> would be the inverse display EOTF for encoding color values into what the monitor expects.
Yeah, will update this to make it clear.
> > +
> > +
> > +This patch series adds properties for plane color features. It adds
> > +properties for degamma used to linearize data and CSC used for
> > +gamut conversion. It also includes Gamma support used to again
> > +non-linearize data as per panel supported color space. These can be
> > +utilize by user space to convert planes from one format to another,
> > +one color space to another etc.
>
> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
This is great to hear that we are aligned wrt how the pipeline should work.
Thanks Pekka for taking time out and providing the feedback.
@harry.wentland@amd.com We can work together and build our design to accommodate
both Intel and AMD's hardware needs. This will also make things generic enough for any
other hardware vendor as well.
Thanks & Regards,
Uma Shankar
> > +
> > +Userspace can take smart blending decisions and utilize these
> > +hardware supported plane color features to get accurate color
> > +profile. The same can help in consistent color quality from source
> > +to panel taking advantage of advanced color features in hardware.
> > +
> > +These patches add the property interfaces and enable helper functions.
> > +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > +can build up and add other platform/hardware specific
> > +implementation on top of this series.
> > +
> > +Credits: Special mention and credits to Ville Syrjala for coming up
> > +with a design for this feature and inputs. This series is based on
> > +his original design and idea.
>
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 20:58 ` [Intel-gfx] " Shankar, Uma
@ 2021-10-13 8:30 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-13 8:30 UTC (permalink / raw)
To: Shankar, Uma
Cc: harry.wentland, ville.syrjala, intel-gfx, dri-devel,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 23476 bytes --]
On Tue, 12 Oct 2021 20:58:27 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Pekka Paalanen <ppaalanen@gmail.com>
> > Sent: Tuesday, October 12, 2021 4:01 PM
> > To: Shankar, Uma <uma.shankar@intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > harry.wentland@amd.com; ville.syrjala@linux.intel.com;
> > brian.starkey@arm.com; sebastian@sebastianwick.net;
> > Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> > On Tue, 7 Sep 2021 03:08:43 +0530
> > Uma Shankar <uma.shankar@intel.com> wrote:
> >
> > > This is a RFC proposal for plane color hardware blocks.
> > > It exposes the property interface to userspace and calls out the
> > > details or interfaces created and the intended purpose.
> > >
> > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > ---
> > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > +++++++++++++++++++
> > > 1 file changed, 167 insertions(+)
> > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> > >
> > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > new file mode 100644
> > > index 000000000000..0d1ca858783b
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > @@ -0,0 +1,167 @@
> > > +==================================================
> > > +Display Color Pipeline: Proposed DRM Properties
...
> > > +Proposal is to have below properties for a plane:
> > > +
> > > +* Plane Degamma or Pre-Curve:
> > > + * This will be used to linearize the input framebuffer data.
> > > + * It will apply the reverse of the color transfer function.
> > > + * It can be a degamma curve or OETF for HDR.
> >
> > As you want to produce light-linear values, you use EOTF or inverse OETF.
> >
> > The term OETF has a built-in assumption that that happens in a camera:
> > it takes in light and produces and electrical signal. Lately I have
> > personally started talking about non-linear encoding of color values,
> > since EOTF is often associated with displays if nothing else is said (taking in an electrical signal and producing light).
> >
> > So this would be decoding the color values into light-linear color
> > values. That is what an EOTF does, yes, but I feel there is a nuanced
> > difference. A piece of equipment implements an EOTF by turning an
> > electrical signal into light, hence EOTF often refers to specific
> > equipment. You could talk about content EOTF to denote content value
> > encoding, as opposed to output or display EOTF, but that might be
> > confusing if you look at e.g. the diagrams in BT.2100: is it the EOTF or is it the inverse OETF? Is the (inverse?) OOTF included?
> >
> > So I try to side-step those questions by talking about encoding.
>
> The idea here is that frame buffer presented to display plane engine will be non-linear.
> So output of a media decode should result in content with EOTF applied.
Hi,
sure, but the question is: which EOTF. There can be many different
things called "EOTF" in a single pipeline, and then it's up to the
document writer to make the difference between them. Comparing two
documents with different conventions causes a lot of confusion in my
personal experience, so it is good to define the concepts more
carefully.
> So output of a media decode should result in content with EOTF applied.
I suspect you have it backwards. Media decode produces electrical
(non-linear) pixel color values. If EOTF was applied, they would be
linear instead (and require more memory to achieve the same visual
precision).
If you want to put it this way, you could say "with inverse EOTF
applied", but that might be slightly confusing because it is already
baked in to the video, it's not something a media decoder has to
specifically apply, I think. However, the (inverse) EOTF in this case
is the content EOTF, not the display EOTF.
If content and display EOTF differ, then one must apply first content
EOTF and then inverse display EOTF to get values that are correctly
encoded for the display. (This is necessary but not sufficient in
general.) Mind, that this is not an OOTF nor an artistic adjustment,
this is purely a value encoding conversion.
> Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
Does "rendering intent gamma" refer to artistic adjustments, not OOTF?
cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
the OOTF", although I find those diagrams somewhat confusing still. It
does not seem to clearly account for transmission non-linear encoding
being different from the display EOTF.
Different documents use OOTF to refer to different things. Then there
is also the fundamental difference between PQ and HLG systems, where
OOTF is by definition in different places of the
camera-transmission-display pipeline.
>
> To make it linear, we should apply the OETF. Confusion is whether OETF is equivalent to
> inverse EOTF, we could check this one out to confirm.
OETF does not make anything linear. By definition, OETF converts
optical (linear) values into electrical (practically always
non-linearly encoded) values.
Yes, EOTF is almost always not equal to inverse OETF because of the
existence of OOTF. The applies to inverse EOTF vs. OETF as well.
From what I have learned, it is unexpected to assume that inverse of
one is the other. That will cause confusion. Therefore, if you mean the
inverse, spell it out as inverse. I used to make this same mistake, and
some of it may still be left in
https://gitlab.freedesktop.org/pq/color-and-hdr .
>
> Here since the values for the pre-curve (or degamma as we have called it in past),
> accepts programmable lut values which makes it flexible enough to accommodate any values.
> This will hold for HDR as well as traditional gamma encoded SRGB data as well.
Yes.
> > > + * This linear data can be further acted on by the following
> > > + * color hardware blocks in the display hardware pipeline
> >
> > I think this and the above description ties the intended use down too
> > much. This is one possible way to use degamma, yes, but there may be
> > others. Particularly if CTM can be replaced with a 3D LUT, then the
> > degamma is more likely a shaper (non-linear adjustment to 3D LUT tap positions).
>
> Yeah agree, this is just one of the usecases. Its just a lut table which can be used for
> other purposes as well and is not just limited to a linearization operation. I will update this.
>
> > I would prefer the name pre-curve to underline that this can be
> > whatever one wants it to be, but I understand that people may be more familiar with the name degamma.
>
> I feel pre-curve should be fine but yeah it deviates from naming of legacy crtc/pipe color properties.
> May be we can stay with legacy naming with more documentation to have its usecases clearly called out.
That is fine by me.
> > > +
> > > +UAPI Name: PLANE_DEGAMMA_MODE
> > > +Description: Enum property with values as blob_id's which
> > > +advertizes
> > > the
> >
> > Is enum with blob id values even a thing?
>
> Yeah we could have. This is a dynamic enum created with blobs. Each entry contains
> the data structure to extract the full color capabilities of the hardware. It’s a very
> interesting play with blobs (@ville.syrjala@linux.intel.com brainchild)
Yes, I think I can imagine how that works. The blobs are created
immutable, unable to change once the plane has been advertised to
userspace, because their IDs are used as enum values. But that is ok,
because the blob describes capabilities that cannot change during the
device's lifetime... or can they? What if you would want to extend the
blob format, do you need a KMS client cap to change the format which
would be impossible because you can't change an enum definition after
it has been installed so you cannot swap the blob to a new one?
This also relies on enums being identified by their string names,
because the numerical value is not a constant but a blob ID and gets
determined when the immutable blob is created.
Did I understand correctly?
As a userspace developer, I can totally work with that.
> > > + possible degamma modes and lut ranges supported by the platform.
> > > + This allows userspace to query and get the plane degamma color
> > > + caps and choose the appropriate degamma mode and create lut values
> > > + accordingly.
> >
> > I agree that some sort of "mode" switch is necessary, and
> > advertisement of capabilities as well.
> >
>
> This enum with blob id's is an interesting way to advertise segmented lut tables.
>
> > > +
> > > +UAPI Name: PLANE_DEGAMMA_LUT
> > > +Description: Blob property which allows a userspace to provide LUT values
> > > + to apply degamma curve using the h/w plane degamma processing
> > > + engine, thereby making the content as linear for further color
> > > + processing. Userspace gets the size of LUT and precision etc
> > > + from PLANE_DEGAMA_MODE_PROPERTY
> >
> > So all degamma modes will always be some kind of LUT? That may be a
> > bit restrictive, as I understand AMD may have predefined or
> > parameterised curves that are not LUTs. So there should be room for an
> > arbitrary structure of parameters, which can be passed in as a blob
> > id, and the contents defined by the degamma mode.
>
> For Intel's hardware these are luts but yeah AMD hardware seems to have these
> as fixed function units. We should think of a way to have this option as well in the
> UAPI. We could extend the DEGAMMA_MODE property to have all the info, and
> DEGAMMA_LUT_PROPERTY may not be needed based on some of the attributes
> passed via DEGAMMA_MODE. This can be one way to have room for both.
> @harry.wentland@amd.com thoughts ?
Yeah, though I don't think you can use DEGAMMA_MODE property to pass
parameters to fixed-function curves. The parameters need another
property. Would be natural to use the other property for LUT data when
mode it set to LUT.
A trivial and made-up example of a parameterised fixed-function curve
is pow(x, gamma), where gamma is the parameter.
> >
> > LUT size, precision, and other details of each degamma mode would be
> > good to expose somehow. I kind of expected those would have been
> > exposed through the above mentioned "enum with blob id values" where
> > each blob content structure is defined by the respective enum value.
>
> Yes, you are spot on here.
>
> > > +
> > > +* Plane CTM
> > > + * This is a Property to program the color transformation matrix.
> >
> > No mode property here? Is there any hardware with something else than
> > a matrix at this point?
>
> Not that I am aware of.
>
> > Should we assume there will be hardware with something else, and have
> > a CSC mode property with only a single enum value defined so far:
> > "matrix"? Or do we say PLANE_CTM is a matrix and if you have something
> > else in hardware, then invent a new property for it?
>
> I think this should be good as we have this for crtc with no one complaining.
> There may be hardware with fixed function operation for the CSC but then
> its not a matrix and it would be pretty hardware dependent, so we can leave
> that from a generic UAPI.
Ok. And if that eventually turns out to be a mistake, it's easy to
invent more properties.
> > > + * This can be used to perform a color space conversion like
> > > + * BT2020 to BT709 or BT601 etc.
> > > + * This block is generally kept after the degamma unit so that
> >
> > Not "generally". If blocks can change places, then it becomes
> > intractable for generic userspace to program.
>
> Sure, will drop this wording here. But one open will still remain for userspace,
> as to how it gets the pipeline dynamically for a respective hardware.
> Currently we have assumed that this would be the logical fixed order of
> hardware units.
If we cannot model the abstract KMS pipeline as a fixed order of units
(where each unit may exist or not), we need to take a few steps back
here and look at what do we actually want to expose. That is a much
bigger design problem which we are currently not even considering.
> > > + * linear data can be fed to it for conversion.
> > > +
> > > +UAPI Name: PLANE_CTM
> > > +Description: Blob property which allows a userspace to provide CTM coefficients
> > > + to do color space conversion or any other enhancement by doing a
> > > + matrix multiplication using the h/w CTM processing engine
> > > +
> >
> > Speaking of color space conversions, we should probably define what
> > happens to out-of-range color values. Converting color into smaller
> > gamut or smaller dynamic range always has the risk of ending up with
> > out-of-range values. I suppose those get simply clipped independently on each color channel, right?
>
> We have standard matrix to convert colorspaces. This is just the property of the colorspace,
> I guess clipping will be the only option here (irrespective of hardware)
>
> > Such clipping can change hue, so userspace would be better avoid
> > triggering clipping at all, but we still need to know what would happen with out-of-range values.
> >
> > We would also need to know when clipping will happen. If FP16
> > (half-float) FB produces out-of-range values and degamma stage is not
> > used, will the CTM see original or clipped values? Or is that
> > something we have to define as hardware-specific?
> >
> > Generic userspace will try hard to avoid triggering hardware-specific
> > behaviour, so you can expect such behaviour to go unused.
>
> Here hardware should just operate on the matrix values programmed. This should
> be the limitation of the color space conversion operation and hardware may not have
> any role to play apart from just honoring the matrix values and producing the
> resultant output.
I'm not talking about the matrix values. I'm talking about the values
originating from the FB, are they clipped or not, before being processed
by the matrix?
Userspace could want to use the matrix to bring out-of-range FB values
into range, but that plan cannot work if the FB values get clipped
already before the matrix.
I referred to FP16 format explicitly because that format can express
values outside of the usual [0.0, 1.0] range in a framebuffer.
Of course, the matrix values themselves have some limits too, and
userspace should somehow be aware of them.
>
> > > +* Plane Gamma or Post-Curve
> > > + * This can be used to perform 2 operations:
> > > + * non-lineralize the framebuffer data. Can be used for
> > > + * non linear blending. It can be a gamma curve or EOTF
> > > + * for HDR.
> > > + * Perform Tone Mapping operation. This is an operation
> > > + * done when blending is done with HDR and SDR content.
> >
> > I like this wording better than the wording for pre-curve: "can", not
> > "will". It leaves room for creative use of this processing block.
>
> Ok thanks, will update pre-curve section as well.
>
> >
> > Tone-mapping is needed always when dynamic range differs, so also for
> > HDR to HDR, not just SDR to/from HDR.
>
> Yes correct, will update.
>
> > > +
> > > +UAPI Name: PLANE_GAMMA_MODE
> > > +Description: Enum property with values as blob_id's which advertizes the
> > > + possible gamma modes and lut ranges supported by the platform.
> > > + This allows userspace to query and get the plane gamma color
> > > + caps and choose the appropriate gamma mode and create lut values
> > > + accordingly.
> > > +
> > > +UAPI Name: PLANE_GAMMA_LUT
> > > +Description: Blob property which allows a userspace to provide LUT values
> > > + to apply gamma curve or perform tone mapping using the h/w plane
> > > + gamma processing engine, thereby making the content as linear
> > > + for further color processing. Userspace gets the size of LUT and
> > > + precision etc from PLANE_GAMA_MODE_PROPERTY
> >
> > The same comments here as with DEGAMMA.
>
> Noted.
>
> > > +
> > > +This is part of one plane engine. Data from multiple planes will be
> > > +then fed to pipe where it will get blended. There is a similar set
> > > +of properties available at crtc level which acts on this blended data.
> > > +
> > > +Below is a sample usecase:
> > > +
> > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > ┌─────────────┐
> > > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> > > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> > Mapping├────────┐
> > > + └────────────┘ └─────────────┘ └─────────────┘
> > └─────────────┘ │
> > > + │
> > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > ┌─────────────┐ │
> > > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> > > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> > ├─────┐ │
> > > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> > > + └────────────┘ └─────────────┘ └─────────────┘
> > └─────────────┘ │ │
> > > + │ │
> > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > ┌─────────────┐ │ │
> > > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> > > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> > in├───┐ │ │
> > > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > > + └────────────┘ └─────────────┘ └─────────────┘
> > └─────────────┘ │ │ │
> >
> > EOTF, not OETF, since it is converting E to O, electrical to optical.
>
> I think media decode would have given a EOTF applied data to be directly consumed by display
> sink (in case we have chosen a display pass through). Not sure here though, it’s a bit confusing.
I hope I managed to explain this earlier in this email.
Display sinks "always" use non-linearly encoded values, because it
saves bandwidth without losing visual quality. For the same reason,
images tend to be stored with non-linear value encoding whenever
possible.
Thanks,
pq
> > > +
> > > + │ │ │
> > > +
> > > + │ │ │
> > > +
> > > +│ │ │
> > >
> > +┌──────────────────────────────────────────────────────────────────
> > ──
> > > +───────────┴─┴──┘
> > > +│
> > > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────►
> > TO Port
> > > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > > + │ after blend │ │ Conversion │ │ transfer func │
> > > + └─────────────┘ └─────────────┘ └───────────────┘
> >
> > Blending does not change whether the data is linear or not. I suppose
> > in this example, CRTC degamma and CTM would be passthrough, and gamma
> > would be the inverse display EOTF for encoding color values into what the monitor expects.
>
> Yeah, will update this to make it clear.
>
> > > +
> > > +
> > > +This patch series adds properties for plane color features. It adds
> > > +properties for degamma used to linearize data and CSC used for
> > > +gamut conversion. It also includes Gamma support used to again
> > > +non-linearize data as per panel supported color space. These can be
> > > +utilize by user space to convert planes from one format to another,
> > > +one color space to another etc.
> >
> > FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
>
> This is great to hear that we are aligned wrt how the pipeline should work.
>
> Thanks Pekka for taking time out and providing the feedback.
>
> @harry.wentland@amd.com We can work together and build our design to accommodate
> both Intel and AMD's hardware needs. This will also make things generic enough for any
> other hardware vendor as well.
>
> Thanks & Regards,
> Uma Shankar
>
> > > +
> > > +Userspace can take smart blending decisions and utilize these
> > > +hardware supported plane color features to get accurate color
> > > +profile. The same can help in consistent color quality from source
> > > +to panel taking advantage of advanced color features in hardware.
> > > +
> > > +These patches add the property interfaces and enable helper functions.
> > > +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > > +can build up and add other platform/hardware specific
> > > +implementation on top of this series.
> > > +
> > > +Credits: Special mention and credits to Ville Syrjala for coming up
> > > +with a design for this feature and inputs. This series is based on
> > > +his original design and idea.
> >
> >
> > Thanks,
> > pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-13 8:30 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-13 8:30 UTC (permalink / raw)
To: Shankar, Uma
Cc: harry.wentland, ville.syrjala, intel-gfx, dri-devel,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 23476 bytes --]
On Tue, 12 Oct 2021 20:58:27 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Pekka Paalanen <ppaalanen@gmail.com>
> > Sent: Tuesday, October 12, 2021 4:01 PM
> > To: Shankar, Uma <uma.shankar@intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > harry.wentland@amd.com; ville.syrjala@linux.intel.com;
> > brian.starkey@arm.com; sebastian@sebastianwick.net;
> > Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> > On Tue, 7 Sep 2021 03:08:43 +0530
> > Uma Shankar <uma.shankar@intel.com> wrote:
> >
> > > This is a RFC proposal for plane color hardware blocks.
> > > It exposes the property interface to userspace and calls out the
> > > details or interfaces created and the intended purpose.
> > >
> > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > ---
> > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > +++++++++++++++++++
> > > 1 file changed, 167 insertions(+)
> > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> > >
> > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > new file mode 100644
> > > index 000000000000..0d1ca858783b
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > @@ -0,0 +1,167 @@
> > > +==================================================
> > > +Display Color Pipeline: Proposed DRM Properties
...
> > > +Proposal is to have below properties for a plane:
> > > +
> > > +* Plane Degamma or Pre-Curve:
> > > + * This will be used to linearize the input framebuffer data.
> > > + * It will apply the reverse of the color transfer function.
> > > + * It can be a degamma curve or OETF for HDR.
> >
> > As you want to produce light-linear values, you use EOTF or inverse OETF.
> >
> > The term OETF has a built-in assumption that that happens in a camera:
> > it takes in light and produces and electrical signal. Lately I have
> > personally started talking about non-linear encoding of color values,
> > since EOTF is often associated with displays if nothing else is said (taking in an electrical signal and producing light).
> >
> > So this would be decoding the color values into light-linear color
> > values. That is what an EOTF does, yes, but I feel there is a nuanced
> > difference. A piece of equipment implements an EOTF by turning an
> > electrical signal into light, hence EOTF often refers to specific
> > equipment. You could talk about content EOTF to denote content value
> > encoding, as opposed to output or display EOTF, but that might be
> > confusing if you look at e.g. the diagrams in BT.2100: is it the EOTF or is it the inverse OETF? Is the (inverse?) OOTF included?
> >
> > So I try to side-step those questions by talking about encoding.
>
> The idea here is that frame buffer presented to display plane engine will be non-linear.
> So output of a media decode should result in content with EOTF applied.
Hi,
sure, but the question is: which EOTF. There can be many different
things called "EOTF" in a single pipeline, and then it's up to the
document writer to make the difference between them. Comparing two
documents with different conventions causes a lot of confusion in my
personal experience, so it is good to define the concepts more
carefully.
> So output of a media decode should result in content with EOTF applied.
I suspect you have it backwards. Media decode produces electrical
(non-linear) pixel color values. If EOTF was applied, they would be
linear instead (and require more memory to achieve the same visual
precision).
If you want to put it this way, you could say "with inverse EOTF
applied", but that might be slightly confusing because it is already
baked in to the video, it's not something a media decoder has to
specifically apply, I think. However, the (inverse) EOTF in this case
is the content EOTF, not the display EOTF.
If content and display EOTF differ, then one must apply first content
EOTF and then inverse display EOTF to get values that are correctly
encoded for the display. (This is necessary but not sufficient in
general.) Mind, that this is not an OOTF nor an artistic adjustment,
this is purely a value encoding conversion.
> Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
Does "rendering intent gamma" refer to artistic adjustments, not OOTF?
cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
the OOTF", although I find those diagrams somewhat confusing still. It
does not seem to clearly account for transmission non-linear encoding
being different from the display EOTF.
Different documents use OOTF to refer to different things. Then there
is also the fundamental difference between PQ and HLG systems, where
OOTF is by definition in different places of the
camera-transmission-display pipeline.
>
> To make it linear, we should apply the OETF. Confusion is whether OETF is equivalent to
> inverse EOTF, we could check this one out to confirm.
OETF does not make anything linear. By definition, OETF converts
optical (linear) values into electrical (practically always
non-linearly encoded) values.
Yes, EOTF is almost always not equal to inverse OETF because of the
existence of OOTF. The applies to inverse EOTF vs. OETF as well.
From what I have learned, it is unexpected to assume that inverse of
one is the other. That will cause confusion. Therefore, if you mean the
inverse, spell it out as inverse. I used to make this same mistake, and
some of it may still be left in
https://gitlab.freedesktop.org/pq/color-and-hdr .
>
> Here since the values for the pre-curve (or degamma as we have called it in past),
> accepts programmable lut values which makes it flexible enough to accommodate any values.
> This will hold for HDR as well as traditional gamma encoded SRGB data as well.
Yes.
> > > + * This linear data can be further acted on by the following
> > > + * color hardware blocks in the display hardware pipeline
> >
> > I think this and the above description ties the intended use down too
> > much. This is one possible way to use degamma, yes, but there may be
> > others. Particularly if CTM can be replaced with a 3D LUT, then the
> > degamma is more likely a shaper (non-linear adjustment to 3D LUT tap positions).
>
> Yeah agree, this is just one of the usecases. Its just a lut table which can be used for
> other purposes as well and is not just limited to a linearization operation. I will update this.
>
> > I would prefer the name pre-curve to underline that this can be
> > whatever one wants it to be, but I understand that people may be more familiar with the name degamma.
>
> I feel pre-curve should be fine but yeah it deviates from naming of legacy crtc/pipe color properties.
> May be we can stay with legacy naming with more documentation to have its usecases clearly called out.
That is fine by me.
> > > +
> > > +UAPI Name: PLANE_DEGAMMA_MODE
> > > +Description: Enum property with values as blob_id's which
> > > +advertizes
> > > the
> >
> > Is enum with blob id values even a thing?
>
> Yeah we could have. This is a dynamic enum created with blobs. Each entry contains
> the data structure to extract the full color capabilities of the hardware. It’s a very
> interesting play with blobs (@ville.syrjala@linux.intel.com brainchild)
Yes, I think I can imagine how that works. The blobs are created
immutable, unable to change once the plane has been advertised to
userspace, because their IDs are used as enum values. But that is ok,
because the blob describes capabilities that cannot change during the
device's lifetime... or can they? What if you would want to extend the
blob format, do you need a KMS client cap to change the format which
would be impossible because you can't change an enum definition after
it has been installed so you cannot swap the blob to a new one?
This also relies on enums being identified by their string names,
because the numerical value is not a constant but a blob ID and gets
determined when the immutable blob is created.
Did I understand correctly?
As a userspace developer, I can totally work with that.
> > > + possible degamma modes and lut ranges supported by the platform.
> > > + This allows userspace to query and get the plane degamma color
> > > + caps and choose the appropriate degamma mode and create lut values
> > > + accordingly.
> >
> > I agree that some sort of "mode" switch is necessary, and
> > advertisement of capabilities as well.
> >
>
> This enum with blob id's is an interesting way to advertise segmented lut tables.
>
> > > +
> > > +UAPI Name: PLANE_DEGAMMA_LUT
> > > +Description: Blob property which allows a userspace to provide LUT values
> > > + to apply degamma curve using the h/w plane degamma processing
> > > + engine, thereby making the content as linear for further color
> > > + processing. Userspace gets the size of LUT and precision etc
> > > + from PLANE_DEGAMA_MODE_PROPERTY
> >
> > So all degamma modes will always be some kind of LUT? That may be a
> > bit restrictive, as I understand AMD may have predefined or
> > parameterised curves that are not LUTs. So there should be room for an
> > arbitrary structure of parameters, which can be passed in as a blob
> > id, and the contents defined by the degamma mode.
>
> For Intel's hardware these are luts but yeah AMD hardware seems to have these
> as fixed function units. We should think of a way to have this option as well in the
> UAPI. We could extend the DEGAMMA_MODE property to have all the info, and
> DEGAMMA_LUT_PROPERTY may not be needed based on some of the attributes
> passed via DEGAMMA_MODE. This can be one way to have room for both.
> @harry.wentland@amd.com thoughts ?
Yeah, though I don't think you can use DEGAMMA_MODE property to pass
parameters to fixed-function curves. The parameters need another
property. Would be natural to use the other property for LUT data when
mode it set to LUT.
A trivial and made-up example of a parameterised fixed-function curve
is pow(x, gamma), where gamma is the parameter.
> >
> > LUT size, precision, and other details of each degamma mode would be
> > good to expose somehow. I kind of expected those would have been
> > exposed through the above mentioned "enum with blob id values" where
> > each blob content structure is defined by the respective enum value.
>
> Yes, you are spot on here.
>
> > > +
> > > +* Plane CTM
> > > + * This is a Property to program the color transformation matrix.
> >
> > No mode property here? Is there any hardware with something else than
> > a matrix at this point?
>
> Not that I am aware of.
>
> > Should we assume there will be hardware with something else, and have
> > a CSC mode property with only a single enum value defined so far:
> > "matrix"? Or do we say PLANE_CTM is a matrix and if you have something
> > else in hardware, then invent a new property for it?
>
> I think this should be good as we have this for crtc with no one complaining.
> There may be hardware with fixed function operation for the CSC but then
> its not a matrix and it would be pretty hardware dependent, so we can leave
> that from a generic UAPI.
Ok. And if that eventually turns out to be a mistake, it's easy to
invent more properties.
> > > + * This can be used to perform a color space conversion like
> > > + * BT2020 to BT709 or BT601 etc.
> > > + * This block is generally kept after the degamma unit so that
> >
> > Not "generally". If blocks can change places, then it becomes
> > intractable for generic userspace to program.
>
> Sure, will drop this wording here. But one open will still remain for userspace,
> as to how it gets the pipeline dynamically for a respective hardware.
> Currently we have assumed that this would be the logical fixed order of
> hardware units.
If we cannot model the abstract KMS pipeline as a fixed order of units
(where each unit may exist or not), we need to take a few steps back
here and look at what do we actually want to expose. That is a much
bigger design problem which we are currently not even considering.
> > > + * linear data can be fed to it for conversion.
> > > +
> > > +UAPI Name: PLANE_CTM
> > > +Description: Blob property which allows a userspace to provide CTM coefficients
> > > + to do color space conversion or any other enhancement by doing a
> > > + matrix multiplication using the h/w CTM processing engine
> > > +
> >
> > Speaking of color space conversions, we should probably define what
> > happens to out-of-range color values. Converting color into smaller
> > gamut or smaller dynamic range always has the risk of ending up with
> > out-of-range values. I suppose those get simply clipped independently on each color channel, right?
>
> We have standard matrix to convert colorspaces. This is just the property of the colorspace,
> I guess clipping will be the only option here (irrespective of hardware)
>
> > Such clipping can change hue, so userspace would be better avoid
> > triggering clipping at all, but we still need to know what would happen with out-of-range values.
> >
> > We would also need to know when clipping will happen. If FP16
> > (half-float) FB produces out-of-range values and degamma stage is not
> > used, will the CTM see original or clipped values? Or is that
> > something we have to define as hardware-specific?
> >
> > Generic userspace will try hard to avoid triggering hardware-specific
> > behaviour, so you can expect such behaviour to go unused.
>
> Here hardware should just operate on the matrix values programmed. This should
> be the limitation of the color space conversion operation and hardware may not have
> any role to play apart from just honoring the matrix values and producing the
> resultant output.
I'm not talking about the matrix values. I'm talking about the values
originating from the FB, are they clipped or not, before being processed
by the matrix?
Userspace could want to use the matrix to bring out-of-range FB values
into range, but that plan cannot work if the FB values get clipped
already before the matrix.
I referred to FP16 format explicitly because that format can express
values outside of the usual [0.0, 1.0] range in a framebuffer.
Of course, the matrix values themselves have some limits too, and
userspace should somehow be aware of them.
>
> > > +* Plane Gamma or Post-Curve
> > > + * This can be used to perform 2 operations:
> > > + * non-lineralize the framebuffer data. Can be used for
> > > + * non linear blending. It can be a gamma curve or EOTF
> > > + * for HDR.
> > > + * Perform Tone Mapping operation. This is an operation
> > > + * done when blending is done with HDR and SDR content.
> >
> > I like this wording better than the wording for pre-curve: "can", not
> > "will". It leaves room for creative use of this processing block.
>
> Ok thanks, will update pre-curve section as well.
>
> >
> > Tone-mapping is needed always when dynamic range differs, so also for
> > HDR to HDR, not just SDR to/from HDR.
>
> Yes correct, will update.
>
> > > +
> > > +UAPI Name: PLANE_GAMMA_MODE
> > > +Description: Enum property with values as blob_id's which advertizes the
> > > + possible gamma modes and lut ranges supported by the platform.
> > > + This allows userspace to query and get the plane gamma color
> > > + caps and choose the appropriate gamma mode and create lut values
> > > + accordingly.
> > > +
> > > +UAPI Name: PLANE_GAMMA_LUT
> > > +Description: Blob property which allows a userspace to provide LUT values
> > > + to apply gamma curve or perform tone mapping using the h/w plane
> > > + gamma processing engine, thereby making the content as linear
> > > + for further color processing. Userspace gets the size of LUT and
> > > + precision etc from PLANE_GAMA_MODE_PROPERTY
> >
> > The same comments here as with DEGAMMA.
>
> Noted.
>
> > > +
> > > +This is part of one plane engine. Data from multiple planes will be
> > > +then fed to pipe where it will get blended. There is a similar set
> > > +of properties available at crtc level which acts on this blended data.
> > > +
> > > +Below is a sample usecase:
> > > +
> > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > ┌─────────────┐
> > > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> > > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> > Mapping├────────┐
> > > + └────────────┘ └─────────────┘ └─────────────┘
> > └─────────────┘ │
> > > + │
> > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > ┌─────────────┐ │
> > > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> > > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> > ├─────┐ │
> > > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> > > + └────────────┘ └─────────────┘ └─────────────┘
> > └─────────────┘ │ │
> > > + │ │
> > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > ┌─────────────┐ │ │
> > > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> > > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> > in├───┐ │ │
> > > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > > + └────────────┘ └─────────────┘ └─────────────┘
> > └─────────────┘ │ │ │
> >
> > EOTF, not OETF, since it is converting E to O, electrical to optical.
>
> I think media decode would have given a EOTF applied data to be directly consumed by display
> sink (in case we have chosen a display pass through). Not sure here though, it’s a bit confusing.
I hope I managed to explain this earlier in this email.
Display sinks "always" use non-linearly encoded values, because it
saves bandwidth without losing visual quality. For the same reason,
images tend to be stored with non-linear value encoding whenever
possible.
Thanks,
pq
> > > +
> > > + │ │ │
> > > +
> > > + │ │ │
> > > +
> > > +│ │ │
> > >
> > +┌──────────────────────────────────────────────────────────────────
> > ──
> > > +───────────┴─┴──┘
> > > +│
> > > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────►
> > TO Port
> > > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > > + │ after blend │ │ Conversion │ │ transfer func │
> > > + └─────────────┘ └─────────────┘ └───────────────┘
> >
> > Blending does not change whether the data is linear or not. I suppose
> > in this example, CRTC degamma and CTM would be passthrough, and gamma
> > would be the inverse display EOTF for encoding color values into what the monitor expects.
>
> Yeah, will update this to make it clear.
>
> > > +
> > > +
> > > +This patch series adds properties for plane color features. It adds
> > > +properties for degamma used to linearize data and CSC used for
> > > +gamut conversion. It also includes Gamma support used to again
> > > +non-linearize data as per panel supported color space. These can be
> > > +utilize by user space to convert planes from one format to another,
> > > +one color space to another etc.
> >
> > FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
>
> This is great to hear that we are aligned wrt how the pipeline should work.
>
> Thanks Pekka for taking time out and providing the feedback.
>
> @harry.wentland@amd.com We can work together and build our design to accommodate
> both Intel and AMD's hardware needs. This will also make things generic enough for any
> other hardware vendor as well.
>
> Thanks & Regards,
> Uma Shankar
>
> > > +
> > > +Userspace can take smart blending decisions and utilize these
> > > +hardware supported plane color features to get accurate color
> > > +profile. The same can help in consistent color quality from source
> > > +to panel taking advantage of advanced color features in hardware.
> > > +
> > > +These patches add the property interfaces and enable helper functions.
> > > +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > > +can build up and add other platform/hardware specific
> > > +implementation on top of this series.
> > > +
> > > +Credits: Special mention and credits to Ville Syrjala for coming up
> > > +with a design for this feature and inputs. This series is based on
> > > +his original design and idea.
> >
> >
> > Thanks,
> > pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-13 8:30 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-14 19:44 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-14 19:44 UTC (permalink / raw)
To: Pekka Paalanen
Cc: harry.wentland, ville.syrjala, intel-gfx, dri-devel,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Wednesday, October 13, 2021 2:01 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> brian.starkey@arm.com; sebastian@sebastianwick.net;
> Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 12 Oct 2021 20:58:27 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Pekka Paalanen <ppaalanen@gmail.com>
> > > Sent: Tuesday, October 12, 2021 4:01 PM
> > > To: Shankar, Uma <uma.shankar@intel.com>
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
> > > ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> > > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
> > > Pipeline
> > >
> > > On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
> > > <uma.shankar@intel.com> wrote:
> > >
> > > > This is a RFC proposal for plane color hardware blocks.
> > > > It exposes the property interface to userspace and calls out the
> > > > details or interfaces created and the intended purpose.
> > > >
> > > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > > ---
> > > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > > +++++++++++++++++++
> > > > 1 file changed, 167 insertions(+) create mode 100644
> > > > Documentation/gpu/rfc/drm_color_pipeline.rst
> > > >
> > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > new file mode 100644
> > > > index 000000000000..0d1ca858783b
> > > > --- /dev/null
> > > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > @@ -0,0 +1,167 @@
> > > > +==================================================
> > > > +Display Color Pipeline: Proposed DRM Properties
>
> ...
>
> > > > +Proposal is to have below properties for a plane:
> > > > +
> > > > +* Plane Degamma or Pre-Curve:
> > > > + * This will be used to linearize the input framebuffer data.
> > > > + * It will apply the reverse of the color transfer function.
> > > > + * It can be a degamma curve or OETF for HDR.
> > >
> > > As you want to produce light-linear values, you use EOTF or inverse OETF.
> > >
> > > The term OETF has a built-in assumption that that happens in a camera:
> > > it takes in light and produces and electrical signal. Lately I
> > > have personally started talking about non-linear encoding of color
> > > values, since EOTF is often associated with displays if nothing
> > > else is said (taking
> in an electrical signal and producing light).
> > >
> > > So this would be decoding the color values into light-linear color
> > > values. That is what an EOTF does, yes, but I feel there is a
> > > nuanced difference. A piece of equipment implements an EOTF by
> > > turning an electrical signal into light, hence EOTF often refers
> > > to specific equipment. You could talk about content EOTF to denote
> > > content value encoding, as opposed to output or display EOTF, but
> > > that might be confusing if you look at e.g. the diagrams in
> > > BT.2100: is it the EOTF
> or is it the inverse OETF? Is the (inverse?) OOTF included?
> > >
> > > So I try to side-step those questions by talking about encoding.
> >
> > The idea here is that frame buffer presented to display plane engine
> > will be non-
> linear.
> > So output of a media decode should result in content with EOTF applied.
>
> Hi,
>
> sure, but the question is: which EOTF. There can be many different
> things called "EOTF" in a single pipeline, and then it's up to the
> document writer to make the difference between them. Comparing two
> documents with different conventions causes a lot of confusion in my
> personal experience, so it is good to define the concepts more carefully.
Hi Pekka,
I think you have given some nice inputs to really deep dive and document here.
Will update this with the right expectations wrt what transfer functions to be used at various stages in the operation pipeline.
> > So output of a media decode should result in content with EOTF applied.
>
> I suspect you have it backwards. Media decode produces electrical
> (non-linear) pixel color values. If EOTF was applied, they would be
> linear instead (and require more memory to achieve the same visual precision).
>
> If you want to put it this way, you could say "with inverse EOTF
> applied", but that might be slightly confusing because it is already
> baked in to the video, it's not something a media decoder has to
> specifically apply, I think. However, the (inverse) EOTF in this case is the content EOTF, not the display EOTF.
>
> If content and display EOTF differ, then one must apply first content
> EOTF and then inverse display EOTF to get values that are correctly
> encoded for the display. (This is necessary but not sufficient in
> general.) Mind, that this is not an OOTF nor an artistic adjustment,
> this is purely a value encoding conversion.
>
0
Got it, thanks for correcting. Will also do some more study around this and update.
> > Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
>
> Does "rendering intent gamma" refer to artistic adjustments, not OOTF?
> ]
This ideally should be OOTF adjustments here.
> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
> the OOTF", although I find those diagrams somewhat confusing still. It
> does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
>
> Different documents use OOTF to refer to different things. Then there
> is also the fundamental difference between PQ and HLG systems, where
> OOTF is by definition in different places of the camera-transmission-display pipeline.
Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
Will do some research to get my understanding in place. Thanks for all the inputs.
> >
> > To make it linear, we should apply the OETF. Confusion is whether
> > OETF is equivalent to inverse EOTF, we could check this one out to confirm.
>
> OETF does not make anything linear. By definition, OETF converts
> optical (linear) values into electrical (practically always non-linearly encoded) values.
>
> Yes, EOTF is almost always not equal to inverse OETF because of the
> existence of OOTF. The applies to inverse EOTF vs. OETF as well.
>
> From what I have learned, it is unexpected to assume that inverse of
> one is the other. That will cause confusion. Therefore, if you mean
> the inverse, spell it out as inverse. I used to make this same
> mistake, and some of it may still be left in https://gitlab.freedesktop.org/pq/color-and-hdr .
Got it.
> >
> > Here since the values for the pre-curve (or degamma as we have
> > called it in past), accepts programmable lut values which makes it
> > flexible enough to
> accommodate any values.
> > This will hold for HDR as well as traditional gamma encoded SRGB data as well.
>
> Yes.
>
> > > > + * This linear data can be further acted on by the following
> > > > + * color hardware blocks in the display hardware pipeline
> > >
> > > I think this and the above description ties the intended use down
> > > too much. This is one possible way to use degamma, yes, but there
> > > may be others. Particularly if CTM can be replaced with a 3D LUT,
> > > then the degamma is more likely a shaper (non-linear adjustment to
> > > 3D LUT tap
> positions).
> >
> > Yeah agree, this is just one of the usecases. Its just a lut table
> > which can be used for other purposes as well and is not just limited
> > to a
> linearization operation. I will update this.
> >
> > > I would prefer the name pre-curve to underline that this can be
> > > whatever one wants it to be, but I understand that people may be
> > > more familiar
> with the name degamma.
> >
> > I feel pre-curve should be fine but yeah it deviates from naming of
> > legacy crtc/pipe
> color properties.
> > May be we can stay with legacy naming with more documentation to
> > have its
> usecases clearly called out.
>
> That is fine by me.
>
> > > > +
> > > > +UAPI Name: PLANE_DEGAMMA_MODE
> > > > +Description: Enum property with values as blob_id's which
> > > > +advertizes
> > > > the
> > >
> > > Is enum with blob id values even a thing?
> >
> > Yeah we could have. This is a dynamic enum created with blobs. Each
> > entry contains the data structure to extract the full color
> > capabilities of the hardware. It’s a very interesting play with
> > blobs (@ville.syrjala@linux.intel.com brainchild)
>
> Yes, I think I can imagine how that works. The blobs are created
> immutable, unable to change once the plane has been advertised to
> userspace, because their IDs are used as enum values. But that is ok,
> because the blob describes capabilities that cannot change during the
> device's lifetime... or can they? What if you would want to extend the
> blob format, do you need a KMS client cap to change the format which
> would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
>
> This also relies on enums being identified by their string names,
> because the numerical value is not a constant but a blob ID and gets
> determined when the immutable blob is created.
>
> Did I understand correctly?
Yes that’s right. We are not expecting these structures to change as they represent the platforms capabilities.
> As a userspace developer, I can totally work with that.
>
> > > > + possible degamma modes and lut ranges supported by the platform.
> > > > + This allows userspace to query and get the plane degamma color
> > > > + caps and choose the appropriate degamma mode and create lut values
> > > > + accordingly.
> > >
> > > I agree that some sort of "mode" switch is necessary, and
> > > advertisement of capabilities as well.
> > >
> >
> > This enum with blob id's is an interesting way to advertise segmented lut tables.
> >
> > > > +
> > > > +UAPI Name: PLANE_DEGAMMA_LUT
> > > > +Description: Blob property which allows a userspace to provide LUT values
> > > > + to apply degamma curve using the h/w plane degamma processing
> > > > + engine, thereby making the content as linear for further color
> > > > + processing. Userspace gets the size of LUT and precision etc
> > > > + from PLANE_DEGAMA_MODE_PROPERTY
> > >
> > > So all degamma modes will always be some kind of LUT? That may be
> > > a bit restrictive, as I understand AMD may have predefined or
> > > parameterised curves that are not LUTs. So there should be room
> > > for an arbitrary structure of parameters, which can be passed in
> > > as a blob id, and the contents defined by the degamma mode.
> >
> > For Intel's hardware these are luts but yeah AMD hardware seems to
> > have these as fixed function units. We should think of a way to have
> > this option as well in the UAPI. We could extend the DEGAMMA_MODE
> > property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
> > needed based on some of the attributes passed via DEGAMMA_MODE. This
> > can be
> one way to have room for both.
> > @harry.wentland@amd.com thoughts ?
>
> Yeah, though I don't think you can use DEGAMMA_MODE property to pass
> parameters to fixed-function curves. The parameters need another
> property. Would be natural to use the other property for LUT data when mode it set to LUT.
>
> A trivial and made-up example of a parameterised fixed-function curve
> is pow(x, gamma), where gamma is the parameter.
We can maybe have a parallel property as well with proper documentation if this helps with flexibility for varying hardware vendors. UAPI document will list what to use and when.
May be platform will not even list the other one which may make things less complicated to userspace.
> > >
> > > LUT size, precision, and other details of each degamma mode would
> > > be good to expose somehow. I kind of expected those would have
> > > been exposed through the above mentioned "enum with blob id
> > > values" where each blob content structure is defined by the respective enum value.
> >
> > Yes, you are spot on here.
> >
> > > > +
> > > > +* Plane CTM
> > > > + * This is a Property to program the color transformation matrix.
> > >
> > > No mode property here? Is there any hardware with something else
> > > than a matrix at this point?
> >
> > Not that I am aware of.
> >
> > > Should we assume there will be hardware with something else, and
> > > have a CSC mode property with only a single enum value defined so far:
> > > "matrix"? Or do we say PLANE_CTM is a matrix and if you have
> > > something else in hardware, then invent a new property for it?
> >
> > I think this should be good as we have this for crtc with no one complaining.
> > There may be hardware with fixed function operation for the CSC but
> > then its not a matrix and it would be pretty hardware dependent, so
> > we can leave that from a generic UAPI.
>
> Ok. And if that eventually turns out to be a mistake, it's easy to
> invent more properties.
I feel that is what would be required. This is just another instance of what we have at crtc level.
> > > > + * This can be used to perform a color space conversion like
> > > > + * BT2020 to BT709 or BT601 etc.
> > > > + * This block is generally kept after the degamma unit so that
> > >
> > > Not "generally". If blocks can change places, then it becomes
> > > intractable for generic userspace to program.
> >
> > Sure, will drop this wording here. But one open will still remain
> > for userspace, as to how it gets the pipeline dynamically for a respective hardware.
> > Currently we have assumed that this would be the logical fixed order
> > of hardware units.
>
> If we cannot model the abstract KMS pipeline as a fixed order of units
> (where each unit may exist or not), we need to take a few steps back
> here and look at what do we actually want to expose. That is a much
> bigger design problem which we are currently not even considering.
I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
> > > > + * linear data can be fed to it for conversion.
> > > > +
> > > > +UAPI Name: PLANE_CTM
> > > > +Description: Blob property which allows a userspace to provide
> > > > +CTM
> coefficients
> > > > + to do color space conversion or any other enhancement by doing a
> > > > + matrix multiplication using the h/w CTM processing engine
> > > > +
> > >
> > > Speaking of color space conversions, we should probably define
> > > what happens to out-of-range color values. Converting color into
> > > smaller gamut or smaller dynamic range always has the risk of
> > > ending up with out-of-range values. I suppose those get simply
> > > clipped independently on each
> color channel, right?
> >
> > We have standard matrix to convert colorspaces. This is just the
> > property of the colorspace, I guess clipping will be the only option
> > here (irrespective of hardware)
> >
> > > Such clipping can change hue, so userspace would be better avoid
> > > triggering clipping at all, but we still need to know what would
> > > happen with out-
> of-range values.
> > >
> > > We would also need to know when clipping will happen. If FP16
> > > (half-float) FB produces out-of-range values and degamma stage is
> > > not used, will the CTM see original or clipped values? Or is that
> > > something we have to define as hardware-specific?
> > >
> > > Generic userspace will try hard to avoid triggering
> > > hardware-specific behaviour, so you can expect such behaviour to go unused.
> >
> > Here hardware should just operate on the matrix values programmed.
> > This should be the limitation of the color space conversion
> > operation and hardware may not have any role to play apart from just
> > honoring the matrix values and producing the resultant output.
>
> I'm not talking about the matrix values. I'm talking about the values
> originating from the FB, are they clipped or not, before being processed by the matrix?
>
> Userspace could want to use the matrix to bring out-of-range FB values
> into range, but that plan cannot work if the FB values get clipped already before the matrix.
>
> I referred to FP16 format explicitly because that format can express
> values outside of the usual [0.0, 1.0] range in a framebuffer.
>
> Of course, the matrix values themselves have some limits too, and
> userspace should somehow be aware of them.
AFAIK, the values will not be clipped before being submitted to CSC blocks.
But this can be confirmed to not leave any misconception here.
> >
> > > > +* Plane Gamma or Post-Curve
> > > > + * This can be used to perform 2 operations:
> > > > + * non-lineralize the framebuffer data. Can be used for
> > > > + * non linear blending. It can be a gamma curve or EOTF
> > > > + * for HDR.
> > > > + * Perform Tone Mapping operation. This is an operation
> > > > + * done when blending is done with HDR and SDR content.
> > >
> > > I like this wording better than the wording for pre-curve: "can",
> > > not "will". It leaves room for creative use of this processing block.
> >
> > Ok thanks, will update pre-curve section as well.
> >
> > >
> > > Tone-mapping is needed always when dynamic range differs, so also
> > > for HDR to HDR, not just SDR to/from HDR.
> >
> > Yes correct, will update.
> >
> > > > +
> > > > +UAPI Name: PLANE_GAMMA_MODE
> > > > +Description: Enum property with values as blob_id's which advertizes the
> > > > + possible gamma modes and lut ranges supported by the platform.
> > > > + This allows userspace to query and get the plane gamma color
> > > > + caps and choose the appropriate gamma mode and create lut values
> > > > + accordingly.
> > > > +
> > > > +UAPI Name: PLANE_GAMMA_LUT
> > > > +Description: Blob property which allows a userspace to provide LUT values
> > > > + to apply gamma curve or perform tone mapping using the h/w plane
> > > > + gamma processing engine, thereby making the content as linear
> > > > + for further color processing. Userspace gets the size of LUT and
> > > > + precision etc from PLANE_GAMA_MODE_PROPERTY
> > >
> > > The same comments here as with DEGAMMA.
> >
> > Noted.
> >
> > > > +
> > > > +This is part of one plane engine. Data from multiple planes
> > > > +will be then fed to pipe where it will get blended. There is a
> > > > +similar set of properties available at crtc level which acts on this blended data.
> > > > +
> > > > +Below is a sample usecase:
> > > > +
> > > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > > ┌─────────────┐
> > > > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > > > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR
> │
> > > > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> > > Mapping├────────┐
> > > > + └────────────┘ └─────────────┘ └─────────────┘
> > > └─────────────┘ │
> > > > + │
> > > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > > ┌─────────────┐ │
> > > > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> │
> > > > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> > > ├─────┐ │
> > > > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │
> │
> > > > + └────────────┘ └─────────────┘ └─────────────┘
> > > └─────────────┘ │ │
> > > > + │ │
> > > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > > ┌─────────────┐ │ │
> > > > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> │
> > > > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> > > in├───┐ │ │
> > > > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > > > + └────────────┘ └─────────────┘ └─────────────┘
> > > └─────────────┘ │ │ │
> > >
> > > EOTF, not OETF, since it is converting E to O, electrical to optical.
> >
> > I think media decode would have given a EOTF applied data to be
> > directly consumed by display sink (in case we have chosen a display pass through).
> Not sure here though, it’s a bit confusing.
>
> I hope I managed to explain this earlier in this email.
>
> Display sinks "always" use non-linearly encoded values, because it
> saves bandwidth without losing visual quality. For the same reason,
> images tend to be stored with non-linear value encoding whenever possible.
Yeah, thanks for the explanation and useful pointers. Will work on it to put the right expectations in the document.
Thanks Pekka for the valuable feedback.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > > > +
> > > > + │ │ │
> > > > +
> > > > + │ │ │
> > > > +
> > > > +│ │ │
> > > >
> > >
> +┌──────────────────────────────────────────────────────────────────
> > > ──
> > > > +───────────┴─┴──┘
> > > > +│
> > > > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > > > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > > > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone
> > > > +├─────►
> > > TO Port
> > > > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > > > + │ after blend │ │ Conversion │ │ transfer func │
> > > > + └─────────────┘ └─────────────┘ └───────────────┘
> > >
> > > Blending does not change whether the data is linear or not. I
> > > suppose in this example, CRTC degamma and CTM would be
> > > passthrough, and gamma would be the inverse display EOTF for
> > > encoding color values into
> what the monitor expects.
> >
> > Yeah, will update this to make it clear.
> >
> > > > +
> > > > +
> > > > +This patch series adds properties for plane color features. It
> > > > +adds properties for degamma used to linearize data and CSC used
> > > > +for gamut conversion. It also includes Gamma support used to
> > > > +again non-linearize data as per panel supported color space.
> > > > +These can be utilize by user space to convert planes from one
> > > > +format to another, one color space to another etc.
> > >
> > > FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
> >
> > This is great to hear that we are aligned wrt how the pipeline should work.
> >
> > Thanks Pekka for taking time out and providing the feedback.
> >
> > @harry.wentland@amd.com We can work together and build our design to
> > accommodate both Intel and AMD's hardware needs. This will also make
> > things generic enough for any other hardware vendor as well.
> >
> > Thanks & Regards,
> > Uma Shankar
> >
> > > > +
> > > > +Userspace can take smart blending decisions and utilize these
> > > > +hardware supported plane color features to get accurate color
> > > > +profile. The same can help in consistent color quality from
> > > > +source to panel taking advantage of advanced color features in hardware.
> > > > +
> > > > +These patches add the property interfaces and enable helper functions.
> > > > +This series adds Intel's XE_LPD hw specific plane gamma feature.
> > > > +We can build up and add other platform/hardware specific
> > > > +implementation on top of this series.
> > > > +
> > > > +Credits: Special mention and credits to Ville Syrjala for
> > > > +coming up with a design for this feature and inputs. This
> > > > +series is based on his original design and idea.
> > >
> > >
> > > Thanks,
> > > pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-14 19:44 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-14 19:44 UTC (permalink / raw)
To: Pekka Paalanen
Cc: harry.wentland, ville.syrjala, intel-gfx, dri-devel,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Wednesday, October 13, 2021 2:01 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> brian.starkey@arm.com; sebastian@sebastianwick.net;
> Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
> On Tue, 12 Oct 2021 20:58:27 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Pekka Paalanen <ppaalanen@gmail.com>
> > > Sent: Tuesday, October 12, 2021 4:01 PM
> > > To: Shankar, Uma <uma.shankar@intel.com>
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
> > > ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> > > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
> > > Pipeline
> > >
> > > On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
> > > <uma.shankar@intel.com> wrote:
> > >
> > > > This is a RFC proposal for plane color hardware blocks.
> > > > It exposes the property interface to userspace and calls out the
> > > > details or interfaces created and the intended purpose.
> > > >
> > > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > > ---
> > > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > > +++++++++++++++++++
> > > > 1 file changed, 167 insertions(+) create mode 100644
> > > > Documentation/gpu/rfc/drm_color_pipeline.rst
> > > >
> > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > new file mode 100644
> > > > index 000000000000..0d1ca858783b
> > > > --- /dev/null
> > > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > @@ -0,0 +1,167 @@
> > > > +==================================================
> > > > +Display Color Pipeline: Proposed DRM Properties
>
> ...
>
> > > > +Proposal is to have below properties for a plane:
> > > > +
> > > > +* Plane Degamma or Pre-Curve:
> > > > + * This will be used to linearize the input framebuffer data.
> > > > + * It will apply the reverse of the color transfer function.
> > > > + * It can be a degamma curve or OETF for HDR.
> > >
> > > As you want to produce light-linear values, you use EOTF or inverse OETF.
> > >
> > > The term OETF has a built-in assumption that that happens in a camera:
> > > it takes in light and produces and electrical signal. Lately I
> > > have personally started talking about non-linear encoding of color
> > > values, since EOTF is often associated with displays if nothing
> > > else is said (taking
> in an electrical signal and producing light).
> > >
> > > So this would be decoding the color values into light-linear color
> > > values. That is what an EOTF does, yes, but I feel there is a
> > > nuanced difference. A piece of equipment implements an EOTF by
> > > turning an electrical signal into light, hence EOTF often refers
> > > to specific equipment. You could talk about content EOTF to denote
> > > content value encoding, as opposed to output or display EOTF, but
> > > that might be confusing if you look at e.g. the diagrams in
> > > BT.2100: is it the EOTF
> or is it the inverse OETF? Is the (inverse?) OOTF included?
> > >
> > > So I try to side-step those questions by talking about encoding.
> >
> > The idea here is that frame buffer presented to display plane engine
> > will be non-
> linear.
> > So output of a media decode should result in content with EOTF applied.
>
> Hi,
>
> sure, but the question is: which EOTF. There can be many different
> things called "EOTF" in a single pipeline, and then it's up to the
> document writer to make the difference between them. Comparing two
> documents with different conventions causes a lot of confusion in my
> personal experience, so it is good to define the concepts more carefully.
Hi Pekka,
I think you have given some nice inputs to really deep dive and document here.
Will update this with the right expectations wrt what transfer functions to be used at various stages in the operation pipeline.
> > So output of a media decode should result in content with EOTF applied.
>
> I suspect you have it backwards. Media decode produces electrical
> (non-linear) pixel color values. If EOTF was applied, they would be
> linear instead (and require more memory to achieve the same visual precision).
>
> If you want to put it this way, you could say "with inverse EOTF
> applied", but that might be slightly confusing because it is already
> baked in to the video, it's not something a media decoder has to
> specifically apply, I think. However, the (inverse) EOTF in this case is the content EOTF, not the display EOTF.
>
> If content and display EOTF differ, then one must apply first content
> EOTF and then inverse display EOTF to get values that are correctly
> encoded for the display. (This is necessary but not sufficient in
> general.) Mind, that this is not an OOTF nor an artistic adjustment,
> this is purely a value encoding conversion.
>
0
Got it, thanks for correcting. Will also do some more study around this and update.
> > Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
>
> Does "rendering intent gamma" refer to artistic adjustments, not OOTF?
> ]
This ideally should be OOTF adjustments here.
> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
> the OOTF", although I find those diagrams somewhat confusing still. It
> does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
>
> Different documents use OOTF to refer to different things. Then there
> is also the fundamental difference between PQ and HLG systems, where
> OOTF is by definition in different places of the camera-transmission-display pipeline.
Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
Will do some research to get my understanding in place. Thanks for all the inputs.
> >
> > To make it linear, we should apply the OETF. Confusion is whether
> > OETF is equivalent to inverse EOTF, we could check this one out to confirm.
>
> OETF does not make anything linear. By definition, OETF converts
> optical (linear) values into electrical (practically always non-linearly encoded) values.
>
> Yes, EOTF is almost always not equal to inverse OETF because of the
> existence of OOTF. The applies to inverse EOTF vs. OETF as well.
>
> From what I have learned, it is unexpected to assume that inverse of
> one is the other. That will cause confusion. Therefore, if you mean
> the inverse, spell it out as inverse. I used to make this same
> mistake, and some of it may still be left in https://gitlab.freedesktop.org/pq/color-and-hdr .
Got it.
> >
> > Here since the values for the pre-curve (or degamma as we have
> > called it in past), accepts programmable lut values which makes it
> > flexible enough to
> accommodate any values.
> > This will hold for HDR as well as traditional gamma encoded SRGB data as well.
>
> Yes.
>
> > > > + * This linear data can be further acted on by the following
> > > > + * color hardware blocks in the display hardware pipeline
> > >
> > > I think this and the above description ties the intended use down
> > > too much. This is one possible way to use degamma, yes, but there
> > > may be others. Particularly if CTM can be replaced with a 3D LUT,
> > > then the degamma is more likely a shaper (non-linear adjustment to
> > > 3D LUT tap
> positions).
> >
> > Yeah agree, this is just one of the usecases. Its just a lut table
> > which can be used for other purposes as well and is not just limited
> > to a
> linearization operation. I will update this.
> >
> > > I would prefer the name pre-curve to underline that this can be
> > > whatever one wants it to be, but I understand that people may be
> > > more familiar
> with the name degamma.
> >
> > I feel pre-curve should be fine but yeah it deviates from naming of
> > legacy crtc/pipe
> color properties.
> > May be we can stay with legacy naming with more documentation to
> > have its
> usecases clearly called out.
>
> That is fine by me.
>
> > > > +
> > > > +UAPI Name: PLANE_DEGAMMA_MODE
> > > > +Description: Enum property with values as blob_id's which
> > > > +advertizes
> > > > the
> > >
> > > Is enum with blob id values even a thing?
> >
> > Yeah we could have. This is a dynamic enum created with blobs. Each
> > entry contains the data structure to extract the full color
> > capabilities of the hardware. It’s a very interesting play with
> > blobs (@ville.syrjala@linux.intel.com brainchild)
>
> Yes, I think I can imagine how that works. The blobs are created
> immutable, unable to change once the plane has been advertised to
> userspace, because their IDs are used as enum values. But that is ok,
> because the blob describes capabilities that cannot change during the
> device's lifetime... or can they? What if you would want to extend the
> blob format, do you need a KMS client cap to change the format which
> would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
>
> This also relies on enums being identified by their string names,
> because the numerical value is not a constant but a blob ID and gets
> determined when the immutable blob is created.
>
> Did I understand correctly?
Yes that’s right. We are not expecting these structures to change as they represent the platforms capabilities.
> As a userspace developer, I can totally work with that.
>
> > > > + possible degamma modes and lut ranges supported by the platform.
> > > > + This allows userspace to query and get the plane degamma color
> > > > + caps and choose the appropriate degamma mode and create lut values
> > > > + accordingly.
> > >
> > > I agree that some sort of "mode" switch is necessary, and
> > > advertisement of capabilities as well.
> > >
> >
> > This enum with blob id's is an interesting way to advertise segmented lut tables.
> >
> > > > +
> > > > +UAPI Name: PLANE_DEGAMMA_LUT
> > > > +Description: Blob property which allows a userspace to provide LUT values
> > > > + to apply degamma curve using the h/w plane degamma processing
> > > > + engine, thereby making the content as linear for further color
> > > > + processing. Userspace gets the size of LUT and precision etc
> > > > + from PLANE_DEGAMA_MODE_PROPERTY
> > >
> > > So all degamma modes will always be some kind of LUT? That may be
> > > a bit restrictive, as I understand AMD may have predefined or
> > > parameterised curves that are not LUTs. So there should be room
> > > for an arbitrary structure of parameters, which can be passed in
> > > as a blob id, and the contents defined by the degamma mode.
> >
> > For Intel's hardware these are luts but yeah AMD hardware seems to
> > have these as fixed function units. We should think of a way to have
> > this option as well in the UAPI. We could extend the DEGAMMA_MODE
> > property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
> > needed based on some of the attributes passed via DEGAMMA_MODE. This
> > can be
> one way to have room for both.
> > @harry.wentland@amd.com thoughts ?
>
> Yeah, though I don't think you can use DEGAMMA_MODE property to pass
> parameters to fixed-function curves. The parameters need another
> property. Would be natural to use the other property for LUT data when mode it set to LUT.
>
> A trivial and made-up example of a parameterised fixed-function curve
> is pow(x, gamma), where gamma is the parameter.
We can maybe have a parallel property as well with proper documentation if this helps with flexibility for varying hardware vendors. UAPI document will list what to use and when.
May be platform will not even list the other one which may make things less complicated to userspace.
> > >
> > > LUT size, precision, and other details of each degamma mode would
> > > be good to expose somehow. I kind of expected those would have
> > > been exposed through the above mentioned "enum with blob id
> > > values" where each blob content structure is defined by the respective enum value.
> >
> > Yes, you are spot on here.
> >
> > > > +
> > > > +* Plane CTM
> > > > + * This is a Property to program the color transformation matrix.
> > >
> > > No mode property here? Is there any hardware with something else
> > > than a matrix at this point?
> >
> > Not that I am aware of.
> >
> > > Should we assume there will be hardware with something else, and
> > > have a CSC mode property with only a single enum value defined so far:
> > > "matrix"? Or do we say PLANE_CTM is a matrix and if you have
> > > something else in hardware, then invent a new property for it?
> >
> > I think this should be good as we have this for crtc with no one complaining.
> > There may be hardware with fixed function operation for the CSC but
> > then its not a matrix and it would be pretty hardware dependent, so
> > we can leave that from a generic UAPI.
>
> Ok. And if that eventually turns out to be a mistake, it's easy to
> invent more properties.
I feel that is what would be required. This is just another instance of what we have at crtc level.
> > > > + * This can be used to perform a color space conversion like
> > > > + * BT2020 to BT709 or BT601 etc.
> > > > + * This block is generally kept after the degamma unit so that
> > >
> > > Not "generally". If blocks can change places, then it becomes
> > > intractable for generic userspace to program.
> >
> > Sure, will drop this wording here. But one open will still remain
> > for userspace, as to how it gets the pipeline dynamically for a respective hardware.
> > Currently we have assumed that this would be the logical fixed order
> > of hardware units.
>
> If we cannot model the abstract KMS pipeline as a fixed order of units
> (where each unit may exist or not), we need to take a few steps back
> here and look at what do we actually want to expose. That is a much
> bigger design problem which we are currently not even considering.
I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
> > > > + * linear data can be fed to it for conversion.
> > > > +
> > > > +UAPI Name: PLANE_CTM
> > > > +Description: Blob property which allows a userspace to provide
> > > > +CTM
> coefficients
> > > > + to do color space conversion or any other enhancement by doing a
> > > > + matrix multiplication using the h/w CTM processing engine
> > > > +
> > >
> > > Speaking of color space conversions, we should probably define
> > > what happens to out-of-range color values. Converting color into
> > > smaller gamut or smaller dynamic range always has the risk of
> > > ending up with out-of-range values. I suppose those get simply
> > > clipped independently on each
> color channel, right?
> >
> > We have standard matrix to convert colorspaces. This is just the
> > property of the colorspace, I guess clipping will be the only option
> > here (irrespective of hardware)
> >
> > > Such clipping can change hue, so userspace would be better avoid
> > > triggering clipping at all, but we still need to know what would
> > > happen with out-
> of-range values.
> > >
> > > We would also need to know when clipping will happen. If FP16
> > > (half-float) FB produces out-of-range values and degamma stage is
> > > not used, will the CTM see original or clipped values? Or is that
> > > something we have to define as hardware-specific?
> > >
> > > Generic userspace will try hard to avoid triggering
> > > hardware-specific behaviour, so you can expect such behaviour to go unused.
> >
> > Here hardware should just operate on the matrix values programmed.
> > This should be the limitation of the color space conversion
> > operation and hardware may not have any role to play apart from just
> > honoring the matrix values and producing the resultant output.
>
> I'm not talking about the matrix values. I'm talking about the values
> originating from the FB, are they clipped or not, before being processed by the matrix?
>
> Userspace could want to use the matrix to bring out-of-range FB values
> into range, but that plan cannot work if the FB values get clipped already before the matrix.
>
> I referred to FP16 format explicitly because that format can express
> values outside of the usual [0.0, 1.0] range in a framebuffer.
>
> Of course, the matrix values themselves have some limits too, and
> userspace should somehow be aware of them.
AFAIK, the values will not be clipped before being submitted to CSC blocks.
But this can be confirmed to not leave any misconception here.
> >
> > > > +* Plane Gamma or Post-Curve
> > > > + * This can be used to perform 2 operations:
> > > > + * non-lineralize the framebuffer data. Can be used for
> > > > + * non linear blending. It can be a gamma curve or EOTF
> > > > + * for HDR.
> > > > + * Perform Tone Mapping operation. This is an operation
> > > > + * done when blending is done with HDR and SDR content.
> > >
> > > I like this wording better than the wording for pre-curve: "can",
> > > not "will". It leaves room for creative use of this processing block.
> >
> > Ok thanks, will update pre-curve section as well.
> >
> > >
> > > Tone-mapping is needed always when dynamic range differs, so also
> > > for HDR to HDR, not just SDR to/from HDR.
> >
> > Yes correct, will update.
> >
> > > > +
> > > > +UAPI Name: PLANE_GAMMA_MODE
> > > > +Description: Enum property with values as blob_id's which advertizes the
> > > > + possible gamma modes and lut ranges supported by the platform.
> > > > + This allows userspace to query and get the plane gamma color
> > > > + caps and choose the appropriate gamma mode and create lut values
> > > > + accordingly.
> > > > +
> > > > +UAPI Name: PLANE_GAMMA_LUT
> > > > +Description: Blob property which allows a userspace to provide LUT values
> > > > + to apply gamma curve or perform tone mapping using the h/w plane
> > > > + gamma processing engine, thereby making the content as linear
> > > > + for further color processing. Userspace gets the size of LUT and
> > > > + precision etc from PLANE_GAMA_MODE_PROPERTY
> > >
> > > The same comments here as with DEGAMMA.
> >
> > Noted.
> >
> > > > +
> > > > +This is part of one plane engine. Data from multiple planes
> > > > +will be then fed to pipe where it will get blended. There is a
> > > > +similar set of properties available at crtc level which acts on this blended data.
> > > > +
> > > > +Below is a sample usecase:
> > > > +
> > > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > > ┌─────────────┐
> > > > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > > > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR
> │
> > > > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> > > Mapping├────────┐
> > > > + └────────────┘ └─────────────┘ └─────────────┘
> > > └─────────────┘ │
> > > > + │
> > > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > > ┌─────────────┐ │
> > > > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> │
> > > > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> > > ├─────┐ │
> > > > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │
> │
> > > > + └────────────┘ └─────────────┘ └─────────────┘
> > > └─────────────┘ │ │
> > > > + │ │
> > > > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> > > ┌─────────────┐ │ │
> > > > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> │
> > > > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> > > in├───┐ │ │
> > > > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > > > + └────────────┘ └─────────────┘ └─────────────┘
> > > └─────────────┘ │ │ │
> > >
> > > EOTF, not OETF, since it is converting E to O, electrical to optical.
> >
> > I think media decode would have given a EOTF applied data to be
> > directly consumed by display sink (in case we have chosen a display pass through).
> Not sure here though, it’s a bit confusing.
>
> I hope I managed to explain this earlier in this email.
>
> Display sinks "always" use non-linearly encoded values, because it
> saves bandwidth without losing visual quality. For the same reason,
> images tend to be stored with non-linear value encoding whenever possible.
Yeah, thanks for the explanation and useful pointers. Will work on it to put the right expectations in the document.
Thanks Pekka for the valuable feedback.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > > > +
> > > > + │ │ │
> > > > +
> > > > + │ │ │
> > > > +
> > > > +│ │ │
> > > >
> > >
> +┌──────────────────────────────────────────────────────────────────
> > > ──
> > > > +───────────┴─┴──┘
> > > > +│
> > > > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > > > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > > > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone
> > > > +├─────►
> > > TO Port
> > > > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > > > + │ after blend │ │ Conversion │ │ transfer func │
> > > > + └─────────────┘ └─────────────┘ └───────────────┘
> > >
> > > Blending does not change whether the data is linear or not. I
> > > suppose in this example, CRTC degamma and CTM would be
> > > passthrough, and gamma would be the inverse display EOTF for
> > > encoding color values into
> what the monitor expects.
> >
> > Yeah, will update this to make it clear.
> >
> > > > +
> > > > +
> > > > +This patch series adds properties for plane color features. It
> > > > +adds properties for degamma used to linearize data and CSC used
> > > > +for gamut conversion. It also includes Gamma support used to
> > > > +again non-linearize data as per panel supported color space.
> > > > +These can be utilize by user space to convert planes from one
> > > > +format to another, one color space to another etc.
> > >
> > > FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
> >
> > This is great to hear that we are aligned wrt how the pipeline should work.
> >
> > Thanks Pekka for taking time out and providing the feedback.
> >
> > @harry.wentland@amd.com We can work together and build our design to
> > accommodate both Intel and AMD's hardware needs. This will also make
> > things generic enough for any other hardware vendor as well.
> >
> > Thanks & Regards,
> > Uma Shankar
> >
> > > > +
> > > > +Userspace can take smart blending decisions and utilize these
> > > > +hardware supported plane color features to get accurate color
> > > > +profile. The same can help in consistent color quality from
> > > > +source to panel taking advantage of advanced color features in hardware.
> > > > +
> > > > +These patches add the property interfaces and enable helper functions.
> > > > +This series adds Intel's XE_LPD hw specific plane gamma feature.
> > > > +We can build up and add other platform/hardware specific
> > > > +implementation on top of this series.
> > > > +
> > > > +Credits: Special mention and credits to Ville Syrjala for
> > > > +coming up with a design for this feature and inputs. This
> > > > +series is based on his original design and idea.
> > >
> > >
> > > Thanks,
> > > pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-14 19:44 ` [Intel-gfx] " Shankar, Uma
@ 2021-10-15 7:42 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-15 7:42 UTC (permalink / raw)
To: Shankar, Uma
Cc: harry.wentland, ville.syrjala, intel-gfx, dri-devel,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 7883 bytes --]
On Thu, 14 Oct 2021 19:44:25 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Pekka Paalanen <ppaalanen@gmail.com>
> > Sent: Wednesday, October 13, 2021 2:01 PM
> > To: Shankar, Uma <uma.shankar@intel.com>
> > Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
> > gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > brian.starkey@arm.com; sebastian@sebastianwick.net;
> > Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> > On Tue, 12 Oct 2021 20:58:27 +0000
> > "Shankar, Uma" <uma.shankar@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Sent: Tuesday, October 12, 2021 4:01 PM
> > > > To: Shankar, Uma <uma.shankar@intel.com>
> > > > Cc: intel-gfx@lists.freedesktop.org;
> > > > dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
> > > > ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> > > > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
> > > > Pipeline
> > > >
> > > > On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
> > > > <uma.shankar@intel.com> wrote:
> > > >
> > > > > This is a RFC proposal for plane color hardware blocks.
> > > > > It exposes the property interface to userspace and calls out the
> > > > > details or interfaces created and the intended purpose.
> > > > >
> > > > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > > > ---
> > > > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > > > +++++++++++++++++++
> > > > > 1 file changed, 167 insertions(+) create mode 100644
> > > > > Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > >
> > > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > > new file mode 100644
> > > > > index 000000000000..0d1ca858783b
> > > > > --- /dev/null
> > > > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > > @@ -0,0 +1,167 @@
> > > > > +==================================================
> > > > > +Display Color Pipeline: Proposed DRM Properties
...
> > cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
> > the OOTF", although I find those diagrams somewhat confusing still. It
> > does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
> >
> > Different documents use OOTF to refer to different things. Then there
> > is also the fundamental difference between PQ and HLG systems, where
> > OOTF is by definition in different places of the camera-transmission-display pipeline.
>
> Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
> Will do some research to get my understanding in place. Thanks for all the inputs.
I'm sure I was at least equally confused or even more at the start. I
have just had a year of casual reading, discussions, and a W3C workshop
attendance to improve my understanding. :-)
Now I know enough to be dangerous.
...
> > > > > +
> > > > > +UAPI Name: PLANE_DEGAMMA_MODE
> > > > > +Description: Enum property with values as blob_id's which
> > > > > +advertizes
> > > > > the
> > > >
> > > > Is enum with blob id values even a thing?
> > >
> > > Yeah we could have. This is a dynamic enum created with blobs. Each
> > > entry contains the data structure to extract the full color
> > > capabilities of the hardware. It’s a very interesting play with
> > > blobs (@ville.syrjala@linux.intel.com brainchild)
> >
> > Yes, I think I can imagine how that works. The blobs are created
> > immutable, unable to change once the plane has been advertised to
> > userspace, because their IDs are used as enum values. But that is ok,
> > because the blob describes capabilities that cannot change during the
> > device's lifetime... or can they? What if you would want to extend the
> > blob format, do you need a KMS client cap to change the format which
> > would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
> >
> > This also relies on enums being identified by their string names,
> > because the numerical value is not a constant but a blob ID and gets
> > determined when the immutable blob is created.
> >
> > Did I understand correctly?
>
> Yes that’s right. We are not expecting these structures to change as
> they represent the platforms capabilities.
Until there comes a new platform whose capabilities you cannot quite
describe with the existing structure. What's the plan to deal with that?
A new enum value, like LUT2 instead of LUT? I suppose that works.
>
> > As a userspace developer, I can totally work with that.
> >
> > > > > + possible degamma modes and lut ranges supported by the platform.
> > > > > + This allows userspace to query and get the plane degamma color
> > > > > + caps and choose the appropriate degamma mode and create lut values
> > > > > + accordingly.
> > > >
> > > > I agree that some sort of "mode" switch is necessary, and
> > > > advertisement of capabilities as well.
> > > >
> > >
> > > This enum with blob id's is an interesting way to advertise segmented lut tables.
> > >
> > > > > +
> > > > > +UAPI Name: PLANE_DEGAMMA_LUT
> > > > > +Description: Blob property which allows a userspace to provide LUT values
> > > > > + to apply degamma curve using the h/w plane degamma processing
> > > > > + engine, thereby making the content as linear for further color
> > > > > + processing. Userspace gets the size of LUT and precision etc
> > > > > + from PLANE_DEGAMA_MODE_PROPERTY
> > > >
> > > > So all degamma modes will always be some kind of LUT? That may be
> > > > a bit restrictive, as I understand AMD may have predefined or
> > > > parameterised curves that are not LUTs. So there should be room
> > > > for an arbitrary structure of parameters, which can be passed in
> > > > as a blob id, and the contents defined by the degamma mode.
> > >
> > > For Intel's hardware these are luts but yeah AMD hardware seems to
> > > have these as fixed function units. We should think of a way to have
> > > this option as well in the UAPI. We could extend the DEGAMMA_MODE
> > > property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
> > > needed based on some of the attributes passed via DEGAMMA_MODE. This
> > > can be
> > one way to have room for both.
> > > @harry.wentland@amd.com thoughts ?
> >
> > Yeah, though I don't think you can use DEGAMMA_MODE property to pass
> > parameters to fixed-function curves. The parameters need another
> > property. Would be natural to use the other property for LUT data when mode it set to LUT.
> >
> > A trivial and made-up example of a parameterised fixed-function curve
> > is pow(x, gamma), where gamma is the parameter.
>
> We can maybe have a parallel property as well with proper
> documentation if this helps with flexibility for varying hardware
> vendors. UAPI document will list what to use and when. May be
> platform will not even list the other one which may make things less
> complicated to userspace.
I'm not sure I got what you're thinking. My idea is that the
interpretation of the blob contents depends on the value of the mode
enum. Obviously the two will always need to be set together by
userspace to ensure they match, otherwise DRM needs to reject the
commit.
The rest of your comments I agree with.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-15 7:42 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-15 7:42 UTC (permalink / raw)
To: Shankar, Uma
Cc: harry.wentland, ville.syrjala, intel-gfx, dri-devel,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 7883 bytes --]
On Thu, 14 Oct 2021 19:44:25 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Pekka Paalanen <ppaalanen@gmail.com>
> > Sent: Wednesday, October 13, 2021 2:01 PM
> > To: Shankar, Uma <uma.shankar@intel.com>
> > Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
> > gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > brian.starkey@arm.com; sebastian@sebastianwick.net;
> > Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> > On Tue, 12 Oct 2021 20:58:27 +0000
> > "Shankar, Uma" <uma.shankar@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Sent: Tuesday, October 12, 2021 4:01 PM
> > > > To: Shankar, Uma <uma.shankar@intel.com>
> > > > Cc: intel-gfx@lists.freedesktop.org;
> > > > dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
> > > > ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> > > > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > > > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
> > > > Pipeline
> > > >
> > > > On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
> > > > <uma.shankar@intel.com> wrote:
> > > >
> > > > > This is a RFC proposal for plane color hardware blocks.
> > > > > It exposes the property interface to userspace and calls out the
> > > > > details or interfaces created and the intended purpose.
> > > > >
> > > > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > > > ---
> > > > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > > > +++++++++++++++++++
> > > > > 1 file changed, 167 insertions(+) create mode 100644
> > > > > Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > >
> > > > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > > new file mode 100644
> > > > > index 000000000000..0d1ca858783b
> > > > > --- /dev/null
> > > > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > > > @@ -0,0 +1,167 @@
> > > > > +==================================================
> > > > > +Display Color Pipeline: Proposed DRM Properties
...
> > cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
> > the OOTF", although I find those diagrams somewhat confusing still. It
> > does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
> >
> > Different documents use OOTF to refer to different things. Then there
> > is also the fundamental difference between PQ and HLG systems, where
> > OOTF is by definition in different places of the camera-transmission-display pipeline.
>
> Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
> Will do some research to get my understanding in place. Thanks for all the inputs.
I'm sure I was at least equally confused or even more at the start. I
have just had a year of casual reading, discussions, and a W3C workshop
attendance to improve my understanding. :-)
Now I know enough to be dangerous.
...
> > > > > +
> > > > > +UAPI Name: PLANE_DEGAMMA_MODE
> > > > > +Description: Enum property with values as blob_id's which
> > > > > +advertizes
> > > > > the
> > > >
> > > > Is enum with blob id values even a thing?
> > >
> > > Yeah we could have. This is a dynamic enum created with blobs. Each
> > > entry contains the data structure to extract the full color
> > > capabilities of the hardware. It’s a very interesting play with
> > > blobs (@ville.syrjala@linux.intel.com brainchild)
> >
> > Yes, I think I can imagine how that works. The blobs are created
> > immutable, unable to change once the plane has been advertised to
> > userspace, because their IDs are used as enum values. But that is ok,
> > because the blob describes capabilities that cannot change during the
> > device's lifetime... or can they? What if you would want to extend the
> > blob format, do you need a KMS client cap to change the format which
> > would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
> >
> > This also relies on enums being identified by their string names,
> > because the numerical value is not a constant but a blob ID and gets
> > determined when the immutable blob is created.
> >
> > Did I understand correctly?
>
> Yes that’s right. We are not expecting these structures to change as
> they represent the platforms capabilities.
Until there comes a new platform whose capabilities you cannot quite
describe with the existing structure. What's the plan to deal with that?
A new enum value, like LUT2 instead of LUT? I suppose that works.
>
> > As a userspace developer, I can totally work with that.
> >
> > > > > + possible degamma modes and lut ranges supported by the platform.
> > > > > + This allows userspace to query and get the plane degamma color
> > > > > + caps and choose the appropriate degamma mode and create lut values
> > > > > + accordingly.
> > > >
> > > > I agree that some sort of "mode" switch is necessary, and
> > > > advertisement of capabilities as well.
> > > >
> > >
> > > This enum with blob id's is an interesting way to advertise segmented lut tables.
> > >
> > > > > +
> > > > > +UAPI Name: PLANE_DEGAMMA_LUT
> > > > > +Description: Blob property which allows a userspace to provide LUT values
> > > > > + to apply degamma curve using the h/w plane degamma processing
> > > > > + engine, thereby making the content as linear for further color
> > > > > + processing. Userspace gets the size of LUT and precision etc
> > > > > + from PLANE_DEGAMA_MODE_PROPERTY
> > > >
> > > > So all degamma modes will always be some kind of LUT? That may be
> > > > a bit restrictive, as I understand AMD may have predefined or
> > > > parameterised curves that are not LUTs. So there should be room
> > > > for an arbitrary structure of parameters, which can be passed in
> > > > as a blob id, and the contents defined by the degamma mode.
> > >
> > > For Intel's hardware these are luts but yeah AMD hardware seems to
> > > have these as fixed function units. We should think of a way to have
> > > this option as well in the UAPI. We could extend the DEGAMMA_MODE
> > > property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
> > > needed based on some of the attributes passed via DEGAMMA_MODE. This
> > > can be
> > one way to have room for both.
> > > @harry.wentland@amd.com thoughts ?
> >
> > Yeah, though I don't think you can use DEGAMMA_MODE property to pass
> > parameters to fixed-function curves. The parameters need another
> > property. Would be natural to use the other property for LUT data when mode it set to LUT.
> >
> > A trivial and made-up example of a parameterised fixed-function curve
> > is pow(x, gamma), where gamma is the parameter.
>
> We can maybe have a parallel property as well with proper
> documentation if this helps with flexibility for varying hardware
> vendors. UAPI document will list what to use and when. May be
> platform will not even list the other one which may make things less
> complicated to userspace.
I'm not sure I got what you're thinking. My idea is that the
interpretation of the blob contents depends on the value of the mode
enum. Obviously the two will always need to be set together by
userspace to ensure they match, otherwise DRM needs to reject the
commit.
The rest of your comments I agree with.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-15 7:42 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-26 15:11 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:11 UTC (permalink / raw)
To: Pekka Paalanen, Shankar, Uma
Cc: ville.syrjala, intel-gfx, dri-devel, brian.starkey, sebastian,
Shashank.Sharma, Cyr, Aric
Thanks, Uma, for the updated patches. I'm finally finding
time to go through them.
On 2021-10-15 03:42, Pekka Paalanen wrote:
> On Thu, 14 Oct 2021 19:44:25 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
>>> -----Original Message-----
>>> From: Pekka Paalanen <ppaalanen@gmail.com>
>>> Sent: Wednesday, October 13, 2021 2:01 PM
>>> To: Shankar, Uma <uma.shankar@intel.com>
>>> Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
>>> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>>> brian.starkey@arm.com; sebastian@sebastianwick.net;
>>> Shashank.Sharma@amd.com
>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>>
>>> On Tue, 12 Oct 2021 20:58:27 +0000
>>> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Pekka Paalanen <ppaalanen@gmail.com>
>>>>> Sent: Tuesday, October 12, 2021 4:01 PM
>>>>> To: Shankar, Uma <uma.shankar@intel.com>
>>>>> Cc: intel-gfx@lists.freedesktop.org;
>>>>> dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
>>>>> ville.syrjala@linux.intel.com; brian.starkey@arm.com;
>>>>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>>>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
>>>>> Pipeline
>>>>>
>>>>> On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
>>>>> <uma.shankar@intel.com> wrote:
>>>>>
>>>>>> This is a RFC proposal for plane color hardware blocks.
>>>>>> It exposes the property interface to userspace and calls out the
>>>>>> details or interfaces created and the intended purpose.
>>>>>>
>>>>>> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>>> ---
>>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst | 167
>>>>>> +++++++++++++++++++
>>>>>> 1 file changed, 167 insertions(+) create mode 100644
>>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>>
>>>>>> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>> b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>> new file mode 100644
>>>>>> index 000000000000..0d1ca858783b
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>> @@ -0,0 +1,167 @@
>>>>>> +==================================================
>>>>>> +Display Color Pipeline: Proposed DRM Properties
>
> ...
>
>>> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
>>> the OOTF", although I find those diagrams somewhat confusing still. It
>>> does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
>>>
>>> Different documents use OOTF to refer to different things. Then there
>>> is also the fundamental difference between PQ and HLG systems, where
>>> OOTF is by definition in different places of the camera-transmission-display pipeline.
>>
>> Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
>> Will do some research to get my understanding in place. Thanks for all the inputs.
>
> I'm sure I was at least equally confused or even more at the start. I
> have just had a year of casual reading, discussions, and a W3C workshop
> attendance to improve my understanding. :-)
>
> Now I know enough to be dangerous.
>
> ...
>
>>>>>> +
>>>>>> +UAPI Name: PLANE_DEGAMMA_MODE
>>>>>> +Description: Enum property with values as blob_id's which
>>>>>> +advertizes
>>>>>> the
>>>>>
>>>>> Is enum with blob id values even a thing?
>>>>
>>>> Yeah we could have. This is a dynamic enum created with blobs. Each
>>>> entry contains the data structure to extract the full color
>>>> capabilities of the hardware. It’s a very interesting play with
>>>> blobs (@ville.syrjala@linux.intel.com brainchild)
>>>
>>> Yes, I think I can imagine how that works. The blobs are created
>>> immutable, unable to change once the plane has been advertised to
>>> userspace, because their IDs are used as enum values. But that is ok,
>>> because the blob describes capabilities that cannot change during the
>>> device's lifetime... or can they? What if you would want to extend the
>>> blob format, do you need a KMS client cap to change the format which
>>> would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
>>>
>>> This also relies on enums being identified by their string names,
>>> because the numerical value is not a constant but a blob ID and gets
>>> determined when the immutable blob is created.
>>>
>>> Did I understand correctly?
>>
>> Yes that’s right. We are not expecting these structures to change as
>> they represent the platforms capabilities.
>
> Until there comes a new platform whose capabilities you cannot quite
> describe with the existing structure. What's the plan to deal with that?
> A new enum value, like LUT2 instead of LUT? I suppose that works.
>
See my comment on the coverletter. It would be great if we could come
up with a PWL definition that's generic enough to work on all HW
that uses PWL and not require compositors to learn a new LUT2
type in the future.
>>
>>> As a userspace developer, I can totally work with that.
>>>
>>>>>> + possible degamma modes and lut ranges supported by the platform.
>>>>>> + This allows userspace to query and get the plane degamma color
>>>>>> + caps and choose the appropriate degamma mode and create lut values
>>>>>> + accordingly.
>>>>>
>>>>> I agree that some sort of "mode" switch is necessary, and
>>>>> advertisement of capabilities as well.
>>>>>
>>>>
>>>> This enum with blob id's is an interesting way to advertise segmented lut tables.
>>>>
>>>>>> +
>>>>>> +UAPI Name: PLANE_DEGAMMA_LUT
>>>>>> +Description: Blob property which allows a userspace to provide LUT values
>>>>>> + to apply degamma curve using the h/w plane degamma processing
>>>>>> + engine, thereby making the content as linear for further color
>>>>>> + processing. Userspace gets the size of LUT and precision etc
>>>>>> + from PLANE_DEGAMA_MODE_PROPERTY
>>>>>
>>>>> So all degamma modes will always be some kind of LUT? That may be
>>>>> a bit restrictive, as I understand AMD may have predefined or
>>>>> parameterised curves that are not LUTs. So there should be room
>>>>> for an arbitrary structure of parameters, which can be passed in
>>>>> as a blob id, and the contents defined by the degamma mode.
>>>>
>>>> For Intel's hardware these are luts but yeah AMD hardware seems to
>>>> have these as fixed function units. We should think of a way to have
>>>> this option as well in the UAPI. We could extend the DEGAMMA_MODE
>>>> property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
>>>> needed based on some of the attributes passed via DEGAMMA_MODE. This
>>>> can be
>>> one way to have room for both.
>>>> @harry.wentland@amd.com thoughts ?
>>>
>>> Yeah, though I don't think you can use DEGAMMA_MODE property to pass
>>> parameters to fixed-function curves. The parameters need another
>>> property. Would be natural to use the other property for LUT data when mode it set to LUT.
>>>
>>> A trivial and made-up example of a parameterised fixed-function curve
>>> is pow(x, gamma), where gamma is the parameter.
>>
It's a bit HW dependent. Some of AMD HW has some pre-defined EOTF
ROMs who allowing us to program a RAM LUT in the same block. Other
HW split those into two independent, consecutive blocks, a pre-defined
EOTF ROM first, followed by a Gamma Correction RAM LUT.
These can probably both be supported the the proposed PLANE_DEGAMMA_LUT
with enum values for the predefined (sRGB, BT2020, etc.) EOTFs, as
well as an option for a programmable LUT.
Harry
>> We can maybe have a parallel property as well with proper
>> documentation if this helps with flexibility for varying hardware
>> vendors. UAPI document will list what to use and when. May be
>> platform will not even list the other one which may make things less
>> complicated to userspace.
>
> I'm not sure I got what you're thinking. My idea is that the
> interpretation of the blob contents depends on the value of the mode
> enum. Obviously the two will always need to be set together by
> userspace to ensure they match, otherwise DRM needs to reject the
> commit.
>
>
> The rest of your comments I agree with.
>
>
> Thanks,
> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-26 15:11 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:11 UTC (permalink / raw)
To: Pekka Paalanen, Shankar, Uma
Cc: ville.syrjala, intel-gfx, dri-devel, brian.starkey, sebastian,
Shashank.Sharma, Cyr, Aric
Thanks, Uma, for the updated patches. I'm finally finding
time to go through them.
On 2021-10-15 03:42, Pekka Paalanen wrote:
> On Thu, 14 Oct 2021 19:44:25 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
>>> -----Original Message-----
>>> From: Pekka Paalanen <ppaalanen@gmail.com>
>>> Sent: Wednesday, October 13, 2021 2:01 PM
>>> To: Shankar, Uma <uma.shankar@intel.com>
>>> Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
>>> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>>> brian.starkey@arm.com; sebastian@sebastianwick.net;
>>> Shashank.Sharma@amd.com
>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>>
>>> On Tue, 12 Oct 2021 20:58:27 +0000
>>> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Pekka Paalanen <ppaalanen@gmail.com>
>>>>> Sent: Tuesday, October 12, 2021 4:01 PM
>>>>> To: Shankar, Uma <uma.shankar@intel.com>
>>>>> Cc: intel-gfx@lists.freedesktop.org;
>>>>> dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
>>>>> ville.syrjala@linux.intel.com; brian.starkey@arm.com;
>>>>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>>>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
>>>>> Pipeline
>>>>>
>>>>> On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
>>>>> <uma.shankar@intel.com> wrote:
>>>>>
>>>>>> This is a RFC proposal for plane color hardware blocks.
>>>>>> It exposes the property interface to userspace and calls out the
>>>>>> details or interfaces created and the intended purpose.
>>>>>>
>>>>>> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>>> ---
>>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst | 167
>>>>>> +++++++++++++++++++
>>>>>> 1 file changed, 167 insertions(+) create mode 100644
>>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>>
>>>>>> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>> b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>> new file mode 100644
>>>>>> index 000000000000..0d1ca858783b
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>> @@ -0,0 +1,167 @@
>>>>>> +==================================================
>>>>>> +Display Color Pipeline: Proposed DRM Properties
>
> ...
>
>>> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
>>> the OOTF", although I find those diagrams somewhat confusing still. It
>>> does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
>>>
>>> Different documents use OOTF to refer to different things. Then there
>>> is also the fundamental difference between PQ and HLG systems, where
>>> OOTF is by definition in different places of the camera-transmission-display pipeline.
>>
>> Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
>> Will do some research to get my understanding in place. Thanks for all the inputs.
>
> I'm sure I was at least equally confused or even more at the start. I
> have just had a year of casual reading, discussions, and a W3C workshop
> attendance to improve my understanding. :-)
>
> Now I know enough to be dangerous.
>
> ...
>
>>>>>> +
>>>>>> +UAPI Name: PLANE_DEGAMMA_MODE
>>>>>> +Description: Enum property with values as blob_id's which
>>>>>> +advertizes
>>>>>> the
>>>>>
>>>>> Is enum with blob id values even a thing?
>>>>
>>>> Yeah we could have. This is a dynamic enum created with blobs. Each
>>>> entry contains the data structure to extract the full color
>>>> capabilities of the hardware. It’s a very interesting play with
>>>> blobs (@ville.syrjala@linux.intel.com brainchild)
>>>
>>> Yes, I think I can imagine how that works. The blobs are created
>>> immutable, unable to change once the plane has been advertised to
>>> userspace, because their IDs are used as enum values. But that is ok,
>>> because the blob describes capabilities that cannot change during the
>>> device's lifetime... or can they? What if you would want to extend the
>>> blob format, do you need a KMS client cap to change the format which
>>> would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
>>>
>>> This also relies on enums being identified by their string names,
>>> because the numerical value is not a constant but a blob ID and gets
>>> determined when the immutable blob is created.
>>>
>>> Did I understand correctly?
>>
>> Yes that’s right. We are not expecting these structures to change as
>> they represent the platforms capabilities.
>
> Until there comes a new platform whose capabilities you cannot quite
> describe with the existing structure. What's the plan to deal with that?
> A new enum value, like LUT2 instead of LUT? I suppose that works.
>
See my comment on the coverletter. It would be great if we could come
up with a PWL definition that's generic enough to work on all HW
that uses PWL and not require compositors to learn a new LUT2
type in the future.
>>
>>> As a userspace developer, I can totally work with that.
>>>
>>>>>> + possible degamma modes and lut ranges supported by the platform.
>>>>>> + This allows userspace to query and get the plane degamma color
>>>>>> + caps and choose the appropriate degamma mode and create lut values
>>>>>> + accordingly.
>>>>>
>>>>> I agree that some sort of "mode" switch is necessary, and
>>>>> advertisement of capabilities as well.
>>>>>
>>>>
>>>> This enum with blob id's is an interesting way to advertise segmented lut tables.
>>>>
>>>>>> +
>>>>>> +UAPI Name: PLANE_DEGAMMA_LUT
>>>>>> +Description: Blob property which allows a userspace to provide LUT values
>>>>>> + to apply degamma curve using the h/w plane degamma processing
>>>>>> + engine, thereby making the content as linear for further color
>>>>>> + processing. Userspace gets the size of LUT and precision etc
>>>>>> + from PLANE_DEGAMA_MODE_PROPERTY
>>>>>
>>>>> So all degamma modes will always be some kind of LUT? That may be
>>>>> a bit restrictive, as I understand AMD may have predefined or
>>>>> parameterised curves that are not LUTs. So there should be room
>>>>> for an arbitrary structure of parameters, which can be passed in
>>>>> as a blob id, and the contents defined by the degamma mode.
>>>>
>>>> For Intel's hardware these are luts but yeah AMD hardware seems to
>>>> have these as fixed function units. We should think of a way to have
>>>> this option as well in the UAPI. We could extend the DEGAMMA_MODE
>>>> property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
>>>> needed based on some of the attributes passed via DEGAMMA_MODE. This
>>>> can be
>>> one way to have room for both.
>>>> @harry.wentland@amd.com thoughts ?
>>>
>>> Yeah, though I don't think you can use DEGAMMA_MODE property to pass
>>> parameters to fixed-function curves. The parameters need another
>>> property. Would be natural to use the other property for LUT data when mode it set to LUT.
>>>
>>> A trivial and made-up example of a parameterised fixed-function curve
>>> is pow(x, gamma), where gamma is the parameter.
>>
It's a bit HW dependent. Some of AMD HW has some pre-defined EOTF
ROMs who allowing us to program a RAM LUT in the same block. Other
HW split those into two independent, consecutive blocks, a pre-defined
EOTF ROM first, followed by a Gamma Correction RAM LUT.
These can probably both be supported the the proposed PLANE_DEGAMMA_LUT
with enum values for the predefined (sRGB, BT2020, etc.) EOTFs, as
well as an option for a programmable LUT.
Harry
>> We can maybe have a parallel property as well with proper
>> documentation if this helps with flexibility for varying hardware
>> vendors. UAPI document will list what to use and when. May be
>> platform will not even list the other one which may make things less
>> complicated to userspace.
>
> I'm not sure I got what you're thinking. My idea is that the
> interpretation of the blob contents depends on the value of the mode
> enum. Obviously the two will always need to be set together by
> userspace to ensure they match, otherwise DRM needs to reject the
> commit.
>
>
> The rest of your comments I agree with.
>
>
> Thanks,
> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-14 19:44 ` [Intel-gfx] " Shankar, Uma
@ 2021-10-26 15:36 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:36 UTC (permalink / raw)
To: Shankar, Uma, Pekka Paalanen
Cc: ville.syrjala, intel-gfx, dri-devel, brian.starkey, sebastian,
Shashank.Sharma
On 2021-10-14 15:44, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Pekka Paalanen <ppaalanen@gmail.com>
>> Sent: Wednesday, October 13, 2021 2:01 PM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
>> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> brian.starkey@arm.com; sebastian@sebastianwick.net;
>> Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue, 12 Oct 2021 20:58:27 +0000
>> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>>
>>>> -----Original Message-----
>>>> From: Pekka Paalanen <ppaalanen@gmail.com>
>>>> Sent: Tuesday, October 12, 2021 4:01 PM
>>>> To: Shankar, Uma <uma.shankar@intel.com>
>>>> Cc: intel-gfx@lists.freedesktop.org;
>>>> dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
>>>> ville.syrjala@linux.intel.com; brian.starkey@arm.com;
>>>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
>>>> Pipeline
>>>>
>>>> On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
>>>> <uma.shankar@intel.com> wrote:
>>>>
>>>>> This is a RFC proposal for plane color hardware blocks.
>>>>> It exposes the property interface to userspace and calls out the
>>>>> details or interfaces created and the intended purpose.
>>>>>
>>>>> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst | 167
>>>>> +++++++++++++++++++
>>>>> 1 file changed, 167 insertions(+) create mode 100644
>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>
>>>>> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>> b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>> new file mode 100644
>>>>> index 000000000000..0d1ca858783b
>>>>> --- /dev/null
>>>>> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>> @@ -0,0 +1,167 @@
>>>>> +==================================================
>>>>> +Display Color Pipeline: Proposed DRM Properties
>>
>> ...
>>
>>>>> +Proposal is to have below properties for a plane:
>>>>> +
>>>>> +* Plane Degamma or Pre-Curve:
>>>>> + * This will be used to linearize the input framebuffer data.
>>>>> + * It will apply the reverse of the color transfer function.
>>>>> + * It can be a degamma curve or OETF for HDR.
>>>>
>>>> As you want to produce light-linear values, you use EOTF or inverse OETF.
>>>>
>>>> The term OETF has a built-in assumption that that happens in a camera:
>>>> it takes in light and produces and electrical signal. Lately I
>>>> have personally started talking about non-linear encoding of color
>>>> values, since EOTF is often associated with displays if nothing
>>>> else is said (taking
>> in an electrical signal and producing light).
>>>>
>>>> So this would be decoding the color values into light-linear color
>>>> values. That is what an EOTF does, yes, but I feel there is a
>>>> nuanced difference. A piece of equipment implements an EOTF by
>>>> turning an electrical signal into light, hence EOTF often refers
>>>> to specific equipment. You could talk about content EOTF to denote
>>>> content value encoding, as opposed to output or display EOTF, but
>>>> that might be confusing if you look at e.g. the diagrams in
>>>> BT.2100: is it the EOTF
>> or is it the inverse OETF? Is the (inverse?) OOTF included?
>>>>
>>>> So I try to side-step those questions by talking about encoding.
>>>
>>> The idea here is that frame buffer presented to display plane engine
>>> will be non-
>> linear.
>>> So output of a media decode should result in content with EOTF applied.
>>
>> Hi,
>>
>> sure, but the question is: which EOTF. There can be many different
>> things called "EOTF" in a single pipeline, and then it's up to the
>> document writer to make the difference between them. Comparing two
>> documents with different conventions causes a lot of confusion in my
>> personal experience, so it is good to define the concepts more carefully.
>
> Hi Pekka,
> I think you have given some nice inputs to really deep dive and document here.
> Will update this with the right expectations wrt what transfer functions to be used at various stages in the operation pipeline.
>
>>> So output of a media decode should result in content with EOTF applied.
>>
>> I suspect you have it backwards. Media decode produces electrical
>> (non-linear) pixel color values. If EOTF was applied, they would be
>> linear instead (and require more memory to achieve the same visual precision).
>>
>> If you want to put it this way, you could say "with inverse EOTF
>> applied", but that might be slightly confusing because it is already
>> baked in to the video, it's not something a media decoder has to
>> specifically apply, I think. However, the (inverse) EOTF in this case is the content EOTF, not the display EOTF.
>>
>> If content and display EOTF differ, then one must apply first content
>> EOTF and then inverse display EOTF to get values that are correctly
>> encoded for the display. (This is necessary but not sufficient in
>> general.) Mind, that this is not an OOTF nor an artistic adjustment,
>> this is purely a value encoding conversion.
>>
> 0
>
> Got it, thanks for correcting. Will also do some more study around this and update.
>
>>> Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
>>
>> Does "rendering intent gamma" refer to artistic adjustments, not OOTF?
>> ]
>
> This ideally should be OOTF adjustments here.
>
>> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
>> the OOTF", although I find those diagrams somewhat confusing still. It
>> does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
>>
>> Different documents use OOTF to refer to different things. Then there
>> is also the fundamental difference between PQ and HLG systems, where
>> OOTF is by definition in different places of the camera-transmission-display pipeline.
>
> Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
> Will do some research to get my understanding in place. Thanks for all the inputs.
>
>>>
>>> To make it linear, we should apply the OETF. Confusion is whether
>>> OETF is equivalent to inverse EOTF, we could check this one out to confirm.
>>
>> OETF does not make anything linear. By definition, OETF converts
>> optical (linear) values into electrical (practically always non-linearly encoded) values.
>>
>> Yes, EOTF is almost always not equal to inverse OETF because of the
>> existence of OOTF. The applies to inverse EOTF vs. OETF as well.
>>
>> From what I have learned, it is unexpected to assume that inverse of
>> one is the other. That will cause confusion. Therefore, if you mean
>> the inverse, spell it out as inverse. I used to make this same
>> mistake, and some of it may still be left in https://gitlab.freedesktop.org/pq/color-and-hdr .
>
> Got it.
>
>>>
>>> Here since the values for the pre-curve (or degamma as we have
>>> called it in past), accepts programmable lut values which makes it
>>> flexible enough to
>> accommodate any values.
>>> This will hold for HDR as well as traditional gamma encoded SRGB data as well.
>>
>> Yes.
>>
>>>>> + * This linear data can be further acted on by the following
>>>>> + * color hardware blocks in the display hardware pipeline
>>>>
>>>> I think this and the above description ties the intended use down
>>>> too much. This is one possible way to use degamma, yes, but there
>>>> may be others. Particularly if CTM can be replaced with a 3D LUT,
>>>> then the degamma is more likely a shaper (non-linear adjustment to
>>>> 3D LUT tap
>> positions).
>>>
>>> Yeah agree, this is just one of the usecases. Its just a lut table
>>> which can be used for other purposes as well and is not just limited
>>> to a
>> linearization operation. I will update this.
>>>
>>>> I would prefer the name pre-curve to underline that this can be
>>>> whatever one wants it to be, but I understand that people may be
>>>> more familiar
>> with the name degamma.
>>>
>>> I feel pre-curve should be fine but yeah it deviates from naming of
>>> legacy crtc/pipe
>> color properties.
>>> May be we can stay with legacy naming with more documentation to
>>> have its
>> usecases clearly called out.
>>
>> That is fine by me.
>>
>>>>> +
>>>>> +UAPI Name: PLANE_DEGAMMA_MODE
>>>>> +Description: Enum property with values as blob_id's which
>>>>> +advertizes
>>>>> the
>>>>
>>>> Is enum with blob id values even a thing?
>>>
>>> Yeah we could have. This is a dynamic enum created with blobs. Each
>>> entry contains the data structure to extract the full color
>>> capabilities of the hardware. It’s a very interesting play with
>>> blobs (@ville.syrjala@linux.intel.com brainchild)
>>
>> Yes, I think I can imagine how that works. The blobs are created
>> immutable, unable to change once the plane has been advertised to
>> userspace, because their IDs are used as enum values. But that is ok,
>> because the blob describes capabilities that cannot change during the
>> device's lifetime... or can they? What if you would want to extend the
>> blob format, do you need a KMS client cap to change the format which
>> would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
>>
>> This also relies on enums being identified by their string names,
>> because the numerical value is not a constant but a blob ID and gets
>> determined when the immutable blob is created.
>>
>> Did I understand correctly?
>
> Yes that’s right. We are not expecting these structures to change as they represent the platforms capabilities.
>
>> As a userspace developer, I can totally work with that.
>>
>>>>> + possible degamma modes and lut ranges supported by the platform.
>>>>> + This allows userspace to query and get the plane degamma color
>>>>> + caps and choose the appropriate degamma mode and create lut values
>>>>> + accordingly.
>>>>
>>>> I agree that some sort of "mode" switch is necessary, and
>>>> advertisement of capabilities as well.
>>>>
>>>
>>> This enum with blob id's is an interesting way to advertise segmented lut tables.
>>>
>>>>> +
>>>>> +UAPI Name: PLANE_DEGAMMA_LUT
>>>>> +Description: Blob property which allows a userspace to provide LUT values
>>>>> + to apply degamma curve using the h/w plane degamma processing
>>>>> + engine, thereby making the content as linear for further color
>>>>> + processing. Userspace gets the size of LUT and precision etc
>>>>> + from PLANE_DEGAMA_MODE_PROPERTY
>>>>
>>>> So all degamma modes will always be some kind of LUT? That may be
>>>> a bit restrictive, as I understand AMD may have predefined or
>>>> parameterised curves that are not LUTs. So there should be room
>>>> for an arbitrary structure of parameters, which can be passed in
>>>> as a blob id, and the contents defined by the degamma mode.
>>>
>>> For Intel's hardware these are luts but yeah AMD hardware seems to
>>> have these as fixed function units. We should think of a way to have
>>> this option as well in the UAPI. We could extend the DEGAMMA_MODE
>>> property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
>>> needed based on some of the attributes passed via DEGAMMA_MODE. This
>>> can be
>> one way to have room for both.
>>> @harry.wentland@amd.com thoughts ?
>>
>> Yeah, though I don't think you can use DEGAMMA_MODE property to pass
>> parameters to fixed-function curves. The parameters need another
>> property. Would be natural to use the other property for LUT data when mode it set to LUT.
>>
>> A trivial and made-up example of a parameterised fixed-function curve
>> is pow(x, gamma), where gamma is the parameter.
>
> We can maybe have a parallel property as well with proper documentation if this helps with flexibility for varying hardware vendors. UAPI document will list what to use and when.
> May be platform will not even list the other one which may make things less complicated to userspace.
>
>>>>
>>>> LUT size, precision, and other details of each degamma mode would
>>>> be good to expose somehow. I kind of expected those would have
>>>> been exposed through the above mentioned "enum with blob id
>>>> values" where each blob content structure is defined by the respective enum value.
>>>
>>> Yes, you are spot on here.
>>>
>>>>> +
>>>>> +* Plane CTM
>>>>> + * This is a Property to program the color transformation matrix.
>>>>
>>>> No mode property here? Is there any hardware with something else
>>>> than a matrix at this point?
>>>
>>> Not that I am aware of.
>>>
>>>> Should we assume there will be hardware with something else, and
>>>> have a CSC mode property with only a single enum value defined so far:
>>>> "matrix"? Or do we say PLANE_CTM is a matrix and if you have
>>>> something else in hardware, then invent a new property for it?
>>>
>>> I think this should be good as we have this for crtc with no one complaining.
>>> There may be hardware with fixed function operation for the CSC but
>>> then its not a matrix and it would be pretty hardware dependent, so
>>> we can leave that from a generic UAPI.
>>
>> Ok. And if that eventually turns out to be a mistake, it's easy to
>> invent more properties.
>
> I feel that is what would be required. This is just another instance of what we have at crtc level.
>
Would a userspace client ever want to use both CTM and 3D LUT?
We could add a mode property to CTM to allow for a CTM or 3D LUT or
we could add new properties for 3D LUT support.
3D LUT might come with shaper 1D LUTs that can be programmed in
conjunction with the 3D LUT. 3D LUTs operating in non-linear
space require less precision than 3D LUTs operating in linear
space, hence the 1D LUT can be used to non-linearize the
pixel data for 3D LUT operation.
FWIW, AMD HW (depending on generation) can do these operations
(in this order):
1) 1D LUT (fixed or PWL programmable)
2) simple multiplier (for scaling SDR content to HDR output)
3) CTM matrix
4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
5) 3D LUT
6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
7) blending
8) CTM matrix
9) 1D LUT (shaper LUT like above)
10) 3D LUT
11) 1D LUT (generally for EOTF^-1 for display EOTF)
Not all blocks are available on all (current and future) HW.
I sketched a few diagrams that show how these might be used by
a compositor if we exposed all of these blocks and should
really try to add some of them to the color-and-hdr docs
repo.
>>>>> + * This can be used to perform a color space conversion like
>>>>> + * BT2020 to BT709 or BT601 etc.
>>>>> + * This block is generally kept after the degamma unit so that
>>>>
>>>> Not "generally". If blocks can change places, then it becomes
>>>> intractable for generic userspace to program.
>>>
>>> Sure, will drop this wording here. But one open will still remain
>>> for userspace, as to how it gets the pipeline dynamically for a respective hardware.
>>> Currently we have assumed that this would be the logical fixed order
>>> of hardware units.
>>
>> If we cannot model the abstract KMS pipeline as a fixed order of units
>> (where each unit may exist or not), we need to take a few steps back
>> here and look at what do we actually want to expose. That is a much
>> bigger design problem which we are currently not even considering.
>
> I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
I think the color pipeline should be modeled in a way that makes
sense from a color science standpoint and in a way that makes sense
for compositor implementations. Fortunately HW design generally
aligns with these intentions but we should be careful to not
let HW design dictate KMS interfaces.
Harry
>
>>>>> + * linear data can be fed to it for conversion.
>>>>> +
>>>>> +UAPI Name: PLANE_CTM
>>>>> +Description: Blob property which allows a userspace to provide
>>>>> +CTM
>> coefficients
>>>>> + to do color space conversion or any other enhancement by doing a
>>>>> + matrix multiplication using the h/w CTM processing engine
>>>>> +
>>>>
>>>> Speaking of color space conversions, we should probably define
>>>> what happens to out-of-range color values. Converting color into
>>>> smaller gamut or smaller dynamic range always has the risk of
>>>> ending up with out-of-range values. I suppose those get simply
>>>> clipped independently on each
>> color channel, right?
>>>
>>> We have standard matrix to convert colorspaces. This is just the
>>> property of the colorspace, I guess clipping will be the only option
>>> here (irrespective of hardware)
>>>
>>>> Such clipping can change hue, so userspace would be better avoid
>>>> triggering clipping at all, but we still need to know what would
>>>> happen with out-
>> of-range values.
>>>>
>>>> We would also need to know when clipping will happen. If FP16
>>>> (half-float) FB produces out-of-range values and degamma stage is
>>>> not used, will the CTM see original or clipped values? Or is that
>>>> something we have to define as hardware-specific?
>>>>
>>>> Generic userspace will try hard to avoid triggering
>>>> hardware-specific behaviour, so you can expect such behaviour to go unused.
>>>
>>> Here hardware should just operate on the matrix values programmed.
>>> This should be the limitation of the color space conversion
>>> operation and hardware may not have any role to play apart from just
>>> honoring the matrix values and producing the resultant output.
>>
>> I'm not talking about the matrix values. I'm talking about the values
>> originating from the FB, are they clipped or not, before being processed by the matrix?
>>
>> Userspace could want to use the matrix to bring out-of-range FB values
>> into range, but that plan cannot work if the FB values get clipped already before the matrix.
>>
>> I referred to FP16 format explicitly because that format can express
>> values outside of the usual [0.0, 1.0] range in a framebuffer.
>>
>> Of course, the matrix values themselves have some limits too, and
>> userspace should somehow be aware of them.
>
> AFAIK, the values will not be clipped before being submitted to CSC blocks.
> But this can be confirmed to not leave any misconception here.
>
>>>
>>>>> +* Plane Gamma or Post-Curve
>>>>> + * This can be used to perform 2 operations:
>>>>> + * non-lineralize the framebuffer data. Can be used for
>>>>> + * non linear blending. It can be a gamma curve or EOTF
>>>>> + * for HDR.
>>>>> + * Perform Tone Mapping operation. This is an operation
>>>>> + * done when blending is done with HDR and SDR content.
>>>>
>>>> I like this wording better than the wording for pre-curve: "can",
>>>> not "will". It leaves room for creative use of this processing block.
>>>
>>> Ok thanks, will update pre-curve section as well.
>>>
>>>>
>>>> Tone-mapping is needed always when dynamic range differs, so also
>>>> for HDR to HDR, not just SDR to/from HDR.
>>>
>>> Yes correct, will update.
>>>
>>>>> +
>>>>> +UAPI Name: PLANE_GAMMA_MODE
>>>>> +Description: Enum property with values as blob_id's which advertizes the
>>>>> + possible gamma modes and lut ranges supported by the platform.
>>>>> + This allows userspace to query and get the plane gamma color
>>>>> + caps and choose the appropriate gamma mode and create lut values
>>>>> + accordingly.
>>>>> +
>>>>> +UAPI Name: PLANE_GAMMA_LUT
>>>>> +Description: Blob property which allows a userspace to provide LUT values
>>>>> + to apply gamma curve or perform tone mapping using the h/w plane
>>>>> + gamma processing engine, thereby making the content as linear
>>>>> + for further color processing. Userspace gets the size of LUT and
>>>>> + precision etc from PLANE_GAMA_MODE_PROPERTY
>>>>
>>>> The same comments here as with DEGAMMA.
>>>
>>> Noted.
>>>
>>>>> +
>>>>> +This is part of one plane engine. Data from multiple planes
>>>>> +will be then fed to pipe where it will get blended. There is a
>>>>> +similar set of properties available at crtc level which acts on this blended data.
>>>>> +
>>>>> +Below is a sample usecase:
>>>>> +
>>>>> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
>>>> ┌─────────────┐
>>>>> + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
>>>>> + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR
>> │
>>>>> + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
>>>> Mapping├────────┐
>>>>> + └────────────┘ └─────────────┘ └─────────────┘
>>>> └─────────────┘ │
>>>>> + │
>>>>> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
>>>> ┌─────────────┐ │
>>>>> + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
>> │
>>>>> + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
>>>> ├─────┐ │
>>>>> + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │
>> │
>>>>> + └────────────┘ └─────────────┘ └─────────────┘
>>>> └─────────────┘ │ │
>>>>> + │ │
>>>>> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
>>>> ┌─────────────┐ │ │
>>>>> + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
>> │
>>>>> + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
>>>> in├───┐ │ │
>>>>> + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
>>>>> + └────────────┘ └─────────────┘ └─────────────┘
>>>> └─────────────┘ │ │ │
>>>>
>>>> EOTF, not OETF, since it is converting E to O, electrical to optical.
>>>
>>> I think media decode would have given a EOTF applied data to be
>>> directly consumed by display sink (in case we have chosen a display pass through).
>> Not sure here though, it’s a bit confusing.
>>
>> I hope I managed to explain this earlier in this email.
>>
>> Display sinks "always" use non-linearly encoded values, because it
>> saves bandwidth without losing visual quality. For the same reason,
>> images tend to be stored with non-linear value encoding whenever possible.
>
> Yeah, thanks for the explanation and useful pointers. Will work on it to put the right expectations in the document.
>
> Thanks Pekka for the valuable feedback.
>
> Regards,
> Uma Shankar
>>
>> Thanks,
>> pq
>>
>>>>> +
>>>>> + │ │ │
>>>>> +
>>>>> + │ │ │
>>>>> +
>>>>> +│ │ │
>>>>>
>>>>
>> +┌──────────────────────────────────────────────────────────────────
>>>> ──
>>>>> +───────────┴─┴──┘
>>>>> +│
>>>>> +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
>>>>> +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
>>>>> +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone
>>>>> +├─────►
>>>> TO Port
>>>>> + │ data linear │ │ Color Space │ │ Mapping/apply │
>>>>> + │ after blend │ │ Conversion │ │ transfer func │
>>>>> + └─────────────┘ └─────────────┘ └───────────────┘
>>>>
>>>> Blending does not change whether the data is linear or not. I
>>>> suppose in this example, CRTC degamma and CTM would be
>>>> passthrough, and gamma would be the inverse display EOTF for
>>>> encoding color values into
>> what the monitor expects.
>>>
>>> Yeah, will update this to make it clear.
>>>
>>>>> +
>>>>> +
>>>>> +This patch series adds properties for plane color features. It
>>>>> +adds properties for degamma used to linearize data and CSC used
>>>>> +for gamut conversion. It also includes Gamma support used to
>>>>> +again non-linearize data as per panel supported color space.
>>>>> +These can be utilize by user space to convert planes from one
>>>>> +format to another, one color space to another etc.
>>>>
>>>> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
>>>
>>> This is great to hear that we are aligned wrt how the pipeline should work.
>>>
>>> Thanks Pekka for taking time out and providing the feedback.
>>>
>>> @harry.wentland@amd.com We can work together and build our design to
>>> accommodate both Intel and AMD's hardware needs. This will also make
>>> things generic enough for any other hardware vendor as well.
>>>
>>> Thanks & Regards,
>>> Uma Shankar
>>>
>>>>> +
>>>>> +Userspace can take smart blending decisions and utilize these
>>>>> +hardware supported plane color features to get accurate color
>>>>> +profile. The same can help in consistent color quality from
>>>>> +source to panel taking advantage of advanced color features in hardware.
>>>>> +
>>>>> +These patches add the property interfaces and enable helper functions.
>>>>> +This series adds Intel's XE_LPD hw specific plane gamma feature.
>>>>> +We can build up and add other platform/hardware specific
>>>>> +implementation on top of this series.
>>>>> +
>>>>> +Credits: Special mention and credits to Ville Syrjala for
>>>>> +coming up with a design for this feature and inputs. This
>>>>> +series is based on his original design and idea.
>>>>
>>>>
>>>> Thanks,
>>>> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-26 15:36 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:36 UTC (permalink / raw)
To: Shankar, Uma, Pekka Paalanen
Cc: ville.syrjala, intel-gfx, dri-devel, brian.starkey, sebastian,
Shashank.Sharma
On 2021-10-14 15:44, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Pekka Paalanen <ppaalanen@gmail.com>
>> Sent: Wednesday, October 13, 2021 2:01 PM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: harry.wentland@amd.com; ville.syrjala@linux.intel.com; intel-
>> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> brian.starkey@arm.com; sebastian@sebastianwick.net;
>> Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue, 12 Oct 2021 20:58:27 +0000
>> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>>
>>>> -----Original Message-----
>>>> From: Pekka Paalanen <ppaalanen@gmail.com>
>>>> Sent: Tuesday, October 12, 2021 4:01 PM
>>>> To: Shankar, Uma <uma.shankar@intel.com>
>>>> Cc: intel-gfx@lists.freedesktop.org;
>>>> dri-devel@lists.freedesktop.org; harry.wentland@amd.com;
>>>> ville.syrjala@linux.intel.com; brian.starkey@arm.com;
>>>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware
>>>> Pipeline
>>>>
>>>> On Tue, 7 Sep 2021 03:08:43 +0530 Uma Shankar
>>>> <uma.shankar@intel.com> wrote:
>>>>
>>>>> This is a RFC proposal for plane color hardware blocks.
>>>>> It exposes the property interface to userspace and calls out the
>>>>> details or interfaces created and the intended purpose.
>>>>>
>>>>> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst | 167
>>>>> +++++++++++++++++++
>>>>> 1 file changed, 167 insertions(+) create mode 100644
>>>>> Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>>
>>>>> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>> b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>> new file mode 100644
>>>>> index 000000000000..0d1ca858783b
>>>>> --- /dev/null
>>>>> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
>>>>> @@ -0,0 +1,167 @@
>>>>> +==================================================
>>>>> +Display Color Pipeline: Proposed DRM Properties
>>
>> ...
>>
>>>>> +Proposal is to have below properties for a plane:
>>>>> +
>>>>> +* Plane Degamma or Pre-Curve:
>>>>> + * This will be used to linearize the input framebuffer data.
>>>>> + * It will apply the reverse of the color transfer function.
>>>>> + * It can be a degamma curve or OETF for HDR.
>>>>
>>>> As you want to produce light-linear values, you use EOTF or inverse OETF.
>>>>
>>>> The term OETF has a built-in assumption that that happens in a camera:
>>>> it takes in light and produces and electrical signal. Lately I
>>>> have personally started talking about non-linear encoding of color
>>>> values, since EOTF is often associated with displays if nothing
>>>> else is said (taking
>> in an electrical signal and producing light).
>>>>
>>>> So this would be decoding the color values into light-linear color
>>>> values. That is what an EOTF does, yes, but I feel there is a
>>>> nuanced difference. A piece of equipment implements an EOTF by
>>>> turning an electrical signal into light, hence EOTF often refers
>>>> to specific equipment. You could talk about content EOTF to denote
>>>> content value encoding, as opposed to output or display EOTF, but
>>>> that might be confusing if you look at e.g. the diagrams in
>>>> BT.2100: is it the EOTF
>> or is it the inverse OETF? Is the (inverse?) OOTF included?
>>>>
>>>> So I try to side-step those questions by talking about encoding.
>>>
>>> The idea here is that frame buffer presented to display plane engine
>>> will be non-
>> linear.
>>> So output of a media decode should result in content with EOTF applied.
>>
>> Hi,
>>
>> sure, but the question is: which EOTF. There can be many different
>> things called "EOTF" in a single pipeline, and then it's up to the
>> document writer to make the difference between them. Comparing two
>> documents with different conventions causes a lot of confusion in my
>> personal experience, so it is good to define the concepts more carefully.
>
> Hi Pekka,
> I think you have given some nice inputs to really deep dive and document here.
> Will update this with the right expectations wrt what transfer functions to be used at various stages in the operation pipeline.
>
>>> So output of a media decode should result in content with EOTF applied.
>>
>> I suspect you have it backwards. Media decode produces electrical
>> (non-linear) pixel color values. If EOTF was applied, they would be
>> linear instead (and require more memory to achieve the same visual precision).
>>
>> If you want to put it this way, you could say "with inverse EOTF
>> applied", but that might be slightly confusing because it is already
>> baked in to the video, it's not something a media decoder has to
>> specifically apply, I think. However, the (inverse) EOTF in this case is the content EOTF, not the display EOTF.
>>
>> If content and display EOTF differ, then one must apply first content
>> EOTF and then inverse display EOTF to get values that are correctly
>> encoded for the display. (This is necessary but not sufficient in
>> general.) Mind, that this is not an OOTF nor an artistic adjustment,
>> this is purely a value encoding conversion.
>>
> 0
>
> Got it, thanks for correcting. Will also do some more study around this and update.
>
>>> Playback transfer function (EOTF): inverse OETF plus rendering intent gamma.
>>
>> Does "rendering intent gamma" refer to artistic adjustments, not OOTF?
>> ]
>
> This ideally should be OOTF adjustments here.
>
>> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and
>> the OOTF", although I find those diagrams somewhat confusing still. It
>> does not seem to clearly account for transmission non-linear encoding being different from the display EOTF.
>>
>> Different documents use OOTF to refer to different things. Then there
>> is also the fundamental difference between PQ and HLG systems, where
>> OOTF is by definition in different places of the camera-transmission-display pipeline.
>
> Agree this is a bit confusing, I admit I was much more confused than what you were for sure.
> Will do some research to get my understanding in place. Thanks for all the inputs.
>
>>>
>>> To make it linear, we should apply the OETF. Confusion is whether
>>> OETF is equivalent to inverse EOTF, we could check this one out to confirm.
>>
>> OETF does not make anything linear. By definition, OETF converts
>> optical (linear) values into electrical (practically always non-linearly encoded) values.
>>
>> Yes, EOTF is almost always not equal to inverse OETF because of the
>> existence of OOTF. The applies to inverse EOTF vs. OETF as well.
>>
>> From what I have learned, it is unexpected to assume that inverse of
>> one is the other. That will cause confusion. Therefore, if you mean
>> the inverse, spell it out as inverse. I used to make this same
>> mistake, and some of it may still be left in https://gitlab.freedesktop.org/pq/color-and-hdr .
>
> Got it.
>
>>>
>>> Here since the values for the pre-curve (or degamma as we have
>>> called it in past), accepts programmable lut values which makes it
>>> flexible enough to
>> accommodate any values.
>>> This will hold for HDR as well as traditional gamma encoded SRGB data as well.
>>
>> Yes.
>>
>>>>> + * This linear data can be further acted on by the following
>>>>> + * color hardware blocks in the display hardware pipeline
>>>>
>>>> I think this and the above description ties the intended use down
>>>> too much. This is one possible way to use degamma, yes, but there
>>>> may be others. Particularly if CTM can be replaced with a 3D LUT,
>>>> then the degamma is more likely a shaper (non-linear adjustment to
>>>> 3D LUT tap
>> positions).
>>>
>>> Yeah agree, this is just one of the usecases. Its just a lut table
>>> which can be used for other purposes as well and is not just limited
>>> to a
>> linearization operation. I will update this.
>>>
>>>> I would prefer the name pre-curve to underline that this can be
>>>> whatever one wants it to be, but I understand that people may be
>>>> more familiar
>> with the name degamma.
>>>
>>> I feel pre-curve should be fine but yeah it deviates from naming of
>>> legacy crtc/pipe
>> color properties.
>>> May be we can stay with legacy naming with more documentation to
>>> have its
>> usecases clearly called out.
>>
>> That is fine by me.
>>
>>>>> +
>>>>> +UAPI Name: PLANE_DEGAMMA_MODE
>>>>> +Description: Enum property with values as blob_id's which
>>>>> +advertizes
>>>>> the
>>>>
>>>> Is enum with blob id values even a thing?
>>>
>>> Yeah we could have. This is a dynamic enum created with blobs. Each
>>> entry contains the data structure to extract the full color
>>> capabilities of the hardware. It’s a very interesting play with
>>> blobs (@ville.syrjala@linux.intel.com brainchild)
>>
>> Yes, I think I can imagine how that works. The blobs are created
>> immutable, unable to change once the plane has been advertised to
>> userspace, because their IDs are used as enum values. But that is ok,
>> because the blob describes capabilities that cannot change during the
>> device's lifetime... or can they? What if you would want to extend the
>> blob format, do you need a KMS client cap to change the format which
>> would be impossible because you can't change an enum definition after it has been installed so you cannot swap the blob to a new one?
>>
>> This also relies on enums being identified by their string names,
>> because the numerical value is not a constant but a blob ID and gets
>> determined when the immutable blob is created.
>>
>> Did I understand correctly?
>
> Yes that’s right. We are not expecting these structures to change as they represent the platforms capabilities.
>
>> As a userspace developer, I can totally work with that.
>>
>>>>> + possible degamma modes and lut ranges supported by the platform.
>>>>> + This allows userspace to query and get the plane degamma color
>>>>> + caps and choose the appropriate degamma mode and create lut values
>>>>> + accordingly.
>>>>
>>>> I agree that some sort of "mode" switch is necessary, and
>>>> advertisement of capabilities as well.
>>>>
>>>
>>> This enum with blob id's is an interesting way to advertise segmented lut tables.
>>>
>>>>> +
>>>>> +UAPI Name: PLANE_DEGAMMA_LUT
>>>>> +Description: Blob property which allows a userspace to provide LUT values
>>>>> + to apply degamma curve using the h/w plane degamma processing
>>>>> + engine, thereby making the content as linear for further color
>>>>> + processing. Userspace gets the size of LUT and precision etc
>>>>> + from PLANE_DEGAMA_MODE_PROPERTY
>>>>
>>>> So all degamma modes will always be some kind of LUT? That may be
>>>> a bit restrictive, as I understand AMD may have predefined or
>>>> parameterised curves that are not LUTs. So there should be room
>>>> for an arbitrary structure of parameters, which can be passed in
>>>> as a blob id, and the contents defined by the degamma mode.
>>>
>>> For Intel's hardware these are luts but yeah AMD hardware seems to
>>> have these as fixed function units. We should think of a way to have
>>> this option as well in the UAPI. We could extend the DEGAMMA_MODE
>>> property to have all the info, and DEGAMMA_LUT_PROPERTY may not be
>>> needed based on some of the attributes passed via DEGAMMA_MODE. This
>>> can be
>> one way to have room for both.
>>> @harry.wentland@amd.com thoughts ?
>>
>> Yeah, though I don't think you can use DEGAMMA_MODE property to pass
>> parameters to fixed-function curves. The parameters need another
>> property. Would be natural to use the other property for LUT data when mode it set to LUT.
>>
>> A trivial and made-up example of a parameterised fixed-function curve
>> is pow(x, gamma), where gamma is the parameter.
>
> We can maybe have a parallel property as well with proper documentation if this helps with flexibility for varying hardware vendors. UAPI document will list what to use and when.
> May be platform will not even list the other one which may make things less complicated to userspace.
>
>>>>
>>>> LUT size, precision, and other details of each degamma mode would
>>>> be good to expose somehow. I kind of expected those would have
>>>> been exposed through the above mentioned "enum with blob id
>>>> values" where each blob content structure is defined by the respective enum value.
>>>
>>> Yes, you are spot on here.
>>>
>>>>> +
>>>>> +* Plane CTM
>>>>> + * This is a Property to program the color transformation matrix.
>>>>
>>>> No mode property here? Is there any hardware with something else
>>>> than a matrix at this point?
>>>
>>> Not that I am aware of.
>>>
>>>> Should we assume there will be hardware with something else, and
>>>> have a CSC mode property with only a single enum value defined so far:
>>>> "matrix"? Or do we say PLANE_CTM is a matrix and if you have
>>>> something else in hardware, then invent a new property for it?
>>>
>>> I think this should be good as we have this for crtc with no one complaining.
>>> There may be hardware with fixed function operation for the CSC but
>>> then its not a matrix and it would be pretty hardware dependent, so
>>> we can leave that from a generic UAPI.
>>
>> Ok. And if that eventually turns out to be a mistake, it's easy to
>> invent more properties.
>
> I feel that is what would be required. This is just another instance of what we have at crtc level.
>
Would a userspace client ever want to use both CTM and 3D LUT?
We could add a mode property to CTM to allow for a CTM or 3D LUT or
we could add new properties for 3D LUT support.
3D LUT might come with shaper 1D LUTs that can be programmed in
conjunction with the 3D LUT. 3D LUTs operating in non-linear
space require less precision than 3D LUTs operating in linear
space, hence the 1D LUT can be used to non-linearize the
pixel data for 3D LUT operation.
FWIW, AMD HW (depending on generation) can do these operations
(in this order):
1) 1D LUT (fixed or PWL programmable)
2) simple multiplier (for scaling SDR content to HDR output)
3) CTM matrix
4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
5) 3D LUT
6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
7) blending
8) CTM matrix
9) 1D LUT (shaper LUT like above)
10) 3D LUT
11) 1D LUT (generally for EOTF^-1 for display EOTF)
Not all blocks are available on all (current and future) HW.
I sketched a few diagrams that show how these might be used by
a compositor if we exposed all of these blocks and should
really try to add some of them to the color-and-hdr docs
repo.
>>>>> + * This can be used to perform a color space conversion like
>>>>> + * BT2020 to BT709 or BT601 etc.
>>>>> + * This block is generally kept after the degamma unit so that
>>>>
>>>> Not "generally". If blocks can change places, then it becomes
>>>> intractable for generic userspace to program.
>>>
>>> Sure, will drop this wording here. But one open will still remain
>>> for userspace, as to how it gets the pipeline dynamically for a respective hardware.
>>> Currently we have assumed that this would be the logical fixed order
>>> of hardware units.
>>
>> If we cannot model the abstract KMS pipeline as a fixed order of units
>> (where each unit may exist or not), we need to take a few steps back
>> here and look at what do we actually want to expose. That is a much
>> bigger design problem which we are currently not even considering.
>
> I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
I think the color pipeline should be modeled in a way that makes
sense from a color science standpoint and in a way that makes sense
for compositor implementations. Fortunately HW design generally
aligns with these intentions but we should be careful to not
let HW design dictate KMS interfaces.
Harry
>
>>>>> + * linear data can be fed to it for conversion.
>>>>> +
>>>>> +UAPI Name: PLANE_CTM
>>>>> +Description: Blob property which allows a userspace to provide
>>>>> +CTM
>> coefficients
>>>>> + to do color space conversion or any other enhancement by doing a
>>>>> + matrix multiplication using the h/w CTM processing engine
>>>>> +
>>>>
>>>> Speaking of color space conversions, we should probably define
>>>> what happens to out-of-range color values. Converting color into
>>>> smaller gamut or smaller dynamic range always has the risk of
>>>> ending up with out-of-range values. I suppose those get simply
>>>> clipped independently on each
>> color channel, right?
>>>
>>> We have standard matrix to convert colorspaces. This is just the
>>> property of the colorspace, I guess clipping will be the only option
>>> here (irrespective of hardware)
>>>
>>>> Such clipping can change hue, so userspace would be better avoid
>>>> triggering clipping at all, but we still need to know what would
>>>> happen with out-
>> of-range values.
>>>>
>>>> We would also need to know when clipping will happen. If FP16
>>>> (half-float) FB produces out-of-range values and degamma stage is
>>>> not used, will the CTM see original or clipped values? Or is that
>>>> something we have to define as hardware-specific?
>>>>
>>>> Generic userspace will try hard to avoid triggering
>>>> hardware-specific behaviour, so you can expect such behaviour to go unused.
>>>
>>> Here hardware should just operate on the matrix values programmed.
>>> This should be the limitation of the color space conversion
>>> operation and hardware may not have any role to play apart from just
>>> honoring the matrix values and producing the resultant output.
>>
>> I'm not talking about the matrix values. I'm talking about the values
>> originating from the FB, are they clipped or not, before being processed by the matrix?
>>
>> Userspace could want to use the matrix to bring out-of-range FB values
>> into range, but that plan cannot work if the FB values get clipped already before the matrix.
>>
>> I referred to FP16 format explicitly because that format can express
>> values outside of the usual [0.0, 1.0] range in a framebuffer.
>>
>> Of course, the matrix values themselves have some limits too, and
>> userspace should somehow be aware of them.
>
> AFAIK, the values will not be clipped before being submitted to CSC blocks.
> But this can be confirmed to not leave any misconception here.
>
>>>
>>>>> +* Plane Gamma or Post-Curve
>>>>> + * This can be used to perform 2 operations:
>>>>> + * non-lineralize the framebuffer data. Can be used for
>>>>> + * non linear blending. It can be a gamma curve or EOTF
>>>>> + * for HDR.
>>>>> + * Perform Tone Mapping operation. This is an operation
>>>>> + * done when blending is done with HDR and SDR content.
>>>>
>>>> I like this wording better than the wording for pre-curve: "can",
>>>> not "will". It leaves room for creative use of this processing block.
>>>
>>> Ok thanks, will update pre-curve section as well.
>>>
>>>>
>>>> Tone-mapping is needed always when dynamic range differs, so also
>>>> for HDR to HDR, not just SDR to/from HDR.
>>>
>>> Yes correct, will update.
>>>
>>>>> +
>>>>> +UAPI Name: PLANE_GAMMA_MODE
>>>>> +Description: Enum property with values as blob_id's which advertizes the
>>>>> + possible gamma modes and lut ranges supported by the platform.
>>>>> + This allows userspace to query and get the plane gamma color
>>>>> + caps and choose the appropriate gamma mode and create lut values
>>>>> + accordingly.
>>>>> +
>>>>> +UAPI Name: PLANE_GAMMA_LUT
>>>>> +Description: Blob property which allows a userspace to provide LUT values
>>>>> + to apply gamma curve or perform tone mapping using the h/w plane
>>>>> + gamma processing engine, thereby making the content as linear
>>>>> + for further color processing. Userspace gets the size of LUT and
>>>>> + precision etc from PLANE_GAMA_MODE_PROPERTY
>>>>
>>>> The same comments here as with DEGAMMA.
>>>
>>> Noted.
>>>
>>>>> +
>>>>> +This is part of one plane engine. Data from multiple planes
>>>>> +will be then fed to pipe where it will get blended. There is a
>>>>> +similar set of properties available at crtc level which acts on this blended data.
>>>>> +
>>>>> +Below is a sample usecase:
>>>>> +
>>>>> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
>>>> ┌─────────────┐
>>>>> + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
>>>>> + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR
>> │
>>>>> + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
>>>> Mapping├────────┐
>>>>> + └────────────┘ └─────────────┘ └─────────────┘
>>>> └─────────────┘ │
>>>>> + │
>>>>> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
>>>> ┌─────────────┐ │
>>>>> + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
>> │
>>>>> + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
>>>> ├─────┐ │
>>>>> + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │
>> │
>>>>> + └────────────┘ └─────────────┘ └─────────────┘
>>>> └─────────────┘ │ │
>>>>> + │ │
>>>>> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
>>>> ┌─────────────┐ │ │
>>>>> + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
>> │
>>>>> + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
>>>> in├───┐ │ │
>>>>> + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
>>>>> + └────────────┘ └─────────────┘ └─────────────┘
>>>> └─────────────┘ │ │ │
>>>>
>>>> EOTF, not OETF, since it is converting E to O, electrical to optical.
>>>
>>> I think media decode would have given a EOTF applied data to be
>>> directly consumed by display sink (in case we have chosen a display pass through).
>> Not sure here though, it’s a bit confusing.
>>
>> I hope I managed to explain this earlier in this email.
>>
>> Display sinks "always" use non-linearly encoded values, because it
>> saves bandwidth without losing visual quality. For the same reason,
>> images tend to be stored with non-linear value encoding whenever possible.
>
> Yeah, thanks for the explanation and useful pointers. Will work on it to put the right expectations in the document.
>
> Thanks Pekka for the valuable feedback.
>
> Regards,
> Uma Shankar
>>
>> Thanks,
>> pq
>>
>>>>> +
>>>>> + │ │ │
>>>>> +
>>>>> + │ │ │
>>>>> +
>>>>> +│ │ │
>>>>>
>>>>
>> +┌──────────────────────────────────────────────────────────────────
>>>> ──
>>>>> +───────────┴─┴──┘
>>>>> +│
>>>>> +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
>>>>> +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
>>>>> +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone
>>>>> +├─────►
>>>> TO Port
>>>>> + │ data linear │ │ Color Space │ │ Mapping/apply │
>>>>> + │ after blend │ │ Conversion │ │ transfer func │
>>>>> + └─────────────┘ └─────────────┘ └───────────────┘
>>>>
>>>> Blending does not change whether the data is linear or not. I
>>>> suppose in this example, CRTC degamma and CTM would be
>>>> passthrough, and gamma would be the inverse display EOTF for
>>>> encoding color values into
>> what the monitor expects.
>>>
>>> Yeah, will update this to make it clear.
>>>
>>>>> +
>>>>> +
>>>>> +This patch series adds properties for plane color features. It
>>>>> +adds properties for degamma used to linearize data and CSC used
>>>>> +for gamut conversion. It also includes Gamma support used to
>>>>> +again non-linearize data as per panel supported color space.
>>>>> +These can be utilize by user space to convert planes from one
>>>>> +format to another, one color space to another etc.
>>>>
>>>> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
>>>
>>> This is great to hear that we are aligned wrt how the pipeline should work.
>>>
>>> Thanks Pekka for taking time out and providing the feedback.
>>>
>>> @harry.wentland@amd.com We can work together and build our design to
>>> accommodate both Intel and AMD's hardware needs. This will also make
>>> things generic enough for any other hardware vendor as well.
>>>
>>> Thanks & Regards,
>>> Uma Shankar
>>>
>>>>> +
>>>>> +Userspace can take smart blending decisions and utilize these
>>>>> +hardware supported plane color features to get accurate color
>>>>> +profile. The same can help in consistent color quality from
>>>>> +source to panel taking advantage of advanced color features in hardware.
>>>>> +
>>>>> +These patches add the property interfaces and enable helper functions.
>>>>> +This series adds Intel's XE_LPD hw specific plane gamma feature.
>>>>> +We can build up and add other platform/hardware specific
>>>>> +implementation on top of this series.
>>>>> +
>>>>> +Credits: Special mention and credits to Ville Syrjala for
>>>>> +coming up with a design for this feature and inputs. This
>>>>> +series is based on his original design and idea.
>>>>
>>>>
>>>> Thanks,
>>>> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-26 15:36 ` [Intel-gfx] " Harry Wentland
@ 2021-10-27 8:00 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-27 8:00 UTC (permalink / raw)
To: Harry Wentland
Cc: Shankar, Uma, ville.syrjala, intel-gfx, dri-devel, brian.starkey,
sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 4814 bytes --]
On Tue, 26 Oct 2021 11:36:33 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-10-14 15:44, Shankar, Uma wrote:
> >
...
> >>>>> +
> >>>>> +* Plane CTM
> >>>>> + * This is a Property to program the color transformation matrix.
> >>>>
> >>>> No mode property here? Is there any hardware with something else
> >>>> than a matrix at this point?
> >>>
> >>> Not that I am aware of.
> >>>
> >>>> Should we assume there will be hardware with something else, and
> >>>> have a CSC mode property with only a single enum value defined so far:
> >>>> "matrix"? Or do we say PLANE_CTM is a matrix and if you have
> >>>> something else in hardware, then invent a new property for it?
> >>>
> >>> I think this should be good as we have this for crtc with no one complaining.
> >>> There may be hardware with fixed function operation for the CSC but
> >>> then its not a matrix and it would be pretty hardware dependent, so
> >>> we can leave that from a generic UAPI.
> >>
> >> Ok. And if that eventually turns out to be a mistake, it's easy to
> >> invent more properties.
> >
> > I feel that is what would be required. This is just another instance of what we have at crtc level.
> >
>
> Would a userspace client ever want to use both CTM and 3D LUT?
The only reason I can think of is to keep the 3D LUT size (number of
taps) small. I suspect that if one can use a matrix to get close, and
then fix the residual with a 3D LUT, the 3D LUT could be significantly
smaller than if you'd need to bake the matrix into the 3D LUT. But this
is just my own suspicion, I haven't looked for references about this
topic.
IOW, it's a question of precision - the same reason as to why you would
want a 1D LUT before and after a 3D LUT.
> We could add a mode property to CTM to allow for a CTM or 3D LUT or
> we could add new properties for 3D LUT support.
>
> 3D LUT might come with shaper 1D LUTs that can be programmed in
> conjunction with the 3D LUT. 3D LUTs operating in non-linear
> space require less precision than 3D LUTs operating in linear
> space, hence the 1D LUT can be used to non-linearize the
> pixel data for 3D LUT operation.
>
> FWIW, AMD HW (depending on generation) can do these operations
> (in this order):
>
> 1) 1D LUT (fixed or PWL programmable)
> 2) simple multiplier (for scaling SDR content to HDR output)
> 3) CTM matrix
> 4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
> 5) 3D LUT
> 6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
> 7) blending
> 8) CTM matrix
> 9) 1D LUT (shaper LUT like above)
> 10) 3D LUT
> 11) 1D LUT (generally for EOTF^-1 for display EOTF)
>
> Not all blocks are available on all (current and future) HW.
>
> I sketched a few diagrams that show how these might be used by
> a compositor if we exposed all of these blocks and should
> really try to add some of them to the color-and-hdr docs
> repo.
Yes, please.
That pipeline looks pretty comprehensive.
Btw. how about YUV<->RGB conversion? Where would that matrix go? It
needs to operate on non-linear values, while a color space conversion
matrix needs to operate on linear color values.
> >>>>> + * This can be used to perform a color space conversion like
> >>>>> + * BT2020 to BT709 or BT601 etc.
> >>>>> + * This block is generally kept after the degamma unit so that
> >>>>
> >>>> Not "generally". If blocks can change places, then it becomes
> >>>> intractable for generic userspace to program.
> >>>
> >>> Sure, will drop this wording here. But one open will still remain
> >>> for userspace, as to how it gets the pipeline dynamically for a respective hardware.
> >>> Currently we have assumed that this would be the logical fixed order
> >>> of hardware units.
> >>
> >> If we cannot model the abstract KMS pipeline as a fixed order of units
> >> (where each unit may exist or not), we need to take a few steps back
> >> here and look at what do we actually want to expose. That is a much
> >> bigger design problem which we are currently not even considering.
> >
> > I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
>
> I think the color pipeline should be modeled in a way that makes
> sense from a color science standpoint and in a way that makes sense
> for compositor implementations. Fortunately HW design generally
> aligns with these intentions but we should be careful to not
> let HW design dictate KMS interfaces.
I'm so happy to hear that!
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-27 8:00 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-27 8:00 UTC (permalink / raw)
To: Harry Wentland
Cc: Shankar, Uma, ville.syrjala, intel-gfx, dri-devel, brian.starkey,
sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 4814 bytes --]
On Tue, 26 Oct 2021 11:36:33 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-10-14 15:44, Shankar, Uma wrote:
> >
...
> >>>>> +
> >>>>> +* Plane CTM
> >>>>> + * This is a Property to program the color transformation matrix.
> >>>>
> >>>> No mode property here? Is there any hardware with something else
> >>>> than a matrix at this point?
> >>>
> >>> Not that I am aware of.
> >>>
> >>>> Should we assume there will be hardware with something else, and
> >>>> have a CSC mode property with only a single enum value defined so far:
> >>>> "matrix"? Or do we say PLANE_CTM is a matrix and if you have
> >>>> something else in hardware, then invent a new property for it?
> >>>
> >>> I think this should be good as we have this for crtc with no one complaining.
> >>> There may be hardware with fixed function operation for the CSC but
> >>> then its not a matrix and it would be pretty hardware dependent, so
> >>> we can leave that from a generic UAPI.
> >>
> >> Ok. And if that eventually turns out to be a mistake, it's easy to
> >> invent more properties.
> >
> > I feel that is what would be required. This is just another instance of what we have at crtc level.
> >
>
> Would a userspace client ever want to use both CTM and 3D LUT?
The only reason I can think of is to keep the 3D LUT size (number of
taps) small. I suspect that if one can use a matrix to get close, and
then fix the residual with a 3D LUT, the 3D LUT could be significantly
smaller than if you'd need to bake the matrix into the 3D LUT. But this
is just my own suspicion, I haven't looked for references about this
topic.
IOW, it's a question of precision - the same reason as to why you would
want a 1D LUT before and after a 3D LUT.
> We could add a mode property to CTM to allow for a CTM or 3D LUT or
> we could add new properties for 3D LUT support.
>
> 3D LUT might come with shaper 1D LUTs that can be programmed in
> conjunction with the 3D LUT. 3D LUTs operating in non-linear
> space require less precision than 3D LUTs operating in linear
> space, hence the 1D LUT can be used to non-linearize the
> pixel data for 3D LUT operation.
>
> FWIW, AMD HW (depending on generation) can do these operations
> (in this order):
>
> 1) 1D LUT (fixed or PWL programmable)
> 2) simple multiplier (for scaling SDR content to HDR output)
> 3) CTM matrix
> 4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
> 5) 3D LUT
> 6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
> 7) blending
> 8) CTM matrix
> 9) 1D LUT (shaper LUT like above)
> 10) 3D LUT
> 11) 1D LUT (generally for EOTF^-1 for display EOTF)
>
> Not all blocks are available on all (current and future) HW.
>
> I sketched a few diagrams that show how these might be used by
> a compositor if we exposed all of these blocks and should
> really try to add some of them to the color-and-hdr docs
> repo.
Yes, please.
That pipeline looks pretty comprehensive.
Btw. how about YUV<->RGB conversion? Where would that matrix go? It
needs to operate on non-linear values, while a color space conversion
matrix needs to operate on linear color values.
> >>>>> + * This can be used to perform a color space conversion like
> >>>>> + * BT2020 to BT709 or BT601 etc.
> >>>>> + * This block is generally kept after the degamma unit so that
> >>>>
> >>>> Not "generally". If blocks can change places, then it becomes
> >>>> intractable for generic userspace to program.
> >>>
> >>> Sure, will drop this wording here. But one open will still remain
> >>> for userspace, as to how it gets the pipeline dynamically for a respective hardware.
> >>> Currently we have assumed that this would be the logical fixed order
> >>> of hardware units.
> >>
> >> If we cannot model the abstract KMS pipeline as a fixed order of units
> >> (where each unit may exist or not), we need to take a few steps back
> >> here and look at what do we actually want to expose. That is a much
> >> bigger design problem which we are currently not even considering.
> >
> > I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
>
> I think the color pipeline should be modeled in a way that makes
> sense from a color science standpoint and in a way that makes sense
> for compositor implementations. Fortunately HW design generally
> aligns with these intentions but we should be careful to not
> let HW design dictate KMS interfaces.
I'm so happy to hear that!
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-27 8:00 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-27 12:48 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-27 12:48 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Shankar, Uma, ville.syrjala, intel-gfx, dri-devel, brian.starkey,
sebastian, Shashank.Sharma, Cyr, Aric
On 2021-10-27 04:00, Pekka Paalanen wrote:
> On Tue, 26 Oct 2021 11:36:33 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> On 2021-10-14 15:44, Shankar, Uma wrote:
>>>
>
...
>> FWIW, AMD HW (depending on generation) can do these operations
>> (in this order):
>>
>> 1) 1D LUT (fixed or PWL programmable)
>> 2) simple multiplier (for scaling SDR content to HDR output)
>> 3) CTM matrix
>> 4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
>> 5) 3D LUT
>> 6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
>> 7) blending
>> 8) CTM matrix
>> 9) 1D LUT (shaper LUT like above)
>> 10) 3D LUT
>> 11) 1D LUT (generally for EOTF^-1 for display EOTF)
>>
>> Not all blocks are available on all (current and future) HW.
>>
>> I sketched a few diagrams that show how these might be used by
>> a compositor if we exposed all of these blocks and should
>> really try to add some of them to the color-and-hdr docs
>> repo.
>
> Yes, please.
>
> That pipeline looks pretty comprehensive.
>
> Btw. how about YUV<->RGB conversion? Where would that matrix go? It
> needs to operate on non-linear values, while a color space conversion
> matrix needs to operate on linear color values.
>
That is communicated via drm_framebuffer.format, and drm_plane's
color_range and color_encoding. I expect it to happen before
everything else, i.e. at step 0. It seems like any color management
implementation I've seen is always operating in RGB.
Harry
>>>>>>> + * This can be used to perform a color space conversion like
>>>>>>> + * BT2020 to BT709 or BT601 etc.
>>>>>>> + * This block is generally kept after the degamma unit so that
>>>>>>
>>>>>> Not "generally". If blocks can change places, then it becomes
>>>>>> intractable for generic userspace to program.
>>>>>
>>>>> Sure, will drop this wording here. But one open will still remain
>>>>> for userspace, as to how it gets the pipeline dynamically for a respective hardware.
>>>>> Currently we have assumed that this would be the logical fixed order
>>>>> of hardware units.
>>>>
>>>> If we cannot model the abstract KMS pipeline as a fixed order of units
>>>> (where each unit may exist or not), we need to take a few steps back
>>>> here and look at what do we actually want to expose. That is a much
>>>> bigger design problem which we are currently not even considering.
>>>
>>> I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
>>
>> I think the color pipeline should be modeled in a way that makes
>> sense from a color science standpoint and in a way that makes sense
>> for compositor implementations. Fortunately HW design generally
>> aligns with these intentions but we should be careful to not
>> let HW design dictate KMS interfaces.
>
> I'm so happy to hear that!
>
>
> Thanks,
> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-27 12:48 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-27 12:48 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Shankar, Uma, ville.syrjala, intel-gfx, dri-devel, brian.starkey,
sebastian, Shashank.Sharma, Cyr, Aric
On 2021-10-27 04:00, Pekka Paalanen wrote:
> On Tue, 26 Oct 2021 11:36:33 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> On 2021-10-14 15:44, Shankar, Uma wrote:
>>>
>
...
>> FWIW, AMD HW (depending on generation) can do these operations
>> (in this order):
>>
>> 1) 1D LUT (fixed or PWL programmable)
>> 2) simple multiplier (for scaling SDR content to HDR output)
>> 3) CTM matrix
>> 4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
>> 5) 3D LUT
>> 6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
>> 7) blending
>> 8) CTM matrix
>> 9) 1D LUT (shaper LUT like above)
>> 10) 3D LUT
>> 11) 1D LUT (generally for EOTF^-1 for display EOTF)
>>
>> Not all blocks are available on all (current and future) HW.
>>
>> I sketched a few diagrams that show how these might be used by
>> a compositor if we exposed all of these blocks and should
>> really try to add some of them to the color-and-hdr docs
>> repo.
>
> Yes, please.
>
> That pipeline looks pretty comprehensive.
>
> Btw. how about YUV<->RGB conversion? Where would that matrix go? It
> needs to operate on non-linear values, while a color space conversion
> matrix needs to operate on linear color values.
>
That is communicated via drm_framebuffer.format, and drm_plane's
color_range and color_encoding. I expect it to happen before
everything else, i.e. at step 0. It seems like any color management
implementation I've seen is always operating in RGB.
Harry
>>>>>>> + * This can be used to perform a color space conversion like
>>>>>>> + * BT2020 to BT709 or BT601 etc.
>>>>>>> + * This block is generally kept after the degamma unit so that
>>>>>>
>>>>>> Not "generally". If blocks can change places, then it becomes
>>>>>> intractable for generic userspace to program.
>>>>>
>>>>> Sure, will drop this wording here. But one open will still remain
>>>>> for userspace, as to how it gets the pipeline dynamically for a respective hardware.
>>>>> Currently we have assumed that this would be the logical fixed order
>>>>> of hardware units.
>>>>
>>>> If we cannot model the abstract KMS pipeline as a fixed order of units
>>>> (where each unit may exist or not), we need to take a few steps back
>>>> here and look at what do we actually want to expose. That is a much
>>>> bigger design problem which we are currently not even considering.
>>>
>>> I think most of the hardware vendor platforms have this pipeline, so we can implement the properties which include all the possible hardware blocks. If certain units don't exist, the respective properties should not be exposed which will make things easier for userspace.
>>
>> I think the color pipeline should be modeled in a way that makes
>> sense from a color science standpoint and in a way that makes sense
>> for compositor implementations. Fortunately HW design generally
>> aligns with these intentions but we should be careful to not
>> let HW design dictate KMS interfaces.
>
> I'm so happy to hear that!
>
>
> Thanks,
> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-10-12 20:58 ` [Intel-gfx] " Shankar, Uma
@ 2021-10-26 15:40 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:40 UTC (permalink / raw)
To: Shankar, Uma, Pekka Paalanen, ville.syrjala
Cc: intel-gfx, dri-devel, brian.starkey, sebastian, Shashank.Sharma
On 2021-10-12 16:58, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Pekka Paalanen <ppaalanen@gmail.com>
>> Sent: Tuesday, October 12, 2021 4:01 PM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> harry.wentland@amd.com; ville.syrjala@linux.intel.com;
>> brian.starkey@arm.com; sebastian@sebastianwick.net;
>> Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue, 7 Sep 2021 03:08:43 +0530
>> Uma Shankar <uma.shankar@intel.com> wrote:
>>
snip
>>> +
>>> +
>>> +This patch series adds properties for plane color features. It adds
>>> +properties for degamma used to linearize data and CSC used for
>>> +gamut conversion. It also includes Gamma support used to again
>>> +non-linearize data as per panel supported color space. These can be
>>> +utilize by user space to convert planes from one format to another,
>>> +one color space to another etc.
>>
>> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
>
> This is great to hear that we are aligned wrt how the pipeline should work.
>
> Thanks Pekka for taking time out and providing the feedback.
>
> @harry.wentland@amd.com We can work together and build our design to accommodate
> both Intel and AMD's hardware needs. This will also make things generic enough for any
> other hardware vendor as well.
>
Definitely. I think we're on the right path. Personally I would like to
arrive at a solid KMS definition for this by the time Weston guys
get to the HDR enablement with SW composition so we can start looking
at KMS offloading for HDR planes as next step.
Harry
> Thanks & Regards,
> Uma Shankar
>
>>> +
>>> +Userspace can take smart blending decisions and utilize these
>>> +hardware supported plane color features to get accurate color
>>> +profile. The same can help in consistent color quality from source
>>> +to panel taking advantage of advanced color features in hardware.
>>> +
>>> +These patches add the property interfaces and enable helper functions.
>>> +This series adds Intel's XE_LPD hw specific plane gamma feature. We
>>> +can build up and add other platform/hardware specific
>>> +implementation on top of this series.
>>> +
>>> +Credits: Special mention and credits to Ville Syrjala for coming up
>>> +with a design for this feature and inputs. This series is based on
>>> +his original design and idea.
>>
>>
>> Thanks,
>> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-10-26 15:40 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:40 UTC (permalink / raw)
To: Shankar, Uma, Pekka Paalanen, ville.syrjala
Cc: intel-gfx, dri-devel, brian.starkey, sebastian, Shashank.Sharma
On 2021-10-12 16:58, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Pekka Paalanen <ppaalanen@gmail.com>
>> Sent: Tuesday, October 12, 2021 4:01 PM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> harry.wentland@amd.com; ville.syrjala@linux.intel.com;
>> brian.starkey@arm.com; sebastian@sebastianwick.net;
>> Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue, 7 Sep 2021 03:08:43 +0530
>> Uma Shankar <uma.shankar@intel.com> wrote:
>>
snip
>>> +
>>> +
>>> +This patch series adds properties for plane color features. It adds
>>> +properties for degamma used to linearize data and CSC used for
>>> +gamut conversion. It also includes Gamma support used to again
>>> +non-linearize data as per panel supported color space. These can be
>>> +utilize by user space to convert planes from one format to another,
>>> +one color space to another etc.
>>
>> FWIW, this is exactly the structure I have assumed in the Weston CM&HDR work.
>
> This is great to hear that we are aligned wrt how the pipeline should work.
>
> Thanks Pekka for taking time out and providing the feedback.
>
> @harry.wentland@amd.com We can work together and build our design to accommodate
> both Intel and AMD's hardware needs. This will also make things generic enough for any
> other hardware vendor as well.
>
Definitely. I think we're on the right path. Personally I would like to
arrive at a solid KMS definition for this by the time Weston guys
get to the HDR enablement with SW composition so we can start looking
at KMS offloading for HDR planes as next step.
Harry
> Thanks & Regards,
> Uma Shankar
>
>>> +
>>> +Userspace can take smart blending decisions and utilize these
>>> +hardware supported plane color features to get accurate color
>>> +profile. The same can help in consistent color quality from source
>>> +to panel taking advantage of advanced color features in hardware.
>>> +
>>> +These patches add the property interfaces and enable helper functions.
>>> +This series adds Intel's XE_LPD hw specific plane gamma feature. We
>>> +can build up and add other platform/hardware specific
>>> +implementation on top of this series.
>>> +
>>> +Credits: Special mention and credits to Ville Syrjala for coming up
>>> +with a design for this feature and inputs. This series is based on
>>> +his original design and idea.
>>
>>
>> Thanks,
>> pq
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-09-06 21:38 ` Uma Shankar
@ 2021-11-23 15:05 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-23 15:05 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, Shashank.Sharma
On 2021-09-06 17:38, Uma Shankar wrote:
> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls
> out the details or interfaces created and the intended
> purpose.
>
> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++
> 1 file changed, 167 insertions(+)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst
> new file mode 100644
> index 000000000000..0d1ca858783b
> --- /dev/null
> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> @@ -0,0 +1,167 @@
> +==================================================
> +Display Color Pipeline: Proposed DRM Properties
> +==================================================
> +
> +This is how a typical display color hardware pipeline looks like:
> + +-------------------------------------------+
> + | RAM |
> + | +------+ +---------+ +---------+ |
> + | | FB 1 | | FB 2 | | FB N | |
> + | +------+ +---------+ +---------+ |
> + +-------------------------------------------+
> + | Plane Color Hardware Block |
> + +--------------------------------------------+
> + | +---v-----+ +---v-------+ +---v------+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | DeGamma | | Degamma | | Degamma | |
> + | +---+-----+ +---+-------+ +---+------+ |
> + | | | | |
> + | +---v-----+ +---v-------+ +---v------+ |
> + | |Plane A | | Plane B | | Plane N | |
> + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + | +---v-----+ +----v------+ +----v-----+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | Gamma | | Gamma | | Gamma | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + +--------------------------------------------+
> ++------v--------------v---------------v-------|
> +|| ||
> +|| Pipe Blender ||
> ++--------------------+------------------------+
> +| | |
> +| +-----------v----------+ |
> +| | Pipe DeGamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | Pipe Color |
> +| +-----------v----------+ Hardware |
> +| | Pipe CSC/CTM | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> +| +-----------v----------+ |
> +| | Pipe Gamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> ++---------------------------------------------+
> + |
> + v
> + Pipe Output
> +
This diagram defines what happens before and after the blending
space but did where does scaling fit into it? Scaling can look
different when performed in linear or non-linear space so I think
it is important to define where in the pipeline it sits.
In my view scaling would happen between plane degamma and plane CSC.
Harry
> +Proposal is to have below properties for a plane:
> +
> +* Plane Degamma or Pre-Curve:
> + * This will be used to linearize the input framebuffer data.
> + * It will apply the reverse of the color transfer function.
> + * It can be a degamma curve or OETF for HDR.
> + * This linear data can be further acted on by the following
> + * color hardware blocks in the display hardware pipeline
> +
> +UAPI Name: PLANE_DEGAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes the
> + possible degamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane degamma color
> + caps and choose the appropriate degamma mode and create lut values
> + accordingly.
> +
> +UAPI Name: PLANE_DEGAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply degamma curve using the h/w plane degamma processing
> + engine, thereby making the content as linear for further color
> + processing. Userspace gets the size of LUT and precision etc
> + from PLANE_DEGAMA_MODE_PROPERTY
> +
> +* Plane CTM
> + * This is a Property to program the color transformation matrix.
> + * This can be used to perform a color space conversion like
> + * BT2020 to BT709 or BT601 etc.
> + * This block is generally kept after the degamma unit so that
> + * linear data can be fed to it for conversion.
> +
> +UAPI Name: PLANE_CTM
> +Description: Blob property which allows a userspace to provide CTM coefficients
> + to do color space conversion or any other enhancement by doing a
> + matrix multiplication using the h/w CTM processing engine
> +
> +* Plane Gamma or Post-Curve
> + * This can be used to perform 2 operations:
> + * non-lineralize the framebuffer data. Can be used for
> + * non linear blending. It can be a gamma curve or EOTF
> + * for HDR.
> + * Perform Tone Mapping operation. This is an operation
> + * done when blending is done with HDR and SDR content.
> +
> +UAPI Name: PLANE_GAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes the
> + possible gamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane gamma color
> + caps and choose the appropriate gamma mode and create lut values
> + accordingly.
> +
> +UAPI Name: PLANE_GAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply gamma curve or perform tone mapping using the h/w plane
> + gamma processing engine, thereby making the content as linear
> + for further color processing. Userspace gets the size of LUT and
> + precision etc from PLANE_GAMA_MODE_PROPERTY
> +
> +This is part of one plane engine. Data from multiple planes will be
> +then fed to pipe where it will get blended. There is a similar set of
> +properties available at crtc level which acts on this blended data.
> +
> +Below is a sample usecase:
> +
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
> + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone Mapping├────────┐
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
> + │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
> + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR ├─────┐ │
> + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
> + │ │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
> + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data in├───┐ │ │
> + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │
> + │ │ │
> + │ │ │
> + │ │ │
> +┌───────────────────────────────────────────────────────────────────────────────┴─┴──┘
> +│
> +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────► TO Port
> + │ data linear │ │ Color Space │ │ Mapping/apply │
> + │ after blend │ │ Conversion │ │ transfer func │
> + └─────────────┘ └─────────────┘ └───────────────┘
> +
> +
> +This patch series adds properties for plane color features. It adds
> +properties for degamma used to linearize data and CSC used for gamut
> +conversion. It also includes Gamma support used to again non-linearize
> +data as per panel supported color space. These can be utilize by user
> +space to convert planes from one format to another, one color space to
> +another etc.
> +
> +Userspace can take smart blending decisions and utilize these hardware
> +supported plane color features to get accurate color profile. The same
> +can help in consistent color quality from source to panel taking
> +advantage of advanced color features in hardware.
> +
> +These patches add the property interfaces and enable helper functions.
> +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> +can build up and add other platform/hardware specific implementation
> +on top of this series.
> +
> +Credits: Special mention and credits to Ville Syrjala for coming up
> +with a design for this feature and inputs. This series is based on
> +his original design and idea.
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-11-23 15:05 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-23 15:05 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, ppaalanen
On 2021-09-06 17:38, Uma Shankar wrote:
> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls
> out the details or interfaces created and the intended
> purpose.
>
> Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++
> 1 file changed, 167 insertions(+)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst
> new file mode 100644
> index 000000000000..0d1ca858783b
> --- /dev/null
> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> @@ -0,0 +1,167 @@
> +==================================================
> +Display Color Pipeline: Proposed DRM Properties
> +==================================================
> +
> +This is how a typical display color hardware pipeline looks like:
> + +-------------------------------------------+
> + | RAM |
> + | +------+ +---------+ +---------+ |
> + | | FB 1 | | FB 2 | | FB N | |
> + | +------+ +---------+ +---------+ |
> + +-------------------------------------------+
> + | Plane Color Hardware Block |
> + +--------------------------------------------+
> + | +---v-----+ +---v-------+ +---v------+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | DeGamma | | Degamma | | Degamma | |
> + | +---+-----+ +---+-------+ +---+------+ |
> + | | | | |
> + | +---v-----+ +---v-------+ +---v------+ |
> + | |Plane A | | Plane B | | Plane N | |
> + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + | +---v-----+ +----v------+ +----v-----+ |
> + | | Plane A | | Plane B | | Plane N | |
> + | | Gamma | | Gamma | | Gamma | |
> + | +---+-----+ +----+------+ +----+-----+ |
> + | | | | |
> + +--------------------------------------------+
> ++------v--------------v---------------v-------|
> +|| ||
> +|| Pipe Blender ||
> ++--------------------+------------------------+
> +| | |
> +| +-----------v----------+ |
> +| | Pipe DeGamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | Pipe Color |
> +| +-----------v----------+ Hardware |
> +| | Pipe CSC/CTM | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> +| +-----------v----------+ |
> +| | Pipe Gamma | |
> +| | | |
> +| +-----------+----------+ |
> +| | |
> ++---------------------------------------------+
> + |
> + v
> + Pipe Output
> +
This diagram defines what happens before and after the blending
space but did where does scaling fit into it? Scaling can look
different when performed in linear or non-linear space so I think
it is important to define where in the pipeline it sits.
In my view scaling would happen between plane degamma and plane CSC.
Harry
> +Proposal is to have below properties for a plane:
> +
> +* Plane Degamma or Pre-Curve:
> + * This will be used to linearize the input framebuffer data.
> + * It will apply the reverse of the color transfer function.
> + * It can be a degamma curve or OETF for HDR.
> + * This linear data can be further acted on by the following
> + * color hardware blocks in the display hardware pipeline
> +
> +UAPI Name: PLANE_DEGAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes the
> + possible degamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane degamma color
> + caps and choose the appropriate degamma mode and create lut values
> + accordingly.
> +
> +UAPI Name: PLANE_DEGAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply degamma curve using the h/w plane degamma processing
> + engine, thereby making the content as linear for further color
> + processing. Userspace gets the size of LUT and precision etc
> + from PLANE_DEGAMA_MODE_PROPERTY
> +
> +* Plane CTM
> + * This is a Property to program the color transformation matrix.
> + * This can be used to perform a color space conversion like
> + * BT2020 to BT709 or BT601 etc.
> + * This block is generally kept after the degamma unit so that
> + * linear data can be fed to it for conversion.
> +
> +UAPI Name: PLANE_CTM
> +Description: Blob property which allows a userspace to provide CTM coefficients
> + to do color space conversion or any other enhancement by doing a
> + matrix multiplication using the h/w CTM processing engine
> +
> +* Plane Gamma or Post-Curve
> + * This can be used to perform 2 operations:
> + * non-lineralize the framebuffer data. Can be used for
> + * non linear blending. It can be a gamma curve or EOTF
> + * for HDR.
> + * Perform Tone Mapping operation. This is an operation
> + * done when blending is done with HDR and SDR content.
> +
> +UAPI Name: PLANE_GAMMA_MODE
> +Description: Enum property with values as blob_id's which advertizes the
> + possible gamma modes and lut ranges supported by the platform.
> + This allows userspace to query and get the plane gamma color
> + caps and choose the appropriate gamma mode and create lut values
> + accordingly.
> +
> +UAPI Name: PLANE_GAMMA_LUT
> +Description: Blob property which allows a userspace to provide LUT values
> + to apply gamma curve or perform tone mapping using the h/w plane
> + gamma processing engine, thereby making the content as linear
> + for further color processing. Userspace gets the size of LUT and
> + precision etc from PLANE_GAMA_MODE_PROPERTY
> +
> +This is part of one plane engine. Data from multiple planes will be
> +then fed to pipe where it will get blended. There is a similar set of
> +properties available at crtc level which acts on this blended data.
> +
> +Below is a sample usecase:
> +
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
> + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone Mapping├────────┐
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │
> + │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
> + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR ├─────┐ │
> + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │
> + │ │
> + ┌────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
> + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data in├───┐ │ │
> + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> + └────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │
> + │ │ │
> + │ │ │
> + │ │ │
> +┌───────────────────────────────────────────────────────────────────────────────┴─┴──┘
> +│
> +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────► TO Port
> + │ data linear │ │ Color Space │ │ Mapping/apply │
> + │ after blend │ │ Conversion │ │ transfer func │
> + └─────────────┘ └─────────────┘ └───────────────┘
> +
> +
> +This patch series adds properties for plane color features. It adds
> +properties for degamma used to linearize data and CSC used for gamut
> +conversion. It also includes Gamma support used to again non-linearize
> +data as per panel supported color space. These can be utilize by user
> +space to convert planes from one format to another, one color space to
> +another etc.
> +
> +Userspace can take smart blending decisions and utilize these hardware
> +supported plane color features to get accurate color profile. The same
> +can help in consistent color quality from source to panel taking
> +advantage of advanced color features in hardware.
> +
> +These patches add the property interfaces and enable helper functions.
> +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> +can build up and add other platform/hardware specific implementation
> +on top of this series.
> +
> +Credits: Special mention and credits to Ville Syrjala for coming up
> +with a design for this feature and inputs. This series is based on
> +his original design and idea.
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-11-23 15:05 ` [Intel-gfx] " Harry Wentland
@ 2021-11-25 20:43 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-11-25 20:43 UTC (permalink / raw)
To: Harry Wentland, intel-gfx, dri-devel; +Cc: sebastian, Shashank.Sharma
> -----Original Message-----
> From: Harry Wentland <harry.wentland@amd.com>
> Sent: Tuesday, November 23, 2021 8:35 PM
> To: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: ville.syrjala@linux.intel.com; ppaalanen@gmail.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > This is a RFC proposal for plane color hardware blocks.
> > It exposes the property interface to userspace and calls out the
> > details or interfaces created and the intended purpose.
> >
> > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > +++++++++++++++++++
> > 1 file changed, 167 insertions(+)
> > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
> > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > new file mode 100644
> > index 000000000000..0d1ca858783b
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > @@ -0,0 +1,167 @@
> > +==================================================
> > +Display Color Pipeline: Proposed DRM Properties
> > +==================================================
> > +
> > +This is how a typical display color hardware pipeline looks like:
> > + +-------------------------------------------+
> > + | RAM |
> > + | +------+ +---------+ +---------+ |
> > + | | FB 1 | | FB 2 | | FB N | |
> > + | +------+ +---------+ +---------+ |
> > + +-------------------------------------------+
> > + | Plane Color Hardware Block |
> > + +--------------------------------------------+
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | DeGamma | | Degamma | | Degamma | |
> > + | +---+-----+ +---+-------+ +---+------+ |
> > + | | | | |
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | |Plane A | | Plane B | | Plane N | |
> > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + | +---v-----+ +----v------+ +----v-----+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | Gamma | | Gamma | | Gamma | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + +--------------------------------------------+
> > ++------v--------------v---------------v-------|
> > +|| ||
> > +|| Pipe Blender ||
> > ++--------------------+------------------------+
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe DeGamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | Pipe Color |
> > +| +-----------v----------+ Hardware |
> > +| | Pipe CSC/CTM | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe Gamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > ++---------------------------------------------+
> > + |
> > + v
> > + Pipe Output
> > +
>
> This diagram defines what happens before and after the blending space but did
> where does scaling fit into it? Scaling can look different when performed in linear or
> non-linear space so I think it is important to define where in the pipeline it sits.
>
> In my view scaling would happen between plane degamma and plane CSC.
Yeah we can add scaling as well to make it clear. Scaling ideally should happen after
Degamma. In intel's case it is after the CSC.
Regards,
Uma Shankar
> Harry
>
> > +Proposal is to have below properties for a plane:
> > +
> > +* Plane Degamma or Pre-Curve:
> > + * This will be used to linearize the input framebuffer data.
> > + * It will apply the reverse of the color transfer function.
> > + * It can be a degamma curve or OETF for HDR.
> > + * This linear data can be further acted on by the following
> > + * color hardware blocks in the display hardware pipeline
> > +
> > +UAPI Name: PLANE_DEGAMMA_MODE
> > +Description: Enum property with values as blob_id's which advertizes the
> > + possible degamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane degamma color
> > + caps and choose the appropriate degamma mode and create lut values
> > + accordingly.
> > +
> > +UAPI Name: PLANE_DEGAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply degamma curve using the h/w plane degamma processing
> > + engine, thereby making the content as linear for further color
> > + processing. Userspace gets the size of LUT and precision etc
> > + from PLANE_DEGAMA_MODE_PROPERTY
> > +
> > +* Plane CTM
> > + * This is a Property to program the color transformation matrix.
> > + * This can be used to perform a color space conversion like
> > + * BT2020 to BT709 or BT601 etc.
> > + * This block is generally kept after the degamma unit so that
> > + * linear data can be fed to it for conversion.
> > +
> > +UAPI Name: PLANE_CTM
> > +Description: Blob property which allows a userspace to provide CTM coefficients
> > + to do color space conversion or any other enhancement by doing a
> > + matrix multiplication using the h/w CTM processing engine
> > +
> > +* Plane Gamma or Post-Curve
> > + * This can be used to perform 2 operations:
> > + * non-lineralize the framebuffer data. Can be used for
> > + * non linear blending. It can be a gamma curve or EOTF
> > + * for HDR.
> > + * Perform Tone Mapping operation. This is an operation
> > + * done when blending is done with HDR and SDR content.
> > +
> > +UAPI Name: PLANE_GAMMA_MODE
> > +Description: Enum property with values as blob_id's which advertizes the
> > + possible gamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane gamma color
> > + caps and choose the appropriate gamma mode and create lut values
> > + accordingly.
> > +
> > +UAPI Name: PLANE_GAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply gamma curve or perform tone mapping using the h/w plane
> > + gamma processing engine, thereby making the content as linear
> > + for further color processing. Userspace gets the size of LUT and
> > + precision etc from PLANE_GAMA_MODE_PROPERTY
> > +
> > +This is part of one plane engine. Data from multiple planes will be
> > +then fed to pipe where it will get blended. There is a similar set of
> > +properties available at crtc level which acts on this blended data.
> > +
> > +Below is a sample usecase:
> > +
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐
> > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> Mapping├────────┐
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │
> > + │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │
> > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> ├─────┐ │
> > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │
> > + │ │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │ │
> > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> in├───┐ │ │
> > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │ │
> > + │ │ │
> > + │ │ │
> > +
> > +│ │ │
> >
> +┌──────────────────────────────────────────────────────────────────
> ──
> > +───────────┴─┴──┘
> > +│
> > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────►
> TO Port
> > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > + │ after blend │ │ Conversion │ │ transfer func │
> > + └─────────────┘ └─────────────┘ └───────────────┘
> > +
> > +
> > +This patch series adds properties for plane color features. It adds
> > +properties for degamma used to linearize data and CSC used for gamut
> > +conversion. It also includes Gamma support used to again
> > +non-linearize data as per panel supported color space. These can be
> > +utilize by user space to convert planes from one format to another,
> > +one color space to another etc.
> > +
> > +Userspace can take smart blending decisions and utilize these
> > +hardware supported plane color features to get accurate color
> > +profile. The same can help in consistent color quality from source to
> > +panel taking advantage of advanced color features in hardware.
> > +
> > +These patches add the property interfaces and enable helper functions.
> > +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > +can build up and add other platform/hardware specific implementation
> > +on top of this series.
> > +
> > +Credits: Special mention and credits to Ville Syrjala for coming up
> > +with a design for this feature and inputs. This series is based on
> > +his original design and idea.
> >
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-11-25 20:43 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-11-25 20:43 UTC (permalink / raw)
To: Harry Wentland, intel-gfx, dri-devel; +Cc: sebastian, ppaalanen
> -----Original Message-----
> From: Harry Wentland <harry.wentland@amd.com>
> Sent: Tuesday, November 23, 2021 8:35 PM
> To: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: ville.syrjala@linux.intel.com; ppaalanen@gmail.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > This is a RFC proposal for plane color hardware blocks.
> > It exposes the property interface to userspace and calls out the
> > details or interfaces created and the intended purpose.
> >
> > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > +++++++++++++++++++
> > 1 file changed, 167 insertions(+)
> > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
> > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > new file mode 100644
> > index 000000000000..0d1ca858783b
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > @@ -0,0 +1,167 @@
> > +==================================================
> > +Display Color Pipeline: Proposed DRM Properties
> > +==================================================
> > +
> > +This is how a typical display color hardware pipeline looks like:
> > + +-------------------------------------------+
> > + | RAM |
> > + | +------+ +---------+ +---------+ |
> > + | | FB 1 | | FB 2 | | FB N | |
> > + | +------+ +---------+ +---------+ |
> > + +-------------------------------------------+
> > + | Plane Color Hardware Block |
> > + +--------------------------------------------+
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | DeGamma | | Degamma | | Degamma | |
> > + | +---+-----+ +---+-------+ +---+------+ |
> > + | | | | |
> > + | +---v-----+ +---v-------+ +---v------+ |
> > + | |Plane A | | Plane B | | Plane N | |
> > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + | +---v-----+ +----v------+ +----v-----+ |
> > + | | Plane A | | Plane B | | Plane N | |
> > + | | Gamma | | Gamma | | Gamma | |
> > + | +---+-----+ +----+------+ +----+-----+ |
> > + | | | | |
> > + +--------------------------------------------+
> > ++------v--------------v---------------v-------|
> > +|| ||
> > +|| Pipe Blender ||
> > ++--------------------+------------------------+
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe DeGamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | Pipe Color |
> > +| +-----------v----------+ Hardware |
> > +| | Pipe CSC/CTM | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > +| +-----------v----------+ |
> > +| | Pipe Gamma | |
> > +| | | |
> > +| +-----------+----------+ |
> > +| | |
> > ++---------------------------------------------+
> > + |
> > + v
> > + Pipe Output
> > +
>
> This diagram defines what happens before and after the blending space but did
> where does scaling fit into it? Scaling can look different when performed in linear or
> non-linear space so I think it is important to define where in the pipeline it sits.
>
> In my view scaling would happen between plane degamma and plane CSC.
Yeah we can add scaling as well to make it clear. Scaling ideally should happen after
Degamma. In intel's case it is after the CSC.
Regards,
Uma Shankar
> Harry
>
> > +Proposal is to have below properties for a plane:
> > +
> > +* Plane Degamma or Pre-Curve:
> > + * This will be used to linearize the input framebuffer data.
> > + * It will apply the reverse of the color transfer function.
> > + * It can be a degamma curve or OETF for HDR.
> > + * This linear data can be further acted on by the following
> > + * color hardware blocks in the display hardware pipeline
> > +
> > +UAPI Name: PLANE_DEGAMMA_MODE
> > +Description: Enum property with values as blob_id's which advertizes the
> > + possible degamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane degamma color
> > + caps and choose the appropriate degamma mode and create lut values
> > + accordingly.
> > +
> > +UAPI Name: PLANE_DEGAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply degamma curve using the h/w plane degamma processing
> > + engine, thereby making the content as linear for further color
> > + processing. Userspace gets the size of LUT and precision etc
> > + from PLANE_DEGAMA_MODE_PROPERTY
> > +
> > +* Plane CTM
> > + * This is a Property to program the color transformation matrix.
> > + * This can be used to perform a color space conversion like
> > + * BT2020 to BT709 or BT601 etc.
> > + * This block is generally kept after the degamma unit so that
> > + * linear data can be fed to it for conversion.
> > +
> > +UAPI Name: PLANE_CTM
> > +Description: Blob property which allows a userspace to provide CTM coefficients
> > + to do color space conversion or any other enhancement by doing a
> > + matrix multiplication using the h/w CTM processing engine
> > +
> > +* Plane Gamma or Post-Curve
> > + * This can be used to perform 2 operations:
> > + * non-lineralize the framebuffer data. Can be used for
> > + * non linear blending. It can be a gamma curve or EOTF
> > + * for HDR.
> > + * Perform Tone Mapping operation. This is an operation
> > + * done when blending is done with HDR and SDR content.
> > +
> > +UAPI Name: PLANE_GAMMA_MODE
> > +Description: Enum property with values as blob_id's which advertizes the
> > + possible gamma modes and lut ranges supported by the platform.
> > + This allows userspace to query and get the plane gamma color
> > + caps and choose the appropriate gamma mode and create lut values
> > + accordingly.
> > +
> > +UAPI Name: PLANE_GAMMA_LUT
> > +Description: Blob property which allows a userspace to provide LUT values
> > + to apply gamma curve or perform tone mapping using the h/w plane
> > + gamma processing engine, thereby making the content as linear
> > + for further color processing. Userspace gets the size of LUT and
> > + precision etc from PLANE_GAMA_MODE_PROPERTY
> > +
> > +This is part of one plane engine. Data from multiple planes will be
> > +then fed to pipe where it will get blended. There is a similar set of
> > +properties available at crtc level which acts on this blended data.
> > +
> > +Below is a sample usecase:
> > +
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐
> > + │FB1 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │
> > + │ ├─────►│Linearize- ├────►│ BT709 to ├────►│ SDR to HDR │
> > + │BT709 SDR │ │BT709 inverse│ │ BT2020 │ │ Tone
> Mapping├────────┐
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │
> > + │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │
> > + │FB2 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │
> > + │ ├─────►│Linearize- ├────►│ BT601 to ├────►│ SDR to HDR
> ├─────┐ │
> > + │BT601 SDR │ │BT601 inverse│ │ BT2020 │ │ Tone Mapping│ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │
> > + │ │
> > + ┌────────────┐ ┌─────────────┐ ┌─────────────┐
> ┌─────────────┐ │ │
> > + │FB3 │ │Degamma Block│ │ CTM Matrix │ │ Gamma Block │ │ │
> > + │ ├─────►│Linearize- ├────►│ NOP (Data in├────►│ NOP (Data
> in├───┐ │ │
> > + │BT2020 HDR │ │HDR OETF │ │ BT2020) │ │ HDR) │ │ │ │
> > + └────────────┘ └─────────────┘ └─────────────┘
> └─────────────┘ │ │ │
> > + │ │ │
> > + │ │ │
> > +
> > +│ │ │
> >
> +┌──────────────────────────────────────────────────────────────────
> ──
> > +───────────┴─┴──┘
> > +│
> > +│ ┌─────────────┐ ┌─────────────┐ ┌───────────────┐
> > +│ │ CRTC Degamma│ │ CRTC CTM │ │ CRTC Gamma │
> > +└─┤ Use to make ├─────►│ Use for any ├─────►│ Use for Tone ├─────►
> TO Port
> > + │ data linear │ │ Color Space │ │ Mapping/apply │
> > + │ after blend │ │ Conversion │ │ transfer func │
> > + └─────────────┘ └─────────────┘ └───────────────┘
> > +
> > +
> > +This patch series adds properties for plane color features. It adds
> > +properties for degamma used to linearize data and CSC used for gamut
> > +conversion. It also includes Gamma support used to again
> > +non-linearize data as per panel supported color space. These can be
> > +utilize by user space to convert planes from one format to another,
> > +one color space to another etc.
> > +
> > +Userspace can take smart blending decisions and utilize these
> > +hardware supported plane color features to get accurate color
> > +profile. The same can help in consistent color quality from source to
> > +panel taking advantage of advanced color features in hardware.
> > +
> > +These patches add the property interfaces and enable helper functions.
> > +This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > +can build up and add other platform/hardware specific implementation
> > +on top of this series.
> > +
> > +Credits: Special mention and credits to Ville Syrjala for coming up
> > +with a design for this feature and inputs. This series is based on
> > +his original design and idea.
> >
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
2021-11-25 20:43 ` [Intel-gfx] " Shankar, Uma
@ 2021-11-26 8:21 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-26 8:21 UTC (permalink / raw)
To: Shankar, Uma; +Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian
[-- Attachment #1: Type: text/plain, Size: 5231 bytes --]
On Thu, 25 Nov 2021 20:43:19 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Harry Wentland <harry.wentland@amd.com>
> > Sent: Tuesday, November 23, 2021 8:35 PM
> > To: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> > devel@lists.freedesktop.org
> > Cc: ville.syrjala@linux.intel.com; ppaalanen@gmail.com; brian.starkey@arm.com;
> > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> >
> >
> > On 2021-09-06 17:38, Uma Shankar wrote:
> > > This is a RFC proposal for plane color hardware blocks.
> > > It exposes the property interface to userspace and calls out the
> > > details or interfaces created and the intended purpose.
> > >
> > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > ---
> > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > +++++++++++++++++++
> > > 1 file changed, 167 insertions(+)
> > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> > >
> > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > new file mode 100644
> > > index 000000000000..0d1ca858783b
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > @@ -0,0 +1,167 @@
> > > +==================================================
> > > +Display Color Pipeline: Proposed DRM Properties
> > > +==================================================
> > > +
> > > +This is how a typical display color hardware pipeline looks like:
> > > + +-------------------------------------------+
> > > + | RAM |
> > > + | +------+ +---------+ +---------+ |
> > > + | | FB 1 | | FB 2 | | FB N | |
> > > + | +------+ +---------+ +---------+ |
> > > + +-------------------------------------------+
> > > + | Plane Color Hardware Block |
> > > + +--------------------------------------------+
> > > + | +---v-----+ +---v-------+ +---v------+ |
> > > + | | Plane A | | Plane B | | Plane N | |
> > > + | | DeGamma | | Degamma | | Degamma | |
> > > + | +---+-----+ +---+-------+ +---+------+ |
> > > + | | | | |
> > > + | +---v-----+ +---v-------+ +---v------+ |
> > > + | |Plane A | | Plane B | | Plane N | |
> > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > > + | +---+-----+ +----+------+ +----+-----+ |
> > > + | | | | |
> > > + | +---v-----+ +----v------+ +----v-----+ |
> > > + | | Plane A | | Plane B | | Plane N | |
> > > + | | Gamma | | Gamma | | Gamma | |
> > > + | +---+-----+ +----+------+ +----+-----+ |
> > > + | | | | |
> > > + +--------------------------------------------+
> > > ++------v--------------v---------------v-------|
> > > +|| ||
> > > +|| Pipe Blender ||
> > > ++--------------------+------------------------+
> > > +| | |
> > > +| +-----------v----------+ |
> > > +| | Pipe DeGamma | |
> > > +| | | |
> > > +| +-----------+----------+ |
> > > +| | Pipe Color |
> > > +| +-----------v----------+ Hardware |
> > > +| | Pipe CSC/CTM | |
> > > +| | | |
> > > +| +-----------+----------+ |
> > > +| | |
> > > +| +-----------v----------+ |
> > > +| | Pipe Gamma | |
> > > +| | | |
> > > +| +-----------+----------+ |
> > > +| | |
> > > ++---------------------------------------------+
> > > + |
> > > + v
> > > + Pipe Output
> > > +
> >
> > This diagram defines what happens before and after the blending space but did
> > where does scaling fit into it? Scaling can look different when performed in linear or
> > non-linear space so I think it is important to define where in the pipeline it sits.
> >
> > In my view scaling would happen between plane degamma and plane CSC.
>
> Yeah we can add scaling as well to make it clear. Scaling ideally should happen after
> Degamma. In intel's case it is after the CSC.
Btw. are you aware that if a plane has an alpha channel which is used
for pixel coverage (i.e. shape anti-aliasing), then non-nearest
sampling and therefore also scaling must operate on alpha
pre-multiplied optical (linear) values?
For the best results, of course.
So after degamma indeed, but you cannot degamma with pre-multiplied
alpha, yet scaling should use pre-multiplied alpha.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
@ 2021-11-26 8:21 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-26 8:21 UTC (permalink / raw)
To: Shankar, Uma; +Cc: intel-gfx, dri-devel, sebastian, Harry Wentland
[-- Attachment #1: Type: text/plain, Size: 5231 bytes --]
On Thu, 25 Nov 2021 20:43:19 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Harry Wentland <harry.wentland@amd.com>
> > Sent: Tuesday, November 23, 2021 8:35 PM
> > To: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> > devel@lists.freedesktop.org
> > Cc: ville.syrjala@linux.intel.com; ppaalanen@gmail.com; brian.starkey@arm.com;
> > sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
> >
> >
> >
> > On 2021-09-06 17:38, Uma Shankar wrote:
> > > This is a RFC proposal for plane color hardware blocks.
> > > It exposes the property interface to userspace and calls out the
> > > details or interfaces created and the intended purpose.
> > >
> > > Credits: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > ---
> > > Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> > > +++++++++++++++++++
> > > 1 file changed, 167 insertions(+)
> > > create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> > >
> > > diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > new file mode 100644
> > > index 000000000000..0d1ca858783b
> > > --- /dev/null
> > > +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> > > @@ -0,0 +1,167 @@
> > > +==================================================
> > > +Display Color Pipeline: Proposed DRM Properties
> > > +==================================================
> > > +
> > > +This is how a typical display color hardware pipeline looks like:
> > > + +-------------------------------------------+
> > > + | RAM |
> > > + | +------+ +---------+ +---------+ |
> > > + | | FB 1 | | FB 2 | | FB N | |
> > > + | +------+ +---------+ +---------+ |
> > > + +-------------------------------------------+
> > > + | Plane Color Hardware Block |
> > > + +--------------------------------------------+
> > > + | +---v-----+ +---v-------+ +---v------+ |
> > > + | | Plane A | | Plane B | | Plane N | |
> > > + | | DeGamma | | Degamma | | Degamma | |
> > > + | +---+-----+ +---+-------+ +---+------+ |
> > > + | | | | |
> > > + | +---v-----+ +---v-------+ +---v------+ |
> > > + | |Plane A | | Plane B | | Plane N | |
> > > + | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > > + | +---+-----+ +----+------+ +----+-----+ |
> > > + | | | | |
> > > + | +---v-----+ +----v------+ +----v-----+ |
> > > + | | Plane A | | Plane B | | Plane N | |
> > > + | | Gamma | | Gamma | | Gamma | |
> > > + | +---+-----+ +----+------+ +----+-----+ |
> > > + | | | | |
> > > + +--------------------------------------------+
> > > ++------v--------------v---------------v-------|
> > > +|| ||
> > > +|| Pipe Blender ||
> > > ++--------------------+------------------------+
> > > +| | |
> > > +| +-----------v----------+ |
> > > +| | Pipe DeGamma | |
> > > +| | | |
> > > +| +-----------+----------+ |
> > > +| | Pipe Color |
> > > +| +-----------v----------+ Hardware |
> > > +| | Pipe CSC/CTM | |
> > > +| | | |
> > > +| +-----------+----------+ |
> > > +| | |
> > > +| +-----------v----------+ |
> > > +| | Pipe Gamma | |
> > > +| | | |
> > > +| +-----------+----------+ |
> > > +| | |
> > > ++---------------------------------------------+
> > > + |
> > > + v
> > > + Pipe Output
> > > +
> >
> > This diagram defines what happens before and after the blending space but did
> > where does scaling fit into it? Scaling can look different when performed in linear or
> > non-linear space so I think it is important to define where in the pipeline it sits.
> >
> > In my view scaling would happen between plane degamma and plane CSC.
>
> Yeah we can add scaling as well to make it clear. Scaling ideally should happen after
> Degamma. In intel's case it is after the CSC.
Btw. are you aware that if a plane has an alpha channel which is used
for pixel coverage (i.e. shape anti-aliasing), then non-nearest
sampling and therefore also scaling must operate on alpha
pre-multiplied optical (linear) values?
For the best results, of course.
So after degamma indeed, but you cannot degamma with pre-multiplied
alpha, yet scaling should use pre-multiplied alpha.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values.
This also defines a new structure to define color lut ranges,
along with related macro definitions and enums. This will help
describe multi segmented lut ranges in the hardware.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 90c55383f1ee..1079794c86c3 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -903,6 +903,64 @@ struct hdr_output_metadata {
};
};
+/*
+ * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
+ * can be used for either purpose, but not simultaneously. To expose
+ * modes that support gamma and degamma simultaneously the gamma mode
+ * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
+ * ranges.
+ */
+/* LUT is for gamma (after CTM) */
+#define DRM_MODE_LUT_GAMMA BIT(0)
+/* LUT is for degamma (before CTM) */
+#define DRM_MODE_LUT_DEGAMMA BIT(1)
+/* linearly interpolate between the points */
+#define DRM_MODE_LUT_INTERPOLATE BIT(2)
+/*
+ * the last value of the previous range is the
+ * first value of the current range.
+ */
+#define DRM_MODE_LUT_REUSE_LAST BIT(3)
+/* the curve must be non-decreasing */
+#define DRM_MODE_LUT_NON_DECREASING BIT(4)
+/* the curve is reflected across origin for negative inputs */
+#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
+/* the same curve (red) is used for blue and green channels as well */
+#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
+
+struct drm_color_lut_range {
+ /* DRM_MODE_LUT_* */
+ __u32 flags;
+ /* number of points on the curve */
+ __u16 count;
+ /* input/output bits per component */
+ __u8 input_bpc, output_bpc;
+ /* input start/end values */
+ __s32 start, end;
+ /* output min/max values */
+ __s32 min, max;
+};
+
+enum lut_type {
+ LUT_TYPE_DEGAMMA = 0,
+ LUT_TYPE_GAMMA = 1,
+};
+
+/*
+ * Creating 64 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+ /*
+ * Data is U32.32 fixed point format.
+ */
+ __u64 red;
+ __u64 green;
+ __u64 blue;
+ __u64 reserved;
+};
+
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values.
This also defines a new structure to define color lut ranges,
along with related macro definitions and enums. This will help
describe multi segmented lut ranges in the hardware.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 90c55383f1ee..1079794c86c3 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -903,6 +903,64 @@ struct hdr_output_metadata {
};
};
+/*
+ * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
+ * can be used for either purpose, but not simultaneously. To expose
+ * modes that support gamma and degamma simultaneously the gamma mode
+ * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
+ * ranges.
+ */
+/* LUT is for gamma (after CTM) */
+#define DRM_MODE_LUT_GAMMA BIT(0)
+/* LUT is for degamma (before CTM) */
+#define DRM_MODE_LUT_DEGAMMA BIT(1)
+/* linearly interpolate between the points */
+#define DRM_MODE_LUT_INTERPOLATE BIT(2)
+/*
+ * the last value of the previous range is the
+ * first value of the current range.
+ */
+#define DRM_MODE_LUT_REUSE_LAST BIT(3)
+/* the curve must be non-decreasing */
+#define DRM_MODE_LUT_NON_DECREASING BIT(4)
+/* the curve is reflected across origin for negative inputs */
+#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
+/* the same curve (red) is used for blue and green channels as well */
+#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
+
+struct drm_color_lut_range {
+ /* DRM_MODE_LUT_* */
+ __u32 flags;
+ /* number of points on the curve */
+ __u16 count;
+ /* input/output bits per component */
+ __u8 input_bpc, output_bpc;
+ /* input start/end values */
+ __s32 start, end;
+ /* output min/max values */
+ __s32 min, max;
+};
+
+enum lut_type {
+ LUT_TYPE_DEGAMMA = 0,
+ LUT_TYPE_GAMMA = 1,
+};
+
+/*
+ * Creating 64 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+ /*
+ * Data is U32.32 fixed point format.
+ */
+ __u64 red;
+ __u64 green;
+ __u64 blue;
+ __u64 reserved;
+};
+
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-09-06 21:38 ` Uma Shankar
@ 2021-11-03 15:08 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-03 15:08 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: Shashank.Sharma, sebastian
On 2021-09-06 17:38, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values.
>
> This also defines a new structure to define color lut ranges,
> along with related macro definitions and enums. This will help
> describe multi segmented lut ranges in the hardware.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 90c55383f1ee..1079794c86c3 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> };
> };
>
> +/*
> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> + * can be used for either purpose, but not simultaneously. To expose
> + * modes that support gamma and degamma simultaneously the gamma mode
> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> + * ranges.
> + */
> +/* LUT is for gamma (after CTM) */
> +#define DRM_MODE_LUT_GAMMA BIT(0)
> +/* LUT is for degamma (before CTM) */
> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> +/* linearly interpolate between the points */
> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> +/*
> + * the last value of the previous range is the
> + * first value of the current range.
> + */
> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> +/* the curve must be non-decreasing */
> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> +/* the curve is reflected across origin for negative inputs */
> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> +/* the same curve (red) is used for blue and green channels as well */
> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> +
> +struct drm_color_lut_range {
> + /* DRM_MODE_LUT_* */
> + __u32 flags;
> + /* number of points on the curve */
> + __u16 count;
> + /* input/output bits per component */
> + __u8 input_bpc, output_bpc;
> + /* input start/end values */
> + __s32 start, end;
> + /* output min/max values */
> + __s32 min, max;
> +};
> +
> +enum lut_type {
> + LUT_TYPE_DEGAMMA = 0,
> + LUT_TYPE_GAMMA = 1,
> +};
> +
> +/*
> + * Creating 64 bit palette entries for better data
> + * precision. This will be required for HDR and
> + * similar color processing usecases.
> + */
> +struct drm_color_lut_ext {
> + /*
> + * Data is U32.32 fixed point format.
> + */
> + __u64 red;
> + __u64 green;
> + __u64 blue;
> + __u64 reserved;
> +};
I've been drawing out examples of drm_color_lut_range defined PWLs
and understand a bit better what you and Ville are trying to accomplish
with it. It actually makes a lot of sense and would allow for a generic
way to populate different PWL definitions with a generic function.
But I still have some key questions that either are not answered in these
patch sets or that I somehow overlooked.
Can you explain how the U32.32 fixed point format relates to the input_bpc
and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
the framebuffer.
E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
is non-multiplied)?
If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
be interpreted as 0x3ff << (24-10)?
Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
the output value be 0x3ff << (16-10)?
On AMD HW the pipe-internal format is a custom floating point format. We could
probably express that in terms of input/output_bpc and do the translation in our
driver between that and the internal floating point format, depending on the
framebuffer format, but there is the added complication of the magnitude of the
pixel data and correlating HDR with SDR planes.
E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
to represent that with the drm_color_lut_range definition.
If some of these questions should be obvious I apologize for being a bit dense,
though it helps to make this accessible to the lowest common denominator
to ensure not only the smartest devs can work with this.
Harry
> +
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-03 15:08 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-03 15:08 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: Cyr, Aric, ppaalanen, sebastian
On 2021-09-06 17:38, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values.
>
> This also defines a new structure to define color lut ranges,
> along with related macro definitions and enums. This will help
> describe multi segmented lut ranges in the hardware.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 90c55383f1ee..1079794c86c3 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> };
> };
>
> +/*
> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> + * can be used for either purpose, but not simultaneously. To expose
> + * modes that support gamma and degamma simultaneously the gamma mode
> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> + * ranges.
> + */
> +/* LUT is for gamma (after CTM) */
> +#define DRM_MODE_LUT_GAMMA BIT(0)
> +/* LUT is for degamma (before CTM) */
> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> +/* linearly interpolate between the points */
> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> +/*
> + * the last value of the previous range is the
> + * first value of the current range.
> + */
> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> +/* the curve must be non-decreasing */
> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> +/* the curve is reflected across origin for negative inputs */
> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> +/* the same curve (red) is used for blue and green channels as well */
> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> +
> +struct drm_color_lut_range {
> + /* DRM_MODE_LUT_* */
> + __u32 flags;
> + /* number of points on the curve */
> + __u16 count;
> + /* input/output bits per component */
> + __u8 input_bpc, output_bpc;
> + /* input start/end values */
> + __s32 start, end;
> + /* output min/max values */
> + __s32 min, max;
> +};
> +
> +enum lut_type {
> + LUT_TYPE_DEGAMMA = 0,
> + LUT_TYPE_GAMMA = 1,
> +};
> +
> +/*
> + * Creating 64 bit palette entries for better data
> + * precision. This will be required for HDR and
> + * similar color processing usecases.
> + */
> +struct drm_color_lut_ext {
> + /*
> + * Data is U32.32 fixed point format.
> + */
> + __u64 red;
> + __u64 green;
> + __u64 blue;
> + __u64 reserved;
> +};
I've been drawing out examples of drm_color_lut_range defined PWLs
and understand a bit better what you and Ville are trying to accomplish
with it. It actually makes a lot of sense and would allow for a generic
way to populate different PWL definitions with a generic function.
But I still have some key questions that either are not answered in these
patch sets or that I somehow overlooked.
Can you explain how the U32.32 fixed point format relates to the input_bpc
and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
the framebuffer.
E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
is non-multiplied)?
If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
be interpreted as 0x3ff << (24-10)?
Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
the output value be 0x3ff << (16-10)?
On AMD HW the pipe-internal format is a custom floating point format. We could
probably express that in terms of input/output_bpc and do the translation in our
driver between that and the internal floating point format, depending on the
framebuffer format, but there is the added complication of the magnitude of the
pixel data and correlating HDR with SDR planes.
E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
to represent that with the drm_color_lut_range definition.
If some of these questions should be obvious I apologize for being a bit dense,
though it helps to make this accessible to the lowest common denominator
to ensure not only the smartest devs can work with this.
Harry
> +
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-03 15:08 ` [Intel-gfx] " Harry Wentland
@ 2021-11-04 8:38 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-04 8:38 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
[-- Attachment #1: Type: text/plain, Size: 6138 bytes --]
On Wed, 3 Nov 2021 11:08:13 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Existing LUT precision structure is having only 16 bit
> > precision. This is not enough for upcoming enhanced hardwares
> > and advance usecases like HDR processing. Hence added a new
> > structure with 32 bit precision values.
> >
> > This also defines a new structure to define color lut ranges,
> > along with related macro definitions and enums. This will help
> > describe multi segmented lut ranges in the hardware.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 90c55383f1ee..1079794c86c3 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */
> > +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> > +/* linearly interpolate between the points */
> > +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well */
> > +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > +enum lut_type {
> > + LUT_TYPE_DEGAMMA = 0,
> > + LUT_TYPE_GAMMA = 1,
> > +};
> > +
> > +/*
> > + * Creating 64 bit palette entries for better data
> > + * precision. This will be required for HDR and
> > + * similar color processing usecases.
> > + */
> > +struct drm_color_lut_ext {
> > + /*
> > + * Data is U32.32 fixed point format.
> > + */
> > + __u64 red;
> > + __u64 green;
> > + __u64 blue;
> > + __u64 reserved;
> > +};
>
> I've been drawing out examples of drm_color_lut_range defined PWLs
> and understand a bit better what you and Ville are trying to accomplish
> with it. It actually makes a lot of sense and would allow for a generic
> way to populate different PWL definitions with a generic function.
>
> But I still have some key questions that either are not answered in these
> patch sets or that I somehow overlooked.
>
> Can you explain how the U32.32 fixed point format relates to the input_bpc
> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> the framebuffer.
>
> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> is non-multiplied)?
>
> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> be interpreted as 0x3ff << (24-10)?
>
> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> the output value be 0x3ff << (16-10)?
>
> On AMD HW the pipe-internal format is a custom floating point format. We could
> probably express that in terms of input/output_bpc and do the translation in our
> driver between that and the internal floating point format, depending on the
> framebuffer format, but there is the added complication of the magnitude of the
> pixel data and correlating HDR with SDR planes.
>
> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> to represent that with the drm_color_lut_range definition.
Hi Harry,
I think you just would not. Conceptually an SDR plane gets its very own
LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
abstract KMS color pipeline, where [0.0, 1.0] is always the full
dynamic range at any point of the pipeline, meaning it is relative to
its placement in the pipeline. If you want to use values >1.0 in hw,
you can do so under the hood.
At least that is how I would imagine things. With LUTs in general, I
don't think I have ever seen LUT input domain being explicitly defined
to something else than [0.0, 1.0] relative to the elements in the LUT
where 0.0 maps exactly to the first element and 1.0 maps exactly to the
last element.
I'm of course open to other suggestions, but having values outside of
[0.0, 1.0] range in the abstract pipeline will always raise the
question: how do you feed those to the LUT next in the pipeline.
Yeah, I have no idea what it should mean if an FB has a format that
allows values beyond [0.0, 1.0].
Thanks,
pq
> If some of these questions should be obvious I apologize for being a bit dense,
> though it helps to make this accessible to the lowest common denominator
> to ensure not only the smartest devs can work with this.
>
> Harry
>
> > +
> > #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> > #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> > #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-04 8:38 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-04 8:38 UTC (permalink / raw)
To: Harry Wentland; +Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian
[-- Attachment #1: Type: text/plain, Size: 6138 bytes --]
On Wed, 3 Nov 2021 11:08:13 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Existing LUT precision structure is having only 16 bit
> > precision. This is not enough for upcoming enhanced hardwares
> > and advance usecases like HDR processing. Hence added a new
> > structure with 32 bit precision values.
> >
> > This also defines a new structure to define color lut ranges,
> > along with related macro definitions and enums. This will help
> > describe multi segmented lut ranges in the hardware.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 90c55383f1ee..1079794c86c3 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> > };
> > };
> >
> > +/*
> > + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> > + * can be used for either purpose, but not simultaneously. To expose
> > + * modes that support gamma and degamma simultaneously the gamma mode
> > + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> > + * ranges.
> > + */
> > +/* LUT is for gamma (after CTM) */
> > +#define DRM_MODE_LUT_GAMMA BIT(0)
> > +/* LUT is for degamma (before CTM) */
> > +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> > +/* linearly interpolate between the points */
> > +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> > +/*
> > + * the last value of the previous range is the
> > + * first value of the current range.
> > + */
> > +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> > +/* the curve must be non-decreasing */
> > +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> > +/* the curve is reflected across origin for negative inputs */
> > +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> > +/* the same curve (red) is used for blue and green channels as well */
> > +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> > +
> > +struct drm_color_lut_range {
> > + /* DRM_MODE_LUT_* */
> > + __u32 flags;
> > + /* number of points on the curve */
> > + __u16 count;
> > + /* input/output bits per component */
> > + __u8 input_bpc, output_bpc;
> > + /* input start/end values */
> > + __s32 start, end;
> > + /* output min/max values */
> > + __s32 min, max;
> > +};
> > +
> > +enum lut_type {
> > + LUT_TYPE_DEGAMMA = 0,
> > + LUT_TYPE_GAMMA = 1,
> > +};
> > +
> > +/*
> > + * Creating 64 bit palette entries for better data
> > + * precision. This will be required for HDR and
> > + * similar color processing usecases.
> > + */
> > +struct drm_color_lut_ext {
> > + /*
> > + * Data is U32.32 fixed point format.
> > + */
> > + __u64 red;
> > + __u64 green;
> > + __u64 blue;
> > + __u64 reserved;
> > +};
>
> I've been drawing out examples of drm_color_lut_range defined PWLs
> and understand a bit better what you and Ville are trying to accomplish
> with it. It actually makes a lot of sense and would allow for a generic
> way to populate different PWL definitions with a generic function.
>
> But I still have some key questions that either are not answered in these
> patch sets or that I somehow overlooked.
>
> Can you explain how the U32.32 fixed point format relates to the input_bpc
> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> the framebuffer.
>
> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> is non-multiplied)?
>
> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> be interpreted as 0x3ff << (24-10)?
>
> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> the output value be 0x3ff << (16-10)?
>
> On AMD HW the pipe-internal format is a custom floating point format. We could
> probably express that in terms of input/output_bpc and do the translation in our
> driver between that and the internal floating point format, depending on the
> framebuffer format, but there is the added complication of the magnitude of the
> pixel data and correlating HDR with SDR planes.
>
> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> to represent that with the drm_color_lut_range definition.
Hi Harry,
I think you just would not. Conceptually an SDR plane gets its very own
LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
abstract KMS color pipeline, where [0.0, 1.0] is always the full
dynamic range at any point of the pipeline, meaning it is relative to
its placement in the pipeline. If you want to use values >1.0 in hw,
you can do so under the hood.
At least that is how I would imagine things. With LUTs in general, I
don't think I have ever seen LUT input domain being explicitly defined
to something else than [0.0, 1.0] relative to the elements in the LUT
where 0.0 maps exactly to the first element and 1.0 maps exactly to the
last element.
I'm of course open to other suggestions, but having values outside of
[0.0, 1.0] range in the abstract pipeline will always raise the
question: how do you feed those to the LUT next in the pipeline.
Yeah, I have no idea what it should mean if an FB has a format that
allows values beyond [0.0, 1.0].
Thanks,
pq
> If some of these questions should be obvious I apologize for being a bit dense,
> though it helps to make this accessible to the lowest common denominator
> to ensure not only the smartest devs can work with this.
>
> Harry
>
> > +
> > #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> > #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> > #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-04 8:38 ` [Intel-gfx] " Pekka Paalanen
@ 2021-11-04 16:27 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-04 16:27 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On 2021-11-04 04:38, Pekka Paalanen wrote:
> On Wed, 3 Nov 2021 11:08:13 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> On 2021-09-06 17:38, Uma Shankar wrote:
>>> Existing LUT precision structure is having only 16 bit
>>> precision. This is not enough for upcoming enhanced hardwares
>>> and advance usecases like HDR processing. Hence added a new
>>> structure with 32 bit precision values.
>>>
>>> This also defines a new structure to define color lut ranges,
>>> along with related macro definitions and enums. This will help
>>> describe multi segmented lut ranges in the hardware.
>>>
>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>> ---
>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 58 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 90c55383f1ee..1079794c86c3 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
>>> };
>>> };
>>>
>>> +/*
>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
>>> + * can be used for either purpose, but not simultaneously. To expose
>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
>>> + * ranges.
>>> + */
>>> +/* LUT is for gamma (after CTM) */
>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>> +/* LUT is for degamma (before CTM) */
>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
>>> +/* linearly interpolate between the points */
>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
>>> +/*
>>> + * the last value of the previous range is the
>>> + * first value of the current range.
>>> + */
>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>> +/* the curve must be non-decreasing */
>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
>>> +/* the curve is reflected across origin for negative inputs */
>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>> +/* the same curve (red) is used for blue and green channels as well */
>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>> +
>>> +struct drm_color_lut_range {
>>> + /* DRM_MODE_LUT_* */
>>> + __u32 flags;
>>> + /* number of points on the curve */
>>> + __u16 count;
>>> + /* input/output bits per component */
>>> + __u8 input_bpc, output_bpc;
>>> + /* input start/end values */
>>> + __s32 start, end;
>>> + /* output min/max values */
>>> + __s32 min, max;
>>> +};
>>> +
>>> +enum lut_type {
>>> + LUT_TYPE_DEGAMMA = 0,
>>> + LUT_TYPE_GAMMA = 1,
>>> +};
>>> +
>>> +/*
>>> + * Creating 64 bit palette entries for better data
>>> + * precision. This will be required for HDR and
>>> + * similar color processing usecases.
>>> + */
>>> +struct drm_color_lut_ext {
>>> + /*
>>> + * Data is U32.32 fixed point format.
>>> + */
>>> + __u64 red;
>>> + __u64 green;
>>> + __u64 blue;
>>> + __u64 reserved;
>>> +};
>>
>> I've been drawing out examples of drm_color_lut_range defined PWLs
>> and understand a bit better what you and Ville are trying to accomplish
>> with it. It actually makes a lot of sense and would allow for a generic
>> way to populate different PWL definitions with a generic function.
>>
>> But I still have some key questions that either are not answered in these
>> patch sets or that I somehow overlooked.
>>
>> Can you explain how the U32.32 fixed point format relates to the input_bpc
>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
>> the framebuffer.
>>
>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
>> is non-multiplied)?
>>
>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
>> be interpreted as 0x3ff << (24-10)?
>>
>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
>> the output value be 0x3ff << (16-10)?
>>
>> On AMD HW the pipe-internal format is a custom floating point format. We could
>> probably express that in terms of input/output_bpc and do the translation in our
>> driver between that and the internal floating point format, depending on the
>> framebuffer format, but there is the added complication of the magnitude of the
>> pixel data and correlating HDR with SDR planes.
>>
>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
>> to represent that with the drm_color_lut_range definition.
>
>
> Hi Harry,
>
> I think you just would not. Conceptually an SDR plane gets its very own
> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> abstract KMS color pipeline, where [0.0, 1.0] is always the full
> dynamic range at any point of the pipeline, meaning it is relative to
> its placement in the pipeline. If you want to use values >1.0 in hw,
> you can do so under the hood.
>
> At least that is how I would imagine things. With LUTs in general, I
> don't think I have ever seen LUT input domain being explicitly defined
> to something else than [0.0, 1.0] relative to the elements in the LUT
> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> last element.
>
> I'm of course open to other suggestions, but having values outside of
> [0.0, 1.0] range in the abstract pipeline will always raise the
> question: how do you feed those to the LUT next in the pipeline.
>
AMD HW defines the LUT addressing in floating point space and allows
for addressing beyond 1.0. In fact on other OSes our driver uses
[0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
There are color spaces that extend beyond 1.0 and even into the negative
range: https://en.wikipedia.org/wiki/ScRGB
I don't think we should define the LUT to be limited to [0.0, 1.0].
If the framebuffer is not in FP16 the question then becomes how
the integer pixel values relate to LUT addressing.
As well, LUT entries are defined to be U32.32 fixed point, also
allowing for entries much greater than 1.0. If those are programmed
as entries in the input (degamma) LUT how will they be used to address
entries in the output (gamma) LUT?
Maybe we want to say the actual input values are being used to
address the LUT entries? But if we look at segment 1 of Uma's
d13_degamma_hdr definition we see that the range of 0 to
(1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
LUT entries. So this interpretation doesn't make sense.
You can see, I'm still confused by these definitions. An IGT
test would help explain the API intentions a bit better, though
I would like to see more precise documentation.
Despite my confusion I think the segmented PWL definitions are
a neat way to concisely describe the HW capabilities to
userspace and a concise way for userspace to provide the LUT
more precisely than with a uniformly spaced LUT.
Harry
> Yeah, I have no idea what it should mean if an FB has a format that
> allows values beyond [0.0, 1.0].
>
>
> Thanks,
> pq
>
>
>> If some of these questions should be obvious I apologize for being a bit dense,
>> though it helps to make this accessible to the lowest common denominator
>> to ensure not only the smartest devs can work with this.
>>
>> Harry
>>
>>> +
>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>>>
>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-04 16:27 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-04 16:27 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian
On 2021-11-04 04:38, Pekka Paalanen wrote:
> On Wed, 3 Nov 2021 11:08:13 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> On 2021-09-06 17:38, Uma Shankar wrote:
>>> Existing LUT precision structure is having only 16 bit
>>> precision. This is not enough for upcoming enhanced hardwares
>>> and advance usecases like HDR processing. Hence added a new
>>> structure with 32 bit precision values.
>>>
>>> This also defines a new structure to define color lut ranges,
>>> along with related macro definitions and enums. This will help
>>> describe multi segmented lut ranges in the hardware.
>>>
>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>> ---
>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 58 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 90c55383f1ee..1079794c86c3 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
>>> };
>>> };
>>>
>>> +/*
>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
>>> + * can be used for either purpose, but not simultaneously. To expose
>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
>>> + * ranges.
>>> + */
>>> +/* LUT is for gamma (after CTM) */
>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>> +/* LUT is for degamma (before CTM) */
>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
>>> +/* linearly interpolate between the points */
>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
>>> +/*
>>> + * the last value of the previous range is the
>>> + * first value of the current range.
>>> + */
>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>> +/* the curve must be non-decreasing */
>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
>>> +/* the curve is reflected across origin for negative inputs */
>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>> +/* the same curve (red) is used for blue and green channels as well */
>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>> +
>>> +struct drm_color_lut_range {
>>> + /* DRM_MODE_LUT_* */
>>> + __u32 flags;
>>> + /* number of points on the curve */
>>> + __u16 count;
>>> + /* input/output bits per component */
>>> + __u8 input_bpc, output_bpc;
>>> + /* input start/end values */
>>> + __s32 start, end;
>>> + /* output min/max values */
>>> + __s32 min, max;
>>> +};
>>> +
>>> +enum lut_type {
>>> + LUT_TYPE_DEGAMMA = 0,
>>> + LUT_TYPE_GAMMA = 1,
>>> +};
>>> +
>>> +/*
>>> + * Creating 64 bit palette entries for better data
>>> + * precision. This will be required for HDR and
>>> + * similar color processing usecases.
>>> + */
>>> +struct drm_color_lut_ext {
>>> + /*
>>> + * Data is U32.32 fixed point format.
>>> + */
>>> + __u64 red;
>>> + __u64 green;
>>> + __u64 blue;
>>> + __u64 reserved;
>>> +};
>>
>> I've been drawing out examples of drm_color_lut_range defined PWLs
>> and understand a bit better what you and Ville are trying to accomplish
>> with it. It actually makes a lot of sense and would allow for a generic
>> way to populate different PWL definitions with a generic function.
>>
>> But I still have some key questions that either are not answered in these
>> patch sets or that I somehow overlooked.
>>
>> Can you explain how the U32.32 fixed point format relates to the input_bpc
>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
>> the framebuffer.
>>
>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
>> is non-multiplied)?
>>
>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
>> be interpreted as 0x3ff << (24-10)?
>>
>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
>> the output value be 0x3ff << (16-10)?
>>
>> On AMD HW the pipe-internal format is a custom floating point format. We could
>> probably express that in terms of input/output_bpc and do the translation in our
>> driver between that and the internal floating point format, depending on the
>> framebuffer format, but there is the added complication of the magnitude of the
>> pixel data and correlating HDR with SDR planes.
>>
>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
>> to represent that with the drm_color_lut_range definition.
>
>
> Hi Harry,
>
> I think you just would not. Conceptually an SDR plane gets its very own
> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> abstract KMS color pipeline, where [0.0, 1.0] is always the full
> dynamic range at any point of the pipeline, meaning it is relative to
> its placement in the pipeline. If you want to use values >1.0 in hw,
> you can do so under the hood.
>
> At least that is how I would imagine things. With LUTs in general, I
> don't think I have ever seen LUT input domain being explicitly defined
> to something else than [0.0, 1.0] relative to the elements in the LUT
> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> last element.
>
> I'm of course open to other suggestions, but having values outside of
> [0.0, 1.0] range in the abstract pipeline will always raise the
> question: how do you feed those to the LUT next in the pipeline.
>
AMD HW defines the LUT addressing in floating point space and allows
for addressing beyond 1.0. In fact on other OSes our driver uses
[0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
There are color spaces that extend beyond 1.0 and even into the negative
range: https://en.wikipedia.org/wiki/ScRGB
I don't think we should define the LUT to be limited to [0.0, 1.0].
If the framebuffer is not in FP16 the question then becomes how
the integer pixel values relate to LUT addressing.
As well, LUT entries are defined to be U32.32 fixed point, also
allowing for entries much greater than 1.0. If those are programmed
as entries in the input (degamma) LUT how will they be used to address
entries in the output (gamma) LUT?
Maybe we want to say the actual input values are being used to
address the LUT entries? But if we look at segment 1 of Uma's
d13_degamma_hdr definition we see that the range of 0 to
(1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
LUT entries. So this interpretation doesn't make sense.
You can see, I'm still confused by these definitions. An IGT
test would help explain the API intentions a bit better, though
I would like to see more precise documentation.
Despite my confusion I think the segmented PWL definitions are
a neat way to concisely describe the HW capabilities to
userspace and a concise way for userspace to provide the LUT
more precisely than with a uniformly spaced LUT.
Harry
> Yeah, I have no idea what it should mean if an FB has a format that
> allows values beyond [0.0, 1.0].
>
>
> Thanks,
> pq
>
>
>> If some of these questions should be obvious I apologize for being a bit dense,
>> though it helps to make this accessible to the lowest common denominator
>> to ensure not only the smartest devs can work with this.
>>
>> Harry
>>
>>> +
>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>>>
>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-04 16:27 ` [Intel-gfx] " Harry Wentland
@ 2021-11-05 11:49 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-05 11:49 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>
>
> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > On Wed, 3 Nov 2021 11:08:13 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Existing LUT precision structure is having only 16 bit
> >>> precision. This is not enough for upcoming enhanced hardwares
> >>> and advance usecases like HDR processing. Hence added a new
> >>> structure with 32 bit precision values.
> >>>
> >>> This also defines a new structure to define color lut ranges,
> >>> along with related macro definitions and enums. This will help
> >>> describe multi segmented lut ranges in the hardware.
> >>>
> >>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>> ---
> >>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 58 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>> index 90c55383f1ee..1079794c86c3 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> >>> };
> >>> };
> >>>
> >>> +/*
> >>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> >>> + * can be used for either purpose, but not simultaneously. To expose
> >>> + * modes that support gamma and degamma simultaneously the gamma mode
> >>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> >>> + * ranges.
> >>> + */
> >>> +/* LUT is for gamma (after CTM) */
> >>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>> +/* LUT is for degamma (before CTM) */
> >>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> >>> +/* linearly interpolate between the points */
> >>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>> +/*
> >>> + * the last value of the previous range is the
> >>> + * first value of the current range.
> >>> + */
> >>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>> +/* the curve must be non-decreasing */
> >>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>> +/* the curve is reflected across origin for negative inputs */
> >>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>> +/* the same curve (red) is used for blue and green channels as well */
> >>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>> +
> >>> +struct drm_color_lut_range {
> >>> + /* DRM_MODE_LUT_* */
> >>> + __u32 flags;
> >>> + /* number of points on the curve */
> >>> + __u16 count;
> >>> + /* input/output bits per component */
> >>> + __u8 input_bpc, output_bpc;
> >>> + /* input start/end values */
> >>> + __s32 start, end;
> >>> + /* output min/max values */
> >>> + __s32 min, max;
> >>> +};
> >>> +
> >>> +enum lut_type {
> >>> + LUT_TYPE_DEGAMMA = 0,
> >>> + LUT_TYPE_GAMMA = 1,
> >>> +};
> >>> +
> >>> +/*
> >>> + * Creating 64 bit palette entries for better data
> >>> + * precision. This will be required for HDR and
> >>> + * similar color processing usecases.
> >>> + */
> >>> +struct drm_color_lut_ext {
> >>> + /*
> >>> + * Data is U32.32 fixed point format.
> >>> + */
> >>> + __u64 red;
> >>> + __u64 green;
> >>> + __u64 blue;
> >>> + __u64 reserved;
> >>> +};
> >>
> >> I've been drawing out examples of drm_color_lut_range defined PWLs
> >> and understand a bit better what you and Ville are trying to accomplish
> >> with it. It actually makes a lot of sense and would allow for a generic
> >> way to populate different PWL definitions with a generic function.
> >>
> >> But I still have some key questions that either are not answered in these
> >> patch sets or that I somehow overlooked.
> >>
> >> Can you explain how the U32.32 fixed point format relates to the input_bpc
> >> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> >> the framebuffer.
> >>
> >> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> >> is non-multiplied)?
> >>
> >> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> >> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> >> be interpreted as 0x3ff << (24-10)?
> >>
> >> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> >> the output value be 0x3ff << (16-10)?
> >>
> >> On AMD HW the pipe-internal format is a custom floating point format. We could
> >> probably express that in terms of input/output_bpc and do the translation in our
> >> driver between that and the internal floating point format, depending on the
> >> framebuffer format, but there is the added complication of the magnitude of the
> >> pixel data and correlating HDR with SDR planes.
> >>
> >> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> >> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> >> to represent that with the drm_color_lut_range definition.
> >
> >
> > Hi Harry,
> >
> > I think you just would not. Conceptually an SDR plane gets its very own
> > LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> > b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> > abstract KMS color pipeline, where [0.0, 1.0] is always the full
> > dynamic range at any point of the pipeline, meaning it is relative to
> > its placement in the pipeline. If you want to use values >1.0 in hw,
> > you can do so under the hood.
> >
> > At least that is how I would imagine things. With LUTs in general, I
> > don't think I have ever seen LUT input domain being explicitly defined
> > to something else than [0.0, 1.0] relative to the elements in the LUT
> > where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> > last element.
> >
> > I'm of course open to other suggestions, but having values outside of
> > [0.0, 1.0] range in the abstract pipeline will always raise the
> > question: how do you feed those to the LUT next in the pipeline.
> >
>
> AMD HW defines the LUT addressing in floating point space and allows
> for addressing beyond 1.0. In fact on other OSes our driver uses
> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
>
> There are color spaces that extend beyond 1.0 and even into the negative
> range: https://en.wikipedia.org/wiki/ScRGB
>
> I don't think we should define the LUT to be limited to [0.0, 1.0].
That is not the intention, or at least wasn't my intention when
originally I proposed this gamma mode stuff. I specifically wanted
support for extended values. So 0.0-1.0 is supposed to be just the
range for the in gamut values.
>
> If the framebuffer is not in FP16 the question then becomes how
> the integer pixel values relate to LUT addressing.
The idea again is that 0.0-1.0 is the range for the in gamut
values. IIRC our hw does have the possibility of scaling all
the fp16 input values by some programmable constant factor,
but exposing that would require yet another uapi addition.
>
> As well, LUT entries are defined to be U32.32 fixed point, also
> allowing for entries much greater than 1.0. If those are programmed
> as entries in the input (degamma) LUT how will they be used to address
> entries in the output (gamma) LUT?
The u32.32 is a mistake I think. IMO we should be going for signed
values everywhere. Though our hw does not actually let us directly
program negative values for the LUT, rather the hw just reflects
the whole curve across the origin so the lookup is basically just
something like:
output = input < 0 ? -lut[abs(input)] : lut[input];
That is why there is that proposed DRM_MODE_LUT_REFLECT_NEGATIVE flag.
I think nouveau had something funny in its lut programming that
made me think that it might actually have straight up programmable
LUT entries for negative inputs as well. But I'm not sure if anyone
has actually tested that.
>
> Maybe we want to say the actual input values are being used to
> address the LUT entries? But if we look at segment 1 of Uma's
> d13_degamma_hdr definition we see that the range of 0 to
> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
> LUT entries. So this interpretation doesn't make sense.
>
> You can see, I'm still confused by these definitions. An IGT
> test would help explain the API intentions a bit better, though
> I would like to see more precise documentation.
>
> Despite my confusion I think the segmented PWL definitions are
> a neat way to concisely describe the HW capabilities to
> userspace and a concise way for userspace to provide the LUT
> more precisely than with a uniformly spaced LUT.
>
> Harry
>
> > Yeah, I have no idea what it should mean if an FB has a format that
> > allows values beyond [0.0, 1.0].
> >
> >
> > Thanks,
> > pq
> >
> >
> >> If some of these questions should be obvious I apologize for being a bit dense,
> >> though it helps to make this accessible to the lowest common denominator
> >> to ensure not only the smartest devs can work with this.
> >>
> >> Harry
> >>
> >>> +
> >>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> >>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> >>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >>>
> >>
> >
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-05 11:49 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-05 11:49 UTC (permalink / raw)
To: Harry Wentland; +Cc: Cyr, Aric, intel-gfx, Pekka Paalanen, dri-devel, sebastian
On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>
>
> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > On Wed, 3 Nov 2021 11:08:13 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Existing LUT precision structure is having only 16 bit
> >>> precision. This is not enough for upcoming enhanced hardwares
> >>> and advance usecases like HDR processing. Hence added a new
> >>> structure with 32 bit precision values.
> >>>
> >>> This also defines a new structure to define color lut ranges,
> >>> along with related macro definitions and enums. This will help
> >>> describe multi segmented lut ranges in the hardware.
> >>>
> >>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>> ---
> >>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 58 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>> index 90c55383f1ee..1079794c86c3 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> >>> };
> >>> };
> >>>
> >>> +/*
> >>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> >>> + * can be used for either purpose, but not simultaneously. To expose
> >>> + * modes that support gamma and degamma simultaneously the gamma mode
> >>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> >>> + * ranges.
> >>> + */
> >>> +/* LUT is for gamma (after CTM) */
> >>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>> +/* LUT is for degamma (before CTM) */
> >>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> >>> +/* linearly interpolate between the points */
> >>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>> +/*
> >>> + * the last value of the previous range is the
> >>> + * first value of the current range.
> >>> + */
> >>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>> +/* the curve must be non-decreasing */
> >>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>> +/* the curve is reflected across origin for negative inputs */
> >>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>> +/* the same curve (red) is used for blue and green channels as well */
> >>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>> +
> >>> +struct drm_color_lut_range {
> >>> + /* DRM_MODE_LUT_* */
> >>> + __u32 flags;
> >>> + /* number of points on the curve */
> >>> + __u16 count;
> >>> + /* input/output bits per component */
> >>> + __u8 input_bpc, output_bpc;
> >>> + /* input start/end values */
> >>> + __s32 start, end;
> >>> + /* output min/max values */
> >>> + __s32 min, max;
> >>> +};
> >>> +
> >>> +enum lut_type {
> >>> + LUT_TYPE_DEGAMMA = 0,
> >>> + LUT_TYPE_GAMMA = 1,
> >>> +};
> >>> +
> >>> +/*
> >>> + * Creating 64 bit palette entries for better data
> >>> + * precision. This will be required for HDR and
> >>> + * similar color processing usecases.
> >>> + */
> >>> +struct drm_color_lut_ext {
> >>> + /*
> >>> + * Data is U32.32 fixed point format.
> >>> + */
> >>> + __u64 red;
> >>> + __u64 green;
> >>> + __u64 blue;
> >>> + __u64 reserved;
> >>> +};
> >>
> >> I've been drawing out examples of drm_color_lut_range defined PWLs
> >> and understand a bit better what you and Ville are trying to accomplish
> >> with it. It actually makes a lot of sense and would allow for a generic
> >> way to populate different PWL definitions with a generic function.
> >>
> >> But I still have some key questions that either are not answered in these
> >> patch sets or that I somehow overlooked.
> >>
> >> Can you explain how the U32.32 fixed point format relates to the input_bpc
> >> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> >> the framebuffer.
> >>
> >> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> >> is non-multiplied)?
> >>
> >> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> >> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> >> be interpreted as 0x3ff << (24-10)?
> >>
> >> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> >> the output value be 0x3ff << (16-10)?
> >>
> >> On AMD HW the pipe-internal format is a custom floating point format. We could
> >> probably express that in terms of input/output_bpc and do the translation in our
> >> driver between that and the internal floating point format, depending on the
> >> framebuffer format, but there is the added complication of the magnitude of the
> >> pixel data and correlating HDR with SDR planes.
> >>
> >> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> >> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> >> to represent that with the drm_color_lut_range definition.
> >
> >
> > Hi Harry,
> >
> > I think you just would not. Conceptually an SDR plane gets its very own
> > LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> > b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> > abstract KMS color pipeline, where [0.0, 1.0] is always the full
> > dynamic range at any point of the pipeline, meaning it is relative to
> > its placement in the pipeline. If you want to use values >1.0 in hw,
> > you can do so under the hood.
> >
> > At least that is how I would imagine things. With LUTs in general, I
> > don't think I have ever seen LUT input domain being explicitly defined
> > to something else than [0.0, 1.0] relative to the elements in the LUT
> > where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> > last element.
> >
> > I'm of course open to other suggestions, but having values outside of
> > [0.0, 1.0] range in the abstract pipeline will always raise the
> > question: how do you feed those to the LUT next in the pipeline.
> >
>
> AMD HW defines the LUT addressing in floating point space and allows
> for addressing beyond 1.0. In fact on other OSes our driver uses
> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
>
> There are color spaces that extend beyond 1.0 and even into the negative
> range: https://en.wikipedia.org/wiki/ScRGB
>
> I don't think we should define the LUT to be limited to [0.0, 1.0].
That is not the intention, or at least wasn't my intention when
originally I proposed this gamma mode stuff. I specifically wanted
support for extended values. So 0.0-1.0 is supposed to be just the
range for the in gamut values.
>
> If the framebuffer is not in FP16 the question then becomes how
> the integer pixel values relate to LUT addressing.
The idea again is that 0.0-1.0 is the range for the in gamut
values. IIRC our hw does have the possibility of scaling all
the fp16 input values by some programmable constant factor,
but exposing that would require yet another uapi addition.
>
> As well, LUT entries are defined to be U32.32 fixed point, also
> allowing for entries much greater than 1.0. If those are programmed
> as entries in the input (degamma) LUT how will they be used to address
> entries in the output (gamma) LUT?
The u32.32 is a mistake I think. IMO we should be going for signed
values everywhere. Though our hw does not actually let us directly
program negative values for the LUT, rather the hw just reflects
the whole curve across the origin so the lookup is basically just
something like:
output = input < 0 ? -lut[abs(input)] : lut[input];
That is why there is that proposed DRM_MODE_LUT_REFLECT_NEGATIVE flag.
I think nouveau had something funny in its lut programming that
made me think that it might actually have straight up programmable
LUT entries for negative inputs as well. But I'm not sure if anyone
has actually tested that.
>
> Maybe we want to say the actual input values are being used to
> address the LUT entries? But if we look at segment 1 of Uma's
> d13_degamma_hdr definition we see that the range of 0 to
> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
> LUT entries. So this interpretation doesn't make sense.
>
> You can see, I'm still confused by these definitions. An IGT
> test would help explain the API intentions a bit better, though
> I would like to see more precise documentation.
>
> Despite my confusion I think the segmented PWL definitions are
> a neat way to concisely describe the HW capabilities to
> userspace and a concise way for userspace to provide the LUT
> more precisely than with a uniformly spaced LUT.
>
> Harry
>
> > Yeah, I have no idea what it should mean if an FB has a format that
> > allows values beyond [0.0, 1.0].
> >
> >
> > Thanks,
> > pq
> >
> >
> >> If some of these questions should be obvious I apologize for being a bit dense,
> >> though it helps to make this accessible to the lowest common denominator
> >> to ensure not only the smartest devs can work with this.
> >>
> >> Harry
> >>
> >>> +
> >>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> >>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> >>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >>>
> >>
> >
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-05 11:49 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-09 20:22 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 20:22 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On 2021-11-05 07:49, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>>
>>
>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>
>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>> Existing LUT precision structure is having only 16 bit
>>>>> precision. This is not enough for upcoming enhanced hardwares
>>>>> and advance usecases like HDR processing. Hence added a new
>>>>> structure with 32 bit precision values.
>>>>>
>>>>> This also defines a new structure to define color lut ranges,
>>>>> along with related macro definitions and enums. This will help
>>>>> describe multi segmented lut ranges in the hardware.
>>>>>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 58 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>>> index 90c55383f1ee..1079794c86c3 100644
>>>>> --- a/include/uapi/drm/drm_mode.h
>>>>> +++ b/include/uapi/drm/drm_mode.h
>>>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
>>>>> };
>>>>> };
>>>>>
>>>>> +/*
>>>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
>>>>> + * can be used for either purpose, but not simultaneously. To expose
>>>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
>>>>> + * ranges.
>>>>> + */
>>>>> +/* LUT is for gamma (after CTM) */
>>>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>>>> +/* LUT is for degamma (before CTM) */
>>>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
>>>>> +/* linearly interpolate between the points */
>>>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
>>>>> +/*
>>>>> + * the last value of the previous range is the
>>>>> + * first value of the current range.
>>>>> + */
>>>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>>>> +/* the curve must be non-decreasing */
>>>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
>>>>> +/* the curve is reflected across origin for negative inputs */
>>>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>>>> +/* the same curve (red) is used for blue and green channels as well */
>>>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>>>> +
>>>>> +struct drm_color_lut_range {
>>>>> + /* DRM_MODE_LUT_* */
>>>>> + __u32 flags;
>>>>> + /* number of points on the curve */
>>>>> + __u16 count;
>>>>> + /* input/output bits per component */
>>>>> + __u8 input_bpc, output_bpc;
>>>>> + /* input start/end values */
>>>>> + __s32 start, end;
>>>>> + /* output min/max values */
>>>>> + __s32 min, max;
>>>>> +};
>>>>> +
>>>>> +enum lut_type {
>>>>> + LUT_TYPE_DEGAMMA = 0,
>>>>> + LUT_TYPE_GAMMA = 1,
>>>>> +};
>>>>> +
>>>>> +/*
>>>>> + * Creating 64 bit palette entries for better data
>>>>> + * precision. This will be required for HDR and
>>>>> + * similar color processing usecases.
>>>>> + */
>>>>> +struct drm_color_lut_ext {
>>>>> + /*
>>>>> + * Data is U32.32 fixed point format.
>>>>> + */
>>>>> + __u64 red;
>>>>> + __u64 green;
>>>>> + __u64 blue;
>>>>> + __u64 reserved;
>>>>> +};
>>>>
>>>> I've been drawing out examples of drm_color_lut_range defined PWLs
>>>> and understand a bit better what you and Ville are trying to accomplish
>>>> with it. It actually makes a lot of sense and would allow for a generic
>>>> way to populate different PWL definitions with a generic function.
>>>>
>>>> But I still have some key questions that either are not answered in these
>>>> patch sets or that I somehow overlooked.
>>>>
>>>> Can you explain how the U32.32 fixed point format relates to the input_bpc
>>>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
>>>> the framebuffer.
>>>>
>>>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
>>>> is non-multiplied)?
>>>>
>>>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
>>>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
>>>> be interpreted as 0x3ff << (24-10)?
>>>>
>>>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
>>>> the output value be 0x3ff << (16-10)?
>>>>
>>>> On AMD HW the pipe-internal format is a custom floating point format. We could
>>>> probably express that in terms of input/output_bpc and do the translation in our
>>>> driver between that and the internal floating point format, depending on the
>>>> framebuffer format, but there is the added complication of the magnitude of the
>>>> pixel data and correlating HDR with SDR planes.
>>>>
>>>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
>>>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
>>>> to represent that with the drm_color_lut_range definition.
>>>
>>>
>>> Hi Harry,
>>>
>>> I think you just would not. Conceptually an SDR plane gets its very own
>>> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
>>> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
>>> abstract KMS color pipeline, where [0.0, 1.0] is always the full
>>> dynamic range at any point of the pipeline, meaning it is relative to
>>> its placement in the pipeline. If you want to use values >1.0 in hw,
>>> you can do so under the hood.
>>>
>>> At least that is how I would imagine things. With LUTs in general, I
>>> don't think I have ever seen LUT input domain being explicitly defined
>>> to something else than [0.0, 1.0] relative to the elements in the LUT
>>> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
>>> last element.
>>>
>>> I'm of course open to other suggestions, but having values outside of
>>> [0.0, 1.0] range in the abstract pipeline will always raise the
>>> question: how do you feed those to the LUT next in the pipeline.
>>>
>>
>> AMD HW defines the LUT addressing in floating point space and allows
>> for addressing beyond 1.0. In fact on other OSes our driver uses
>> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
>>
>> There are color spaces that extend beyond 1.0 and even into the negative
>> range: https://en.wikipedia.org/wiki/ScRGB>>>
>> I don't think we should define the LUT to be limited to [0.0, 1.0].
>
> That is not the intention, or at least wasn't my intention when
> originally I proposed this gamma mode stuff. I specifically wanted
> support for extended values. So 0.0-1.0 is supposed to be just the
> range for the in gamut values.
>
Make sense and good to hear.
>>
>> If the framebuffer is not in FP16 the question then becomes how
>> the integer pixel values relate to LUT addressing.
>
> The idea again is that 0.0-1.0 is the range for the in gamut
> values. IIRC our hw does have the possibility of scaling all
> the fp16 input values by some programmable constant factor,
> but exposing that would require yet another uapi addition.
>
>>
>> As well, LUT entries are defined to be U32.32 fixed point, also
>> allowing for entries much greater than 1.0. If those are programmed
>> as entries in the input (degamma) LUT how will they be used to address
>> entries in the output (gamma) LUT?
>
> The u32.32 is a mistake I think. IMO we should be going for signed
> values everywhere. Though our hw does not actually let us directly
> program negative values for the LUT, rather the hw just reflects
> the whole curve across the origin so the lookup is basically just
> something like:
> output = input < 0 ? -lut[abs(input)] : lut[input];
>
> That is why there is that proposed DRM_MODE_LUT_REFLECT_NEGATIVE flag.
>
That's pretty much how I expect AMD HW to operate as well.
Harry
> I think nouveau had something funny in its lut programming that
> made me think that it might actually have straight up programmable
> LUT entries for negative inputs as well. But I'm not sure if anyone
> has actually tested that.
>
>>
>> Maybe we want to say the actual input values are being used to
>> address the LUT entries? But if we look at segment 1 of Uma's
>> d13_degamma_hdr definition we see that the range of 0 to
>> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
>> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
>> LUT entries. So this interpretation doesn't make sense.
>>
>> You can see, I'm still confused by these definitions. An IGT
>> test would help explain the API intentions a bit better, though
>> I would like to see more precise documentation.
>>
>> Despite my confusion I think the segmented PWL definitions are
>> a neat way to concisely describe the HW capabilities to
>> userspace and a concise way for userspace to provide the LUT
>> more precisely than with a uniformly spaced LUT.
>>
>> Harry
>>
>>> Yeah, I have no idea what it should mean if an FB has a format that
>>> allows values beyond [0.0, 1.0].
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>>
>>>> If some of these questions should be obvious I apologize for being a bit dense,
>>>> though it helps to make this accessible to the lowest common denominator
>>>> to ensure not only the smartest devs can work with this.
>>>>
>>>> Harry
>>>>
>>>>> +
>>>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>>>>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>>>>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>>>>>
>>>>
>>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-09 20:22 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 20:22 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Cyr, Aric, intel-gfx, Pekka Paalanen, dri-devel, sebastian
On 2021-11-05 07:49, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>>
>>
>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>
>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>> Existing LUT precision structure is having only 16 bit
>>>>> precision. This is not enough for upcoming enhanced hardwares
>>>>> and advance usecases like HDR processing. Hence added a new
>>>>> structure with 32 bit precision values.
>>>>>
>>>>> This also defines a new structure to define color lut ranges,
>>>>> along with related macro definitions and enums. This will help
>>>>> describe multi segmented lut ranges in the hardware.
>>>>>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 58 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>>> index 90c55383f1ee..1079794c86c3 100644
>>>>> --- a/include/uapi/drm/drm_mode.h
>>>>> +++ b/include/uapi/drm/drm_mode.h
>>>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
>>>>> };
>>>>> };
>>>>>
>>>>> +/*
>>>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
>>>>> + * can be used for either purpose, but not simultaneously. To expose
>>>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
>>>>> + * ranges.
>>>>> + */
>>>>> +/* LUT is for gamma (after CTM) */
>>>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>>>> +/* LUT is for degamma (before CTM) */
>>>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
>>>>> +/* linearly interpolate between the points */
>>>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
>>>>> +/*
>>>>> + * the last value of the previous range is the
>>>>> + * first value of the current range.
>>>>> + */
>>>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>>>> +/* the curve must be non-decreasing */
>>>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
>>>>> +/* the curve is reflected across origin for negative inputs */
>>>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>>>> +/* the same curve (red) is used for blue and green channels as well */
>>>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>>>> +
>>>>> +struct drm_color_lut_range {
>>>>> + /* DRM_MODE_LUT_* */
>>>>> + __u32 flags;
>>>>> + /* number of points on the curve */
>>>>> + __u16 count;
>>>>> + /* input/output bits per component */
>>>>> + __u8 input_bpc, output_bpc;
>>>>> + /* input start/end values */
>>>>> + __s32 start, end;
>>>>> + /* output min/max values */
>>>>> + __s32 min, max;
>>>>> +};
>>>>> +
>>>>> +enum lut_type {
>>>>> + LUT_TYPE_DEGAMMA = 0,
>>>>> + LUT_TYPE_GAMMA = 1,
>>>>> +};
>>>>> +
>>>>> +/*
>>>>> + * Creating 64 bit palette entries for better data
>>>>> + * precision. This will be required for HDR and
>>>>> + * similar color processing usecases.
>>>>> + */
>>>>> +struct drm_color_lut_ext {
>>>>> + /*
>>>>> + * Data is U32.32 fixed point format.
>>>>> + */
>>>>> + __u64 red;
>>>>> + __u64 green;
>>>>> + __u64 blue;
>>>>> + __u64 reserved;
>>>>> +};
>>>>
>>>> I've been drawing out examples of drm_color_lut_range defined PWLs
>>>> and understand a bit better what you and Ville are trying to accomplish
>>>> with it. It actually makes a lot of sense and would allow for a generic
>>>> way to populate different PWL definitions with a generic function.
>>>>
>>>> But I still have some key questions that either are not answered in these
>>>> patch sets or that I somehow overlooked.
>>>>
>>>> Can you explain how the U32.32 fixed point format relates to the input_bpc
>>>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
>>>> the framebuffer.
>>>>
>>>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
>>>> is non-multiplied)?
>>>>
>>>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
>>>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
>>>> be interpreted as 0x3ff << (24-10)?
>>>>
>>>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
>>>> the output value be 0x3ff << (16-10)?
>>>>
>>>> On AMD HW the pipe-internal format is a custom floating point format. We could
>>>> probably express that in terms of input/output_bpc and do the translation in our
>>>> driver between that and the internal floating point format, depending on the
>>>> framebuffer format, but there is the added complication of the magnitude of the
>>>> pixel data and correlating HDR with SDR planes.
>>>>
>>>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
>>>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
>>>> to represent that with the drm_color_lut_range definition.
>>>
>>>
>>> Hi Harry,
>>>
>>> I think you just would not. Conceptually an SDR plane gets its very own
>>> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
>>> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
>>> abstract KMS color pipeline, where [0.0, 1.0] is always the full
>>> dynamic range at any point of the pipeline, meaning it is relative to
>>> its placement in the pipeline. If you want to use values >1.0 in hw,
>>> you can do so under the hood.
>>>
>>> At least that is how I would imagine things. With LUTs in general, I
>>> don't think I have ever seen LUT input domain being explicitly defined
>>> to something else than [0.0, 1.0] relative to the elements in the LUT
>>> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
>>> last element.
>>>
>>> I'm of course open to other suggestions, but having values outside of
>>> [0.0, 1.0] range in the abstract pipeline will always raise the
>>> question: how do you feed those to the LUT next in the pipeline.
>>>
>>
>> AMD HW defines the LUT addressing in floating point space and allows
>> for addressing beyond 1.0. In fact on other OSes our driver uses
>> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
>>
>> There are color spaces that extend beyond 1.0 and even into the negative
>> range: https://en.wikipedia.org/wiki/ScRGB>>>
>> I don't think we should define the LUT to be limited to [0.0, 1.0].
>
> That is not the intention, or at least wasn't my intention when
> originally I proposed this gamma mode stuff. I specifically wanted
> support for extended values. So 0.0-1.0 is supposed to be just the
> range for the in gamut values.
>
Make sense and good to hear.
>>
>> If the framebuffer is not in FP16 the question then becomes how
>> the integer pixel values relate to LUT addressing.
>
> The idea again is that 0.0-1.0 is the range for the in gamut
> values. IIRC our hw does have the possibility of scaling all
> the fp16 input values by some programmable constant factor,
> but exposing that would require yet another uapi addition.
>
>>
>> As well, LUT entries are defined to be U32.32 fixed point, also
>> allowing for entries much greater than 1.0. If those are programmed
>> as entries in the input (degamma) LUT how will they be used to address
>> entries in the output (gamma) LUT?
>
> The u32.32 is a mistake I think. IMO we should be going for signed
> values everywhere. Though our hw does not actually let us directly
> program negative values for the LUT, rather the hw just reflects
> the whole curve across the origin so the lookup is basically just
> something like:
> output = input < 0 ? -lut[abs(input)] : lut[input];
>
> That is why there is that proposed DRM_MODE_LUT_REFLECT_NEGATIVE flag.
>
That's pretty much how I expect AMD HW to operate as well.
Harry
> I think nouveau had something funny in its lut programming that
> made me think that it might actually have straight up programmable
> LUT entries for negative inputs as well. But I'm not sure if anyone
> has actually tested that.
>
>>
>> Maybe we want to say the actual input values are being used to
>> address the LUT entries? But if we look at segment 1 of Uma's
>> d13_degamma_hdr definition we see that the range of 0 to
>> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
>> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
>> LUT entries. So this interpretation doesn't make sense.
>>
>> You can see, I'm still confused by these definitions. An IGT
>> test would help explain the API intentions a bit better, though
>> I would like to see more precise documentation.
>>
>> Despite my confusion I think the segmented PWL definitions are
>> a neat way to concisely describe the HW capabilities to
>> userspace and a concise way for userspace to provide the LUT
>> more precisely than with a uniformly spaced LUT.
>>
>> Harry
>>
>>> Yeah, I have no idea what it should mean if an FB has a format that
>>> allows values beyond [0.0, 1.0].
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>>
>>>> If some of these questions should be obvious I apologize for being a bit dense,
>>>> though it helps to make this accessible to the lowest common denominator
>>>> to ensure not only the smartest devs can work with this.
>>>>
>>>> Harry
>>>>
>>>>> +
>>>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>>>>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>>>>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>>>>>
>>>>
>>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-04 16:27 ` [Intel-gfx] " Harry Wentland
@ 2021-11-08 9:54 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-08 9:54 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
[-- Attachment #1: Type: text/plain, Size: 14630 bytes --]
On Thu, 4 Nov 2021 12:27:56 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > On Wed, 3 Nov 2021 11:08:13 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Existing LUT precision structure is having only 16 bit
> >>> precision. This is not enough for upcoming enhanced hardwares
> >>> and advance usecases like HDR processing. Hence added a new
> >>> structure with 32 bit precision values.
> >>>
> >>> This also defines a new structure to define color lut ranges,
> >>> along with related macro definitions and enums. This will help
> >>> describe multi segmented lut ranges in the hardware.
> >>>
> >>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>> ---
> >>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 58 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>> index 90c55383f1ee..1079794c86c3 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> >>> };
> >>> };
> >>>
> >>> +/*
> >>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> >>> + * can be used for either purpose, but not simultaneously. To expose
> >>> + * modes that support gamma and degamma simultaneously the gamma mode
> >>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> >>> + * ranges.
> >>> + */
> >>> +/* LUT is for gamma (after CTM) */
> >>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>> +/* LUT is for degamma (before CTM) */
> >>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> >>> +/* linearly interpolate between the points */
> >>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>> +/*
> >>> + * the last value of the previous range is the
> >>> + * first value of the current range.
> >>> + */
> >>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>> +/* the curve must be non-decreasing */
> >>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>> +/* the curve is reflected across origin for negative inputs */
> >>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>> +/* the same curve (red) is used for blue and green channels as well */
> >>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>> +
> >>> +struct drm_color_lut_range {
> >>> + /* DRM_MODE_LUT_* */
> >>> + __u32 flags;
> >>> + /* number of points on the curve */
> >>> + __u16 count;
> >>> + /* input/output bits per component */
> >>> + __u8 input_bpc, output_bpc;
> >>> + /* input start/end values */
> >>> + __s32 start, end;
> >>> + /* output min/max values */
> >>> + __s32 min, max;
> >>> +};
> >>> +
> >>> +enum lut_type {
> >>> + LUT_TYPE_DEGAMMA = 0,
> >>> + LUT_TYPE_GAMMA = 1,
> >>> +};
> >>> +
> >>> +/*
> >>> + * Creating 64 bit palette entries for better data
> >>> + * precision. This will be required for HDR and
> >>> + * similar color processing usecases.
> >>> + */
> >>> +struct drm_color_lut_ext {
> >>> + /*
> >>> + * Data is U32.32 fixed point format.
> >>> + */
> >>> + __u64 red;
> >>> + __u64 green;
> >>> + __u64 blue;
> >>> + __u64 reserved;
> >>> +};
> >>
> >> I've been drawing out examples of drm_color_lut_range defined PWLs
> >> and understand a bit better what you and Ville are trying to accomplish
> >> with it. It actually makes a lot of sense and would allow for a generic
> >> way to populate different PWL definitions with a generic function.
> >>
> >> But I still have some key questions that either are not answered in these
> >> patch sets or that I somehow overlooked.
> >>
> >> Can you explain how the U32.32 fixed point format relates to the input_bpc
> >> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> >> the framebuffer.
> >>
> >> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> >> is non-multiplied)?
> >>
> >> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> >> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> >> be interpreted as 0x3ff << (24-10)?
> >>
> >> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> >> the output value be 0x3ff << (16-10)?
> >>
> >> On AMD HW the pipe-internal format is a custom floating point format. We could
> >> probably express that in terms of input/output_bpc and do the translation in our
> >> driver between that and the internal floating point format, depending on the
> >> framebuffer format, but there is the added complication of the magnitude of the
> >> pixel data and correlating HDR with SDR planes.
> >>
> >> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> >> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> >> to represent that with the drm_color_lut_range definition.
> >
> >
> > Hi Harry,
> >
> > I think you just would not. Conceptually an SDR plane gets its very own
> > LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> > b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> > abstract KMS color pipeline, where [0.0, 1.0] is always the full
> > dynamic range at any point of the pipeline, meaning it is relative to
> > its placement in the pipeline. If you want to use values >1.0 in hw,
> > you can do so under the hood.
> >
> > At least that is how I would imagine things. With LUTs in general, I
> > don't think I have ever seen LUT input domain being explicitly defined
> > to something else than [0.0, 1.0] relative to the elements in the LUT
> > where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> > last element.
> >
> > I'm of course open to other suggestions, but having values outside of
> > [0.0, 1.0] range in the abstract pipeline will always raise the
> > question: how do you feed those to the LUT next in the pipeline.
> >
>
> AMD HW defines the LUT addressing in floating point space and allows
> for addressing beyond 1.0. In fact on other OSes our driver uses
> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
Hi Harry,
that sounds like some kind of absolute luminance encoding. Very much
like a PQ system. PQ system is very different to anything else, and
fitting that with a relative luminance system (which is everything else
in existence that I know of) has... things to be worked out.
I recall seeing some calculations where [0.0, 128.0] mapped very
nicely to exactly the theoretical absolute dynamic range of the PQ
system. It seems like that range is specifically tailored for operation
in the PQ system.
> There are color spaces that extend beyond 1.0 and even into the negative
> range: https://en.wikipedia.org/wiki/ScRGB
scRGB is really special. It's more like a pure mathematical
representation than a color space. Just like you can take a color
triplet in any well-defined color space, and multiply it with a totally
arbitrary but invertible 3x3 matrix. You get totally arbitrary values
as a result, but you are not actually changing anything. It's just a
different encoding.
scRGB has two peculiar and different properties.
First, if no color component is negative, the values above 1.0 simply
extend the dynamic range.
Second, if any color component has a negative value, that extends the
color gamut, not just dynamic range. You can represent for example a
red color out of your gamut by using slightly negative values for green
and blue and compensate for the "negative light intensity" by
increasing the red value above 1.0, without actually going outside of
the "original" dynamic range.
When color spaces are usually defined, the properties are chosen such
that all color components will be non-negative. That makes them
intuitive, particularly with additive color models (RGB in particular),
because the concept of negative light intensity does not exist in
physics (but it can be emulated in color matching experiments by adding
the negative component of the matching color as a positive component to
the reference color instead).
Then there are the considerations of color gamut and available dynamic
range, which are inter-dependent and together form the available color
volume.
Traditional color management works with relative coordinates where the
per-channel range [0.0, 1.0] defines the color volume with relative,
not absolute, dynamic range. You also were not able to send values
outside of min..max to a monitor, so might as well map those to 0.0 and
1.0. One could say the color volume definition is implicit here, with
the added confusion that you don't actually know the absolute dynamic
range (cd/m²).
Nowadays we have color spaces like BT.2020 which are larger than any
actual display can realize. Therefore, it is not enough to know the
color space to understand the available color volume, but you need
explicit information about the color gamut as well.
We need to know the available color volume to be able to map content
color volume nicely for the display. Likewise, we need to know the
actual color volume of the content too for a good color mapping.
If you use scRGB, you lose all intuitiveness. You have the concept of
negative light intensity which does not exist, but it is used simply as
a means to represent a larger color gamut than what the primaries of
the color space would imply. It can even extend to imaginary colors,
colors that do not exist: there is no light spectrum that would result
in that color in the human eye. (BT.2020 may be big, but all its colors
are real.) So you need to be able to handle arbitrary color channel
values, and you need explicit knowledge of the color volume you are
working with.
Essentially I think this means that one would better be using floating
point for everything, or maybe you can get away with formats like
s32.32 which takes 64 bits when a 16-bit float might have been enough.
But that then ties with the value encoding (linear vs. non-linear), so
one can't make a blanket statement about it.
Anyway, all the above is for the userspace to figure out. I just think
that using the range [0.0, 1.0] is very natural for most workflows,
even HDR. I don't see a practical need to go beyond that range, but I'm
also not against it. One can always program the [0.0, 1.0] range
explicitly via KMS.
The choice of the encoding at any point is always arbitrary, as long as
it doesn't lose too much information. The important thing is to be
consistent in a pipeline. That is why I'm not really concerned about
what range the abstract KMS pipeline is going to be defined with, as
long as it is consistent. An example of inconsistent pipeline would be
to allow arbitrary values in a LUT output, but defining only [0.0, 1.0]
input domain for the next element in the pipeline. Since any pipeline
element could be missing, you can't rely on some elements acting as
"sanitizer" but any earlier element could be feeding directly into any
later element.
> I don't think we should define the LUT to be limited to [0.0, 1.0].
That is fine. You get to define the UAPI and semantics for that, and
you also need to retrofit the existing pipeline components like CRTC
GAMMA and DEGAMMA to work with it somehow or replace them. You also
need to define how arbitrary values get converted to the cable.
However, what happens if we define the abstract KMS color pipeline in
terms of supporting arbitrary values in any point of the pipeline, and
hardware just doesn't work that way because it happens to be using e.g.
limited integer arithmetic?
> If the framebuffer is not in FP16 the question then becomes how
> the integer pixel values relate to LUT addressing.
Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
is to match minimum unsigned integer value to 0.0, and unsigned maximum
integer value to 1.0. This is how things work on the cable too, right?
(Also taking full vs. limited range video signal into account. And
conversion to cable-YUV if that happens.)
If you want integer format FB values to map to something else, then you
have to tag the FB with that range information, somehow. New UAPI.
> As well, LUT entries are defined to be U32.32 fixed point, also
> allowing for entries much greater than 1.0. If those are programmed
> as entries in the input (degamma) LUT how will they be used to address
> entries in the output (gamma) LUT?
>
> Maybe we want to say the actual input values are being used to
> address the LUT entries? But if we look at segment 1 of Uma's
> d13_degamma_hdr definition we see that the range of 0 to
> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
> LUT entries. So this interpretation doesn't make sense.
FWIW, it seems Vulkan has a long list of how to interpret each
(integer) pixel format:
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#_identification_of_formats
Essentially NORM vs. INT.
Hmm, I wonder how SNORM actually works. The integer range has one more
negative code points than positive code points, and zero. So if zero
code maps to 0.0, max maps 1.0, and min maps to -1.0, then the
conversion factor is different for negative vs. positive values?
Thanks,
pq
> You can see, I'm still confused by these definitions. An IGT
> test would help explain the API intentions a bit better, though
> I would like to see more precise documentation.
>
> Despite my confusion I think the segmented PWL definitions are
> a neat way to concisely describe the HW capabilities to
> userspace and a concise way for userspace to provide the LUT
> more precisely than with a uniformly spaced LUT.
>
> Harry
>
> > Yeah, I have no idea what it should mean if an FB has a format that
> > allows values beyond [0.0, 1.0].
> >
> >
> > Thanks,
> > pq
> >
> >
> >> If some of these questions should be obvious I apologize for being a bit dense,
> >> though it helps to make this accessible to the lowest common denominator
> >> to ensure not only the smartest devs can work with this.
> >>
> >> Harry
> >>
> >>> +
> >>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> >>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> >>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >>>
> >>
> >
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-08 9:54 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-08 9:54 UTC (permalink / raw)
To: Harry Wentland; +Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian
[-- Attachment #1: Type: text/plain, Size: 14630 bytes --]
On Thu, 4 Nov 2021 12:27:56 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > On Wed, 3 Nov 2021 11:08:13 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Existing LUT precision structure is having only 16 bit
> >>> precision. This is not enough for upcoming enhanced hardwares
> >>> and advance usecases like HDR processing. Hence added a new
> >>> structure with 32 bit precision values.
> >>>
> >>> This also defines a new structure to define color lut ranges,
> >>> along with related macro definitions and enums. This will help
> >>> describe multi segmented lut ranges in the hardware.
> >>>
> >>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>> ---
> >>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 58 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>> index 90c55383f1ee..1079794c86c3 100644
> >>> --- a/include/uapi/drm/drm_mode.h
> >>> +++ b/include/uapi/drm/drm_mode.h
> >>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> >>> };
> >>> };
> >>>
> >>> +/*
> >>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> >>> + * can be used for either purpose, but not simultaneously. To expose
> >>> + * modes that support gamma and degamma simultaneously the gamma mode
> >>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> >>> + * ranges.
> >>> + */
> >>> +/* LUT is for gamma (after CTM) */
> >>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>> +/* LUT is for degamma (before CTM) */
> >>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> >>> +/* linearly interpolate between the points */
> >>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>> +/*
> >>> + * the last value of the previous range is the
> >>> + * first value of the current range.
> >>> + */
> >>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>> +/* the curve must be non-decreasing */
> >>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>> +/* the curve is reflected across origin for negative inputs */
> >>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>> +/* the same curve (red) is used for blue and green channels as well */
> >>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>> +
> >>> +struct drm_color_lut_range {
> >>> + /* DRM_MODE_LUT_* */
> >>> + __u32 flags;
> >>> + /* number of points on the curve */
> >>> + __u16 count;
> >>> + /* input/output bits per component */
> >>> + __u8 input_bpc, output_bpc;
> >>> + /* input start/end values */
> >>> + __s32 start, end;
> >>> + /* output min/max values */
> >>> + __s32 min, max;
> >>> +};
> >>> +
> >>> +enum lut_type {
> >>> + LUT_TYPE_DEGAMMA = 0,
> >>> + LUT_TYPE_GAMMA = 1,
> >>> +};
> >>> +
> >>> +/*
> >>> + * Creating 64 bit palette entries for better data
> >>> + * precision. This will be required for HDR and
> >>> + * similar color processing usecases.
> >>> + */
> >>> +struct drm_color_lut_ext {
> >>> + /*
> >>> + * Data is U32.32 fixed point format.
> >>> + */
> >>> + __u64 red;
> >>> + __u64 green;
> >>> + __u64 blue;
> >>> + __u64 reserved;
> >>> +};
> >>
> >> I've been drawing out examples of drm_color_lut_range defined PWLs
> >> and understand a bit better what you and Ville are trying to accomplish
> >> with it. It actually makes a lot of sense and would allow for a generic
> >> way to populate different PWL definitions with a generic function.
> >>
> >> But I still have some key questions that either are not answered in these
> >> patch sets or that I somehow overlooked.
> >>
> >> Can you explain how the U32.32 fixed point format relates to the input_bpc
> >> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> >> the framebuffer.
> >>
> >> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> >> is non-multiplied)?
> >>
> >> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> >> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> >> be interpreted as 0x3ff << (24-10)?
> >>
> >> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> >> the output value be 0x3ff << (16-10)?
> >>
> >> On AMD HW the pipe-internal format is a custom floating point format. We could
> >> probably express that in terms of input/output_bpc and do the translation in our
> >> driver between that and the internal floating point format, depending on the
> >> framebuffer format, but there is the added complication of the magnitude of the
> >> pixel data and correlating HDR with SDR planes.
> >>
> >> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> >> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> >> to represent that with the drm_color_lut_range definition.
> >
> >
> > Hi Harry,
> >
> > I think you just would not. Conceptually an SDR plane gets its very own
> > LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> > b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> > abstract KMS color pipeline, where [0.0, 1.0] is always the full
> > dynamic range at any point of the pipeline, meaning it is relative to
> > its placement in the pipeline. If you want to use values >1.0 in hw,
> > you can do so under the hood.
> >
> > At least that is how I would imagine things. With LUTs in general, I
> > don't think I have ever seen LUT input domain being explicitly defined
> > to something else than [0.0, 1.0] relative to the elements in the LUT
> > where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> > last element.
> >
> > I'm of course open to other suggestions, but having values outside of
> > [0.0, 1.0] range in the abstract pipeline will always raise the
> > question: how do you feed those to the LUT next in the pipeline.
> >
>
> AMD HW defines the LUT addressing in floating point space and allows
> for addressing beyond 1.0. In fact on other OSes our driver uses
> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
Hi Harry,
that sounds like some kind of absolute luminance encoding. Very much
like a PQ system. PQ system is very different to anything else, and
fitting that with a relative luminance system (which is everything else
in existence that I know of) has... things to be worked out.
I recall seeing some calculations where [0.0, 128.0] mapped very
nicely to exactly the theoretical absolute dynamic range of the PQ
system. It seems like that range is specifically tailored for operation
in the PQ system.
> There are color spaces that extend beyond 1.0 and even into the negative
> range: https://en.wikipedia.org/wiki/ScRGB
scRGB is really special. It's more like a pure mathematical
representation than a color space. Just like you can take a color
triplet in any well-defined color space, and multiply it with a totally
arbitrary but invertible 3x3 matrix. You get totally arbitrary values
as a result, but you are not actually changing anything. It's just a
different encoding.
scRGB has two peculiar and different properties.
First, if no color component is negative, the values above 1.0 simply
extend the dynamic range.
Second, if any color component has a negative value, that extends the
color gamut, not just dynamic range. You can represent for example a
red color out of your gamut by using slightly negative values for green
and blue and compensate for the "negative light intensity" by
increasing the red value above 1.0, without actually going outside of
the "original" dynamic range.
When color spaces are usually defined, the properties are chosen such
that all color components will be non-negative. That makes them
intuitive, particularly with additive color models (RGB in particular),
because the concept of negative light intensity does not exist in
physics (but it can be emulated in color matching experiments by adding
the negative component of the matching color as a positive component to
the reference color instead).
Then there are the considerations of color gamut and available dynamic
range, which are inter-dependent and together form the available color
volume.
Traditional color management works with relative coordinates where the
per-channel range [0.0, 1.0] defines the color volume with relative,
not absolute, dynamic range. You also were not able to send values
outside of min..max to a monitor, so might as well map those to 0.0 and
1.0. One could say the color volume definition is implicit here, with
the added confusion that you don't actually know the absolute dynamic
range (cd/m²).
Nowadays we have color spaces like BT.2020 which are larger than any
actual display can realize. Therefore, it is not enough to know the
color space to understand the available color volume, but you need
explicit information about the color gamut as well.
We need to know the available color volume to be able to map content
color volume nicely for the display. Likewise, we need to know the
actual color volume of the content too for a good color mapping.
If you use scRGB, you lose all intuitiveness. You have the concept of
negative light intensity which does not exist, but it is used simply as
a means to represent a larger color gamut than what the primaries of
the color space would imply. It can even extend to imaginary colors,
colors that do not exist: there is no light spectrum that would result
in that color in the human eye. (BT.2020 may be big, but all its colors
are real.) So you need to be able to handle arbitrary color channel
values, and you need explicit knowledge of the color volume you are
working with.
Essentially I think this means that one would better be using floating
point for everything, or maybe you can get away with formats like
s32.32 which takes 64 bits when a 16-bit float might have been enough.
But that then ties with the value encoding (linear vs. non-linear), so
one can't make a blanket statement about it.
Anyway, all the above is for the userspace to figure out. I just think
that using the range [0.0, 1.0] is very natural for most workflows,
even HDR. I don't see a practical need to go beyond that range, but I'm
also not against it. One can always program the [0.0, 1.0] range
explicitly via KMS.
The choice of the encoding at any point is always arbitrary, as long as
it doesn't lose too much information. The important thing is to be
consistent in a pipeline. That is why I'm not really concerned about
what range the abstract KMS pipeline is going to be defined with, as
long as it is consistent. An example of inconsistent pipeline would be
to allow arbitrary values in a LUT output, but defining only [0.0, 1.0]
input domain for the next element in the pipeline. Since any pipeline
element could be missing, you can't rely on some elements acting as
"sanitizer" but any earlier element could be feeding directly into any
later element.
> I don't think we should define the LUT to be limited to [0.0, 1.0].
That is fine. You get to define the UAPI and semantics for that, and
you also need to retrofit the existing pipeline components like CRTC
GAMMA and DEGAMMA to work with it somehow or replace them. You also
need to define how arbitrary values get converted to the cable.
However, what happens if we define the abstract KMS color pipeline in
terms of supporting arbitrary values in any point of the pipeline, and
hardware just doesn't work that way because it happens to be using e.g.
limited integer arithmetic?
> If the framebuffer is not in FP16 the question then becomes how
> the integer pixel values relate to LUT addressing.
Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
is to match minimum unsigned integer value to 0.0, and unsigned maximum
integer value to 1.0. This is how things work on the cable too, right?
(Also taking full vs. limited range video signal into account. And
conversion to cable-YUV if that happens.)
If you want integer format FB values to map to something else, then you
have to tag the FB with that range information, somehow. New UAPI.
> As well, LUT entries are defined to be U32.32 fixed point, also
> allowing for entries much greater than 1.0. If those are programmed
> as entries in the input (degamma) LUT how will they be used to address
> entries in the output (gamma) LUT?
>
> Maybe we want to say the actual input values are being used to
> address the LUT entries? But if we look at segment 1 of Uma's
> d13_degamma_hdr definition we see that the range of 0 to
> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
> LUT entries. So this interpretation doesn't make sense.
FWIW, it seems Vulkan has a long list of how to interpret each
(integer) pixel format:
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#_identification_of_formats
Essentially NORM vs. INT.
Hmm, I wonder how SNORM actually works. The integer range has one more
negative code points than positive code points, and zero. So if zero
code maps to 0.0, max maps 1.0, and min maps to -1.0, then the
conversion factor is different for negative vs. positive values?
Thanks,
pq
> You can see, I'm still confused by these definitions. An IGT
> test would help explain the API intentions a bit better, though
> I would like to see more precise documentation.
>
> Despite my confusion I think the segmented PWL definitions are
> a neat way to concisely describe the HW capabilities to
> userspace and a concise way for userspace to provide the LUT
> more precisely than with a uniformly spaced LUT.
>
> Harry
>
> > Yeah, I have no idea what it should mean if an FB has a format that
> > allows values beyond [0.0, 1.0].
> >
> >
> > Thanks,
> > pq
> >
> >
> >> If some of these questions should be obvious I apologize for being a bit dense,
> >> though it helps to make this accessible to the lowest common denominator
> >> to ensure not only the smartest devs can work with this.
> >>
> >> Harry
> >>
> >>> +
> >>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> >>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> >>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> >>>
> >>
> >
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-08 9:54 ` [Intel-gfx] " Pekka Paalanen
@ 2021-11-09 20:47 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 20:47 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On 2021-11-08 04:54, Pekka Paalanen wrote:
> On Thu, 4 Nov 2021 12:27:56 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>
>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>> Existing LUT precision structure is having only 16 bit
>>>>> precision. This is not enough for upcoming enhanced hardwares
>>>>> and advance usecases like HDR processing. Hence added a new
>>>>> structure with 32 bit precision values.
>>>>>
>>>>> This also defines a new structure to define color lut ranges,
>>>>> along with related macro definitions and enums. This will help
>>>>> describe multi segmented lut ranges in the hardware.
>>>>>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 58 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>>> index 90c55383f1ee..1079794c86c3 100644
>>>>> --- a/include/uapi/drm/drm_mode.h
>>>>> +++ b/include/uapi/drm/drm_mode.h
>>>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
>>>>> };
>>>>> };
>>>>>
>>>>> +/*
>>>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
>>>>> + * can be used for either purpose, but not simultaneously. To expose
>>>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
>>>>> + * ranges.
>>>>> + */
>>>>> +/* LUT is for gamma (after CTM) */
>>>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>>>> +/* LUT is for degamma (before CTM) */
>>>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
>>>>> +/* linearly interpolate between the points */
>>>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
>>>>> +/*
>>>>> + * the last value of the previous range is the
>>>>> + * first value of the current range.
>>>>> + */
>>>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>>>> +/* the curve must be non-decreasing */
>>>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
>>>>> +/* the curve is reflected across origin for negative inputs */
>>>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>>>> +/* the same curve (red) is used for blue and green channels as well */
>>>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>>>> +
>>>>> +struct drm_color_lut_range {
>>>>> + /* DRM_MODE_LUT_* */
>>>>> + __u32 flags;
>>>>> + /* number of points on the curve */
>>>>> + __u16 count;
>>>>> + /* input/output bits per component */
>>>>> + __u8 input_bpc, output_bpc;
>>>>> + /* input start/end values */
>>>>> + __s32 start, end;
>>>>> + /* output min/max values */
>>>>> + __s32 min, max;
>>>>> +};
>>>>> +
>>>>> +enum lut_type {
>>>>> + LUT_TYPE_DEGAMMA = 0,
>>>>> + LUT_TYPE_GAMMA = 1,
>>>>> +};
>>>>> +
>>>>> +/*
>>>>> + * Creating 64 bit palette entries for better data
>>>>> + * precision. This will be required for HDR and
>>>>> + * similar color processing usecases.
>>>>> + */
>>>>> +struct drm_color_lut_ext {
>>>>> + /*
>>>>> + * Data is U32.32 fixed point format.
>>>>> + */
>>>>> + __u64 red;
>>>>> + __u64 green;
>>>>> + __u64 blue;
>>>>> + __u64 reserved;
>>>>> +};
>>>>
>>>> I've been drawing out examples of drm_color_lut_range defined PWLs
>>>> and understand a bit better what you and Ville are trying to accomplish
>>>> with it. It actually makes a lot of sense and would allow for a generic
>>>> way to populate different PWL definitions with a generic function.
>>>>
>>>> But I still have some key questions that either are not answered in these
>>>> patch sets or that I somehow overlooked.
>>>>
>>>> Can you explain how the U32.32 fixed point format relates to the input_bpc
>>>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
>>>> the framebuffer.
>>>>
>>>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
>>>> is non-multiplied)?
>>>>
>>>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
>>>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
>>>> be interpreted as 0x3ff << (24-10)?
>>>>
>>>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
>>>> the output value be 0x3ff << (16-10)?
>>>>
>>>> On AMD HW the pipe-internal format is a custom floating point format. We could
>>>> probably express that in terms of input/output_bpc and do the translation in our
>>>> driver between that and the internal floating point format, depending on the
>>>> framebuffer format, but there is the added complication of the magnitude of the
>>>> pixel data and correlating HDR with SDR planes.
>>>>
>>>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
>>>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
>>>> to represent that with the drm_color_lut_range definition.
>>>
>>>
>>> Hi Harry,
>>>
>>> I think you just would not. Conceptually an SDR plane gets its very own
>>> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
>>> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
>>> abstract KMS color pipeline, where [0.0, 1.0] is always the full
>>> dynamic range at any point of the pipeline, meaning it is relative to
>>> its placement in the pipeline. If you want to use values >1.0 in hw,
>>> you can do so under the hood.
>>>
>>> At least that is how I would imagine things. With LUTs in general, I
>>> don't think I have ever seen LUT input domain being explicitly defined
>>> to something else than [0.0, 1.0] relative to the elements in the LUT
>>> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
>>> last element.
>>>
>>> I'm of course open to other suggestions, but having values outside of
>>> [0.0, 1.0] range in the abstract pipeline will always raise the
>>> question: how do you feed those to the LUT next in the pipeline.
>>>
>>
>> AMD HW defines the LUT addressing in floating point space and allows
>> for addressing beyond 1.0. In fact on other OSes our driver uses
>> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
>
> Hi Harry,
>
> that sounds like some kind of absolute luminance encoding. Very much
> like a PQ system. PQ system is very different to anything else, and
> fitting that with a relative luminance system (which is everything else
> in existence that I know of) has... things to be worked out.
>
> I recall seeing some calculations where [0.0, 128.0] mapped very
> nicely to exactly the theoretical absolute dynamic range of the PQ
> system. It seems like that range is specifically tailored for operation
> in the PQ system.
>
>> There are color spaces that extend beyond 1.0 and even into the negative
>> range: https://en.wikipedia.org/wiki/ScRGB
>
> scRGB is really special. It's more like a pure mathematical
> representation than a color space. Just like you can take a color
> triplet in any well-defined color space, and multiply it with a totally
> arbitrary but invertible 3x3 matrix. You get totally arbitrary values
> as a result, but you are not actually changing anything. It's just a
> different encoding.
>
> scRGB has two peculiar and different properties.
>
> First, if no color component is negative, the values above 1.0 simply
> extend the dynamic range.
>
> Second, if any color component has a negative value, that extends the
> color gamut, not just dynamic range. You can represent for example a
> red color out of your gamut by using slightly negative values for green
> and blue and compensate for the "negative light intensity" by
> increasing the red value above 1.0, without actually going outside of
> the "original" dynamic range.
>
> When color spaces are usually defined, the properties are chosen such
> that all color components will be non-negative. That makes them
> intuitive, particularly with additive color models (RGB in particular),
> because the concept of negative light intensity does not exist in
> physics (but it can be emulated in color matching experiments by adding
> the negative component of the matching color as a positive component to
> the reference color instead).
>
> Then there are the considerations of color gamut and available dynamic
> range, which are inter-dependent and together form the available color
> volume.
>
> Traditional color management works with relative coordinates where the
> per-channel range [0.0, 1.0] defines the color volume with relative,
> not absolute, dynamic range. You also were not able to send values
> outside of min..max to a monitor, so might as well map those to 0.0 and
> 1.0. One could say the color volume definition is implicit here, with
> the added confusion that you don't actually know the absolute dynamic
> range (cd/m²).
>
> Nowadays we have color spaces like BT.2020 which are larger than any
> actual display can realize. Therefore, it is not enough to know the
> color space to understand the available color volume, but you need
> explicit information about the color gamut as well.
>
> We need to know the available color volume to be able to map content
> color volume nicely for the display. Likewise, we need to know the
> actual color volume of the content too for a good color mapping.
>
> If you use scRGB, you lose all intuitiveness. You have the concept of
> negative light intensity which does not exist, but it is used simply as
> a means to represent a larger color gamut than what the primaries of
> the color space would imply. It can even extend to imaginary colors,
> colors that do not exist: there is no light spectrum that would result
> in that color in the human eye. (BT.2020 may be big, but all its colors
> are real.) So you need to be able to handle arbitrary color channel
> values, and you need explicit knowledge of the color volume you are
> working with.
>
> Essentially I think this means that one would better be using floating
> point for everything, or maybe you can get away with formats like
> s32.32 which takes 64 bits when a 16-bit float might have been enough.
> But that then ties with the value encoding (linear vs. non-linear), so
> one can't make a blanket statement about it.
>
> Anyway, all the above is for the userspace to figure out. I just think
> that using the range [0.0, 1.0] is very natural for most workflows,
> even HDR. I don't see a practical need to go beyond that range, but I'm
> also not against it. One can always program the [0.0, 1.0] range
> explicitly via KMS.
>
I agree that this should be for userspace to figure out. For that reason
(and because we see OSes that do funky things) I prefer to not limit
userspace to [0.0, 1.0].
> The choice of the encoding at any point is always arbitrary, as long as
> it doesn't lose too much information. The important thing is to be
> consistent in a pipeline. That is why I'm not really concerned about
> what range the abstract KMS pipeline is going to be defined with, as
> long as it is consistent. An example of inconsistent pipeline would be
> to allow arbitrary values in a LUT output, but defining only [0.0, 1.0]
> input domain for the next element in the pipeline. Since any pipeline
> element could be missing, you can't rely on some elements acting as
> "sanitizer" but any earlier element could be feeding directly into any
> later element.
>
>> I don't think we should define the LUT to be limited to [0.0, 1.0].
>
> That is fine. You get to define the UAPI and semantics for that, and
> you also need to retrofit the existing pipeline components like CRTC
> GAMMA and DEGAMMA to work with it somehow or replace them. You also
> need to define how arbitrary values get converted to the cable.
>
> However, what happens if we define the abstract KMS color pipeline in
> terms of supporting arbitrary values in any point of the pipeline, and
> hardware just doesn't work that way because it happens to be using e.g.
> limited integer arithmetic?
>
>> If the framebuffer is not in FP16 the question then becomes how
>> the integer pixel values relate to LUT addressing.
>
> Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> is to match minimum unsigned integer value to 0.0, and unsigned maximum
> integer value to 1.0. This is how things work on the cable too, right?
> (Also taking full vs. limited range video signal into account. And
> conversion to cable-YUV if that happens.)
>
> If you want integer format FB values to map to something else, then you
> have to tag the FB with that range information, somehow. New UAPI.
>
On the cable we send integer values, not floating point. AMD HW uses
floating point internally, though, and the PWL API defines floating
point entries, so on some level we need to be clear what the floating
point entries mean. Either we document that to be [0.0, 1.0] or we
have some UAPI to define it. I'm leaning toward the latter but have
to think about it some more.
>> As well, LUT entries are defined to be U32.32 fixed point, also
>> allowing for entries much greater than 1.0. If those are programmed
>> as entries in the input (degamma) LUT how will they be used to address
>> entries in the output (gamma) LUT?
>>
>> Maybe we want to say the actual input values are being used to
>> address the LUT entries? But if we look at segment 1 of Uma's
>> d13_degamma_hdr definition we see that the range of 0 to
>> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
>> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
>> LUT entries. So this interpretation doesn't make sense.
>
> FWIW, it seems Vulkan has a long list of how to interpret each
> (integer) pixel format:
> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#_identification_of_formats
>
> Essentially NORM vs. INT.
Thanks for sharing.
Harry
>
> Hmm, I wonder how SNORM actually works. The integer range has one more
> negative code points than positive code points, and zero. So if zero
> code maps to 0.0, max maps 1.0, and min maps to -1.0, then the
> conversion factor is different for negative vs. positive values?
>
>
> Thanks,
> pq
>
>> You can see, I'm still confused by these definitions. An IGT
>> test would help explain the API intentions a bit better, though
>> I would like to see more precise documentation.
>>
>> Despite my confusion I think the segmented PWL definitions are
>> a neat way to concisely describe the HW capabilities to
>> userspace and a concise way for userspace to provide the LUT
>> more precisely than with a uniformly spaced LUT.
>>
>> Harry
>>
>>> Yeah, I have no idea what it should mean if an FB has a format that
>>> allows values beyond [0.0, 1.0].
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>>
>>>> If some of these questions should be obvious I apologize for being a bit dense,
>>>> though it helps to make this accessible to the lowest common denominator
>>>> to ensure not only the smartest devs can work with this.
>>>>
>>>> Harry
>>>>
>>>>> +
>>>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>>>>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>>>>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-09 20:47 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 20:47 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian
On 2021-11-08 04:54, Pekka Paalanen wrote:
> On Thu, 4 Nov 2021 12:27:56 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
>
>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>
>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>> Existing LUT precision structure is having only 16 bit
>>>>> precision. This is not enough for upcoming enhanced hardwares
>>>>> and advance usecases like HDR processing. Hence added a new
>>>>> structure with 32 bit precision values.
>>>>>
>>>>> This also defines a new structure to define color lut ranges,
>>>>> along with related macro definitions and enums. This will help
>>>>> describe multi segmented lut ranges in the hardware.
>>>>>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 58 insertions(+)
>>>>>
>>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>>> index 90c55383f1ee..1079794c86c3 100644
>>>>> --- a/include/uapi/drm/drm_mode.h
>>>>> +++ b/include/uapi/drm/drm_mode.h
>>>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
>>>>> };
>>>>> };
>>>>>
>>>>> +/*
>>>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
>>>>> + * can be used for either purpose, but not simultaneously. To expose
>>>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
>>>>> + * ranges.
>>>>> + */
>>>>> +/* LUT is for gamma (after CTM) */
>>>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>>>> +/* LUT is for degamma (before CTM) */
>>>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
>>>>> +/* linearly interpolate between the points */
>>>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
>>>>> +/*
>>>>> + * the last value of the previous range is the
>>>>> + * first value of the current range.
>>>>> + */
>>>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>>>> +/* the curve must be non-decreasing */
>>>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
>>>>> +/* the curve is reflected across origin for negative inputs */
>>>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>>>> +/* the same curve (red) is used for blue and green channels as well */
>>>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>>>> +
>>>>> +struct drm_color_lut_range {
>>>>> + /* DRM_MODE_LUT_* */
>>>>> + __u32 flags;
>>>>> + /* number of points on the curve */
>>>>> + __u16 count;
>>>>> + /* input/output bits per component */
>>>>> + __u8 input_bpc, output_bpc;
>>>>> + /* input start/end values */
>>>>> + __s32 start, end;
>>>>> + /* output min/max values */
>>>>> + __s32 min, max;
>>>>> +};
>>>>> +
>>>>> +enum lut_type {
>>>>> + LUT_TYPE_DEGAMMA = 0,
>>>>> + LUT_TYPE_GAMMA = 1,
>>>>> +};
>>>>> +
>>>>> +/*
>>>>> + * Creating 64 bit palette entries for better data
>>>>> + * precision. This will be required for HDR and
>>>>> + * similar color processing usecases.
>>>>> + */
>>>>> +struct drm_color_lut_ext {
>>>>> + /*
>>>>> + * Data is U32.32 fixed point format.
>>>>> + */
>>>>> + __u64 red;
>>>>> + __u64 green;
>>>>> + __u64 blue;
>>>>> + __u64 reserved;
>>>>> +};
>>>>
>>>> I've been drawing out examples of drm_color_lut_range defined PWLs
>>>> and understand a bit better what you and Ville are trying to accomplish
>>>> with it. It actually makes a lot of sense and would allow for a generic
>>>> way to populate different PWL definitions with a generic function.
>>>>
>>>> But I still have some key questions that either are not answered in these
>>>> patch sets or that I somehow overlooked.
>>>>
>>>> Can you explain how the U32.32 fixed point format relates to the input_bpc
>>>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
>>>> the framebuffer.
>>>>
>>>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
>>>> is non-multiplied)?
>>>>
>>>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
>>>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
>>>> be interpreted as 0x3ff << (24-10)?
>>>>
>>>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
>>>> the output value be 0x3ff << (16-10)?
>>>>
>>>> On AMD HW the pipe-internal format is a custom floating point format. We could
>>>> probably express that in terms of input/output_bpc and do the translation in our
>>>> driver between that and the internal floating point format, depending on the
>>>> framebuffer format, but there is the added complication of the magnitude of the
>>>> pixel data and correlating HDR with SDR planes.
>>>>
>>>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
>>>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
>>>> to represent that with the drm_color_lut_range definition.
>>>
>>>
>>> Hi Harry,
>>>
>>> I think you just would not. Conceptually an SDR plane gets its very own
>>> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
>>> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
>>> abstract KMS color pipeline, where [0.0, 1.0] is always the full
>>> dynamic range at any point of the pipeline, meaning it is relative to
>>> its placement in the pipeline. If you want to use values >1.0 in hw,
>>> you can do so under the hood.
>>>
>>> At least that is how I would imagine things. With LUTs in general, I
>>> don't think I have ever seen LUT input domain being explicitly defined
>>> to something else than [0.0, 1.0] relative to the elements in the LUT
>>> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
>>> last element.
>>>
>>> I'm of course open to other suggestions, but having values outside of
>>> [0.0, 1.0] range in the abstract pipeline will always raise the
>>> question: how do you feed those to the LUT next in the pipeline.
>>>
>>
>> AMD HW defines the LUT addressing in floating point space and allows
>> for addressing beyond 1.0. In fact on other OSes our driver uses
>> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
>
> Hi Harry,
>
> that sounds like some kind of absolute luminance encoding. Very much
> like a PQ system. PQ system is very different to anything else, and
> fitting that with a relative luminance system (which is everything else
> in existence that I know of) has... things to be worked out.
>
> I recall seeing some calculations where [0.0, 128.0] mapped very
> nicely to exactly the theoretical absolute dynamic range of the PQ
> system. It seems like that range is specifically tailored for operation
> in the PQ system.
>
>> There are color spaces that extend beyond 1.0 and even into the negative
>> range: https://en.wikipedia.org/wiki/ScRGB
>
> scRGB is really special. It's more like a pure mathematical
> representation than a color space. Just like you can take a color
> triplet in any well-defined color space, and multiply it with a totally
> arbitrary but invertible 3x3 matrix. You get totally arbitrary values
> as a result, but you are not actually changing anything. It's just a
> different encoding.
>
> scRGB has two peculiar and different properties.
>
> First, if no color component is negative, the values above 1.0 simply
> extend the dynamic range.
>
> Second, if any color component has a negative value, that extends the
> color gamut, not just dynamic range. You can represent for example a
> red color out of your gamut by using slightly negative values for green
> and blue and compensate for the "negative light intensity" by
> increasing the red value above 1.0, without actually going outside of
> the "original" dynamic range.
>
> When color spaces are usually defined, the properties are chosen such
> that all color components will be non-negative. That makes them
> intuitive, particularly with additive color models (RGB in particular),
> because the concept of negative light intensity does not exist in
> physics (but it can be emulated in color matching experiments by adding
> the negative component of the matching color as a positive component to
> the reference color instead).
>
> Then there are the considerations of color gamut and available dynamic
> range, which are inter-dependent and together form the available color
> volume.
>
> Traditional color management works with relative coordinates where the
> per-channel range [0.0, 1.0] defines the color volume with relative,
> not absolute, dynamic range. You also were not able to send values
> outside of min..max to a monitor, so might as well map those to 0.0 and
> 1.0. One could say the color volume definition is implicit here, with
> the added confusion that you don't actually know the absolute dynamic
> range (cd/m²).
>
> Nowadays we have color spaces like BT.2020 which are larger than any
> actual display can realize. Therefore, it is not enough to know the
> color space to understand the available color volume, but you need
> explicit information about the color gamut as well.
>
> We need to know the available color volume to be able to map content
> color volume nicely for the display. Likewise, we need to know the
> actual color volume of the content too for a good color mapping.
>
> If you use scRGB, you lose all intuitiveness. You have the concept of
> negative light intensity which does not exist, but it is used simply as
> a means to represent a larger color gamut than what the primaries of
> the color space would imply. It can even extend to imaginary colors,
> colors that do not exist: there is no light spectrum that would result
> in that color in the human eye. (BT.2020 may be big, but all its colors
> are real.) So you need to be able to handle arbitrary color channel
> values, and you need explicit knowledge of the color volume you are
> working with.
>
> Essentially I think this means that one would better be using floating
> point for everything, or maybe you can get away with formats like
> s32.32 which takes 64 bits when a 16-bit float might have been enough.
> But that then ties with the value encoding (linear vs. non-linear), so
> one can't make a blanket statement about it.
>
> Anyway, all the above is for the userspace to figure out. I just think
> that using the range [0.0, 1.0] is very natural for most workflows,
> even HDR. I don't see a practical need to go beyond that range, but I'm
> also not against it. One can always program the [0.0, 1.0] range
> explicitly via KMS.
>
I agree that this should be for userspace to figure out. For that reason
(and because we see OSes that do funky things) I prefer to not limit
userspace to [0.0, 1.0].
> The choice of the encoding at any point is always arbitrary, as long as
> it doesn't lose too much information. The important thing is to be
> consistent in a pipeline. That is why I'm not really concerned about
> what range the abstract KMS pipeline is going to be defined with, as
> long as it is consistent. An example of inconsistent pipeline would be
> to allow arbitrary values in a LUT output, but defining only [0.0, 1.0]
> input domain for the next element in the pipeline. Since any pipeline
> element could be missing, you can't rely on some elements acting as
> "sanitizer" but any earlier element could be feeding directly into any
> later element.
>
>> I don't think we should define the LUT to be limited to [0.0, 1.0].
>
> That is fine. You get to define the UAPI and semantics for that, and
> you also need to retrofit the existing pipeline components like CRTC
> GAMMA and DEGAMMA to work with it somehow or replace them. You also
> need to define how arbitrary values get converted to the cable.
>
> However, what happens if we define the abstract KMS color pipeline in
> terms of supporting arbitrary values in any point of the pipeline, and
> hardware just doesn't work that way because it happens to be using e.g.
> limited integer arithmetic?
>
>> If the framebuffer is not in FP16 the question then becomes how
>> the integer pixel values relate to LUT addressing.
>
> Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> is to match minimum unsigned integer value to 0.0, and unsigned maximum
> integer value to 1.0. This is how things work on the cable too, right?
> (Also taking full vs. limited range video signal into account. And
> conversion to cable-YUV if that happens.)
>
> If you want integer format FB values to map to something else, then you
> have to tag the FB with that range information, somehow. New UAPI.
>
On the cable we send integer values, not floating point. AMD HW uses
floating point internally, though, and the PWL API defines floating
point entries, so on some level we need to be clear what the floating
point entries mean. Either we document that to be [0.0, 1.0] or we
have some UAPI to define it. I'm leaning toward the latter but have
to think about it some more.
>> As well, LUT entries are defined to be U32.32 fixed point, also
>> allowing for entries much greater than 1.0. If those are programmed
>> as entries in the input (degamma) LUT how will they be used to address
>> entries in the output (gamma) LUT?
>>
>> Maybe we want to say the actual input values are being used to
>> address the LUT entries? But if we look at segment 1 of Uma's
>> d13_degamma_hdr definition we see that the range of 0 to
>> (1 << 24) -1 is covered by 128 (1 << 7) entries, so the range
>> of 0 to 256 (for RGB with 8 bpc) would only be covered by 2
>> LUT entries. So this interpretation doesn't make sense.
>
> FWIW, it seems Vulkan has a long list of how to interpret each
> (integer) pixel format:
> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#_identification_of_formats
>
> Essentially NORM vs. INT.
Thanks for sharing.
Harry
>
> Hmm, I wonder how SNORM actually works. The integer range has one more
> negative code points than positive code points, and zero. So if zero
> code maps to 0.0, max maps 1.0, and min maps to -1.0, then the
> conversion factor is different for negative vs. positive values?
>
>
> Thanks,
> pq
>
>> You can see, I'm still confused by these definitions. An IGT
>> test would help explain the API intentions a bit better, though
>> I would like to see more precise documentation.
>>
>> Despite my confusion I think the segmented PWL definitions are
>> a neat way to concisely describe the HW capabilities to
>> userspace and a concise way for userspace to provide the LUT
>> more precisely than with a uniformly spaced LUT.
>>
>> Harry
>>
>>> Yeah, I have no idea what it should mean if an FB has a format that
>>> allows values beyond [0.0, 1.0].
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>>
>>>> If some of these questions should be obvious I apologize for being a bit dense,
>>>> though it helps to make this accessible to the lowest common denominator
>>>> to ensure not only the smartest devs can work with this.
>>>>
>>>> Harry
>>>>
>>>>> +
>>>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>>>>> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>>>>> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-09 20:47 ` [Intel-gfx] " Harry Wentland
@ 2021-11-09 22:02 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-09 22:02 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> On 2021-11-08 04:54, Pekka Paalanen wrote:
> > On Thu, 4 Nov 2021 12:27:56 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> >>> On Wed, 3 Nov 2021 11:08:13 -0400
> >>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>
> >>>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>>> Existing LUT precision structure is having only 16 bit
> >>>>> precision. This is not enough for upcoming enhanced hardwares
> >>>>> and advance usecases like HDR processing. Hence added a new
> >>>>> structure with 32 bit precision values.
> >>>>>
> >>>>> This also defines a new structure to define color lut ranges,
> >>>>> along with related macro definitions and enums. This will help
> >>>>> describe multi segmented lut ranges in the hardware.
> >>>>>
> >>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>>> ---
> >>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>>>> 1 file changed, 58 insertions(+)
> >>>>>
> >>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>>>> index 90c55383f1ee..1079794c86c3 100644
> >>>>> --- a/include/uapi/drm/drm_mode.h
> >>>>> +++ b/include/uapi/drm/drm_mode.h
> >>>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> +/*
> >>>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> >>>>> + * can be used for either purpose, but not simultaneously. To expose
> >>>>> + * modes that support gamma and degamma simultaneously the gamma mode
> >>>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> >>>>> + * ranges.
> >>>>> + */
> >>>>> +/* LUT is for gamma (after CTM) */
> >>>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>>>> +/* LUT is for degamma (before CTM) */
> >>>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> >>>>> +/* linearly interpolate between the points */
> >>>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>>>> +/*
> >>>>> + * the last value of the previous range is the
> >>>>> + * first value of the current range.
> >>>>> + */
> >>>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>>>> +/* the curve must be non-decreasing */
> >>>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>>>> +/* the curve is reflected across origin for negative inputs */
> >>>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>>>> +/* the same curve (red) is used for blue and green channels as well */
> >>>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>>>> +
> >>>>> +struct drm_color_lut_range {
> >>>>> + /* DRM_MODE_LUT_* */
> >>>>> + __u32 flags;
> >>>>> + /* number of points on the curve */
> >>>>> + __u16 count;
> >>>>> + /* input/output bits per component */
> >>>>> + __u8 input_bpc, output_bpc;
> >>>>> + /* input start/end values */
> >>>>> + __s32 start, end;
> >>>>> + /* output min/max values */
> >>>>> + __s32 min, max;
> >>>>> +};
> >>>>> +
> >>>>> +enum lut_type {
> >>>>> + LUT_TYPE_DEGAMMA = 0,
> >>>>> + LUT_TYPE_GAMMA = 1,
> >>>>> +};
> >>>>> +
> >>>>> +/*
> >>>>> + * Creating 64 bit palette entries for better data
> >>>>> + * precision. This will be required for HDR and
> >>>>> + * similar color processing usecases.
> >>>>> + */
> >>>>> +struct drm_color_lut_ext {
> >>>>> + /*
> >>>>> + * Data is U32.32 fixed point format.
> >>>>> + */
> >>>>> + __u64 red;
> >>>>> + __u64 green;
> >>>>> + __u64 blue;
> >>>>> + __u64 reserved;
> >>>>> +};
> >>>>
> >>>> I've been drawing out examples of drm_color_lut_range defined PWLs
> >>>> and understand a bit better what you and Ville are trying to accomplish
> >>>> with it. It actually makes a lot of sense and would allow for a generic
> >>>> way to populate different PWL definitions with a generic function.
> >>>>
> >>>> But I still have some key questions that either are not answered in these
> >>>> patch sets or that I somehow overlooked.
> >>>>
> >>>> Can you explain how the U32.32 fixed point format relates to the input_bpc
> >>>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> >>>> the framebuffer.
> >>>>
> >>>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> >>>> is non-multiplied)?
> >>>>
> >>>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> >>>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> >>>> be interpreted as 0x3ff << (24-10)?
> >>>>
> >>>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> >>>> the output value be 0x3ff << (16-10)?
> >>>>
> >>>> On AMD HW the pipe-internal format is a custom floating point format. We could
> >>>> probably express that in terms of input/output_bpc and do the translation in our
> >>>> driver between that and the internal floating point format, depending on the
> >>>> framebuffer format, but there is the added complication of the magnitude of the
> >>>> pixel data and correlating HDR with SDR planes.
> >>>>
> >>>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> >>>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> >>>> to represent that with the drm_color_lut_range definition.
> >>>
> >>>
> >>> Hi Harry,
> >>>
> >>> I think you just would not. Conceptually an SDR plane gets its very own
> >>> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> >>> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> >>> abstract KMS color pipeline, where [0.0, 1.0] is always the full
> >>> dynamic range at any point of the pipeline, meaning it is relative to
> >>> its placement in the pipeline. If you want to use values >1.0 in hw,
> >>> you can do so under the hood.
> >>>
> >>> At least that is how I would imagine things. With LUTs in general, I
> >>> don't think I have ever seen LUT input domain being explicitly defined
> >>> to something else than [0.0, 1.0] relative to the elements in the LUT
> >>> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> >>> last element.
> >>>
> >>> I'm of course open to other suggestions, but having values outside of
> >>> [0.0, 1.0] range in the abstract pipeline will always raise the
> >>> question: how do you feed those to the LUT next in the pipeline.
> >>>
> >>
> >> AMD HW defines the LUT addressing in floating point space and allows
> >> for addressing beyond 1.0. In fact on other OSes our driver uses
> >> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
> >
> > Hi Harry,
> >
> > that sounds like some kind of absolute luminance encoding. Very much
> > like a PQ system. PQ system is very different to anything else, and
> > fitting that with a relative luminance system (which is everything else
> > in existence that I know of) has... things to be worked out.
> >
> > I recall seeing some calculations where [0.0, 128.0] mapped very
> > nicely to exactly the theoretical absolute dynamic range of the PQ
> > system. It seems like that range is specifically tailored for operation
> > in the PQ system.
> >
> >> There are color spaces that extend beyond 1.0 and even into the negative
> >> range: https://en.wikipedia.org/wiki/ScRGB
> >
> > scRGB is really special. It's more like a pure mathematical
> > representation than a color space. Just like you can take a color
> > triplet in any well-defined color space, and multiply it with a totally
> > arbitrary but invertible 3x3 matrix. You get totally arbitrary values
> > as a result, but you are not actually changing anything. It's just a
> > different encoding.
> >
> > scRGB has two peculiar and different properties.
> >
> > First, if no color component is negative, the values above 1.0 simply
> > extend the dynamic range.
> >
> > Second, if any color component has a negative value, that extends the
> > color gamut, not just dynamic range. You can represent for example a
> > red color out of your gamut by using slightly negative values for green
> > and blue and compensate for the "negative light intensity" by
> > increasing the red value above 1.0, without actually going outside of
> > the "original" dynamic range.
> >
> > When color spaces are usually defined, the properties are chosen such
> > that all color components will be non-negative. That makes them
> > intuitive, particularly with additive color models (RGB in particular),
> > because the concept of negative light intensity does not exist in
> > physics (but it can be emulated in color matching experiments by adding
> > the negative component of the matching color as a positive component to
> > the reference color instead).
> >
> > Then there are the considerations of color gamut and available dynamic
> > range, which are inter-dependent and together form the available color
> > volume.
> >
> > Traditional color management works with relative coordinates where the
> > per-channel range [0.0, 1.0] defines the color volume with relative,
> > not absolute, dynamic range. You also were not able to send values
> > outside of min..max to a monitor, so might as well map those to 0.0 and
> > 1.0. One could say the color volume definition is implicit here, with
> > the added confusion that you don't actually know the absolute dynamic
> > range (cd/m²).
> >
> > Nowadays we have color spaces like BT.2020 which are larger than any
> > actual display can realize. Therefore, it is not enough to know the
> > color space to understand the available color volume, but you need
> > explicit information about the color gamut as well.
> >
> > We need to know the available color volume to be able to map content
> > color volume nicely for the display. Likewise, we need to know the
> > actual color volume of the content too for a good color mapping.
> >
> > If you use scRGB, you lose all intuitiveness. You have the concept of
> > negative light intensity which does not exist, but it is used simply as
> > a means to represent a larger color gamut than what the primaries of
> > the color space would imply. It can even extend to imaginary colors,
> > colors that do not exist: there is no light spectrum that would result
> > in that color in the human eye. (BT.2020 may be big, but all its colors
> > are real.) So you need to be able to handle arbitrary color channel
> > values, and you need explicit knowledge of the color volume you are
> > working with.
> >
> > Essentially I think this means that one would better be using floating
> > point for everything, or maybe you can get away with formats like
> > s32.32 which takes 64 bits when a 16-bit float might have been enough.
> > But that then ties with the value encoding (linear vs. non-linear), so
> > one can't make a blanket statement about it.
> >
> > Anyway, all the above is for the userspace to figure out. I just think
> > that using the range [0.0, 1.0] is very natural for most workflows,
> > even HDR. I don't see a practical need to go beyond that range, but I'm
> > also not against it. One can always program the [0.0, 1.0] range
> > explicitly via KMS.
> >
>
> I agree that this should be for userspace to figure out. For that reason
> (and because we see OSes that do funky things) I prefer to not limit
> userspace to [0.0, 1.0].
>
> > The choice of the encoding at any point is always arbitrary, as long as
> > it doesn't lose too much information. The important thing is to be
> > consistent in a pipeline. That is why I'm not really concerned about
> > what range the abstract KMS pipeline is going to be defined with, as
> > long as it is consistent. An example of inconsistent pipeline would be
> > to allow arbitrary values in a LUT output, but defining only [0.0, 1.0]
> > input domain for the next element in the pipeline. Since any pipeline
> > element could be missing, you can't rely on some elements acting as
> > "sanitizer" but any earlier element could be feeding directly into any
> > later element.
> >
> >> I don't think we should define the LUT to be limited to [0.0, 1.0].
> >
> > That is fine. You get to define the UAPI and semantics for that, and
> > you also need to retrofit the existing pipeline components like CRTC
> > GAMMA and DEGAMMA to work with it somehow or replace them. You also
> > need to define how arbitrary values get converted to the cable.
> >
> > However, what happens if we define the abstract KMS color pipeline in
> > terms of supporting arbitrary values in any point of the pipeline, and
> > hardware just doesn't work that way because it happens to be using e.g.
> > limited integer arithmetic?
> >
> >> If the framebuffer is not in FP16 the question then becomes how
> >> the integer pixel values relate to LUT addressing.
> >
> > Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> > is to match minimum unsigned integer value to 0.0, and unsigned maximum
> > integer value to 1.0. This is how things work on the cable too, right?
> > (Also taking full vs. limited range video signal into account. And
> > conversion to cable-YUV if that happens.)
> >
> > If you want integer format FB values to map to something else, then you
> > have to tag the FB with that range information, somehow. New UAPI.
> >
>
> On the cable we send integer values, not floating point. AMD HW uses
> floating point internally, though, and the PWL API defines floating
> point entries, so on some level we need to be clear what the floating
> point entries mean. Either we document that to be [0.0, 1.0] or we
> have some UAPI to define it. I'm leaning toward the latter but have
> to think about it some more.
As for Intel hw if you have an integer pixel value of 0xff... (with
however many bits you have with a specific pixel format) it will get
extended to 0.fff... (to whatever precision the pipe has internally).
So if we go by that a fixed point 1.0 value in the proposed
drm_color_lut_range would be considered just outside the gamut. And
pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
value as well [1]. I think that definition pretty much matches how GL
UNORM<->float conversion works as well.
[1] though IIRC some our hw did get that a bit wrong and it
actually generates a 1.0 fixed point value for the pipe
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-09 22:02 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-09 22:02 UTC (permalink / raw)
To: Harry Wentland; +Cc: Cyr, Aric, intel-gfx, Pekka Paalanen, dri-devel, sebastian
On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> On 2021-11-08 04:54, Pekka Paalanen wrote:
> > On Thu, 4 Nov 2021 12:27:56 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >
> >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> >>> On Wed, 3 Nov 2021 11:08:13 -0400
> >>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>
> >>>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>>> Existing LUT precision structure is having only 16 bit
> >>>>> precision. This is not enough for upcoming enhanced hardwares
> >>>>> and advance usecases like HDR processing. Hence added a new
> >>>>> structure with 32 bit precision values.
> >>>>>
> >>>>> This also defines a new structure to define color lut ranges,
> >>>>> along with related macro definitions and enums. This will help
> >>>>> describe multi segmented lut ranges in the hardware.
> >>>>>
> >>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>>> ---
> >>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>>>> 1 file changed, 58 insertions(+)
> >>>>>
> >>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>>>> index 90c55383f1ee..1079794c86c3 100644
> >>>>> --- a/include/uapi/drm/drm_mode.h
> >>>>> +++ b/include/uapi/drm/drm_mode.h
> >>>>> @@ -903,6 +903,64 @@ struct hdr_output_metadata {
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> +/*
> >>>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means the LUT
> >>>>> + * can be used for either purpose, but not simultaneously. To expose
> >>>>> + * modes that support gamma and degamma simultaneously the gamma mode
> >>>>> + * must declare distinct DRM_MODE_LUT_GAMMA and DRM_MODE_LUT_DEGAMMA
> >>>>> + * ranges.
> >>>>> + */
> >>>>> +/* LUT is for gamma (after CTM) */
> >>>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
> >>>>> +/* LUT is for degamma (before CTM) */
> >>>>> +#define DRM_MODE_LUT_DEGAMMA BIT(1)
> >>>>> +/* linearly interpolate between the points */
> >>>>> +#define DRM_MODE_LUT_INTERPOLATE BIT(2)
> >>>>> +/*
> >>>>> + * the last value of the previous range is the
> >>>>> + * first value of the current range.
> >>>>> + */
> >>>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
> >>>>> +/* the curve must be non-decreasing */
> >>>>> +#define DRM_MODE_LUT_NON_DECREASING BIT(4)
> >>>>> +/* the curve is reflected across origin for negative inputs */
> >>>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
> >>>>> +/* the same curve (red) is used for blue and green channels as well */
> >>>>> +#define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
> >>>>> +
> >>>>> +struct drm_color_lut_range {
> >>>>> + /* DRM_MODE_LUT_* */
> >>>>> + __u32 flags;
> >>>>> + /* number of points on the curve */
> >>>>> + __u16 count;
> >>>>> + /* input/output bits per component */
> >>>>> + __u8 input_bpc, output_bpc;
> >>>>> + /* input start/end values */
> >>>>> + __s32 start, end;
> >>>>> + /* output min/max values */
> >>>>> + __s32 min, max;
> >>>>> +};
> >>>>> +
> >>>>> +enum lut_type {
> >>>>> + LUT_TYPE_DEGAMMA = 0,
> >>>>> + LUT_TYPE_GAMMA = 1,
> >>>>> +};
> >>>>> +
> >>>>> +/*
> >>>>> + * Creating 64 bit palette entries for better data
> >>>>> + * precision. This will be required for HDR and
> >>>>> + * similar color processing usecases.
> >>>>> + */
> >>>>> +struct drm_color_lut_ext {
> >>>>> + /*
> >>>>> + * Data is U32.32 fixed point format.
> >>>>> + */
> >>>>> + __u64 red;
> >>>>> + __u64 green;
> >>>>> + __u64 blue;
> >>>>> + __u64 reserved;
> >>>>> +};
> >>>>
> >>>> I've been drawing out examples of drm_color_lut_range defined PWLs
> >>>> and understand a bit better what you and Ville are trying to accomplish
> >>>> with it. It actually makes a lot of sense and would allow for a generic
> >>>> way to populate different PWL definitions with a generic function.
> >>>>
> >>>> But I still have some key questions that either are not answered in these
> >>>> patch sets or that I somehow overlooked.
> >>>>
> >>>> Can you explain how the U32.32 fixed point format relates to the input_bpc
> >>>> and output_bpc in drm_color_lut_range, as we as to the pixel coming in from
> >>>> the framebuffer.
> >>>>
> >>>> E.g. if we have ARGB2101010 what happens to a 0x3ff red value (assuming alpha
> >>>> is non-multiplied)?
> >>>>
> >>>> If the drm_color_lut_range segments are defined with input_bpc of 24 bpc will
> >>>> 0x3ff be zero-expanded to 24-bit? Is the 24 bpc an integer? I.e. would our 3xff
> >>>> be interpreted as 0x3ff << (24-10)?
> >>>>
> >>>> Assuming the output_bpc is 16 bpc and the programmed LUT makes this 1-to-1 would
> >>>> the output value be 0x3ff << (16-10)?
> >>>>
> >>>> On AMD HW the pipe-internal format is a custom floating point format. We could
> >>>> probably express that in terms of input/output_bpc and do the translation in our
> >>>> driver between that and the internal floating point format, depending on the
> >>>> framebuffer format, but there is the added complication of the magnitude of the
> >>>> pixel data and correlating HDR with SDR planes.
> >>>>
> >>>> E.g. any SDR data would map from 0.0 to 1.0 floating point, while HDR content would
> >>>> map from 0.0 to some value larger than 1.0. I don't (yet) have a clear picture how
> >>>> to represent that with the drm_color_lut_range definition.
> >>>
> >>>
> >>> Hi Harry,
> >>>
> >>> I think you just would not. Conceptually an SDR plane gets its very own
> >>> LUT that converts the FB [0.0, 1.0] range to any appropriate [a >= 0.0,
> >>> b <= 1.0] range in HDR. This is purely conceptual, in the terms of the
> >>> abstract KMS color pipeline, where [0.0, 1.0] is always the full
> >>> dynamic range at any point of the pipeline, meaning it is relative to
> >>> its placement in the pipeline. If you want to use values >1.0 in hw,
> >>> you can do so under the hood.
> >>>
> >>> At least that is how I would imagine things. With LUTs in general, I
> >>> don't think I have ever seen LUT input domain being explicitly defined
> >>> to something else than [0.0, 1.0] relative to the elements in the LUT
> >>> where 0.0 maps exactly to the first element and 1.0 maps exactly to the
> >>> last element.
> >>>
> >>> I'm of course open to other suggestions, but having values outside of
> >>> [0.0, 1.0] range in the abstract pipeline will always raise the
> >>> question: how do you feed those to the LUT next in the pipeline.
> >>>
> >>
> >> AMD HW defines the LUT addressing in floating point space and allows
> >> for addressing beyond 1.0. In fact on other OSes our driver uses
> >> [0.0, 1.0] for SDR LUTs and [0.0, 128.0] for HDR LUTs.
> >
> > Hi Harry,
> >
> > that sounds like some kind of absolute luminance encoding. Very much
> > like a PQ system. PQ system is very different to anything else, and
> > fitting that with a relative luminance system (which is everything else
> > in existence that I know of) has... things to be worked out.
> >
> > I recall seeing some calculations where [0.0, 128.0] mapped very
> > nicely to exactly the theoretical absolute dynamic range of the PQ
> > system. It seems like that range is specifically tailored for operation
> > in the PQ system.
> >
> >> There are color spaces that extend beyond 1.0 and even into the negative
> >> range: https://en.wikipedia.org/wiki/ScRGB
> >
> > scRGB is really special. It's more like a pure mathematical
> > representation than a color space. Just like you can take a color
> > triplet in any well-defined color space, and multiply it with a totally
> > arbitrary but invertible 3x3 matrix. You get totally arbitrary values
> > as a result, but you are not actually changing anything. It's just a
> > different encoding.
> >
> > scRGB has two peculiar and different properties.
> >
> > First, if no color component is negative, the values above 1.0 simply
> > extend the dynamic range.
> >
> > Second, if any color component has a negative value, that extends the
> > color gamut, not just dynamic range. You can represent for example a
> > red color out of your gamut by using slightly negative values for green
> > and blue and compensate for the "negative light intensity" by
> > increasing the red value above 1.0, without actually going outside of
> > the "original" dynamic range.
> >
> > When color spaces are usually defined, the properties are chosen such
> > that all color components will be non-negative. That makes them
> > intuitive, particularly with additive color models (RGB in particular),
> > because the concept of negative light intensity does not exist in
> > physics (but it can be emulated in color matching experiments by adding
> > the negative component of the matching color as a positive component to
> > the reference color instead).
> >
> > Then there are the considerations of color gamut and available dynamic
> > range, which are inter-dependent and together form the available color
> > volume.
> >
> > Traditional color management works with relative coordinates where the
> > per-channel range [0.0, 1.0] defines the color volume with relative,
> > not absolute, dynamic range. You also were not able to send values
> > outside of min..max to a monitor, so might as well map those to 0.0 and
> > 1.0. One could say the color volume definition is implicit here, with
> > the added confusion that you don't actually know the absolute dynamic
> > range (cd/m²).
> >
> > Nowadays we have color spaces like BT.2020 which are larger than any
> > actual display can realize. Therefore, it is not enough to know the
> > color space to understand the available color volume, but you need
> > explicit information about the color gamut as well.
> >
> > We need to know the available color volume to be able to map content
> > color volume nicely for the display. Likewise, we need to know the
> > actual color volume of the content too for a good color mapping.
> >
> > If you use scRGB, you lose all intuitiveness. You have the concept of
> > negative light intensity which does not exist, but it is used simply as
> > a means to represent a larger color gamut than what the primaries of
> > the color space would imply. It can even extend to imaginary colors,
> > colors that do not exist: there is no light spectrum that would result
> > in that color in the human eye. (BT.2020 may be big, but all its colors
> > are real.) So you need to be able to handle arbitrary color channel
> > values, and you need explicit knowledge of the color volume you are
> > working with.
> >
> > Essentially I think this means that one would better be using floating
> > point for everything, or maybe you can get away with formats like
> > s32.32 which takes 64 bits when a 16-bit float might have been enough.
> > But that then ties with the value encoding (linear vs. non-linear), so
> > one can't make a blanket statement about it.
> >
> > Anyway, all the above is for the userspace to figure out. I just think
> > that using the range [0.0, 1.0] is very natural for most workflows,
> > even HDR. I don't see a practical need to go beyond that range, but I'm
> > also not against it. One can always program the [0.0, 1.0] range
> > explicitly via KMS.
> >
>
> I agree that this should be for userspace to figure out. For that reason
> (and because we see OSes that do funky things) I prefer to not limit
> userspace to [0.0, 1.0].
>
> > The choice of the encoding at any point is always arbitrary, as long as
> > it doesn't lose too much information. The important thing is to be
> > consistent in a pipeline. That is why I'm not really concerned about
> > what range the abstract KMS pipeline is going to be defined with, as
> > long as it is consistent. An example of inconsistent pipeline would be
> > to allow arbitrary values in a LUT output, but defining only [0.0, 1.0]
> > input domain for the next element in the pipeline. Since any pipeline
> > element could be missing, you can't rely on some elements acting as
> > "sanitizer" but any earlier element could be feeding directly into any
> > later element.
> >
> >> I don't think we should define the LUT to be limited to [0.0, 1.0].
> >
> > That is fine. You get to define the UAPI and semantics for that, and
> > you also need to retrofit the existing pipeline components like CRTC
> > GAMMA and DEGAMMA to work with it somehow or replace them. You also
> > need to define how arbitrary values get converted to the cable.
> >
> > However, what happens if we define the abstract KMS color pipeline in
> > terms of supporting arbitrary values in any point of the pipeline, and
> > hardware just doesn't work that way because it happens to be using e.g.
> > limited integer arithmetic?
> >
> >> If the framebuffer is not in FP16 the question then becomes how
> >> the integer pixel values relate to LUT addressing.
> >
> > Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> > is to match minimum unsigned integer value to 0.0, and unsigned maximum
> > integer value to 1.0. This is how things work on the cable too, right?
> > (Also taking full vs. limited range video signal into account. And
> > conversion to cable-YUV if that happens.)
> >
> > If you want integer format FB values to map to something else, then you
> > have to tag the FB with that range information, somehow. New UAPI.
> >
>
> On the cable we send integer values, not floating point. AMD HW uses
> floating point internally, though, and the PWL API defines floating
> point entries, so on some level we need to be clear what the floating
> point entries mean. Either we document that to be [0.0, 1.0] or we
> have some UAPI to define it. I'm leaning toward the latter but have
> to think about it some more.
As for Intel hw if you have an integer pixel value of 0xff... (with
however many bits you have with a specific pixel format) it will get
extended to 0.fff... (to whatever precision the pipe has internally).
So if we go by that a fixed point 1.0 value in the proposed
drm_color_lut_range would be considered just outside the gamut. And
pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
value as well [1]. I think that definition pretty much matches how GL
UNORM<->float conversion works as well.
[1] though IIRC some our hw did get that a bit wrong and it
actually generates a 1.0 fixed point value for the pipe
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-09 22:02 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-10 8:49 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-10 8:49 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]
On Wed, 10 Nov 2021 00:02:16 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> > On 2021-11-08 04:54, Pekka Paalanen wrote:
> > > On Thu, 4 Nov 2021 12:27:56 -0400
> > > Harry Wentland <harry.wentland@amd.com> wrote:
> > >
> > >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > >>> On Wed, 3 Nov 2021 11:08:13 -0400
> > >>> Harry Wentland <harry.wentland@amd.com> wrote:
> > >>>
> > >>>> On 2021-09-06 17:38, Uma Shankar wrote:
> > >>>>> Existing LUT precision structure is having only 16 bit
> > >>>>> precision. This is not enough for upcoming enhanced hardwares
> > >>>>> and advance usecases like HDR processing. Hence added a new
> > >>>>> structure with 32 bit precision values.
> > >>>>>
> > >>>>> This also defines a new structure to define color lut ranges,
> > >>>>> along with related macro definitions and enums. This will help
> > >>>>> describe multi segmented lut ranges in the hardware.
> > >>>>>
> > >>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > >>>>> ---
> > >>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> > >>>>> 1 file changed, 58 insertions(+)
...
> > >> If the framebuffer is not in FP16 the question then becomes how
> > >> the integer pixel values relate to LUT addressing.
> > >
> > > Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> > > is to match minimum unsigned integer value to 0.0, and unsigned maximum
> > > integer value to 1.0. This is how things work on the cable too, right?
> > > (Also taking full vs. limited range video signal into account. And
> > > conversion to cable-YUV if that happens.)
> > >
> > > If you want integer format FB values to map to something else, then you
> > > have to tag the FB with that range information, somehow. New UAPI.
> > >
> >
> > On the cable we send integer values, not floating point. AMD HW uses
> > floating point internally, though, and the PWL API defines floating
> > point entries, so on some level we need to be clear what the floating
> > point entries mean. Either we document that to be [0.0, 1.0] or we
> > have some UAPI to define it. I'm leaning toward the latter but have
> > to think about it some more.
>
> As for Intel hw if you have an integer pixel value of 0xff... (with
> however many bits you have with a specific pixel format) it will get
> extended to 0.fff... (to whatever precision the pipe has internally).
> So if we go by that a fixed point 1.0 value in the proposed
> drm_color_lut_range would be considered just outside the gamut. And
> pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
> value as well [1]. I think that definition pretty much matches how GL
> UNORM<->float conversion works as well.
Does it work that way in GL though?
I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
255.0/256.0.
Taking a random spec: OpenGL ES 2.0.25
Section 2.1.2 Data Conversions says:
Normalized unsigned integers represent numbers in the range
[0, 1]. The conversion from a normalized unsigned integer c to
the corresponding floating-point f is defined as
f = c / (2^b - 1)
Note how the divisor has -1.
Thanks,
pq
> [1] though IIRC some our hw did get that a bit wrong and it
> actually generates a 1.0 fixed point value for the pipe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-10 8:49 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-10 8:49 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian, Harry Wentland
[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]
On Wed, 10 Nov 2021 00:02:16 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> > On 2021-11-08 04:54, Pekka Paalanen wrote:
> > > On Thu, 4 Nov 2021 12:27:56 -0400
> > > Harry Wentland <harry.wentland@amd.com> wrote:
> > >
> > >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > >>> On Wed, 3 Nov 2021 11:08:13 -0400
> > >>> Harry Wentland <harry.wentland@amd.com> wrote:
> > >>>
> > >>>> On 2021-09-06 17:38, Uma Shankar wrote:
> > >>>>> Existing LUT precision structure is having only 16 bit
> > >>>>> precision. This is not enough for upcoming enhanced hardwares
> > >>>>> and advance usecases like HDR processing. Hence added a new
> > >>>>> structure with 32 bit precision values.
> > >>>>>
> > >>>>> This also defines a new structure to define color lut ranges,
> > >>>>> along with related macro definitions and enums. This will help
> > >>>>> describe multi segmented lut ranges in the hardware.
> > >>>>>
> > >>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > >>>>> ---
> > >>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> > >>>>> 1 file changed, 58 insertions(+)
...
> > >> If the framebuffer is not in FP16 the question then becomes how
> > >> the integer pixel values relate to LUT addressing.
> > >
> > > Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> > > is to match minimum unsigned integer value to 0.0, and unsigned maximum
> > > integer value to 1.0. This is how things work on the cable too, right?
> > > (Also taking full vs. limited range video signal into account. And
> > > conversion to cable-YUV if that happens.)
> > >
> > > If you want integer format FB values to map to something else, then you
> > > have to tag the FB with that range information, somehow. New UAPI.
> > >
> >
> > On the cable we send integer values, not floating point. AMD HW uses
> > floating point internally, though, and the PWL API defines floating
> > point entries, so on some level we need to be clear what the floating
> > point entries mean. Either we document that to be [0.0, 1.0] or we
> > have some UAPI to define it. I'm leaning toward the latter but have
> > to think about it some more.
>
> As for Intel hw if you have an integer pixel value of 0xff... (with
> however many bits you have with a specific pixel format) it will get
> extended to 0.fff... (to whatever precision the pipe has internally).
> So if we go by that a fixed point 1.0 value in the proposed
> drm_color_lut_range would be considered just outside the gamut. And
> pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
> value as well [1]. I think that definition pretty much matches how GL
> UNORM<->float conversion works as well.
Does it work that way in GL though?
I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
255.0/256.0.
Taking a random spec: OpenGL ES 2.0.25
Section 2.1.2 Data Conversions says:
Normalized unsigned integers represent numbers in the range
[0, 1]. The conversion from a normalized unsigned integer c to
the corresponding floating-point f is defined as
f = c / (2^b - 1)
Note how the divisor has -1.
Thanks,
pq
> [1] though IIRC some our hw did get that a bit wrong and it
> actually generates a 1.0 fixed point value for the pipe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-10 8:49 ` [Intel-gfx] " Pekka Paalanen
@ 2021-11-10 11:55 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-10 11:55 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
> On Wed, 10 Nov 2021 00:02:16 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>
> > On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> > > On 2021-11-08 04:54, Pekka Paalanen wrote:
> > > > On Thu, 4 Nov 2021 12:27:56 -0400
> > > > Harry Wentland <harry.wentland@amd.com> wrote:
> > > >
> > > >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > > >>> On Wed, 3 Nov 2021 11:08:13 -0400
> > > >>> Harry Wentland <harry.wentland@amd.com> wrote:
> > > >>>
> > > >>>> On 2021-09-06 17:38, Uma Shankar wrote:
> > > >>>>> Existing LUT precision structure is having only 16 bit
> > > >>>>> precision. This is not enough for upcoming enhanced hardwares
> > > >>>>> and advance usecases like HDR processing. Hence added a new
> > > >>>>> structure with 32 bit precision values.
> > > >>>>>
> > > >>>>> This also defines a new structure to define color lut ranges,
> > > >>>>> along with related macro definitions and enums. This will help
> > > >>>>> describe multi segmented lut ranges in the hardware.
> > > >>>>>
> > > >>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > >>>>> ---
> > > >>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> > > >>>>> 1 file changed, 58 insertions(+)
>
> ...
>
> > > >> If the framebuffer is not in FP16 the question then becomes how
> > > >> the integer pixel values relate to LUT addressing.
> > > >
> > > > Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> > > > is to match minimum unsigned integer value to 0.0, and unsigned maximum
> > > > integer value to 1.0. This is how things work on the cable too, right?
> > > > (Also taking full vs. limited range video signal into account. And
> > > > conversion to cable-YUV if that happens.)
> > > >
> > > > If you want integer format FB values to map to something else, then you
> > > > have to tag the FB with that range information, somehow. New UAPI.
> > > >
> > >
> > > On the cable we send integer values, not floating point. AMD HW uses
> > > floating point internally, though, and the PWL API defines floating
> > > point entries, so on some level we need to be clear what the floating
> > > point entries mean. Either we document that to be [0.0, 1.0] or we
> > > have some UAPI to define it. I'm leaning toward the latter but have
> > > to think about it some more.
> >
> > As for Intel hw if you have an integer pixel value of 0xff... (with
> > however many bits you have with a specific pixel format) it will get
> > extended to 0.fff... (to whatever precision the pipe has internally).
> > So if we go by that a fixed point 1.0 value in the proposed
> > drm_color_lut_range would be considered just outside the gamut. And
> > pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
> > value as well [1]. I think that definition pretty much matches how GL
> > UNORM<->float conversion works as well.
>
> Does it work that way in GL though?
>
> I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
> 255.0/256.0.
>
> Taking a random spec: OpenGL ES 2.0.25
>
> Section 2.1.2 Data Conversions says:
>
> Normalized unsigned integers represent numbers in the range
> [0, 1]. The conversion from a normalized unsigned integer c to
> the corresponding floating-point f is defined as
> f = c / (2^b - 1)
>
> Note how the divisor has -1.
That seems to match what I said, or at least tried to say (~0 <-> 1.0 in
float). drm_color_lut_range being fixed point would follow the ~0 side of
that. Or at least that interpretation would very easily map to our hw.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-10 11:55 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-10 11:55 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian, Harry Wentland
On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
> On Wed, 10 Nov 2021 00:02:16 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>
> > On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> > > On 2021-11-08 04:54, Pekka Paalanen wrote:
> > > > On Thu, 4 Nov 2021 12:27:56 -0400
> > > > Harry Wentland <harry.wentland@amd.com> wrote:
> > > >
> > > >> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > > >>> On Wed, 3 Nov 2021 11:08:13 -0400
> > > >>> Harry Wentland <harry.wentland@amd.com> wrote:
> > > >>>
> > > >>>> On 2021-09-06 17:38, Uma Shankar wrote:
> > > >>>>> Existing LUT precision structure is having only 16 bit
> > > >>>>> precision. This is not enough for upcoming enhanced hardwares
> > > >>>>> and advance usecases like HDR processing. Hence added a new
> > > >>>>> structure with 32 bit precision values.
> > > >>>>>
> > > >>>>> This also defines a new structure to define color lut ranges,
> > > >>>>> along with related macro definitions and enums. This will help
> > > >>>>> describe multi segmented lut ranges in the hardware.
> > > >>>>>
> > > >>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > >>>>> ---
> > > >>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> > > >>>>> 1 file changed, 58 insertions(+)
>
> ...
>
> > > >> If the framebuffer is not in FP16 the question then becomes how
> > > >> the integer pixel values relate to LUT addressing.
> > > >
> > > > Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> > > > is to match minimum unsigned integer value to 0.0, and unsigned maximum
> > > > integer value to 1.0. This is how things work on the cable too, right?
> > > > (Also taking full vs. limited range video signal into account. And
> > > > conversion to cable-YUV if that happens.)
> > > >
> > > > If you want integer format FB values to map to something else, then you
> > > > have to tag the FB with that range information, somehow. New UAPI.
> > > >
> > >
> > > On the cable we send integer values, not floating point. AMD HW uses
> > > floating point internally, though, and the PWL API defines floating
> > > point entries, so on some level we need to be clear what the floating
> > > point entries mean. Either we document that to be [0.0, 1.0] or we
> > > have some UAPI to define it. I'm leaning toward the latter but have
> > > to think about it some more.
> >
> > As for Intel hw if you have an integer pixel value of 0xff... (with
> > however many bits you have with a specific pixel format) it will get
> > extended to 0.fff... (to whatever precision the pipe has internally).
> > So if we go by that a fixed point 1.0 value in the proposed
> > drm_color_lut_range would be considered just outside the gamut. And
> > pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
> > value as well [1]. I think that definition pretty much matches how GL
> > UNORM<->float conversion works as well.
>
> Does it work that way in GL though?
>
> I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
> 255.0/256.0.
>
> Taking a random spec: OpenGL ES 2.0.25
>
> Section 2.1.2 Data Conversions says:
>
> Normalized unsigned integers represent numbers in the range
> [0, 1]. The conversion from a normalized unsigned integer c to
> the corresponding floating-point f is defined as
> f = c / (2^b - 1)
>
> Note how the divisor has -1.
That seems to match what I said, or at least tried to say (~0 <-> 1.0 in
float). drm_color_lut_range being fixed point would follow the ~0 side of
that. Or at least that interpretation would very easily map to our hw.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-10 11:55 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-10 15:17 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-10 15:17 UTC (permalink / raw)
To: Ville Syrjälä, Pekka Paalanen
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On 2021-11-10 06:55, Ville Syrjälä wrote:
> On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
>> On Wed, 10 Nov 2021 00:02:16 +0200
>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>
>>> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
>>>> On 2021-11-08 04:54, Pekka Paalanen wrote:
>>>>> On Thu, 4 Nov 2021 12:27:56 -0400
>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>
>>>>>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>>>>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>>>
>>>>>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>>>>>> Existing LUT precision structure is having only 16 bit
>>>>>>>>> precision. This is not enough for upcoming enhanced hardwares
>>>>>>>>> and advance usecases like HDR processing. Hence added a new
>>>>>>>>> structure with 32 bit precision values.
>>>>>>>>>
>>>>>>>>> This also defines a new structure to define color lut ranges,
>>>>>>>>> along with related macro definitions and enums. This will help
>>>>>>>>> describe multi segmented lut ranges in the hardware.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>>>>>> ---
>>>>>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>>>>>>>> 1 file changed, 58 insertions(+)
>>
>> ...
>>
>>>>>> If the framebuffer is not in FP16 the question then becomes how
>>>>>> the integer pixel values relate to LUT addressing.
>>>>>
>>>>> Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
>>>>> is to match minimum unsigned integer value to 0.0, and unsigned maximum
>>>>> integer value to 1.0. This is how things work on the cable too, right?
>>>>> (Also taking full vs. limited range video signal into account. And
>>>>> conversion to cable-YUV if that happens.)
>>>>>
>>>>> If you want integer format FB values to map to something else, then you
>>>>> have to tag the FB with that range information, somehow. New UAPI.
>>>>>
>>>>
>>>> On the cable we send integer values, not floating point. AMD HW uses
>>>> floating point internally, though, and the PWL API defines floating
>>>> point entries, so on some level we need to be clear what the floating
>>>> point entries mean. Either we document that to be [0.0, 1.0] or we
>>>> have some UAPI to define it. I'm leaning toward the latter but have
>>>> to think about it some more.
>>>
>>> As for Intel hw if you have an integer pixel value of 0xff... (with
>>> however many bits you have with a specific pixel format) it will get
>>> extended to 0.fff... (to whatever precision the pipe has internally).
>>> So if we go by that a fixed point 1.0 value in the proposed
>>> drm_color_lut_range would be considered just outside the gamut. And
>>> pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
>>> value as well [1]. I think that definition pretty much matches how GL
>>> UNORM<->float conversion works as well.
>>
>> Does it work that way in GL though?
>>
>> I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
>> 255.0/256.0.
>>
>> Taking a random spec: OpenGL ES 2.0.25
>>
>> Section 2.1.2 Data Conversions says:
>>
>> Normalized unsigned integers represent numbers in the range
>> [0, 1]. The conversion from a normalized unsigned integer c to
>> the corresponding floating-point f is defined as
>> f = c / (2^b - 1)
>>
>> Note how the divisor has -1.
>
> That seems to match what I said, or at least tried to say (~0 <-> 1.0 in
> float). drm_color_lut_range being fixed point would follow the ~0 side of
> that. Or at least that interpretation would very easily map to our hw.
>
If I understand you right Intel HW represents 0xff (assuming 8 bpc) as
the largest (representable) float that is less than 1.0. That float would
be bigger than 255.0/256.0 but smaller than 256.0/256.0.
Harry
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-10 15:17 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-10 15:17 UTC (permalink / raw)
To: Ville Syrjälä, Pekka Paalanen
Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian
On 2021-11-10 06:55, Ville Syrjälä wrote:
> On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
>> On Wed, 10 Nov 2021 00:02:16 +0200
>> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
>>
>>> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
>>>> On 2021-11-08 04:54, Pekka Paalanen wrote:
>>>>> On Thu, 4 Nov 2021 12:27:56 -0400
>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>
>>>>>> On 2021-11-04 04:38, Pekka Paalanen wrote:
>>>>>>> On Wed, 3 Nov 2021 11:08:13 -0400
>>>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>>>>>
>>>>>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>>>>>> Existing LUT precision structure is having only 16 bit
>>>>>>>>> precision. This is not enough for upcoming enhanced hardwares
>>>>>>>>> and advance usecases like HDR processing. Hence added a new
>>>>>>>>> structure with 32 bit precision values.
>>>>>>>>>
>>>>>>>>> This also defines a new structure to define color lut ranges,
>>>>>>>>> along with related macro definitions and enums. This will help
>>>>>>>>> describe multi segmented lut ranges in the hardware.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>>>>>> ---
>>>>>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
>>>>>>>>> 1 file changed, 58 insertions(+)
>>
>> ...
>>
>>>>>> If the framebuffer is not in FP16 the question then becomes how
>>>>>> the integer pixel values relate to LUT addressing.
>>>>>
>>>>> Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
>>>>> is to match minimum unsigned integer value to 0.0, and unsigned maximum
>>>>> integer value to 1.0. This is how things work on the cable too, right?
>>>>> (Also taking full vs. limited range video signal into account. And
>>>>> conversion to cable-YUV if that happens.)
>>>>>
>>>>> If you want integer format FB values to map to something else, then you
>>>>> have to tag the FB with that range information, somehow. New UAPI.
>>>>>
>>>>
>>>> On the cable we send integer values, not floating point. AMD HW uses
>>>> floating point internally, though, and the PWL API defines floating
>>>> point entries, so on some level we need to be clear what the floating
>>>> point entries mean. Either we document that to be [0.0, 1.0] or we
>>>> have some UAPI to define it. I'm leaning toward the latter but have
>>>> to think about it some more.
>>>
>>> As for Intel hw if you have an integer pixel value of 0xff... (with
>>> however many bits you have with a specific pixel format) it will get
>>> extended to 0.fff... (to whatever precision the pipe has internally).
>>> So if we go by that a fixed point 1.0 value in the proposed
>>> drm_color_lut_range would be considered just outside the gamut. And
>>> pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
>>> value as well [1]. I think that definition pretty much matches how GL
>>> UNORM<->float conversion works as well.
>>
>> Does it work that way in GL though?
>>
>> I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
>> 255.0/256.0.
>>
>> Taking a random spec: OpenGL ES 2.0.25
>>
>> Section 2.1.2 Data Conversions says:
>>
>> Normalized unsigned integers represent numbers in the range
>> [0, 1]. The conversion from a normalized unsigned integer c to
>> the corresponding floating-point f is defined as
>> f = c / (2^b - 1)
>>
>> Note how the divisor has -1.
>
> That seems to match what I said, or at least tried to say (~0 <-> 1.0 in
> float). drm_color_lut_range being fixed point would follow the ~0 side of
> that. Or at least that interpretation would very easily map to our hw.
>
If I understand you right Intel HW represents 0xff (assuming 8 bpc) as
the largest (representable) float that is less than 1.0. That float would
be bigger than 255.0/256.0 but smaller than 256.0/256.0.
Harry
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
2021-11-10 15:17 ` [Intel-gfx] " Harry Wentland
@ 2021-11-11 8:22 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-11 8:22 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
[-- Attachment #1: Type: text/plain, Size: 4252 bytes --]
On Wed, 10 Nov 2021 10:17:59 -0500
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-11-10 06:55, Ville Syrjälä wrote:
> > On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
> >> On Wed, 10 Nov 2021 00:02:16 +0200
> >> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >>
> >>> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> >>>> On 2021-11-08 04:54, Pekka Paalanen wrote:
> >>>>> On Thu, 4 Nov 2021 12:27:56 -0400
> >>>>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>>>
> >>>>>> On 2021-11-04 04:38, Pekka Paalanen wrote:
> >>>>>>> On Wed, 3 Nov 2021 11:08:13 -0400
> >>>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>>>>>
> >>>>>>>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>>>>>>> Existing LUT precision structure is having only 16 bit
> >>>>>>>>> precision. This is not enough for upcoming enhanced hardwares
> >>>>>>>>> and advance usecases like HDR processing. Hence added a new
> >>>>>>>>> structure with 32 bit precision values.
> >>>>>>>>>
> >>>>>>>>> This also defines a new structure to define color lut ranges,
> >>>>>>>>> along with related macro definitions and enums. This will help
> >>>>>>>>> describe multi segmented lut ranges in the hardware.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>>>>>>> ---
> >>>>>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>>>>>>>> 1 file changed, 58 insertions(+)
> >>
> >> ...
> >>
> >>>>>> If the framebuffer is not in FP16 the question then becomes how
> >>>>>> the integer pixel values relate to LUT addressing.
> >>>>>
> >>>>> Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> >>>>> is to match minimum unsigned integer value to 0.0, and unsigned maximum
> >>>>> integer value to 1.0. This is how things work on the cable too, right?
> >>>>> (Also taking full vs. limited range video signal into account. And
> >>>>> conversion to cable-YUV if that happens.)
> >>>>>
> >>>>> If you want integer format FB values to map to something else, then you
> >>>>> have to tag the FB with that range information, somehow. New UAPI.
> >>>>>
> >>>>
> >>>> On the cable we send integer values, not floating point. AMD HW uses
> >>>> floating point internally, though, and the PWL API defines floating
> >>>> point entries, so on some level we need to be clear what the floating
> >>>> point entries mean. Either we document that to be [0.0, 1.0] or we
> >>>> have some UAPI to define it. I'm leaning toward the latter but have
> >>>> to think about it some more.
> >>>
> >>> As for Intel hw if you have an integer pixel value of 0xff... (with
> >>> however many bits you have with a specific pixel format) it will get
> >>> extended to 0.fff... (to whatever precision the pipe has internally).
> >>> So if we go by that a fixed point 1.0 value in the proposed
> >>> drm_color_lut_range would be considered just outside the gamut. And
> >>> pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
> >>> value as well [1]. I think that definition pretty much matches how GL
> >>> UNORM<->float conversion works as well.
> >>
> >> Does it work that way in GL though?
> >>
> >> I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
> >> 255.0/256.0.
...
> >
> > That seems to match what I said, or at least tried to say (~0 <-> 1.0 in
> > float). drm_color_lut_range being fixed point would follow the ~0 side of
> > that. Or at least that interpretation would very easily map to our hw.
> >
>
> If I understand you right Intel HW represents 0xff (assuming 8 bpc) as
> the largest (representable) float that is less than 1.0. That float would
> be bigger than 255.0/256.0 but smaller than 256.0/256.0.
I was just really confused and re-reading what Ville wrote originally
now makes sense to me.
So, not what Harry wrote. Let me attempt to reiterate and mark fixed
point hex values with a h to discriminate from float values.
With 8-bit:
0x00 -> 0.000000..0h = 0.0 float
0xff -> 0.ffffff..fh = 1.0 float
Then 1.000..0h is the first value out of range.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes
@ 2021-11-11 8:22 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-11 8:22 UTC (permalink / raw)
To: Harry Wentland; +Cc: Cyr, Aric, intel-gfx, dri-devel, sebastian
[-- Attachment #1: Type: text/plain, Size: 4252 bytes --]
On Wed, 10 Nov 2021 10:17:59 -0500
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-11-10 06:55, Ville Syrjälä wrote:
> > On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote:
> >> On Wed, 10 Nov 2021 00:02:16 +0200
> >> Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >>
> >>> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harry Wentland wrote:
> >>>> On 2021-11-08 04:54, Pekka Paalanen wrote:
> >>>>> On Thu, 4 Nov 2021 12:27:56 -0400
> >>>>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>>>
> >>>>>> On 2021-11-04 04:38, Pekka Paalanen wrote:
> >>>>>>> On Wed, 3 Nov 2021 11:08:13 -0400
> >>>>>>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>>>>>
> >>>>>>>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>>>>>>> Existing LUT precision structure is having only 16 bit
> >>>>>>>>> precision. This is not enough for upcoming enhanced hardwares
> >>>>>>>>> and advance usecases like HDR processing. Hence added a new
> >>>>>>>>> structure with 32 bit precision values.
> >>>>>>>>>
> >>>>>>>>> This also defines a new structure to define color lut ranges,
> >>>>>>>>> along with related macro definitions and enums. This will help
> >>>>>>>>> describe multi segmented lut ranges in the hardware.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>>>>>>> ---
> >>>>>>>>> include/uapi/drm/drm_mode.h | 58 +++++++++++++++++++++++++++++++++++++
> >>>>>>>>> 1 file changed, 58 insertions(+)
> >>
> >> ...
> >>
> >>>>>> If the framebuffer is not in FP16 the question then becomes how
> >>>>>> the integer pixel values relate to LUT addressing.
> >>>>>
> >>>>> Traditionally, and in any API I've seen (GL, Vulkan), a usual mapping
> >>>>> is to match minimum unsigned integer value to 0.0, and unsigned maximum
> >>>>> integer value to 1.0. This is how things work on the cable too, right?
> >>>>> (Also taking full vs. limited range video signal into account. And
> >>>>> conversion to cable-YUV if that happens.)
> >>>>>
> >>>>> If you want integer format FB values to map to something else, then you
> >>>>> have to tag the FB with that range information, somehow. New UAPI.
> >>>>>
> >>>>
> >>>> On the cable we send integer values, not floating point. AMD HW uses
> >>>> floating point internally, though, and the PWL API defines floating
> >>>> point entries, so on some level we need to be clear what the floating
> >>>> point entries mean. Either we document that to be [0.0, 1.0] or we
> >>>> have some UAPI to define it. I'm leaning toward the latter but have
> >>>> to think about it some more.
> >>>
> >>> As for Intel hw if you have an integer pixel value of 0xff... (with
> >>> however many bits you have with a specific pixel format) it will get
> >>> extended to 0.fff... (to whatever precision the pipe has internally).
> >>> So if we go by that a fixed point 1.0 value in the proposed
> >>> drm_color_lut_range would be considered just outside the gamut. And
> >>> pretty sure fp16 input of 1.0 should also result in a 0.fff... internal
> >>> value as well [1]. I think that definition pretty much matches how GL
> >>> UNORM<->float conversion works as well.
> >>
> >> Does it work that way in GL though?
> >>
> >> I've always thought that with GL_UNSIGNED_BYTE, 0xff maps to 1.0, not
> >> 255.0/256.0.
...
> >
> > That seems to match what I said, or at least tried to say (~0 <-> 1.0 in
> > float). drm_color_lut_range being fixed point would follow the ~0 side of
> > that. Or at least that interpretation would very easily map to our hw.
> >
>
> If I understand you right Intel HW represents 0xff (assuming 8 bpc) as
> the largest (representable) float that is less than 1.0. That float would
> be bigger than 255.0/256.0 but smaller than 256.0/256.0.
I was just really confused and re-reading what Ville wrote originally
now makes sense to me.
So, not what Harry wrote. Let me attempt to reiterate and mark fixed
point hex values with a h to discriminate from float values.
With 8-bit:
0x00 -> 0.000000..0h = 0.0 float
0xff -> 0.ffffff..fh = 1.0 float
Then 1.000..0h is the first value out of range.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 03/22] drm: Add Plane Degamma Mode property
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add Plane Degamma Mode as an enum property. Create a helper
function for all plane color management features.
This is an enum property with values as blob_id's and exposes
the various gamma modes supported and the lut ranges. Getting
the blob id in userspace, user can get the mode supported and
also the range of gamma mode supported with number of lut
coefficients. It can then set one of the modes using this
enum property.
Lut values will be sent through separate GAMMA_LUT blob property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
Documentation/gpu/drm-kms.rst | 90 ++++++++++++++++++++++
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_color_mgmt.c | 93 ++++++++++++++++++++++-
include/drm/drm_mode_object.h | 2 +-
include/drm/drm_plane.h | 23 ++++++
7 files changed, 212 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1ef7951ded5e..f4658417bf20 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -545,9 +545,99 @@ Damage Tracking Properties
Color Management Properties
---------------------------
+Below is how a typical hardware pipeline for color
+will look like:
+
+.. kernel-render:: DOT
+ :alt: Display Color Pipeline
+ :caption: Display Color Pipeline Overview
+
+ digraph "KMS" {
+ node [shape=box]
+
+ subgraph cluster_static {
+ style=dashed
+ label="Display Color Hardware Blocks"
+
+ node [bgcolor=grey style=filled]
+ "Plane Degamma A" -> "Plane CSC/CTM A"
+ "Plane CSC/CTM A" -> "Plane Gamma A"
+ "Pipe Blender" [color=lightblue,style=filled, width=5.25, height=0.75];
+ "Plane Gamma A" -> "Pipe Blender"
+ "Pipe Blender" -> "Pipe DeGamma"
+ "Pipe DeGamma" -> "Pipe CSC/CTM"
+ "Pipe CSC/CTM" -> "Pipe Gamma"
+ "Pipe Gamma" -> "Pipe Output"
+ }
+
+ subgraph cluster_static {
+ style=dashed
+
+ node [shape=box]
+ "Plane Degamma B" -> "Plane CSC/CTM B"
+ "Plane CSC/CTM B" -> "Plane Gamma B"
+ "Plane Gamma B" -> "Pipe Blender"
+ }
+
+ subgraph cluster_static {
+ style=dashed
+
+ node [shape=box]
+ "Plane Degamma C" -> "Plane CSC/CTM C"
+ "Plane CSC/CTM C" -> "Plane Gamma C"
+ "Plane Gamma C" -> "Pipe Blender"
+ }
+
+ subgraph cluster_fb {
+ style=dashed
+ label="RAM"
+
+ node [shape=box width=1.7 height=0.2]
+
+ "FB 1" -> "Plane Degamma A"
+ "FB 2" -> "Plane Degamma B"
+ "FB 3" -> "Plane Degamma C"
+ }
+ }
+
+In real world usecases,
+
+1. Plane Degamma can be used to linearize a non linear gamma
+encoded framebuffer. This is needed to do any linear math like
+color space conversion. For ex, linearize frames encoded in SRGB
+or by HDR curve.
+
+2. Later Plane CTM block can convert the content to some different
+colorspace. For ex, SRGB to BT2020 etc.
+
+3. Plane Gamma block can be used later to re-apply the non-linear
+curve. This can also be used to apply Tone Mapping for HDR usecases.
+
+All the layers or framebuffers need to be converted to same color
+space and format before blending. The plane color hardware blocks
+can help with this. Once the Data is blended, similar color processing
+can be done on blended output using pipe color hardware blocks.
+
+DRM Properties have been created to define and expose all these
+hardware blocks to userspace. A userspace application (compositor
+or any color app) can use these interfaces and define policies to
+efficiently use the display hardware for such color operations.
+
+Pipe Color Management Properties
+---------------------------------
+
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
+Plane Color Management Properties
+---------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+ :doc: Plane Color Properties
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+ :doc: export
+
Tile Group Property
-------------------
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..fddf9df15cd5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -709,6 +709,7 @@ static void drm_atomic_plane_print_state(struct drm_printer *p,
drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
+ drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..f26b03853711 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -311,6 +311,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
state->fence = NULL;
state->commit = NULL;
state->fb_damage_clips = NULL;
+
+ state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 909f31833181..3c952123f747 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+ } else if (property == plane->degamma_mode_property) {
+ state->degamma_mode = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -662,6 +664,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+ } else if (property == plane->degamma_mode_property) {
+ *val = state->degamma_mode;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6..085ed0d0db00 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -34,8 +34,8 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
- * properties on the &drm_crtc object. They are set up by calling
+ * Pipe Color management or color space adjustments is supported through a
+ * set of 5 properties on the &drm_crtc object. They are set up by calling
* drm_crtc_enable_color_mgmt().
*
* "DEGAMMA_LUT”:
@@ -584,6 +584,95 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
}
EXPORT_SYMBOL(drm_plane_create_color_properties);
+/**
+ * DOC: Plane Color Properties
+ *
+ * Plane Color management or color space adjustments is supported
+ * through a set of 5 properties on the &drm_plane object.
+ *
+ * degamma_mode_property:
+ * Blob property which advertizes the possible degamma modes and
+ * lut ranges supported by the platform. This allows userspace
+ * to query and get the plane degamma color caps and choose the
+ * appropriate degamma mode and create lut values accordingly
+ *
+ */
+int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
+ struct drm_plane *plane,
+ int num_values)
+{
+ struct drm_property *prop;
+
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "PLANE_DEGAMMA_MODE", num_values);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->degamma_mode_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
+
+void drm_plane_attach_degamma_properties(struct drm_plane *plane)
+{
+ if (!plane->degamma_mode_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->degamma_mode_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
+
+int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
+ const char *name,
+ const struct drm_color_lut_range *ranges,
+ size_t length, enum lut_type type)
+{
+ struct drm_property_blob *blob;
+ struct drm_property *prop = NULL;
+ int num_ranges = length / sizeof(ranges[0]);
+ int i, ret, num_types_0;
+
+ if (type == LUT_TYPE_DEGAMMA)
+ prop = plane->degamma_mode_property;
+
+ if (!prop)
+ return -EINVAL;
+
+ if (length == 0 && name)
+ return drm_property_add_enum(prop, 0, name);
+
+ if (WARN_ON(length == 0 || length % sizeof(ranges[0]) != 0))
+ return -EINVAL;
+ num_types_0 = hweight8(ranges[0].flags & (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_DEGAMMA));
+ if (num_types_0 == 0)
+ return -EINVAL;
+
+ for (i = 1; i < num_ranges; i++) {
+ int num_types = hweight8(ranges[i].flags & (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_DEGAMMA));
+
+ /* either all ranges have DEGAMMA|GAMMA or none have it */
+ if (num_types_0 != num_types)
+ return -EINVAL;
+ }
+
+ blob = drm_property_create_blob(plane->dev, length, ranges);
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
+
+ ret = drm_property_add_enum(prop, blob->base.id, name);
+ if (ret) {
+ drm_property_blob_put(blob);
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_color_add_gamma_degamma_mode_range);
+
/**
* drm_color_lut_check - check validity of lookup table
* @lut: property blob containing LUT to check
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index c34a3e8030e1..d4128c7daa08 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -60,7 +60,7 @@ struct drm_mode_object {
void (*free_cb)(struct kref *kref);
};
-#define DRM_OBJECT_MAX_PROPERTY 24
+#define DRM_OBJECT_MAX_PROPERTY 26
/**
* struct drm_object_properties - property tracking for &drm_mode_object
*/
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 0c1102dc4d88..b9064101db2b 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -239,6 +239,15 @@ struct drm_plane_state {
/** @state: backpointer to global drm_atomic_state */
struct drm_atomic_state *state;
+
+ /**
+ * @degamma_mode: This is a blob_id and exposes the platform capabilities
+ * wrt to various gamma modes and the respective lut ranges. This also
+ * helps user select a degamma mode amongst the supported ones.
+ */
+ u32 degamma_mode;
+
+ u8 color_mgmt_changed : 1;
};
static inline struct drm_rect
@@ -750,6 +759,12 @@ struct drm_plane {
* scaling.
*/
struct drm_property *scaling_filter_property;
+
+ /**
+ * @degamma_mode_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to linear gamma.
+ */
+ struct drm_property *degamma_mode_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
@@ -841,6 +856,14 @@ void drm_plane_force_disable(struct drm_plane *plane);
int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
struct drm_property *property,
uint64_t value);
+int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
+ struct drm_plane *plane,
+ int num_values);
+void drm_plane_attach_degamma_properties(struct drm_plane *plane);
+int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
+ const char *name,
+ const struct drm_color_lut_range *ranges,
+ size_t length, enum lut_type type);
/**
* drm_plane_find - find a &drm_plane
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 03/22] drm: Add Plane Degamma Mode property
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add Plane Degamma Mode as an enum property. Create a helper
function for all plane color management features.
This is an enum property with values as blob_id's and exposes
the various gamma modes supported and the lut ranges. Getting
the blob id in userspace, user can get the mode supported and
also the range of gamma mode supported with number of lut
coefficients. It can then set one of the modes using this
enum property.
Lut values will be sent through separate GAMMA_LUT blob property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
Documentation/gpu/drm-kms.rst | 90 ++++++++++++++++++++++
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_color_mgmt.c | 93 ++++++++++++++++++++++-
include/drm/drm_mode_object.h | 2 +-
include/drm/drm_plane.h | 23 ++++++
7 files changed, 212 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1ef7951ded5e..f4658417bf20 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -545,9 +545,99 @@ Damage Tracking Properties
Color Management Properties
---------------------------
+Below is how a typical hardware pipeline for color
+will look like:
+
+.. kernel-render:: DOT
+ :alt: Display Color Pipeline
+ :caption: Display Color Pipeline Overview
+
+ digraph "KMS" {
+ node [shape=box]
+
+ subgraph cluster_static {
+ style=dashed
+ label="Display Color Hardware Blocks"
+
+ node [bgcolor=grey style=filled]
+ "Plane Degamma A" -> "Plane CSC/CTM A"
+ "Plane CSC/CTM A" -> "Plane Gamma A"
+ "Pipe Blender" [color=lightblue,style=filled, width=5.25, height=0.75];
+ "Plane Gamma A" -> "Pipe Blender"
+ "Pipe Blender" -> "Pipe DeGamma"
+ "Pipe DeGamma" -> "Pipe CSC/CTM"
+ "Pipe CSC/CTM" -> "Pipe Gamma"
+ "Pipe Gamma" -> "Pipe Output"
+ }
+
+ subgraph cluster_static {
+ style=dashed
+
+ node [shape=box]
+ "Plane Degamma B" -> "Plane CSC/CTM B"
+ "Plane CSC/CTM B" -> "Plane Gamma B"
+ "Plane Gamma B" -> "Pipe Blender"
+ }
+
+ subgraph cluster_static {
+ style=dashed
+
+ node [shape=box]
+ "Plane Degamma C" -> "Plane CSC/CTM C"
+ "Plane CSC/CTM C" -> "Plane Gamma C"
+ "Plane Gamma C" -> "Pipe Blender"
+ }
+
+ subgraph cluster_fb {
+ style=dashed
+ label="RAM"
+
+ node [shape=box width=1.7 height=0.2]
+
+ "FB 1" -> "Plane Degamma A"
+ "FB 2" -> "Plane Degamma B"
+ "FB 3" -> "Plane Degamma C"
+ }
+ }
+
+In real world usecases,
+
+1. Plane Degamma can be used to linearize a non linear gamma
+encoded framebuffer. This is needed to do any linear math like
+color space conversion. For ex, linearize frames encoded in SRGB
+or by HDR curve.
+
+2. Later Plane CTM block can convert the content to some different
+colorspace. For ex, SRGB to BT2020 etc.
+
+3. Plane Gamma block can be used later to re-apply the non-linear
+curve. This can also be used to apply Tone Mapping for HDR usecases.
+
+All the layers or framebuffers need to be converted to same color
+space and format before blending. The plane color hardware blocks
+can help with this. Once the Data is blended, similar color processing
+can be done on blended output using pipe color hardware blocks.
+
+DRM Properties have been created to define and expose all these
+hardware blocks to userspace. A userspace application (compositor
+or any color app) can use these interfaces and define policies to
+efficiently use the display hardware for such color operations.
+
+Pipe Color Management Properties
+---------------------------------
+
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
+Plane Color Management Properties
+---------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+ :doc: Plane Color Properties
+
+.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
+ :doc: export
+
Tile Group Property
-------------------
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..fddf9df15cd5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -709,6 +709,7 @@ static void drm_atomic_plane_print_state(struct drm_printer *p,
drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
+ drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..f26b03853711 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -311,6 +311,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
state->fence = NULL;
state->commit = NULL;
state->fb_damage_clips = NULL;
+
+ state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 909f31833181..3c952123f747 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+ } else if (property == plane->degamma_mode_property) {
+ state->degamma_mode = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -662,6 +664,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+ } else if (property == plane->degamma_mode_property) {
+ *val = state->degamma_mode;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6..085ed0d0db00 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -34,8 +34,8 @@
/**
* DOC: overview
*
- * Color management or color space adjustments is supported through a set of 5
- * properties on the &drm_crtc object. They are set up by calling
+ * Pipe Color management or color space adjustments is supported through a
+ * set of 5 properties on the &drm_crtc object. They are set up by calling
* drm_crtc_enable_color_mgmt().
*
* "DEGAMMA_LUT”:
@@ -584,6 +584,95 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
}
EXPORT_SYMBOL(drm_plane_create_color_properties);
+/**
+ * DOC: Plane Color Properties
+ *
+ * Plane Color management or color space adjustments is supported
+ * through a set of 5 properties on the &drm_plane object.
+ *
+ * degamma_mode_property:
+ * Blob property which advertizes the possible degamma modes and
+ * lut ranges supported by the platform. This allows userspace
+ * to query and get the plane degamma color caps and choose the
+ * appropriate degamma mode and create lut values accordingly
+ *
+ */
+int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
+ struct drm_plane *plane,
+ int num_values)
+{
+ struct drm_property *prop;
+
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "PLANE_DEGAMMA_MODE", num_values);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->degamma_mode_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
+
+void drm_plane_attach_degamma_properties(struct drm_plane *plane)
+{
+ if (!plane->degamma_mode_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->degamma_mode_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
+
+int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
+ const char *name,
+ const struct drm_color_lut_range *ranges,
+ size_t length, enum lut_type type)
+{
+ struct drm_property_blob *blob;
+ struct drm_property *prop = NULL;
+ int num_ranges = length / sizeof(ranges[0]);
+ int i, ret, num_types_0;
+
+ if (type == LUT_TYPE_DEGAMMA)
+ prop = plane->degamma_mode_property;
+
+ if (!prop)
+ return -EINVAL;
+
+ if (length == 0 && name)
+ return drm_property_add_enum(prop, 0, name);
+
+ if (WARN_ON(length == 0 || length % sizeof(ranges[0]) != 0))
+ return -EINVAL;
+ num_types_0 = hweight8(ranges[0].flags & (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_DEGAMMA));
+ if (num_types_0 == 0)
+ return -EINVAL;
+
+ for (i = 1; i < num_ranges; i++) {
+ int num_types = hweight8(ranges[i].flags & (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_DEGAMMA));
+
+ /* either all ranges have DEGAMMA|GAMMA or none have it */
+ if (num_types_0 != num_types)
+ return -EINVAL;
+ }
+
+ blob = drm_property_create_blob(plane->dev, length, ranges);
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
+
+ ret = drm_property_add_enum(prop, blob->base.id, name);
+ if (ret) {
+ drm_property_blob_put(blob);
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_plane_color_add_gamma_degamma_mode_range);
+
/**
* drm_color_lut_check - check validity of lookup table
* @lut: property blob containing LUT to check
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index c34a3e8030e1..d4128c7daa08 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -60,7 +60,7 @@ struct drm_mode_object {
void (*free_cb)(struct kref *kref);
};
-#define DRM_OBJECT_MAX_PROPERTY 24
+#define DRM_OBJECT_MAX_PROPERTY 26
/**
* struct drm_object_properties - property tracking for &drm_mode_object
*/
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 0c1102dc4d88..b9064101db2b 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -239,6 +239,15 @@ struct drm_plane_state {
/** @state: backpointer to global drm_atomic_state */
struct drm_atomic_state *state;
+
+ /**
+ * @degamma_mode: This is a blob_id and exposes the platform capabilities
+ * wrt to various gamma modes and the respective lut ranges. This also
+ * helps user select a degamma mode amongst the supported ones.
+ */
+ u32 degamma_mode;
+
+ u8 color_mgmt_changed : 1;
};
static inline struct drm_rect
@@ -750,6 +759,12 @@ struct drm_plane {
* scaling.
*/
struct drm_property *scaling_filter_property;
+
+ /**
+ * @degamma_mode_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to linear gamma.
+ */
+ struct drm_property *degamma_mode_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
@@ -841,6 +856,14 @@ void drm_plane_force_disable(struct drm_plane *plane);
int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
struct drm_property *property,
uint64_t value);
+int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
+ struct drm_plane *plane,
+ int num_values);
+void drm_plane_attach_degamma_properties(struct drm_plane *plane);
+int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
+ const char *name,
+ const struct drm_color_lut_range *ranges,
+ size_t length, enum lut_type type);
/**
* drm_plane_find - find a &drm_plane
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* Re: [RFC v2 03/22] drm: Add Plane Degamma Mode property
2021-09-06 21:38 ` Uma Shankar
@ 2021-10-12 11:50 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 11:50 UTC (permalink / raw)
To: Uma Shankar
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]
On Tue, 7 Sep 2021 03:08:45 +0530
Uma Shankar <uma.shankar@intel.com> wrote:
> Add Plane Degamma Mode as an enum property. Create a helper
> function for all plane color management features.
>
> This is an enum property with values as blob_id's and exposes
> the various gamma modes supported and the lut ranges. Getting
> the blob id in userspace, user can get the mode supported and
> also the range of gamma mode supported with number of lut
> coefficients. It can then set one of the modes using this
> enum property.
>
> Lut values will be sent through separate GAMMA_LUT blob property.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> Documentation/gpu/drm-kms.rst | 90 ++++++++++++++++++++++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> drivers/gpu/drm/drm_color_mgmt.c | 93 ++++++++++++++++++++++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 23 ++++++
> 7 files changed, 212 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1ef7951ded5e..f4658417bf20 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -545,9 +545,99 @@ Damage Tracking Properties
> Color Management Properties
> ---------------------------
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25, height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
Hi,
Maybe better to avoid the term "gamma" as the curves are not always a
pure power function.
sRGB with a small s.
Thanks,
pq
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware blocks
> +can help with this. Once the Data is blended, similar color processing
> +can be done on blended output using pipe color hardware blocks.
> +
> +DRM Properties have been created to define and expose all these
> +hardware blocks to userspace. A userspace application (compositor
> +or any color app) can use these interfaces and define policies to
> +efficiently use the display hardware for such color operations.
> +
> +Pipe Color Management Properties
> +---------------------------------
> +
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :doc: overview
>
> +Plane Color Management Properties
> +---------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: Plane Color Properties
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: export
> +
> Tile Group Property
> -------------------
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 03/22] drm: Add Plane Degamma Mode property
@ 2021-10-12 11:50 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 11:50 UTC (permalink / raw)
To: Uma Shankar
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]
On Tue, 7 Sep 2021 03:08:45 +0530
Uma Shankar <uma.shankar@intel.com> wrote:
> Add Plane Degamma Mode as an enum property. Create a helper
> function for all plane color management features.
>
> This is an enum property with values as blob_id's and exposes
> the various gamma modes supported and the lut ranges. Getting
> the blob id in userspace, user can get the mode supported and
> also the range of gamma mode supported with number of lut
> coefficients. It can then set one of the modes using this
> enum property.
>
> Lut values will be sent through separate GAMMA_LUT blob property.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> Documentation/gpu/drm-kms.rst | 90 ++++++++++++++++++++++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> drivers/gpu/drm/drm_color_mgmt.c | 93 ++++++++++++++++++++++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 23 ++++++
> 7 files changed, 212 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1ef7951ded5e..f4658417bf20 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -545,9 +545,99 @@ Damage Tracking Properties
> Color Management Properties
> ---------------------------
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25, height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
Hi,
Maybe better to avoid the term "gamma" as the curves are not always a
pure power function.
sRGB with a small s.
Thanks,
pq
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware blocks
> +can help with this. Once the Data is blended, similar color processing
> +can be done on blended output using pipe color hardware blocks.
> +
> +DRM Properties have been created to define and expose all these
> +hardware blocks to userspace. A userspace application (compositor
> +or any color app) can use these interfaces and define policies to
> +efficiently use the display hardware for such color operations.
> +
> +Pipe Color Management Properties
> +---------------------------------
> +
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :doc: overview
>
> +Plane Color Management Properties
> +---------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: Plane Color Properties
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: export
> +
> Tile Group Property
> -------------------
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* RE: [RFC v2 03/22] drm: Add Plane Degamma Mode property
2021-10-12 11:50 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-12 21:02 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 21:02 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 5:20 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 03/22] drm: Add Plane Degamma Mode property
>
> On Tue, 7 Sep 2021 03:08:45 +0530
> Uma Shankar <uma.shankar@intel.com> wrote:
>
> > Add Plane Degamma Mode as an enum property. Create a helper function
> > for all plane color management features.
> >
> > This is an enum property with values as blob_id's and exposes the
> > various gamma modes supported and the lut ranges. Getting the blob id
> > in userspace, user can get the mode supported and also the range of
> > gamma mode supported with number of lut coefficients. It can then set
> > one of the modes using this enum property.
> >
> > Lut values will be sent through separate GAMMA_LUT blob property.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > Documentation/gpu/drm-kms.rst | 90 ++++++++++++++++++++++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > drivers/gpu/drm/drm_color_mgmt.c | 93 ++++++++++++++++++++++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 23 ++++++
> > 7 files changed, 212 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst
> > b/Documentation/gpu/drm-kms.rst index 1ef7951ded5e..f4658417bf20
> > 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -545,9 +545,99 @@ Damage Tracking Properties Color Management
> > Properties
> > ---------------------------
> >
> > +Below is how a typical hardware pipeline for color will look like:
> > +
> > +.. kernel-render:: DOT
> > + :alt: Display Color Pipeline
> > + :caption: Display Color Pipeline Overview
> > +
> > + digraph "KMS" {
> > + node [shape=box]
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > + label="Display Color Hardware Blocks"
> > +
> > + node [bgcolor=grey style=filled]
> > + "Plane Degamma A" -> "Plane CSC/CTM A"
> > + "Plane CSC/CTM A" -> "Plane Gamma A"
> > + "Pipe Blender" [color=lightblue,style=filled, width=5.25, height=0.75];
> > + "Plane Gamma A" -> "Pipe Blender"
> > + "Pipe Blender" -> "Pipe DeGamma"
> > + "Pipe DeGamma" -> "Pipe CSC/CTM"
> > + "Pipe CSC/CTM" -> "Pipe Gamma"
> > + "Pipe Gamma" -> "Pipe Output"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma B" -> "Plane CSC/CTM B"
> > + "Plane CSC/CTM B" -> "Plane Gamma B"
> > + "Plane Gamma B" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma C" -> "Plane CSC/CTM C"
> > + "Plane CSC/CTM C" -> "Plane Gamma C"
> > + "Plane Gamma C" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_fb {
> > + style=dashed
> > + label="RAM"
> > +
> > + node [shape=box width=1.7 height=0.2]
> > +
> > + "FB 1" -> "Plane Degamma A"
> > + "FB 2" -> "Plane Degamma B"
> > + "FB 3" -> "Plane Degamma C"
> > + }
> > + }
> > +
> > +In real world usecases,
> > +
> > +1. Plane Degamma can be used to linearize a non linear gamma encoded
> > +framebuffer. This is needed to do any linear math like color space
> > +conversion. For ex, linearize frames encoded in SRGB or by HDR curve.
>
> Hi,
>
> Maybe better to avoid the term "gamma" as the curves are not always a pure power
> function.
>
> sRGB with a small s.
Sure Pekka, will update these.
Thanks & Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > +
> > +2. Later Plane CTM block can convert the content to some different
> > +colorspace. For ex, SRGB to BT2020 etc.
> > +
> > +3. Plane Gamma block can be used later to re-apply the non-linear
> > +curve. This can also be used to apply Tone Mapping for HDR usecases.
> > +
> > +All the layers or framebuffers need to be converted to same color
> > +space and format before blending. The plane color hardware blocks can
> > +help with this. Once the Data is blended, similar color processing
> > +can be done on blended output using pipe color hardware blocks.
> > +
> > +DRM Properties have been created to define and expose all these
> > +hardware blocks to userspace. A userspace application (compositor or
> > +any color app) can use these interfaces and define policies to
> > +efficiently use the display hardware for such color operations.
> > +
> > +Pipe Color Management Properties
> > +---------------------------------
> > +
> > .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> > :doc: overview
> >
> > +Plane Color Management Properties
> > +---------------------------------
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> > + :doc: Plane Color Properties
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> > + :doc: export
> > +
> > Tile Group Property
> > -------------------
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 03/22] drm: Add Plane Degamma Mode property
@ 2021-10-12 21:02 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 21:02 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 5:20 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 03/22] drm: Add Plane Degamma Mode property
>
> On Tue, 7 Sep 2021 03:08:45 +0530
> Uma Shankar <uma.shankar@intel.com> wrote:
>
> > Add Plane Degamma Mode as an enum property. Create a helper function
> > for all plane color management features.
> >
> > This is an enum property with values as blob_id's and exposes the
> > various gamma modes supported and the lut ranges. Getting the blob id
> > in userspace, user can get the mode supported and also the range of
> > gamma mode supported with number of lut coefficients. It can then set
> > one of the modes using this enum property.
> >
> > Lut values will be sent through separate GAMMA_LUT blob property.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > Documentation/gpu/drm-kms.rst | 90 ++++++++++++++++++++++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > drivers/gpu/drm/drm_color_mgmt.c | 93 ++++++++++++++++++++++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 23 ++++++
> > 7 files changed, 212 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/gpu/drm-kms.rst
> > b/Documentation/gpu/drm-kms.rst index 1ef7951ded5e..f4658417bf20
> > 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -545,9 +545,99 @@ Damage Tracking Properties Color Management
> > Properties
> > ---------------------------
> >
> > +Below is how a typical hardware pipeline for color will look like:
> > +
> > +.. kernel-render:: DOT
> > + :alt: Display Color Pipeline
> > + :caption: Display Color Pipeline Overview
> > +
> > + digraph "KMS" {
> > + node [shape=box]
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > + label="Display Color Hardware Blocks"
> > +
> > + node [bgcolor=grey style=filled]
> > + "Plane Degamma A" -> "Plane CSC/CTM A"
> > + "Plane CSC/CTM A" -> "Plane Gamma A"
> > + "Pipe Blender" [color=lightblue,style=filled, width=5.25, height=0.75];
> > + "Plane Gamma A" -> "Pipe Blender"
> > + "Pipe Blender" -> "Pipe DeGamma"
> > + "Pipe DeGamma" -> "Pipe CSC/CTM"
> > + "Pipe CSC/CTM" -> "Pipe Gamma"
> > + "Pipe Gamma" -> "Pipe Output"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma B" -> "Plane CSC/CTM B"
> > + "Plane CSC/CTM B" -> "Plane Gamma B"
> > + "Plane Gamma B" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_static {
> > + style=dashed
> > +
> > + node [shape=box]
> > + "Plane Degamma C" -> "Plane CSC/CTM C"
> > + "Plane CSC/CTM C" -> "Plane Gamma C"
> > + "Plane Gamma C" -> "Pipe Blender"
> > + }
> > +
> > + subgraph cluster_fb {
> > + style=dashed
> > + label="RAM"
> > +
> > + node [shape=box width=1.7 height=0.2]
> > +
> > + "FB 1" -> "Plane Degamma A"
> > + "FB 2" -> "Plane Degamma B"
> > + "FB 3" -> "Plane Degamma C"
> > + }
> > + }
> > +
> > +In real world usecases,
> > +
> > +1. Plane Degamma can be used to linearize a non linear gamma encoded
> > +framebuffer. This is needed to do any linear math like color space
> > +conversion. For ex, linearize frames encoded in SRGB or by HDR curve.
>
> Hi,
>
> Maybe better to avoid the term "gamma" as the curves are not always a pure power
> function.
>
> sRGB with a small s.
Sure Pekka, will update these.
Thanks & Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > +
> > +2. Later Plane CTM block can convert the content to some different
> > +colorspace. For ex, SRGB to BT2020 etc.
> > +
> > +3. Plane Gamma block can be used later to re-apply the non-linear
> > +curve. This can also be used to apply Tone Mapping for HDR usecases.
> > +
> > +All the layers or framebuffers need to be converted to same color
> > +space and format before blending. The plane color hardware blocks can
> > +help with this. Once the Data is blended, similar color processing
> > +can be done on blended output using pipe color hardware blocks.
> > +
> > +DRM Properties have been created to define and expose all these
> > +hardware blocks to userspace. A userspace application (compositor or
> > +any color app) can use these interfaces and define policies to
> > +efficiently use the display hardware for such color operations.
> > +
> > +Pipe Color Management Properties
> > +---------------------------------
> > +
> > .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> > :doc: overview
> >
> > +Plane Color Management Properties
> > +---------------------------------
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> > + :doc: Plane Color Properties
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> > + :doc: export
> > +
> > Tile Group Property
> > -------------------
^ permalink raw reply [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 04/22] drm: Add Plane Degamma Lut property
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add Plane Degamma Lut as a blob property. User will calculate
the lut values, create the blob and send it to driver using
this property. Lut calculation will be based on the gamma mode
chosen out of the gamma mode exposed.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4 ++++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++++++++++
drivers/gpu/drm/drm_color_mgmt.c | 19 +++++++++++++++++++
include/drm/drm_plane.h | 14 ++++++++++++++
4 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index f26b03853711..6e358067cb7a 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -312,6 +312,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
state->commit = NULL;
state->fb_damage_clips = NULL;
+ if (state->degamma_lut)
+ drm_property_blob_get(state->degamma_lut);
+
state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -359,6 +362,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
drm_crtc_commit_put(state->commit);
drm_property_blob_put(state->fb_damage_clips);
+ drm_property_blob_put(state->degamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 3c952123f747..904291b96ba9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -598,6 +598,13 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
state->color_range = val;
} else if (property == plane->degamma_mode_property) {
state->degamma_mode = val;
+ } else if (property == plane->degamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->degamma_lut,
+ val, -1, sizeof(struct drm_color_lut_ext),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -666,6 +673,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_range;
} else if (property == plane->degamma_mode_property) {
*val = state->degamma_mode;
+ } else if (property == plane->degamma_lut_property) {
+ *val = (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 085ed0d0db00..29d0fc1e52b5 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -596,6 +596,12 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* to query and get the plane degamma color caps and choose the
* appropriate degamma mode and create lut values accordingly
*
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w plane degamma processing
+ * engine, thereby making the content as linear for further color
+ * processing.
+ *
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -610,6 +616,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->degamma_mode_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "PLANE_DEGAMMA_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->degamma_lut_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -621,6 +634,12 @@ void drm_plane_attach_degamma_properties(struct drm_plane *plane)
drm_object_attach_property(&plane->base,
plane->degamma_mode_property, 0);
+
+ if (!plane->degamma_lut_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->degamma_lut_property, 0);
}
EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index b9064101db2b..fbfada0b990d 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -247,6 +247,14 @@ struct drm_plane_state {
*/
u32 degamma_mode;
+ /* @degamma_lut:
+ *
+ * Lookup table for converting framebuffer pixel data before apply the
+ * color conversion matrix @ctm. See drm_plane_enable_color_mgmt(). The
+ * blob (if not NULL) is an array of &struct drm_color_lut_ext.
+ */
+ struct drm_property_blob *degamma_lut;
+
u8 color_mgmt_changed : 1;
};
@@ -765,6 +773,12 @@ struct drm_plane {
* used to convert the framebuffer's colors to linear gamma.
*/
struct drm_property *degamma_mode_property;
+
+ /**
+ * @degamma_lut_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to linear gamma.
+ */
+ struct drm_property *degamma_lut_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 04/22] drm: Add Plane Degamma Lut property
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add Plane Degamma Lut as a blob property. User will calculate
the lut values, create the blob and send it to driver using
this property. Lut calculation will be based on the gamma mode
chosen out of the gamma mode exposed.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4 ++++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++++++++++
drivers/gpu/drm/drm_color_mgmt.c | 19 +++++++++++++++++++
include/drm/drm_plane.h | 14 ++++++++++++++
4 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index f26b03853711..6e358067cb7a 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -312,6 +312,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
state->commit = NULL;
state->fb_damage_clips = NULL;
+ if (state->degamma_lut)
+ drm_property_blob_get(state->degamma_lut);
+
state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -359,6 +362,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
drm_crtc_commit_put(state->commit);
drm_property_blob_put(state->fb_damage_clips);
+ drm_property_blob_put(state->degamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 3c952123f747..904291b96ba9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -598,6 +598,13 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
state->color_range = val;
} else if (property == plane->degamma_mode_property) {
state->degamma_mode = val;
+ } else if (property == plane->degamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->degamma_lut,
+ val, -1, sizeof(struct drm_color_lut_ext),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -666,6 +673,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->color_range;
} else if (property == plane->degamma_mode_property) {
*val = state->degamma_mode;
+ } else if (property == plane->degamma_lut_property) {
+ *val = (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 085ed0d0db00..29d0fc1e52b5 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -596,6 +596,12 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* to query and get the plane degamma color caps and choose the
* appropriate degamma mode and create lut values accordingly
*
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w plane degamma processing
+ * engine, thereby making the content as linear for further color
+ * processing.
+ *
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -610,6 +616,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->degamma_mode_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "PLANE_DEGAMMA_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->degamma_lut_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -621,6 +634,12 @@ void drm_plane_attach_degamma_properties(struct drm_plane *plane)
drm_object_attach_property(&plane->base,
plane->degamma_mode_property, 0);
+
+ if (!plane->degamma_lut_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->degamma_lut_property, 0);
}
EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index b9064101db2b..fbfada0b990d 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -247,6 +247,14 @@ struct drm_plane_state {
*/
u32 degamma_mode;
+ /* @degamma_lut:
+ *
+ * Lookup table for converting framebuffer pixel data before apply the
+ * color conversion matrix @ctm. See drm_plane_enable_color_mgmt(). The
+ * blob (if not NULL) is an array of &struct drm_color_lut_ext.
+ */
+ struct drm_property_blob *degamma_lut;
+
u8 color_mgmt_changed : 1;
};
@@ -765,6 +773,12 @@ struct drm_plane {
* used to convert the framebuffer's colors to linear gamma.
*/
struct drm_property *degamma_mode_property;
+
+ /**
+ * @degamma_lut_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to linear gamma.
+ */
+ struct drm_property *degamma_lut_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Define the structure with XE_LPD degamma lut ranges. HDR and SDR
planes have different capabilities, implemented respective
structure for the HDR planes.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index afcb4bf3826c..6403bd74324b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
}
}
+ /* FIXME input bpc? */
+__maybe_unused
+static const struct drm_color_lut_range d13_degamma_hdr[] = {
+ /* segment 1 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 128,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 0, .end = (1 << 24) - 1,
+ .min = 0, .max = (1 << 24) - 1,
+ },
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = (1 << 24) - 1, .end = 1 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+ /* Segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 1 << 24, .end = 3 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 3 << 24, .end = 7 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+};
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Define the structure with XE_LPD degamma lut ranges. HDR and SDR
planes have different capabilities, implemented respective
structure for the HDR planes.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index afcb4bf3826c..6403bd74324b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
}
}
+ /* FIXME input bpc? */
+__maybe_unused
+static const struct drm_color_lut_range d13_degamma_hdr[] = {
+ /* segment 1 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 128,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 0, .end = (1 << 24) - 1,
+ .min = 0, .max = (1 << 24) - 1,
+ },
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = (1 << 24) - 1, .end = 1 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+ /* Segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 1 << 24, .end = 3 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 3 << 24, .end = 7 << 24,
+ .min = 0, .max = (1 << 27) - 1,
+ },
+};
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-09-06 21:38 ` Uma Shankar
@ 2021-11-03 15:10 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-03 15:10 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, Shashank.Sharma
On 2021-09-06 17:38, Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> index afcb4bf3826c..6403bd74324b 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> }
> }
>
> + /* FIXME input bpc? */
> +__maybe_unused
> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> + /* segment 1 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 128,
Is the distribution of the 128 entries uniform? If so, is a
uniform distribution of 128 points across most of the LUT
good enough for HDR with 128 entries?
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
.start and .end are only a single entry apart. Is this correct?
Harry
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 3 << 24, .end = 7 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> +};
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-03 15:10 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-03 15:10 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, ppaalanen
On 2021-09-06 17:38, Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> index afcb4bf3826c..6403bd74324b 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> }
> }
>
> + /* FIXME input bpc? */
> +__maybe_unused
> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> + /* segment 1 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 128,
Is the distribution of the 128 entries uniform? If so, is a
uniform distribution of 128 points across most of the LUT
good enough for HDR with 128 entries?
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
.start and .end are only a single entry apart. Is this correct?
Harry
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 3 << 24, .end = 7 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> +};
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-03 15:10 ` [Intel-gfx] " Harry Wentland
@ 2021-11-05 12:59 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-05 12:59 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> > index afcb4bf3826c..6403bd74324b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> > }
> > }
> >
> > + /* FIXME input bpc? */
> > +__maybe_unused
> > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 128,
>
> Is the distribution of the 128 entries uniform?
I guess this is the plane gamma thing despite being in intel_color.c,
so yeah I think that's correct.
> If so, is a
> uniform distribution of 128 points across most of the LUT
> good enough for HDR with 128 entries?
No idea how good this actually is. It is .24 so at least
it does have a fair bit of precision.
>
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
>
> .start and .end are only a single entry apart. Is this correct?
One think I wanted to do is simplify this stuff by getting rid of
.end entirely. So I think this should just be '.start=1<<24' (or
whatever way we decide to specify the input precision, which is
I think another slightly open question).
So for this thing we could just have:
{ .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
{ .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
{ .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
{ .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
+ flags/etc. which I left out for brevity.
So that is trying to indicate that the first 129 entries are equally
spaced, and would be used to interpolate for input values [0.0,1.0).
Input values [1.0,3.0) would interpolate between entry 128 and 129,
and [3.0,7.0) would interpolate between entry 129 and 130.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-05 12:59 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-05 12:59 UTC (permalink / raw)
To: Harry Wentland; +Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> > index afcb4bf3826c..6403bd74324b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> > }
> > }
> >
> > + /* FIXME input bpc? */
> > +__maybe_unused
> > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 128,
>
> Is the distribution of the 128 entries uniform?
I guess this is the plane gamma thing despite being in intel_color.c,
so yeah I think that's correct.
> If so, is a
> uniform distribution of 128 points across most of the LUT
> good enough for HDR with 128 entries?
No idea how good this actually is. It is .24 so at least
it does have a fair bit of precision.
>
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
>
> .start and .end are only a single entry apart. Is this correct?
One think I wanted to do is simplify this stuff by getting rid of
.end entirely. So I think this should just be '.start=1<<24' (or
whatever way we decide to specify the input precision, which is
I think another slightly open question).
So for this thing we could just have:
{ .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
{ .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
{ .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
{ .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
+ flags/etc. which I left out for brevity.
So that is trying to indicate that the first 129 entries are equally
spaced, and would be used to interpolate for input values [0.0,1.0).
Input values [1.0,3.0) would interpolate between entry 128 and 129,
and [3.0,7.0) would interpolate between entry 129 and 130.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-05 12:59 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-09 20:19 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 20:19 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On 2021-11-05 08:59, Ville Syrjälä wrote:
> On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>>
>>
>> On 2021-09-06 17:38, Uma Shankar wrote:
>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>> planes have different capabilities, implemented respective
>>> structure for the HDR planes.
>>>
>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
>>> 1 file changed, 52 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
>>> index afcb4bf3826c..6403bd74324b 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
>>> }
>>> }
>>>
>>> + /* FIXME input bpc? */
>>> +__maybe_unused
>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>> + /* segment 1 */
>>> + {
>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>> + DRM_MODE_LUT_INTERPOLATE |
>>> + DRM_MODE_LUT_NON_DECREASING),
>>> + .count = 128,
>>
>> Is the distribution of the 128 entries uniform?
>
> I guess this is the plane gamma thing despite being in intel_color.c,
> so yeah I think that's correct.
>
>> If so, is a
>> uniform distribution of 128 points across most of the LUT
>> good enough for HDR with 128 entries?
>
> No idea how good this actually is. It is .24 so at least
> it does have a fair bit of precision.
>
Precision is good but you also need enough samples. Though that's
probably less my concern and more your concern and should become
apparent once its used.
>>
>>> + .input_bpc = 24, .output_bpc = 16,
>>> + .start = 0, .end = (1 << 24) - 1,
>>> + .min = 0, .max = (1 << 24) - 1,
>>> + },
>>> + /* segment 2 */
>>> + {
>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>> + DRM_MODE_LUT_INTERPOLATE |
>>> + DRM_MODE_LUT_REUSE_LAST |
>>> + DRM_MODE_LUT_NON_DECREASING),
>>> + .count = 1,
>>> + .input_bpc = 24, .output_bpc = 16,
>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>
>> .start and .end are only a single entry apart. Is this correct?
>
> One think I wanted to do is simplify this stuff by getting rid of
> .end entirely. So I think this should just be '.start=1<<24' (or
> whatever way we decide to specify the input precision, which is
> I think another slightly open question).
>
> So for this thing we could just have:
> { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
>
> + flags/etc. which I left out for brevity.
>
Makes sense. I like this.
> So that is trying to indicate that the first 129 entries are equally
> spaced, and would be used to interpolate for input values [0.0,1.0).
> Input values [1.0,3.0) would interpolate between entry 128 and 129,
> and [3.0,7.0) would interpolate between entry 129 and 130.
>
What in the segment definition defines the 1.0 mark? In your example
it seems to be at (1 << 24) but then we would have values that go
beyond the input_bpc for the last three segments.
How about output_bpc? Would output_bpc somehow limit the U32.32 (or
S31.32) entries, and if so, how?
Or should we treat input_/output_bpc only as capability reporting, so
userspace can calculate the possible error when programming the LUT?
Again, this leaves us with the question what the input_/output_bpc
means for our PWL entries.
Harry
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-09 20:19 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 20:19 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On 2021-11-05 08:59, Ville Syrjälä wrote:
> On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>>
>>
>> On 2021-09-06 17:38, Uma Shankar wrote:
>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>> planes have different capabilities, implemented respective
>>> structure for the HDR planes.
>>>
>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
>>> 1 file changed, 52 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
>>> index afcb4bf3826c..6403bd74324b 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
>>> }
>>> }
>>>
>>> + /* FIXME input bpc? */
>>> +__maybe_unused
>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>> + /* segment 1 */
>>> + {
>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>> + DRM_MODE_LUT_INTERPOLATE |
>>> + DRM_MODE_LUT_NON_DECREASING),
>>> + .count = 128,
>>
>> Is the distribution of the 128 entries uniform?
>
> I guess this is the plane gamma thing despite being in intel_color.c,
> so yeah I think that's correct.
>
>> If so, is a
>> uniform distribution of 128 points across most of the LUT
>> good enough for HDR with 128 entries?
>
> No idea how good this actually is. It is .24 so at least
> it does have a fair bit of precision.
>
Precision is good but you also need enough samples. Though that's
probably less my concern and more your concern and should become
apparent once its used.
>>
>>> + .input_bpc = 24, .output_bpc = 16,
>>> + .start = 0, .end = (1 << 24) - 1,
>>> + .min = 0, .max = (1 << 24) - 1,
>>> + },
>>> + /* segment 2 */
>>> + {
>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>> + DRM_MODE_LUT_INTERPOLATE |
>>> + DRM_MODE_LUT_REUSE_LAST |
>>> + DRM_MODE_LUT_NON_DECREASING),
>>> + .count = 1,
>>> + .input_bpc = 24, .output_bpc = 16,
>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>
>> .start and .end are only a single entry apart. Is this correct?
>
> One think I wanted to do is simplify this stuff by getting rid of
> .end entirely. So I think this should just be '.start=1<<24' (or
> whatever way we decide to specify the input precision, which is
> I think another slightly open question).
>
> So for this thing we could just have:
> { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
>
> + flags/etc. which I left out for brevity.
>
Makes sense. I like this.
> So that is trying to indicate that the first 129 entries are equally
> spaced, and would be used to interpolate for input values [0.0,1.0).
> Input values [1.0,3.0) would interpolate between entry 128 and 129,
> and [3.0,7.0) would interpolate between entry 129 and 130.
>
What in the segment definition defines the 1.0 mark? In your example
it seems to be at (1 << 24) but then we would have values that go
beyond the input_bpc for the last three segments.
How about output_bpc? Would output_bpc somehow limit the U32.32 (or
S31.32) entries, and if so, how?
Or should we treat input_/output_bpc only as capability reporting, so
userspace can calculate the possible error when programming the LUT?
Again, this leaves us with the question what the input_/output_bpc
means for our PWL entries.
Harry
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-09 20:19 ` [Intel-gfx] " Harry Wentland
@ 2021-11-09 21:45 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-09 21:45 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On Tue, Nov 09, 2021 at 03:19:47PM -0500, Harry Wentland wrote:
> On 2021-11-05 08:59, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
> >>
> >>
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>> planes have different capabilities, implemented respective
> >>> structure for the HDR planes.
> >>>
> >>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> >>> 1 file changed, 52 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> >>> index afcb4bf3826c..6403bd74324b 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> >>> }
> >>> }
> >>>
> >>> + /* FIXME input bpc? */
> >>> +__maybe_unused
> >>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>> + /* segment 1 */
> >>> + {
> >>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>> + DRM_MODE_LUT_INTERPOLATE |
> >>> + DRM_MODE_LUT_NON_DECREASING),
> >>> + .count = 128,
> >>
> >> Is the distribution of the 128 entries uniform?
> >
> > I guess this is the plane gamma thing despite being in intel_color.c,
> > so yeah I think that's correct.
> >
> >> If so, is a
> >> uniform distribution of 128 points across most of the LUT
> >> good enough for HDR with 128 entries?
> >
> > No idea how good this actually is. It is .24 so at least
> > it does have a fair bit of precision.
> >
>
> Precision is good but you also need enough samples. Though that's
> probably less my concern and more your concern and should become
> apparent once its used.
Yeah, for pipe gamma we have a few different variants with
non-uniform spacing of the samples. But not here AFAICS for
whatever reason.
>
> >>
> >>> + .input_bpc = 24, .output_bpc = 16,
> >>> + .start = 0, .end = (1 << 24) - 1,
> >>> + .min = 0, .max = (1 << 24) - 1,
> >>> + },
> >>> + /* segment 2 */
> >>> + {
> >>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>> + DRM_MODE_LUT_INTERPOLATE |
> >>> + DRM_MODE_LUT_REUSE_LAST |
> >>> + DRM_MODE_LUT_NON_DECREASING),
> >>> + .count = 1,
> >>> + .input_bpc = 24, .output_bpc = 16,
> >>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>
> >> .start and .end are only a single entry apart. Is this correct?
> >
> > One think I wanted to do is simplify this stuff by getting rid of
> > .end entirely. So I think this should just be '.start=1<<24' (or
> > whatever way we decide to specify the input precision, which is
> > I think another slightly open question).
> >
> > So for this thing we could just have:
> > { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
> > { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
> > { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
> > { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
> >
> > + flags/etc. which I left out for brevity.
> >
>
> Makes sense. I like this.
>
> > So that is trying to indicate that the first 129 entries are equally
> > spaced, and would be used to interpolate for input values [0.0,1.0).
> > Input values [1.0,3.0) would interpolate between entry 128 and 129,
> > and [3.0,7.0) would interpolate between entry 129 and 130.
> >
>
> What in the segment definition defines the 1.0 mark? In your example
> it seems to be at (1 << 24) but then we would have values that go
> beyond the input_bpc for the last three segments.
Yes, input_bpc would define the precision of the input values (.start).
so 1.0 would be at 1<<input_bpc. Tne range of input values is allowed to
extend outside the 0.0-1.0 range.
>
> How about output_bpc? Would output_bpc somehow limit the U32.32 (or
> S31.32) entries, and if so, how?
output_bpc would define the actual precision of the output values,
so again 1.0 would be 1<<output_bpc, and .min and .max define the
min/max values (which can extend outside the 0.0-1.0 range). The
alternative I guess would be to not have .output_bpc at all and
just have .min/.max be s32.32 values. Though then you can't tell
what the actual precision is. Same could be done for .input_bpc
I suppose.
>
> Or should we treat input_/output_bpc only as capability reporting, so
> userspace can calculate the possible error when programming the LUT?
> Again, this leaves us with the question what the input_/output_bpc
> means for our PWL entries.
Yeah, I mostly thought they might be interesting if userspace wants
to know the exact precision. But not strictly necessary if you want
just to go generate a "close enough" curve.
What's PWL?
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-09 21:45 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-09 21:45 UTC (permalink / raw)
To: Harry Wentland; +Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On Tue, Nov 09, 2021 at 03:19:47PM -0500, Harry Wentland wrote:
> On 2021-11-05 08:59, Ville Syrjälä wrote:
> > On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
> >>
> >>
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>> planes have different capabilities, implemented respective
> >>> structure for the HDR planes.
> >>>
> >>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> >>> 1 file changed, 52 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> >>> index afcb4bf3826c..6403bd74324b 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> >>> }
> >>> }
> >>>
> >>> + /* FIXME input bpc? */
> >>> +__maybe_unused
> >>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>> + /* segment 1 */
> >>> + {
> >>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>> + DRM_MODE_LUT_INTERPOLATE |
> >>> + DRM_MODE_LUT_NON_DECREASING),
> >>> + .count = 128,
> >>
> >> Is the distribution of the 128 entries uniform?
> >
> > I guess this is the plane gamma thing despite being in intel_color.c,
> > so yeah I think that's correct.
> >
> >> If so, is a
> >> uniform distribution of 128 points across most of the LUT
> >> good enough for HDR with 128 entries?
> >
> > No idea how good this actually is. It is .24 so at least
> > it does have a fair bit of precision.
> >
>
> Precision is good but you also need enough samples. Though that's
> probably less my concern and more your concern and should become
> apparent once its used.
Yeah, for pipe gamma we have a few different variants with
non-uniform spacing of the samples. But not here AFAICS for
whatever reason.
>
> >>
> >>> + .input_bpc = 24, .output_bpc = 16,
> >>> + .start = 0, .end = (1 << 24) - 1,
> >>> + .min = 0, .max = (1 << 24) - 1,
> >>> + },
> >>> + /* segment 2 */
> >>> + {
> >>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>> + DRM_MODE_LUT_INTERPOLATE |
> >>> + DRM_MODE_LUT_REUSE_LAST |
> >>> + DRM_MODE_LUT_NON_DECREASING),
> >>> + .count = 1,
> >>> + .input_bpc = 24, .output_bpc = 16,
> >>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>
> >> .start and .end are only a single entry apart. Is this correct?
> >
> > One think I wanted to do is simplify this stuff by getting rid of
> > .end entirely. So I think this should just be '.start=1<<24' (or
> > whatever way we decide to specify the input precision, which is
> > I think another slightly open question).
> >
> > So for this thing we could just have:
> > { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
> > { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
> > { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
> > { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
> >
> > + flags/etc. which I left out for brevity.
> >
>
> Makes sense. I like this.
>
> > So that is trying to indicate that the first 129 entries are equally
> > spaced, and would be used to interpolate for input values [0.0,1.0).
> > Input values [1.0,3.0) would interpolate between entry 128 and 129,
> > and [3.0,7.0) would interpolate between entry 129 and 130.
> >
>
> What in the segment definition defines the 1.0 mark? In your example
> it seems to be at (1 << 24) but then we would have values that go
> beyond the input_bpc for the last three segments.
Yes, input_bpc would define the precision of the input values (.start).
so 1.0 would be at 1<<input_bpc. Tne range of input values is allowed to
extend outside the 0.0-1.0 range.
>
> How about output_bpc? Would output_bpc somehow limit the U32.32 (or
> S31.32) entries, and if so, how?
output_bpc would define the actual precision of the output values,
so again 1.0 would be 1<<output_bpc, and .min and .max define the
min/max values (which can extend outside the 0.0-1.0 range). The
alternative I guess would be to not have .output_bpc at all and
just have .min/.max be s32.32 values. Though then you can't tell
what the actual precision is. Same could be done for .input_bpc
I suppose.
>
> Or should we treat input_/output_bpc only as capability reporting, so
> userspace can calculate the possible error when programming the LUT?
> Again, this leaves us with the question what the input_/output_bpc
> means for our PWL entries.
Yeah, I mostly thought they might be interesting if userspace wants
to know the exact precision. But not strictly necessary if you want
just to go generate a "close enough" curve.
What's PWL?
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-09 21:45 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-09 21:56 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 21:56 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On 2021-11-09 16:45, Ville Syrjälä wrote:
> On Tue, Nov 09, 2021 at 03:19:47PM -0500, Harry Wentland wrote:
>> On 2021-11-05 08:59, Ville Syrjälä wrote:
>>> On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>>>>
>>>>
>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>>>> planes have different capabilities, implemented respective
>>>>> structure for the HDR planes.
>>>>>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
>>>>> 1 file changed, 52 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
>>>>> index afcb4bf3826c..6403bd74324b 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
>>>>> }
>>>>> }
>>>>>
>>>>> + /* FIXME input bpc? */
>>>>> +__maybe_unused
>>>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>>>> + /* segment 1 */
>>>>> + {
>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>> + .count = 128,
>>>>
>>>> Is the distribution of the 128 entries uniform?
>>>
>>> I guess this is the plane gamma thing despite being in intel_color.c,
>>> so yeah I think that's correct.
>>>
>>>> If so, is a
>>>> uniform distribution of 128 points across most of the LUT
>>>> good enough for HDR with 128 entries?
>>>
>>> No idea how good this actually is. It is .24 so at least
>>> it does have a fair bit of precision.
>>>
>>
>> Precision is good but you also need enough samples. Though that's
>> probably less my concern and more your concern and should become
>> apparent once its used.
>
> Yeah, for pipe gamma we have a few different variants with
> non-uniform spacing of the samples. But not here AFAICS for
> whatever reason.
>
>>
>>>>
>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>> + .start = 0, .end = (1 << 24) - 1,
>>>>> + .min = 0, .max = (1 << 24) - 1,
>>>>> + },
>>>>> + /* segment 2 */
>>>>> + {
>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>> + .count = 1,
>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>>>
>>>> .start and .end are only a single entry apart. Is this correct?
>>>
>>> One think I wanted to do is simplify this stuff by getting rid of
>>> .end entirely. So I think this should just be '.start=1<<24' (or
>>> whatever way we decide to specify the input precision, which is
>>> I think another slightly open question).
>>>
>>> So for this thing we could just have:
>>> { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
>>> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
>>> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
>>> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
>>>
>>> + flags/etc. which I left out for brevity.
>>>
>>
>> Makes sense. I like this.
>>
>>> So that is trying to indicate that the first 129 entries are equally
>>> spaced, and would be used to interpolate for input values [0.0,1.0).
>>> Input values [1.0,3.0) would interpolate between entry 128 and 129,
>>> and [3.0,7.0) would interpolate between entry 129 and 130.
>>>
>>
>> What in the segment definition defines the 1.0 mark? In your example
>> it seems to be at (1 << 24) but then we would have values that go
>> beyond the input_bpc for the last three segments.
>
> Yes, input_bpc would define the precision of the input values (.start).
> so 1.0 would be at 1<<input_bpc. Tne range of input values is allowed to
> extend outside the 0.0-1.0 range.
>
>>
>> How about output_bpc? Would output_bpc somehow limit the U32.32 (or
>> S31.32) entries, and if so, how?
>
> output_bpc would define the actual precision of the output values,
> so again 1.0 would be 1<<output_bpc, and .min and .max define the
> min/max values (which can extend outside the 0.0-1.0 range). The
> alternative I guess would be to not have .output_bpc at all and
> just have .min/.max be s32.32 values. Though then you can't tell
> what the actual precision is. Same could be done for .input_bpc
> I suppose.
>
>>
>> Or should we treat input_/output_bpc only as capability reporting, so
>> userspace can calculate the possible error when programming the LUT?
>> Again, this leaves us with the question what the input_/output_bpc
>> means for our PWL entries.
>
> Yeah, I mostly thought they might be interesting if userspace wants
> to know the exact precision. But not strictly necessary if you want
> just to go generate a "close enough" curve.
>
> What's PWL?
>
Got it, I think.
Piece-wise linear LUT, i.e. a (usually segmented) LUT that
linearly interpolates in between entries.
Harry
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-09 21:56 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-09 21:56 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On 2021-11-09 16:45, Ville Syrjälä wrote:
> On Tue, Nov 09, 2021 at 03:19:47PM -0500, Harry Wentland wrote:
>> On 2021-11-05 08:59, Ville Syrjälä wrote:
>>> On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>>>>
>>>>
>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>>>> planes have different capabilities, implemented respective
>>>>> structure for the HDR planes.
>>>>>
>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
>>>>> 1 file changed, 52 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
>>>>> index afcb4bf3826c..6403bd74324b 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
>>>>> }
>>>>> }
>>>>>
>>>>> + /* FIXME input bpc? */
>>>>> +__maybe_unused
>>>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>>>> + /* segment 1 */
>>>>> + {
>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>> + .count = 128,
>>>>
>>>> Is the distribution of the 128 entries uniform?
>>>
>>> I guess this is the plane gamma thing despite being in intel_color.c,
>>> so yeah I think that's correct.
>>>
>>>> If so, is a
>>>> uniform distribution of 128 points across most of the LUT
>>>> good enough for HDR with 128 entries?
>>>
>>> No idea how good this actually is. It is .24 so at least
>>> it does have a fair bit of precision.
>>>
>>
>> Precision is good but you also need enough samples. Though that's
>> probably less my concern and more your concern and should become
>> apparent once its used.
>
> Yeah, for pipe gamma we have a few different variants with
> non-uniform spacing of the samples. But not here AFAICS for
> whatever reason.
>
>>
>>>>
>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>> + .start = 0, .end = (1 << 24) - 1,
>>>>> + .min = 0, .max = (1 << 24) - 1,
>>>>> + },
>>>>> + /* segment 2 */
>>>>> + {
>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>> + .count = 1,
>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>>>
>>>> .start and .end are only a single entry apart. Is this correct?
>>>
>>> One think I wanted to do is simplify this stuff by getting rid of
>>> .end entirely. So I think this should just be '.start=1<<24' (or
>>> whatever way we decide to specify the input precision, which is
>>> I think another slightly open question).
>>>
>>> So for this thing we could just have:
>>> { .count = 128, .min = 0, .max = (1 << 24) - 1, .start = 0 },
>>> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 1 << 24 },
>>> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 3 << 24 },
>>> { .count = 1, .min = 0, .max = (7 << 24) - 1, .start = 7 << 24 },
>>>
>>> + flags/etc. which I left out for brevity.
>>>
>>
>> Makes sense. I like this.
>>
>>> So that is trying to indicate that the first 129 entries are equally
>>> spaced, and would be used to interpolate for input values [0.0,1.0).
>>> Input values [1.0,3.0) would interpolate between entry 128 and 129,
>>> and [3.0,7.0) would interpolate between entry 129 and 130.
>>>
>>
>> What in the segment definition defines the 1.0 mark? In your example
>> it seems to be at (1 << 24) but then we would have values that go
>> beyond the input_bpc for the last three segments.
>
> Yes, input_bpc would define the precision of the input values (.start).
> so 1.0 would be at 1<<input_bpc. Tne range of input values is allowed to
> extend outside the 0.0-1.0 range.
>
>>
>> How about output_bpc? Would output_bpc somehow limit the U32.32 (or
>> S31.32) entries, and if so, how?
>
> output_bpc would define the actual precision of the output values,
> so again 1.0 would be 1<<output_bpc, and .min and .max define the
> min/max values (which can extend outside the 0.0-1.0 range). The
> alternative I guess would be to not have .output_bpc at all and
> just have .min/.max be s32.32 values. Though then you can't tell
> what the actual precision is. Same could be done for .input_bpc
> I suppose.
>
>>
>> Or should we treat input_/output_bpc only as capability reporting, so
>> userspace can calculate the possible error when programming the LUT?
>> Again, this leaves us with the question what the input_/output_bpc
>> means for our PWL entries.
>
> Yeah, I mostly thought they might be interesting if userspace wants
> to know the exact precision. But not strictly necessary if you want
> just to go generate a "close enough" curve.
>
> What's PWL?
>
Got it, I think.
Piece-wise linear LUT, i.e. a (usually segmented) LUT that
linearly interpolates in between entries.
Harry
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-09-06 21:38 ` Uma Shankar
@ 2021-11-11 15:17 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-11 15:17 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, Shashank.Sharma
On 2021-09-06 17:38, Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> index afcb4bf3826c..6403bd74324b 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> }
> }
>
> + /* FIXME input bpc? */
> +__maybe_unused
> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> + /* segment 1 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 128,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 3 << 24, .end = 7 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> +};
If I understand this right, userspace would need this definition in order
to populate the degamma blob. Should this sit in a UAPI header?
Harry
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-11 15:17 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-11 15:17 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, ppaalanen
On 2021-09-06 17:38, Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> index afcb4bf3826c..6403bd74324b 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> }
> }
>
> + /* FIXME input bpc? */
> +__maybe_unused
> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> + /* segment 1 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 128,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> + DRM_MODE_LUT_INTERPOLATE |
> + DRM_MODE_LUT_REUSE_LAST |
> + DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 3 << 24, .end = 7 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> +};
If I understand this right, userspace would need this definition in order
to populate the degamma blob. Should this sit in a UAPI header?
Harry
> +
> void intel_color_init(struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-11 15:17 ` [Intel-gfx] " Harry Wentland
@ 2021-11-11 16:42 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-11 16:42 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Uma Shankar
On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> > index afcb4bf3826c..6403bd74324b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> > }
> > }
> >
> > + /* FIXME input bpc? */
> > +__maybe_unused
> > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 1 << 24, .end = 3 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 4 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 3 << 24, .end = 7 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > +};
>
> If I understand this right, userspace would need this definition in order
> to populate the degamma blob. Should this sit in a UAPI header?
My original idea (not sure it's fully realized in this series) is to
have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
which each enum value points to a kernel provided blob that contains
one of these LUT descriptors. Userspace can then query them dynamically
and pick the best one for its current use case.
The algorithm for choosing the best one might be something like:
- prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
- prefer interpolated vs. direct lookup based on current needs (eg. X
could prefer direct lookup to get directcolor visuals).
- prefer one with extended range values if needed
- for HDR prefer smaller step size in dark tones,
for SDR perhaps prefer a more uniform step size
Or maybe we should include some kind of usage hints as well?
And I was thinking of even adding a new property type (eg.
ENUM_BLOB) just for this sort of usecase. That could let us
have a bit more generic code to do all the validation around
the property values and whatnot.
The one nagging concern I really have with GAMMA_MODE is how a
mix of old and new userspace would work. Though that is more
of a generic issue with any new property really.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-11 16:42 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-11 16:42 UTC (permalink / raw)
To: Harry Wentland; +Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 52 ++++++++++++++++++++++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> > index afcb4bf3826c..6403bd74324b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
> > }
> > }
> >
> > + /* FIXME input bpc? */
> > +__maybe_unused
> > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 1 << 24, .end = 3 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 4 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 3 << 24, .end = 7 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > +};
>
> If I understand this right, userspace would need this definition in order
> to populate the degamma blob. Should this sit in a UAPI header?
My original idea (not sure it's fully realized in this series) is to
have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
which each enum value points to a kernel provided blob that contains
one of these LUT descriptors. Userspace can then query them dynamically
and pick the best one for its current use case.
The algorithm for choosing the best one might be something like:
- prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
- prefer interpolated vs. direct lookup based on current needs (eg. X
could prefer direct lookup to get directcolor visuals).
- prefer one with extended range values if needed
- for HDR prefer smaller step size in dark tones,
for SDR perhaps prefer a more uniform step size
Or maybe we should include some kind of usage hints as well?
And I was thinking of even adding a new property type (eg.
ENUM_BLOB) just for this sort of usecase. That could let us
have a bit more generic code to do all the validation around
the property values and whatnot.
The one nagging concern I really have with GAMMA_MODE is how a
mix of old and new userspace would work. Though that is more
of a generic issue with any new property really.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* RE: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-11 16:42 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-11 20:42 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-11-11 20:42 UTC (permalink / raw)
To: Ville Syrjälä, Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian
> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Sent: Thursday, November 11, 2021 10:13 PM
> To: Harry Wentland <harry.wentland@amd.com>
> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> HDR planes
>
> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >
> >
> > On 2021-09-06 17:38, Uma Shankar wrote:
> > > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > > planes have different capabilities, implemented respective structure
> > > for the HDR planes.
> > >
> > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_color.c | 52
> > > ++++++++++++++++++++++
> > > 1 file changed, 52 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index afcb4bf3826c..6403bd74324b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)
> > > }
> > > }
> > >
> > > + /* FIXME input bpc? */
> > > +__maybe_unused
> > > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > > + /* segment 1 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 128,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 0, .end = (1 << 24) - 1,
> > > + .min = 0, .max = (1 << 24) - 1,
> > > + },
> > > + /* segment 2 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = (1 << 24) - 1, .end = 1 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > + /* Segment 3 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 1 << 24, .end = 3 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > + /* Segment 4 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 3 << 24, .end = 7 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > +};
> >
> > If I understand this right, userspace would need this definition in
> > order to populate the degamma blob. Should this sit in a UAPI header?
Hi Harry, Pekka and Ville,
Sorry for being a bit late on the replies, got side tracked with various issues.
I am back on this. Apologies for delay.
> My original idea (not sure it's fully realized in this series) is to have a new
> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> value points to a kernel provided blob that contains one of these LUT descriptors.
> Userspace can then query them dynamically and pick the best one for its current use
> case.
We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
property just for this. With that userspace can just query the blob_id's and will get the
various degamma mode possible and the respective segment and lut distributions.
This will be generic, so for userspace it should just be able to query this and parse and get
the lut distribution and segment ranges.
> The algorithm for choosing the best one might be something like:
> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> - prefer interpolated vs. direct lookup based on current needs (eg. X
> could prefer direct lookup to get directcolor visuals).
> - prefer one with extended range values if needed
> - for HDR prefer smaller step size in dark tones,
> for SDR perhaps prefer a more uniform step size
>
> Or maybe we should include some kind of usage hints as well?
I think the segment range and distribution of lut should be enough for a userspace
to pick the right ones, but we can add some examples in UAPI descriptions as hints.
> And I was thinking of even adding a new property type (eg.
> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
> code to do all the validation around the property values and whatnot.
>
> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
> new userspace would work. Though that is more of a generic issue with any new
> property really.
For plane properties getting added newly, old userspace will not get it so I think this should be ok.
Newer userspace will implement this and get the new functionality.
Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
the idea remains same based on your design. Series below for reference:
https://patchwork.freedesktop.org/series/90821/
Regards,
Uma Shankar
> --
> Ville Syrjälä
> Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-11 20:42 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-11-11 20:42 UTC (permalink / raw)
To: Ville Syrjälä, Harry Wentland
Cc: intel-gfx, ppaalanen, dri-devel, sebastian
> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Sent: Thursday, November 11, 2021 10:13 PM
> To: Harry Wentland <harry.wentland@amd.com>
> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> HDR planes
>
> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >
> >
> > On 2021-09-06 17:38, Uma Shankar wrote:
> > > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > > planes have different capabilities, implemented respective structure
> > > for the HDR planes.
> > >
> > > Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_color.c | 52
> > > ++++++++++++++++++++++
> > > 1 file changed, 52 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > > b/drivers/gpu/drm/i915/display/intel_color.c
> > > index afcb4bf3826c..6403bd74324b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > > @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)
> > > }
> > > }
> > >
> > > + /* FIXME input bpc? */
> > > +__maybe_unused
> > > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > > + /* segment 1 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 128,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 0, .end = (1 << 24) - 1,
> > > + .min = 0, .max = (1 << 24) - 1,
> > > + },
> > > + /* segment 2 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = (1 << 24) - 1, .end = 1 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > + /* Segment 3 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 1 << 24, .end = 3 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > + /* Segment 4 */
> > > + {
> > > + .flags = (DRM_MODE_LUT_GAMMA |
> > > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > > + DRM_MODE_LUT_INTERPOLATE |
> > > + DRM_MODE_LUT_REUSE_LAST |
> > > + DRM_MODE_LUT_NON_DECREASING),
> > > + .count = 1,
> > > + .input_bpc = 24, .output_bpc = 16,
> > > + .start = 3 << 24, .end = 7 << 24,
> > > + .min = 0, .max = (1 << 27) - 1,
> > > + },
> > > +};
> >
> > If I understand this right, userspace would need this definition in
> > order to populate the degamma blob. Should this sit in a UAPI header?
Hi Harry, Pekka and Ville,
Sorry for being a bit late on the replies, got side tracked with various issues.
I am back on this. Apologies for delay.
> My original idea (not sure it's fully realized in this series) is to have a new
> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> value points to a kernel provided blob that contains one of these LUT descriptors.
> Userspace can then query them dynamically and pick the best one for its current use
> case.
We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
property just for this. With that userspace can just query the blob_id's and will get the
various degamma mode possible and the respective segment and lut distributions.
This will be generic, so for userspace it should just be able to query this and parse and get
the lut distribution and segment ranges.
> The algorithm for choosing the best one might be something like:
> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> - prefer interpolated vs. direct lookup based on current needs (eg. X
> could prefer direct lookup to get directcolor visuals).
> - prefer one with extended range values if needed
> - for HDR prefer smaller step size in dark tones,
> for SDR perhaps prefer a more uniform step size
>
> Or maybe we should include some kind of usage hints as well?
I think the segment range and distribution of lut should be enough for a userspace
to pick the right ones, but we can add some examples in UAPI descriptions as hints.
> And I was thinking of even adding a new property type (eg.
> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
> code to do all the validation around the property values and whatnot.
>
> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
> new userspace would work. Though that is more of a generic issue with any new
> property really.
For plane properties getting added newly, old userspace will not get it so I think this should be ok.
Newer userspace will implement this and get the new functionality.
Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
the idea remains same based on your design. Series below for reference:
https://patchwork.freedesktop.org/series/90821/
Regards,
Uma Shankar
> --
> Ville Syrjälä
> Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-11 20:42 ` [Intel-gfx] " Shankar, Uma
@ 2021-11-11 21:10 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-11 21:10 UTC (permalink / raw)
To: Shankar, Uma, Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian
On 2021-11-11 15:42, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Sent: Thursday, November 11, 2021 10:13 PM
>> To: Harry Wentland <harry.wentland@amd.com>
>> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
>> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
>> HDR planes
>>
>> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>>> planes have different capabilities, implemented respective structure
>>>> for the HDR planes.
>>>>
>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>> ---
>>>> drivers/gpu/drm/i915/display/intel_color.c | 52
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 52 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
>>>> b/drivers/gpu/drm/i915/display/intel_color.c
>>>> index afcb4bf3826c..6403bd74324b 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
>> *crtc_state)
>>>> }
>>>> }
>>>>
>>>> + /* FIXME input bpc? */
>>>> +__maybe_unused
>>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>>> + /* segment 1 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 128,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = 0, .end = (1 << 24) - 1,
>>>> + .min = 0, .max = (1 << 24) - 1,
>>>> + },
>>>> + /* segment 2 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 1,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>>> + .min = 0, .max = (1 << 27) - 1,
>>>> + },
>>>> + /* Segment 3 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 1,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = 1 << 24, .end = 3 << 24,
>>>> + .min = 0, .max = (1 << 27) - 1,
>>>> + },
>>>> + /* Segment 4 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 1,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = 3 << 24, .end = 7 << 24,
>>>> + .min = 0, .max = (1 << 27) - 1,
>>>> + },
>>>> +};
>>>
>>> If I understand this right, userspace would need this definition in
>>> order to populate the degamma blob. Should this sit in a UAPI header?
>
> Hi Harry, Pekka and Ville,
> Sorry for being a bit late on the replies, got side tracked with various issues.
> I am back on this. Apologies for delay.
>
>> My original idea (not sure it's fully realized in this series) is to have a new
>> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
>> value points to a kernel provided blob that contains one of these LUT descriptors.
>> Userspace can then query them dynamically and pick the best one for its current use
>> case.
>
> We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
> property just for this. With that userspace can just query the blob_id's and will get the
> various degamma mode possible and the respective segment and lut distributions.
>
> This will be generic, so for userspace it should just be able to query this and parse and get
> the lut distribution and segment ranges.
>
Thanks for the explanation.
Uma, have you had a chance to sketch some of this out in IGT? I'm trying
to see how userspace would do this in practice and will try to sketch an
IGT test for this myself, but if you have it already we could share the
effort.
>> The algorithm for choosing the best one might be something like:
>> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
>> - prefer interpolated vs. direct lookup based on current needs (eg. X
>> could prefer direct lookup to get directcolor visuals).
>> - prefer one with extended range values if needed
>> - for HDR prefer smaller step size in dark tones,
>> for SDR perhaps prefer a more uniform step size
>>
>> Or maybe we should include some kind of usage hints as well?
>
> I think the segment range and distribution of lut should be enough for a userspace
> to pick the right ones, but we can add some examples in UAPI descriptions as hints.
>
The range might be enough, but we're already parsing hints like "GAMMA"
or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or
"SDR" as well.
>> And I was thinking of even adding a new property type (eg.
>> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
>> code to do all the validation around the property values and whatnot.
>>
>> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
>> new userspace would work. Though that is more of a generic issue with any new
>> property really.
>
> For plane properties getting added newly, old userspace will not get it so I think this should be ok.
> Newer userspace will implement this and get the new functionality.
> Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
> may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
> the idea remains same based on your design. Series below for reference:
> https://patchwork.freedesktop.org/series/90821/>>
Could we just assume we do a uniform LUT if userspace doesn't
set a _MODE enum value for the respective gamma?
Maybe the _MODE should have a default enum value that means
a uniform (legacy) LUT.
Harry
> Regards,
> Uma Shankar
>
>> --
>> Ville Syrjälä
>> Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-11 21:10 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-11 21:10 UTC (permalink / raw)
To: Shankar, Uma, Ville Syrjälä
Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On 2021-11-11 15:42, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Sent: Thursday, November 11, 2021 10:13 PM
>> To: Harry Wentland <harry.wentland@amd.com>
>> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
>> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
>> HDR planes
>>
>> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>>> planes have different capabilities, implemented respective structure
>>>> for the HDR planes.
>>>>
>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>> ---
>>>> drivers/gpu/drm/i915/display/intel_color.c | 52
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 52 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
>>>> b/drivers/gpu/drm/i915/display/intel_color.c
>>>> index afcb4bf3826c..6403bd74324b 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
>> *crtc_state)
>>>> }
>>>> }
>>>>
>>>> + /* FIXME input bpc? */
>>>> +__maybe_unused
>>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>>> + /* segment 1 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 128,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = 0, .end = (1 << 24) - 1,
>>>> + .min = 0, .max = (1 << 24) - 1,
>>>> + },
>>>> + /* segment 2 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 1,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>>> + .min = 0, .max = (1 << 27) - 1,
>>>> + },
>>>> + /* Segment 3 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 1,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = 1 << 24, .end = 3 << 24,
>>>> + .min = 0, .max = (1 << 27) - 1,
>>>> + },
>>>> + /* Segment 4 */
>>>> + {
>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>> + .count = 1,
>>>> + .input_bpc = 24, .output_bpc = 16,
>>>> + .start = 3 << 24, .end = 7 << 24,
>>>> + .min = 0, .max = (1 << 27) - 1,
>>>> + },
>>>> +};
>>>
>>> If I understand this right, userspace would need this definition in
>>> order to populate the degamma blob. Should this sit in a UAPI header?
>
> Hi Harry, Pekka and Ville,
> Sorry for being a bit late on the replies, got side tracked with various issues.
> I am back on this. Apologies for delay.
>
>> My original idea (not sure it's fully realized in this series) is to have a new
>> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
>> value points to a kernel provided blob that contains one of these LUT descriptors.
>> Userspace can then query them dynamically and pick the best one for its current use
>> case.
>
> We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
> property just for this. With that userspace can just query the blob_id's and will get the
> various degamma mode possible and the respective segment and lut distributions.
>
> This will be generic, so for userspace it should just be able to query this and parse and get
> the lut distribution and segment ranges.
>
Thanks for the explanation.
Uma, have you had a chance to sketch some of this out in IGT? I'm trying
to see how userspace would do this in practice and will try to sketch an
IGT test for this myself, but if you have it already we could share the
effort.
>> The algorithm for choosing the best one might be something like:
>> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
>> - prefer interpolated vs. direct lookup based on current needs (eg. X
>> could prefer direct lookup to get directcolor visuals).
>> - prefer one with extended range values if needed
>> - for HDR prefer smaller step size in dark tones,
>> for SDR perhaps prefer a more uniform step size
>>
>> Or maybe we should include some kind of usage hints as well?
>
> I think the segment range and distribution of lut should be enough for a userspace
> to pick the right ones, but we can add some examples in UAPI descriptions as hints.
>
The range might be enough, but we're already parsing hints like "GAMMA"
or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or
"SDR" as well.
>> And I was thinking of even adding a new property type (eg.
>> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
>> code to do all the validation around the property values and whatnot.
>>
>> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
>> new userspace would work. Though that is more of a generic issue with any new
>> property really.
>
> For plane properties getting added newly, old userspace will not get it so I think this should be ok.
> Newer userspace will implement this and get the new functionality.
> Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
> may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
> the idea remains same based on your design. Series below for reference:
> https://patchwork.freedesktop.org/series/90821/>>
Could we just assume we do a uniform LUT if userspace doesn't
set a _MODE enum value for the respective gamma?
Maybe the _MODE should have a default enum value that means
a uniform (legacy) LUT.
Harry
> Regards,
> Uma Shankar
>
>> --
>> Ville Syrjälä
>> Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* RE: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-11 21:10 ` [Intel-gfx] " Harry Wentland
@ 2021-11-11 21:58 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-11-11 21:58 UTC (permalink / raw)
To: Harry Wentland, Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian
> -----Original Message-----
> From: Harry Wentland <harry.wentland@amd.com>
> Sent: Friday, November 12, 2021 2:41 AM
> To: Shankar, Uma <uma.shankar@intel.com>; Ville Syrjälä
> <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net;
> Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> HDR planes
>
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland <harry.wentland@amd.com>
> >> Cc: Shankar, Uma <uma.shankar@intel.com>;
> >> intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
> >> ppaalanen@gmail.com; brian.starkey@arm.com;
> >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
> >> struct for HDR planes
> >>
> >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >>>
> >>>
> >>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>>> planes have different capabilities, implemented respective
> >>>> structure for the HDR planes.
> >>>>
> >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>> ---
> >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> >>>> ++++++++++++++++++++++
> >>>> 1 file changed, 52 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> index afcb4bf3826c..6403bd74324b 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
> >>>> intel_crtc_state
> >> *crtc_state)
> >>>> }
> >>>> }
> >>>>
> >>>> + /* FIXME input bpc? */
> >>>> +__maybe_unused
> >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>>> + /* segment 1 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 128,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 0, .end = (1 << 24) - 1,
> >>>> + .min = 0, .max = (1 << 24) - 1,
> >>>> + },
> >>>> + /* segment 2 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 3 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 1 << 24, .end = 3 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 4 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 3 << 24, .end = 7 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> +};
> >>>
> >>> If I understand this right, userspace would need this definition in
> >>> order to populate the degamma blob. Should this sit in a UAPI header?
> >
> > Hi Harry, Pekka and Ville,
> > Sorry for being a bit late on the replies, got side tracked with various issues.
> > I am back on this. Apologies for delay.
> >
> >> My original idea (not sure it's fully realized in this series) is to
> >> have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
> >> which each enum value points to a kernel provided blob that contains one of
> these LUT descriptors.
> >> Userspace can then query them dynamically and pick the best one for
> >> its current use case.
> >
> > We have this as part of the series Ville. Patch 3 of this series
> > creates a DEGAMMA_MODE property just for this. With that userspace can
> > just query the blob_id's and will get the various degamma mode possible and the
> respective segment and lut distributions.
> >
> > This will be generic, so for userspace it should just be able to query
> > this and parse and get the lut distribution and segment ranges.
> >
>
> Thanks for the explanation.
>
> Uma, have you had a chance to sketch some of this out in IGT? I'm trying to see how
> userspace would do this in practice and will try to sketch an IGT test for this myself,
> but if you have it already we could share the effort.
Yes Harry, we do have some sample IGT's to test this. Will send those out and will copy
you and all the stakeholders.
> >> The algorithm for choosing the best one might be something like:
> >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> >> could prefer direct lookup to get directcolor visuals).
> >> - prefer one with extended range values if needed
> >> - for HDR prefer smaller step size in dark tones,
> >> for SDR perhaps prefer a more uniform step size
> >>
> >> Or maybe we should include some kind of usage hints as well?
> >
> > I think the segment range and distribution of lut should be enough for
> > a userspace to pick the right ones, but we can add some examples in UAPI
> descriptions as hints.
> >
>
> The range might be enough, but we're already parsing hints like "GAMMA"
> or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or "SDR" as
> well.
On Intel hardware, we differentiate this with precision and have HDR planes (they have extra
Lut precision and samples) separately called out. We could add SDR/HDR FLAG as well.
> >> And I was thinking of even adding a new property type (eg.
> >> ENUM_BLOB) just for this sort of usecase. That could let us have a
> >> bit more generic code to do all the validation around the property values and
> whatnot.
> >>
> >> The one nagging concern I really have with GAMMA_MODE is how a mix of
> >> old and new userspace would work. Though that is more of a generic
> >> issue with any new property really.
> >
> > For plane properties getting added newly, old userspace will not get it so I think
> this should be ok.
> > Newer userspace will implement this and get the new functionality.
> > Problem will be in extending this to crtc where we have a legacy
> > baggage, the client caps approach may help us there. Have it as part
> > of separate series just to not mix it with this new plane stuff, though the idea
> remains same based on your design. Series below for reference:
> > https://patchwork.freedesktop.org/series/90821/>>
>
> Could we just assume we do a uniform LUT if userspace doesn't set a _MODE enum
> value for the respective gamma?
>
> Maybe the _MODE should have a default enum value that means a uniform (legacy)
> LUT.
Yeah we could have this and document the behavior in UAPI description.
Regards,
Uma Shankar
> Harry
>
> > Regards,
> > Uma Shankar
> >
> >> --
> >> Ville Syrjälä
> >> Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-11 21:58 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-11-11 21:58 UTC (permalink / raw)
To: Harry Wentland, Ville Syrjälä
Cc: intel-gfx, ppaalanen, dri-devel, sebastian
> -----Original Message-----
> From: Harry Wentland <harry.wentland@amd.com>
> Sent: Friday, November 12, 2021 2:41 AM
> To: Shankar, Uma <uma.shankar@intel.com>; Ville Syrjälä
> <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net;
> Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> HDR planes
>
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland <harry.wentland@amd.com>
> >> Cc: Shankar, Uma <uma.shankar@intel.com>;
> >> intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
> >> ppaalanen@gmail.com; brian.starkey@arm.com;
> >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
> >> struct for HDR planes
> >>
> >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >>>
> >>>
> >>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>>> planes have different capabilities, implemented respective
> >>>> structure for the HDR planes.
> >>>>
> >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>> ---
> >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> >>>> ++++++++++++++++++++++
> >>>> 1 file changed, 52 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> index afcb4bf3826c..6403bd74324b 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
> >>>> intel_crtc_state
> >> *crtc_state)
> >>>> }
> >>>> }
> >>>>
> >>>> + /* FIXME input bpc? */
> >>>> +__maybe_unused
> >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>>> + /* segment 1 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 128,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 0, .end = (1 << 24) - 1,
> >>>> + .min = 0, .max = (1 << 24) - 1,
> >>>> + },
> >>>> + /* segment 2 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 3 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 1 << 24, .end = 3 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 4 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 3 << 24, .end = 7 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> +};
> >>>
> >>> If I understand this right, userspace would need this definition in
> >>> order to populate the degamma blob. Should this sit in a UAPI header?
> >
> > Hi Harry, Pekka and Ville,
> > Sorry for being a bit late on the replies, got side tracked with various issues.
> > I am back on this. Apologies for delay.
> >
> >> My original idea (not sure it's fully realized in this series) is to
> >> have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
> >> which each enum value points to a kernel provided blob that contains one of
> these LUT descriptors.
> >> Userspace can then query them dynamically and pick the best one for
> >> its current use case.
> >
> > We have this as part of the series Ville. Patch 3 of this series
> > creates a DEGAMMA_MODE property just for this. With that userspace can
> > just query the blob_id's and will get the various degamma mode possible and the
> respective segment and lut distributions.
> >
> > This will be generic, so for userspace it should just be able to query
> > this and parse and get the lut distribution and segment ranges.
> >
>
> Thanks for the explanation.
>
> Uma, have you had a chance to sketch some of this out in IGT? I'm trying to see how
> userspace would do this in practice and will try to sketch an IGT test for this myself,
> but if you have it already we could share the effort.
Yes Harry, we do have some sample IGT's to test this. Will send those out and will copy
you and all the stakeholders.
> >> The algorithm for choosing the best one might be something like:
> >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> >> could prefer direct lookup to get directcolor visuals).
> >> - prefer one with extended range values if needed
> >> - for HDR prefer smaller step size in dark tones,
> >> for SDR perhaps prefer a more uniform step size
> >>
> >> Or maybe we should include some kind of usage hints as well?
> >
> > I think the segment range and distribution of lut should be enough for
> > a userspace to pick the right ones, but we can add some examples in UAPI
> descriptions as hints.
> >
>
> The range might be enough, but we're already parsing hints like "GAMMA"
> or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or "SDR" as
> well.
On Intel hardware, we differentiate this with precision and have HDR planes (they have extra
Lut precision and samples) separately called out. We could add SDR/HDR FLAG as well.
> >> And I was thinking of even adding a new property type (eg.
> >> ENUM_BLOB) just for this sort of usecase. That could let us have a
> >> bit more generic code to do all the validation around the property values and
> whatnot.
> >>
> >> The one nagging concern I really have with GAMMA_MODE is how a mix of
> >> old and new userspace would work. Though that is more of a generic
> >> issue with any new property really.
> >
> > For plane properties getting added newly, old userspace will not get it so I think
> this should be ok.
> > Newer userspace will implement this and get the new functionality.
> > Problem will be in extending this to crtc where we have a legacy
> > baggage, the client caps approach may help us there. Have it as part
> > of separate series just to not mix it with this new plane stuff, though the idea
> remains same based on your design. Series below for reference:
> > https://patchwork.freedesktop.org/series/90821/>>
>
> Could we just assume we do a uniform LUT if userspace doesn't set a _MODE enum
> value for the respective gamma?
>
> Maybe the _MODE should have a default enum value that means a uniform (legacy)
> LUT.
Yeah we could have this and document the behavior in UAPI description.
Regards,
Uma Shankar
> Harry
>
> > Regards,
> > Uma Shankar
> >
> >> --
> >> Ville Syrjälä
> >> Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-11 21:58 ` [Intel-gfx] " Shankar, Uma
@ 2021-11-12 8:37 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-12 8:37 UTC (permalink / raw)
To: Shankar, Uma, Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian
[-- Attachment #1: Type: text/plain, Size: 7484 bytes --]
On Thu, 11 Nov 2021 21:58:35 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Harry Wentland <harry.wentland@amd.com>
> > Sent: Friday, November 12, 2021 2:41 AM
> > To: Shankar, Uma <uma.shankar@intel.com>; Ville Syrjälä
> > <ville.syrjala@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net;
> > Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> > HDR planes
> >
> >
> >
> > On 2021-11-11 15:42, Shankar, Uma wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> Sent: Thursday, November 11, 2021 10:13 PM
> > >> To: Harry Wentland <harry.wentland@amd.com>
> > >> Cc: Shankar, Uma <uma.shankar@intel.com>;
> > >> intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
> > >> ppaalanen@gmail.com; brian.starkey@arm.com;
> > >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
> > >> struct for HDR planes
> > >>
> > >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> > >>>
> > >>>
> > >>> On 2021-09-06 17:38, Uma Shankar wrote:
> > >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > >>>> planes have different capabilities, implemented respective
> > >>>> structure for the HDR planes.
> > >>>>
> > >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > >>>> ---
> > >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> > >>>> ++++++++++++++++++++++
> > >>>> 1 file changed, 52 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> index afcb4bf3826c..6403bd74324b 100644
> > >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
> > >>>> intel_crtc_state
> > >> *crtc_state)
> > >>>> }
> > >>>> }
> > >>>>
> > >>>> + /* FIXME input bpc? */
> > >>>> +__maybe_unused
> > >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > >>>> + /* segment 1 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 128,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 0, .end = (1 << 24) - 1,
> > >>>> + .min = 0, .max = (1 << 24) - 1,
> > >>>> + },
> > >>>> + /* segment 2 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 3 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 1 << 24, .end = 3 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 4 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 3 << 24, .end = 7 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> +};
> > >>>
> > >>> If I understand this right, userspace would need this definition in
> > >>> order to populate the degamma blob. Should this sit in a UAPI header?
Are you asking whether 'struct drm_color_lut_range` is defined in any
userspace visible header?
It seems to be in patch 2.
> > >
> > > Hi Harry, Pekka and Ville,
> > > Sorry for being a bit late on the replies, got side tracked with various issues.
> > > I am back on this. Apologies for delay.
> > >
> > >> My original idea (not sure it's fully realized in this series) is to
> > >> have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
> > >> which each enum value points to a kernel provided blob that contains one of
> > these LUT descriptors.
> > >> Userspace can then query them dynamically and pick the best one for
> > >> its current use case.
> > >
> > > We have this as part of the series Ville. Patch 3 of this series
> > > creates a DEGAMMA_MODE property just for this. With that userspace can
> > > just query the blob_id's and will get the various degamma mode possible and the
> > respective segment and lut distributions.
> > >
> > > This will be generic, so for userspace it should just be able to query
> > > this and parse and get the lut distribution and segment ranges.
> > >
> >
> > Thanks for the explanation.
> >
> > Uma, have you had a chance to sketch some of this out in IGT? I'm trying to see how
> > userspace would do this in practice and will try to sketch an IGT test for this myself,
> > but if you have it already we could share the effort.
>
> Yes Harry, we do have some sample IGT's to test this. Will send those out and will copy
> you and all the stakeholders.
>
> > >> The algorithm for choosing the best one might be something like:
> > >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> > >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> > >> could prefer direct lookup to get directcolor visuals).
> > >> - prefer one with extended range values if needed
> > >> - for HDR prefer smaller step size in dark tones,
> > >> for SDR perhaps prefer a more uniform step size
> > >>
> > >> Or maybe we should include some kind of usage hints as well?
> > >
> > > I think the segment range and distribution of lut should be enough for
> > > a userspace to pick the right ones, but we can add some examples in UAPI
> > descriptions as hints.
> > >
> >
> > The range might be enough, but we're already parsing hints like "GAMMA"
> > or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or "SDR" as
> > well.
What hints are GAMMA or DEGAMMA and who's parsing them? I thought they
are just arbitrary names to identify the element's position in the
abstract pipeline.
>
> On Intel hardware, we differentiate this with precision and have HDR planes (they have extra
> Lut precision and samples) separately called out. We could add SDR/HDR FLAG as well.
What about wide color gamut SDR? That probably needs more precision
than "normal" SDR but is not HDR.
I can't think of how SDR/HDR flags would work or what they would mean.
Feels a bit too simple for practice. Maybe that concept should be
created by a hypothetical userspace helper library instead.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-12 8:37 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-12 8:37 UTC (permalink / raw)
To: Shankar, Uma, Harry Wentland; +Cc: intel-gfx, dri-devel, sebastian
[-- Attachment #1: Type: text/plain, Size: 7484 bytes --]
On Thu, 11 Nov 2021 21:58:35 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Harry Wentland <harry.wentland@amd.com>
> > Sent: Friday, November 12, 2021 2:41 AM
> > To: Shankar, Uma <uma.shankar@intel.com>; Ville Syrjälä
> > <ville.syrjala@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net;
> > Shashank.Sharma@amd.com
> > Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> > HDR planes
> >
> >
> >
> > On 2021-11-11 15:42, Shankar, Uma wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> Sent: Thursday, November 11, 2021 10:13 PM
> > >> To: Harry Wentland <harry.wentland@amd.com>
> > >> Cc: Shankar, Uma <uma.shankar@intel.com>;
> > >> intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
> > >> ppaalanen@gmail.com; brian.starkey@arm.com;
> > >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
> > >> struct for HDR planes
> > >>
> > >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> > >>>
> > >>>
> > >>> On 2021-09-06 17:38, Uma Shankar wrote:
> > >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > >>>> planes have different capabilities, implemented respective
> > >>>> structure for the HDR planes.
> > >>>>
> > >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > >>>> ---
> > >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> > >>>> ++++++++++++++++++++++
> > >>>> 1 file changed, 52 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> index afcb4bf3826c..6403bd74324b 100644
> > >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
> > >>>> intel_crtc_state
> > >> *crtc_state)
> > >>>> }
> > >>>> }
> > >>>>
> > >>>> + /* FIXME input bpc? */
> > >>>> +__maybe_unused
> > >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > >>>> + /* segment 1 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 128,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 0, .end = (1 << 24) - 1,
> > >>>> + .min = 0, .max = (1 << 24) - 1,
> > >>>> + },
> > >>>> + /* segment 2 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 3 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 1 << 24, .end = 3 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 4 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 3 << 24, .end = 7 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> +};
> > >>>
> > >>> If I understand this right, userspace would need this definition in
> > >>> order to populate the degamma blob. Should this sit in a UAPI header?
Are you asking whether 'struct drm_color_lut_range` is defined in any
userspace visible header?
It seems to be in patch 2.
> > >
> > > Hi Harry, Pekka and Ville,
> > > Sorry for being a bit late on the replies, got side tracked with various issues.
> > > I am back on this. Apologies for delay.
> > >
> > >> My original idea (not sure it's fully realized in this series) is to
> > >> have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
> > >> which each enum value points to a kernel provided blob that contains one of
> > these LUT descriptors.
> > >> Userspace can then query them dynamically and pick the best one for
> > >> its current use case.
> > >
> > > We have this as part of the series Ville. Patch 3 of this series
> > > creates a DEGAMMA_MODE property just for this. With that userspace can
> > > just query the blob_id's and will get the various degamma mode possible and the
> > respective segment and lut distributions.
> > >
> > > This will be generic, so for userspace it should just be able to query
> > > this and parse and get the lut distribution and segment ranges.
> > >
> >
> > Thanks for the explanation.
> >
> > Uma, have you had a chance to sketch some of this out in IGT? I'm trying to see how
> > userspace would do this in practice and will try to sketch an IGT test for this myself,
> > but if you have it already we could share the effort.
>
> Yes Harry, we do have some sample IGT's to test this. Will send those out and will copy
> you and all the stakeholders.
>
> > >> The algorithm for choosing the best one might be something like:
> > >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> > >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> > >> could prefer direct lookup to get directcolor visuals).
> > >> - prefer one with extended range values if needed
> > >> - for HDR prefer smaller step size in dark tones,
> > >> for SDR perhaps prefer a more uniform step size
> > >>
> > >> Or maybe we should include some kind of usage hints as well?
> > >
> > > I think the segment range and distribution of lut should be enough for
> > > a userspace to pick the right ones, but we can add some examples in UAPI
> > descriptions as hints.
> > >
> >
> > The range might be enough, but we're already parsing hints like "GAMMA"
> > or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or "SDR" as
> > well.
What hints are GAMMA or DEGAMMA and who's parsing them? I thought they
are just arbitrary names to identify the element's position in the
abstract pipeline.
>
> On Intel hardware, we differentiate this with precision and have HDR planes (they have extra
> Lut precision and samples) separately called out. We could add SDR/HDR FLAG as well.
What about wide color gamut SDR? That probably needs more precision
than "normal" SDR but is not HDR.
I can't think of how SDR/HDR flags would work or what they would mean.
Feels a bit too simple for practice. Maybe that concept should be
created by a hypothetical userspace helper library instead.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-12 8:37 ` [Intel-gfx] " Pekka Paalanen
@ 2021-11-23 14:40 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-23 14:40 UTC (permalink / raw)
To: Pekka Paalanen, Shankar, Uma
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian
On 2021-11-12 03:37, Pekka Paalanen wrote:
> On Thu, 11 Nov 2021 21:58:35 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
>>> -----Original Message-----
>>> From: Harry Wentland <harry.wentland@amd.com>
>>> Sent: Friday, November 12, 2021 2:41 AM
>>> To: Shankar, Uma <uma.shankar@intel.com>; Ville Syrjälä
>>> <ville.syrjala@linux.intel.com>
>>> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>>> ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net;
>>> Shashank.Sharma@amd.com
>>> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
>>> HDR planes
>>>
>>>
>>>
>>> On 2021-11-11 15:42, Shankar, Uma wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> Sent: Thursday, November 11, 2021 10:13 PM
>>>>> To: Harry Wentland <harry.wentland@amd.com>
>>>>> Cc: Shankar, Uma <uma.shankar@intel.com>;
>>>>> intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
>>>>> ppaalanen@gmail.com; brian.starkey@arm.com;
>>>>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>>>>> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
>>>>> struct for HDR planes
>>>>>
>>>>> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>>>>>>
>>>>>>
>>>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>>>>>> planes have different capabilities, implemented respective
>>>>>>> structure for the HDR planes.
>>>>>>>
>>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/i915/display/intel_color.c | 52
>>>>>>> ++++++++++++++++++++++
>>>>>>> 1 file changed, 52 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> b/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> index afcb4bf3826c..6403bd74324b 100644
>>>>>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
>>>>>>> intel_crtc_state
>>>>> *crtc_state)
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> + /* FIXME input bpc? */
>>>>>>> +__maybe_unused
>>>>>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>>>>>> + /* segment 1 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 128,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = 0, .end = (1 << 24) - 1,
>>>>>>> + .min = 0, .max = (1 << 24) - 1,
>>>>>>> + },
>>>>>>> + /* segment 2 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 1,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>>>>>> + .min = 0, .max = (1 << 27) - 1,
>>>>>>> + },
>>>>>>> + /* Segment 3 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 1,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = 1 << 24, .end = 3 << 24,
>>>>>>> + .min = 0, .max = (1 << 27) - 1,
>>>>>>> + },
>>>>>>> + /* Segment 4 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 1,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = 3 << 24, .end = 7 << 24,
>>>>>>> + .min = 0, .max = (1 << 27) - 1,
>>>>>>> + },
>>>>>>> +};
>>>>>>
>>>>>> If I understand this right, userspace would need this definition in
>>>>>> order to populate the degamma blob. Should this sit in a UAPI header?
>
> Are you asking whether 'struct drm_color_lut_range` is defined in any
> userspace visible header?
>
> It seems to be in patch 2.
>
>>>>
>>>> Hi Harry, Pekka and Ville,
>>>> Sorry for being a bit late on the replies, got side tracked with various issues.
>>>> I am back on this. Apologies for delay.
>>>>
>>>>> My original idea (not sure it's fully realized in this series) is to
>>>>> have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
>>>>> which each enum value points to a kernel provided blob that contains one of
>>> these LUT descriptors.
>>>>> Userspace can then query them dynamically and pick the best one for
>>>>> its current use case.
>>>>
>>>> We have this as part of the series Ville. Patch 3 of this series
>>>> creates a DEGAMMA_MODE property just for this. With that userspace can
>>>> just query the blob_id's and will get the various degamma mode possible and the
>>> respective segment and lut distributions.
>>>>
>>>> This will be generic, so for userspace it should just be able to query
>>>> this and parse and get the lut distribution and segment ranges.
>>>>
>>>
>>> Thanks for the explanation.
>>>
>>> Uma, have you had a chance to sketch some of this out in IGT? I'm trying to see how
>>> userspace would do this in practice and will try to sketch an IGT test for this myself,
>>> but if you have it already we could share the effort.
>>
>> Yes Harry, we do have some sample IGT's to test this. Will send those out and will copy
>> you and all the stakeholders.
>>
Thanks. The set is on my list of items to review.
>>>>> The algorithm for choosing the best one might be something like:
>>>>> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
>>>>> - prefer interpolated vs. direct lookup based on current needs (eg. X
>>>>> could prefer direct lookup to get directcolor visuals).
>>>>> - prefer one with extended range values if needed
>>>>> - for HDR prefer smaller step size in dark tones,
>>>>> for SDR perhaps prefer a more uniform step size
>>>>>
>>>>> Or maybe we should include some kind of usage hints as well?
>>>>
>>>> I think the segment range and distribution of lut should be enough for
>>>> a userspace to pick the right ones, but we can add some examples in UAPI
>>> descriptions as hints.
>>>>
>>>
>>> The range might be enough, but we're already parsing hints like "GAMMA"
>>> or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or "SDR" as
>>> well.
>
> What hints are GAMMA or DEGAMMA and who's parsing them? I thought they
> are just arbitrary names to identify the element's position in the
> abstract pipeline.
>
They are provided with the segment definitions, e.g. in
https://patchwork.freedesktop.org/patch/452589/?series=90826&rev=2
I believe they are indicating whether a segment definition is
intended for degamma (linearization) use or for gamma (delinearization)
use.
>>
>> On Intel hardware, we differentiate this with precision and have HDR planes (they have extra
>> Lut precision and samples) separately called out. We could add SDR/HDR FLAG as well.
>
> What about wide color gamut SDR? That probably needs more precision
> than "normal" SDR but is not HDR.
>
> I can't think of how SDR/HDR flags would work or what they would mean.
> Feels a bit too simple for practice. Maybe that concept should be
> created by a hypothetical userspace helper library instead.
>
Maybe this is a decision best left up to compositors. A compositor
will know best what precision and range it needs.
Harry
>
> Thanks,
> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-23 14:40 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-11-23 14:40 UTC (permalink / raw)
To: Pekka Paalanen, Shankar, Uma; +Cc: intel-gfx, dri-devel, sebastian
On 2021-11-12 03:37, Pekka Paalanen wrote:
> On Thu, 11 Nov 2021 21:58:35 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
>>> -----Original Message-----
>>> From: Harry Wentland <harry.wentland@amd.com>
>>> Sent: Friday, November 12, 2021 2:41 AM
>>> To: Shankar, Uma <uma.shankar@intel.com>; Ville Syrjälä
>>> <ville.syrjala@linux.intel.com>
>>> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>>> ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net;
>>> Shashank.Sharma@amd.com
>>> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
>>> HDR planes
>>>
>>>
>>>
>>> On 2021-11-11 15:42, Shankar, Uma wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> Sent: Thursday, November 11, 2021 10:13 PM
>>>>> To: Harry Wentland <harry.wentland@amd.com>
>>>>> Cc: Shankar, Uma <uma.shankar@intel.com>;
>>>>> intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org;
>>>>> ppaalanen@gmail.com; brian.starkey@arm.com;
>>>>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>>>>> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range
>>>>> struct for HDR planes
>>>>>
>>>>> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>>>>>>
>>>>>>
>>>>>> On 2021-09-06 17:38, Uma Shankar wrote:
>>>>>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
>>>>>>> planes have different capabilities, implemented respective
>>>>>>> structure for the HDR planes.
>>>>>>>
>>>>>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/i915/display/intel_color.c | 52
>>>>>>> ++++++++++++++++++++++
>>>>>>> 1 file changed, 52 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> b/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> index afcb4bf3826c..6403bd74324b 100644
>>>>>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>>>>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct
>>>>>>> intel_crtc_state
>>>>> *crtc_state)
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> + /* FIXME input bpc? */
>>>>>>> +__maybe_unused
>>>>>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
>>>>>>> + /* segment 1 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 128,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = 0, .end = (1 << 24) - 1,
>>>>>>> + .min = 0, .max = (1 << 24) - 1,
>>>>>>> + },
>>>>>>> + /* segment 2 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 1,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = (1 << 24) - 1, .end = 1 << 24,
>>>>>>> + .min = 0, .max = (1 << 27) - 1,
>>>>>>> + },
>>>>>>> + /* Segment 3 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 1,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = 1 << 24, .end = 3 << 24,
>>>>>>> + .min = 0, .max = (1 << 27) - 1,
>>>>>>> + },
>>>>>>> + /* Segment 4 */
>>>>>>> + {
>>>>>>> + .flags = (DRM_MODE_LUT_GAMMA |
>>>>>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
>>>>>>> + DRM_MODE_LUT_INTERPOLATE |
>>>>>>> + DRM_MODE_LUT_REUSE_LAST |
>>>>>>> + DRM_MODE_LUT_NON_DECREASING),
>>>>>>> + .count = 1,
>>>>>>> + .input_bpc = 24, .output_bpc = 16,
>>>>>>> + .start = 3 << 24, .end = 7 << 24,
>>>>>>> + .min = 0, .max = (1 << 27) - 1,
>>>>>>> + },
>>>>>>> +};
>>>>>>
>>>>>> If I understand this right, userspace would need this definition in
>>>>>> order to populate the degamma blob. Should this sit in a UAPI header?
>
> Are you asking whether 'struct drm_color_lut_range` is defined in any
> userspace visible header?
>
> It seems to be in patch 2.
>
>>>>
>>>> Hi Harry, Pekka and Ville,
>>>> Sorry for being a bit late on the replies, got side tracked with various issues.
>>>> I am back on this. Apologies for delay.
>>>>
>>>>> My original idea (not sure it's fully realized in this series) is to
>>>>> have a new GAMMA_MODE/etc. enum property on each crtc (or plane) for
>>>>> which each enum value points to a kernel provided blob that contains one of
>>> these LUT descriptors.
>>>>> Userspace can then query them dynamically and pick the best one for
>>>>> its current use case.
>>>>
>>>> We have this as part of the series Ville. Patch 3 of this series
>>>> creates a DEGAMMA_MODE property just for this. With that userspace can
>>>> just query the blob_id's and will get the various degamma mode possible and the
>>> respective segment and lut distributions.
>>>>
>>>> This will be generic, so for userspace it should just be able to query
>>>> this and parse and get the lut distribution and segment ranges.
>>>>
>>>
>>> Thanks for the explanation.
>>>
>>> Uma, have you had a chance to sketch some of this out in IGT? I'm trying to see how
>>> userspace would do this in practice and will try to sketch an IGT test for this myself,
>>> but if you have it already we could share the effort.
>>
>> Yes Harry, we do have some sample IGT's to test this. Will send those out and will copy
>> you and all the stakeholders.
>>
Thanks. The set is on my list of items to review.
>>>>> The algorithm for choosing the best one might be something like:
>>>>> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
>>>>> - prefer interpolated vs. direct lookup based on current needs (eg. X
>>>>> could prefer direct lookup to get directcolor visuals).
>>>>> - prefer one with extended range values if needed
>>>>> - for HDR prefer smaller step size in dark tones,
>>>>> for SDR perhaps prefer a more uniform step size
>>>>>
>>>>> Or maybe we should include some kind of usage hints as well?
>>>>
>>>> I think the segment range and distribution of lut should be enough for
>>>> a userspace to pick the right ones, but we can add some examples in UAPI
>>> descriptions as hints.
>>>>
>>>
>>> The range might be enough, but we're already parsing hints like "GAMMA"
>>> or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or "SDR" as
>>> well.
>
> What hints are GAMMA or DEGAMMA and who's parsing them? I thought they
> are just arbitrary names to identify the element's position in the
> abstract pipeline.
>
They are provided with the segment definitions, e.g. in
https://patchwork.freedesktop.org/patch/452589/?series=90826&rev=2
I believe they are indicating whether a segment definition is
intended for degamma (linearization) use or for gamma (delinearization)
use.
>>
>> On Intel hardware, we differentiate this with precision and have HDR planes (they have extra
>> Lut precision and samples) separately called out. We could add SDR/HDR FLAG as well.
>
> What about wide color gamut SDR? That probably needs more precision
> than "normal" SDR but is not HDR.
>
> I can't think of how SDR/HDR flags would work or what they would mean.
> Feels a bit too simple for practice. Maybe that concept should be
> created by a hypothetical userspace helper library instead.
>
Maybe this is a decision best left up to compositors. A compositor
will know best what precision and range it needs.
Harry
>
> Thanks,
> pq
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-11 21:10 ` [Intel-gfx] " Harry Wentland
@ 2021-11-12 14:54 ` Ville Syrjälä
-1 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-12 14:54 UTC (permalink / raw)
To: Harry Wentland
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Shankar, Uma
On Thu, Nov 11, 2021 at 04:10:41PM -0500, Harry Wentland wrote:
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland <harry.wentland@amd.com>
> >> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> >> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
> >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> >> HDR planes
> >>
> >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >>>
> >>>
> >>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>>> planes have different capabilities, implemented respective structure
> >>>> for the HDR planes.
> >>>>
> >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>> ---
> >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> >>>> ++++++++++++++++++++++
> >>>> 1 file changed, 52 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> index afcb4bf3826c..6403bd74324b 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> >> *crtc_state)
> >>>> }
> >>>> }
> >>>>
> >>>> + /* FIXME input bpc? */
> >>>> +__maybe_unused
> >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>>> + /* segment 1 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 128,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 0, .end = (1 << 24) - 1,
> >>>> + .min = 0, .max = (1 << 24) - 1,
> >>>> + },
> >>>> + /* segment 2 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 3 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 1 << 24, .end = 3 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 4 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 3 << 24, .end = 7 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> +};
> >>>
> >>> If I understand this right, userspace would need this definition in
> >>> order to populate the degamma blob. Should this sit in a UAPI header?
> >
> > Hi Harry, Pekka and Ville,
> > Sorry for being a bit late on the replies, got side tracked with various issues.
> > I am back on this. Apologies for delay.
> >
> >> My original idea (not sure it's fully realized in this series) is to have a new
> >> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> >> value points to a kernel provided blob that contains one of these LUT descriptors.
> >> Userspace can then query them dynamically and pick the best one for its current use
> >> case.
> >
> > We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
> > property just for this. With that userspace can just query the blob_id's and will get the
> > various degamma mode possible and the respective segment and lut distributions.
> >
> > This will be generic, so for userspace it should just be able to query this and parse and get
> > the lut distribution and segment ranges.
> >
>
> Thanks for the explanation.
>
> Uma, have you had a chance to sketch some of this out in IGT? I'm trying
> to see how userspace would do this in practice and will try to sketch an
> IGT test for this myself, but if you have it already we could share the
> effort.
>
> >> The algorithm for choosing the best one might be something like:
> >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> >> could prefer direct lookup to get directcolor visuals).
> >> - prefer one with extended range values if needed
> >> - for HDR prefer smaller step size in dark tones,
> >> for SDR perhaps prefer a more uniform step size
> >>
> >> Or maybe we should include some kind of usage hints as well?
> >
> > I think the segment range and distribution of lut should be enough for a userspace
> > to pick the right ones, but we can add some examples in UAPI descriptions as hints.
> >
>
> The range might be enough, but we're already parsing hints like "GAMMA"
> or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or
> "SDR" as well.
>
> >> And I was thinking of even adding a new property type (eg.
> >> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
> >> code to do all the validation around the property values and whatnot.
> >>
> >> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
> >> new userspace would work. Though that is more of a generic issue with any new
> >> property really.
> >
> > For plane properties getting added newly, old userspace will not get it so I think this should be ok.
> > Newer userspace will implement this and get the new functionality.
> > Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
> > may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
> > the idea remains same based on your design. Series below for reference:
> > https://patchwork.freedesktop.org/series/90821/>>
>
> Could we just assume we do a uniform LUT if userspace doesn't
> set a _MODE enum value for the respective gamma?
>
> Maybe the _MODE should have a default enum value that means
> a uniform (legacy) LUT.
Yeah, it definitely needs a default like that. But the problem arises
when new userspace sets it to something else and then hands the reins
over to some old userspace that doesn't know how to reset it back to
default.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-12 14:54 ` Ville Syrjälä
0 siblings, 0 replies; 154+ messages in thread
From: Ville Syrjälä @ 2021-11-12 14:54 UTC (permalink / raw)
To: Harry Wentland; +Cc: intel-gfx, ppaalanen, dri-devel, sebastian
On Thu, Nov 11, 2021 at 04:10:41PM -0500, Harry Wentland wrote:
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland <harry.wentland@amd.com>
> >> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> >> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
> >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> >> HDR planes
> >>
> >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> >>>
> >>>
> >>> On 2021-09-06 17:38, Uma Shankar wrote:
> >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> >>>> planes have different capabilities, implemented respective structure
> >>>> for the HDR planes.
> >>>>
> >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> >>>> ---
> >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> >>>> ++++++++++++++++++++++
> >>>> 1 file changed, 52 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> index afcb4bf3826c..6403bd74324b 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> >> *crtc_state)
> >>>> }
> >>>> }
> >>>>
> >>>> + /* FIXME input bpc? */
> >>>> +__maybe_unused
> >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> >>>> + /* segment 1 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 128,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 0, .end = (1 << 24) - 1,
> >>>> + .min = 0, .max = (1 << 24) - 1,
> >>>> + },
> >>>> + /* segment 2 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 3 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 1 << 24, .end = 3 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> + /* Segment 4 */
> >>>> + {
> >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> >>>> + DRM_MODE_LUT_INTERPOLATE |
> >>>> + DRM_MODE_LUT_REUSE_LAST |
> >>>> + DRM_MODE_LUT_NON_DECREASING),
> >>>> + .count = 1,
> >>>> + .input_bpc = 24, .output_bpc = 16,
> >>>> + .start = 3 << 24, .end = 7 << 24,
> >>>> + .min = 0, .max = (1 << 27) - 1,
> >>>> + },
> >>>> +};
> >>>
> >>> If I understand this right, userspace would need this definition in
> >>> order to populate the degamma blob. Should this sit in a UAPI header?
> >
> > Hi Harry, Pekka and Ville,
> > Sorry for being a bit late on the replies, got side tracked with various issues.
> > I am back on this. Apologies for delay.
> >
> >> My original idea (not sure it's fully realized in this series) is to have a new
> >> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> >> value points to a kernel provided blob that contains one of these LUT descriptors.
> >> Userspace can then query them dynamically and pick the best one for its current use
> >> case.
> >
> > We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
> > property just for this. With that userspace can just query the blob_id's and will get the
> > various degamma mode possible and the respective segment and lut distributions.
> >
> > This will be generic, so for userspace it should just be able to query this and parse and get
> > the lut distribution and segment ranges.
> >
>
> Thanks for the explanation.
>
> Uma, have you had a chance to sketch some of this out in IGT? I'm trying
> to see how userspace would do this in practice and will try to sketch an
> IGT test for this myself, but if you have it already we could share the
> effort.
>
> >> The algorithm for choosing the best one might be something like:
> >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> >> could prefer direct lookup to get directcolor visuals).
> >> - prefer one with extended range values if needed
> >> - for HDR prefer smaller step size in dark tones,
> >> for SDR perhaps prefer a more uniform step size
> >>
> >> Or maybe we should include some kind of usage hints as well?
> >
> > I think the segment range and distribution of lut should be enough for a userspace
> > to pick the right ones, but we can add some examples in UAPI descriptions as hints.
> >
>
> The range might be enough, but we're already parsing hints like "GAMMA"
> or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or
> "SDR" as well.
>
> >> And I was thinking of even adding a new property type (eg.
> >> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
> >> code to do all the validation around the property values and whatnot.
> >>
> >> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
> >> new userspace would work. Though that is more of a generic issue with any new
> >> property really.
> >
> > For plane properties getting added newly, old userspace will not get it so I think this should be ok.
> > Newer userspace will implement this and get the new functionality.
> > Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
> > may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
> > the idea remains same based on your design. Series below for reference:
> > https://patchwork.freedesktop.org/series/90821/>>
>
> Could we just assume we do a uniform LUT if userspace doesn't
> set a _MODE enum value for the respective gamma?
>
> Maybe the _MODE should have a default enum value that means
> a uniform (legacy) LUT.
Yeah, it definitely needs a default like that. But the problem arises
when new userspace sets it to something else and then hands the reins
over to some old userspace that doesn't know how to reset it back to
default.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
2021-11-12 14:54 ` [Intel-gfx] " Ville Syrjälä
@ 2021-11-16 8:15 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-16 8:15 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Shashank.Sharma, intel-gfx, dri-devel, sebastian, Shankar, Uma
[-- Attachment #1: Type: text/plain, Size: 8492 bytes --]
On Fri, 12 Nov 2021 16:54:35 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Thu, Nov 11, 2021 at 04:10:41PM -0500, Harry Wentland wrote:
> >
> >
> > On 2021-11-11 15:42, Shankar, Uma wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> Sent: Thursday, November 11, 2021 10:13 PM
> > >> To: Harry Wentland <harry.wentland@amd.com>
> > >> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> > >> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
> > >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> > >> HDR planes
> > >>
> > >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> > >>>
> > >>>
> > >>> On 2021-09-06 17:38, Uma Shankar wrote:
> > >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > >>>> planes have different capabilities, implemented respective structure
> > >>>> for the HDR planes.
> > >>>>
> > >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > >>>> ---
> > >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> > >>>> ++++++++++++++++++++++
> > >>>> 1 file changed, 52 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> index afcb4bf3826c..6403bd74324b 100644
> > >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> > >> *crtc_state)
> > >>>> }
> > >>>> }
> > >>>>
> > >>>> + /* FIXME input bpc? */
> > >>>> +__maybe_unused
> > >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > >>>> + /* segment 1 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 128,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 0, .end = (1 << 24) - 1,
> > >>>> + .min = 0, .max = (1 << 24) - 1,
> > >>>> + },
> > >>>> + /* segment 2 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 3 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 1 << 24, .end = 3 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 4 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 3 << 24, .end = 7 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> +};
> > >>>
> > >>> If I understand this right, userspace would need this definition in
> > >>> order to populate the degamma blob. Should this sit in a UAPI header?
> > >
> > > Hi Harry, Pekka and Ville,
> > > Sorry for being a bit late on the replies, got side tracked with various issues.
> > > I am back on this. Apologies for delay.
> > >
> > >> My original idea (not sure it's fully realized in this series) is to have a new
> > >> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> > >> value points to a kernel provided blob that contains one of these LUT descriptors.
> > >> Userspace can then query them dynamically and pick the best one for its current use
> > >> case.
> > >
> > > We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
> > > property just for this. With that userspace can just query the blob_id's and will get the
> > > various degamma mode possible and the respective segment and lut distributions.
> > >
> > > This will be generic, so for userspace it should just be able to query this and parse and get
> > > the lut distribution and segment ranges.
> > >
> >
> > Thanks for the explanation.
> >
> > Uma, have you had a chance to sketch some of this out in IGT? I'm trying
> > to see how userspace would do this in practice and will try to sketch an
> > IGT test for this myself, but if you have it already we could share the
> > effort.
> >
> > >> The algorithm for choosing the best one might be something like:
> > >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> > >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> > >> could prefer direct lookup to get directcolor visuals).
> > >> - prefer one with extended range values if needed
> > >> - for HDR prefer smaller step size in dark tones,
> > >> for SDR perhaps prefer a more uniform step size
> > >>
> > >> Or maybe we should include some kind of usage hints as well?
> > >
> > > I think the segment range and distribution of lut should be enough for a userspace
> > > to pick the right ones, but we can add some examples in UAPI descriptions as hints.
> > >
> >
> > The range might be enough, but we're already parsing hints like "GAMMA"
> > or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or
> > "SDR" as well.
> >
> > >> And I was thinking of even adding a new property type (eg.
> > >> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
> > >> code to do all the validation around the property values and whatnot.
> > >>
> > >> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
> > >> new userspace would work. Though that is more of a generic issue with any new
> > >> property really.
> > >
> > > For plane properties getting added newly, old userspace will not get it so I think this should be ok.
> > > Newer userspace will implement this and get the new functionality.
> > > Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
> > > may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
> > > the idea remains same based on your design. Series below for reference:
> > > https://patchwork.freedesktop.org/series/90821/>>
> >
> > Could we just assume we do a uniform LUT if userspace doesn't
> > set a _MODE enum value for the respective gamma?
> >
> > Maybe the _MODE should have a default enum value that means
> > a uniform (legacy) LUT.
>
> Yeah, it definitely needs a default like that. But the problem arises
> when new userspace sets it to something else and then hands the reins
> over to some old userspace that doesn't know how to reset it back to
> default.
This very problem is the one where I have been suggesting that
userspace that supports temporarily handing DRM-master to something
else needs to be prepared to save and restore also unrecognized KMS
properties.
We've also had talk about a "reset" switch in KMS, but I forget the
conclusion.
Both ideas lack the people working on them. I don't think we can design
each new KMS property ad hoc to somehow magically be compatible with
old vs. new client interoperation. In fact, the problem exists already
with e.g. the old GAMMA etc. properties.
OTOH, when a userspace client is reported to misbehave because
something else left KMS in a funny state, it is just too easy to simply
patch the innocent but misbehaving client to understand whatever new
property the other one was using, particularly if it's just to reset it
to some hardcoded expected value. So it's unclear if this problem even
needs a solution.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [Intel-gfx] [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
@ 2021-11-16 8:15 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-11-16 8:15 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel, sebastian, Harry Wentland
[-- Attachment #1: Type: text/plain, Size: 8492 bytes --]
On Fri, 12 Nov 2021 16:54:35 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Thu, Nov 11, 2021 at 04:10:41PM -0500, Harry Wentland wrote:
> >
> >
> > On 2021-11-11 15:42, Shankar, Uma wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >> Sent: Thursday, November 11, 2021 10:13 PM
> > >> To: Harry Wentland <harry.wentland@amd.com>
> > >> Cc: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> > >> devel@lists.freedesktop.org; ppaalanen@gmail.com; brian.starkey@arm.com;
> > >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> > >> Subject: Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for
> > >> HDR planes
> > >>
> > >> On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
> > >>>
> > >>>
> > >>> On 2021-09-06 17:38, Uma Shankar wrote:
> > >>>> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > >>>> planes have different capabilities, implemented respective structure
> > >>>> for the HDR planes.
> > >>>>
> > >>>> Signed-off-by: Uma Shankar <uma.shankar@intel.com>
> > >>>> ---
> > >>>> drivers/gpu/drm/i915/display/intel_color.c | 52
> > >>>> ++++++++++++++++++++++
> > >>>> 1 file changed, 52 insertions(+)
> > >>>>
> > >>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> index afcb4bf3826c..6403bd74324b 100644
> > >>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > >>>> @@ -2092,6 +2092,58 @@ static void icl_read_luts(struct intel_crtc_state
> > >> *crtc_state)
> > >>>> }
> > >>>> }
> > >>>>
> > >>>> + /* FIXME input bpc? */
> > >>>> +__maybe_unused
> > >>>> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > >>>> + /* segment 1 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 128,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 0, .end = (1 << 24) - 1,
> > >>>> + .min = 0, .max = (1 << 24) - 1,
> > >>>> + },
> > >>>> + /* segment 2 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = (1 << 24) - 1, .end = 1 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 3 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 1 << 24, .end = 3 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> + /* Segment 4 */
> > >>>> + {
> > >>>> + .flags = (DRM_MODE_LUT_GAMMA |
> > >>>> + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > >>>> + DRM_MODE_LUT_INTERPOLATE |
> > >>>> + DRM_MODE_LUT_REUSE_LAST |
> > >>>> + DRM_MODE_LUT_NON_DECREASING),
> > >>>> + .count = 1,
> > >>>> + .input_bpc = 24, .output_bpc = 16,
> > >>>> + .start = 3 << 24, .end = 7 << 24,
> > >>>> + .min = 0, .max = (1 << 27) - 1,
> > >>>> + },
> > >>>> +};
> > >>>
> > >>> If I understand this right, userspace would need this definition in
> > >>> order to populate the degamma blob. Should this sit in a UAPI header?
> > >
> > > Hi Harry, Pekka and Ville,
> > > Sorry for being a bit late on the replies, got side tracked with various issues.
> > > I am back on this. Apologies for delay.
> > >
> > >> My original idea (not sure it's fully realized in this series) is to have a new
> > >> GAMMA_MODE/etc. enum property on each crtc (or plane) for which each enum
> > >> value points to a kernel provided blob that contains one of these LUT descriptors.
> > >> Userspace can then query them dynamically and pick the best one for its current use
> > >> case.
> > >
> > > We have this as part of the series Ville. Patch 3 of this series creates a DEGAMMA_MODE
> > > property just for this. With that userspace can just query the blob_id's and will get the
> > > various degamma mode possible and the respective segment and lut distributions.
> > >
> > > This will be generic, so for userspace it should just be able to query this and parse and get
> > > the lut distribution and segment ranges.
> > >
> >
> > Thanks for the explanation.
> >
> > Uma, have you had a chance to sketch some of this out in IGT? I'm trying
> > to see how userspace would do this in practice and will try to sketch an
> > IGT test for this myself, but if you have it already we could share the
> > effort.
> >
> > >> The algorithm for choosing the best one might be something like:
> > >> - prefer LUT with bpc >= FB bpc, but perhaps not needlessly high bpc
> > >> - prefer interpolated vs. direct lookup based on current needs (eg. X
> > >> could prefer direct lookup to get directcolor visuals).
> > >> - prefer one with extended range values if needed
> > >> - for HDR prefer smaller step size in dark tones,
> > >> for SDR perhaps prefer a more uniform step size
> > >>
> > >> Or maybe we should include some kind of usage hints as well?
> > >
> > > I think the segment range and distribution of lut should be enough for a userspace
> > > to pick the right ones, but we can add some examples in UAPI descriptions as hints.
> > >
> >
> > The range might be enough, but we're already parsing hints like "GAMMA"
> > or "DEGAMMA". I wonder if it would make sense to add a flag for "HDR" or
> > "SDR" as well.
> >
> > >> And I was thinking of even adding a new property type (eg.
> > >> ENUM_BLOB) just for this sort of usecase. That could let us have a bit more generic
> > >> code to do all the validation around the property values and whatnot.
> > >>
> > >> The one nagging concern I really have with GAMMA_MODE is how a mix of old and
> > >> new userspace would work. Though that is more of a generic issue with any new
> > >> property really.
> > >
> > > For plane properties getting added newly, old userspace will not get it so I think this should be ok.
> > > Newer userspace will implement this and get the new functionality.
> > > Problem will be in extending this to crtc where we have a legacy baggage, the client caps approach
> > > may help us there. Have it as part of separate series just to not mix it with this new plane stuff, though
> > > the idea remains same based on your design. Series below for reference:
> > > https://patchwork.freedesktop.org/series/90821/>>
> >
> > Could we just assume we do a uniform LUT if userspace doesn't
> > set a _MODE enum value for the respective gamma?
> >
> > Maybe the _MODE should have a default enum value that means
> > a uniform (legacy) LUT.
>
> Yeah, it definitely needs a default like that. But the problem arises
> when new userspace sets it to something else and then hands the reins
> over to some old userspace that doesn't know how to reset it back to
> default.
This very problem is the one where I have been suggesting that
userspace that supports temporarily handing DRM-master to something
else needs to be prepared to save and restore also unrecognized KMS
properties.
We've also had talk about a "reset" switch in KMS, but I forget the
conclusion.
Both ideas lack the people working on them. I don't think we can design
each new KMS property ad hoc to somehow magically be compatible with
old vs. new client interoperation. In fact, the problem exists already
with e.g. the old GAMMA etc. properties.
OTOH, when a userspace client is reported to misbehave because
something else left KMS in a funny state, it is just too easy to simply
patch the innocent but misbehaving client to understand whatever new
property the other one was using, particularly if it's just to reset it
to some hardcoded expected value. So it's unclear if this problem even
needs a solution.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 06/22] drm/i915/xelpd: Add register definitions for Plane Degamma
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add macros to define Plane Degamma registers
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 52 +++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 313432ed6196..919982c878ac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -262,6 +262,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
INTEL_INFO(dev_priv)->cursor_offsets[PIPE_A] + (reg) + \
DISPLAY_MMIO_BASE(dev_priv))
+/* Plane Gamma Registers */
+#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
#define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
#define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask)) \
@@ -11366,6 +11369,55 @@ enum skl_power_gate {
_PAL_PREC_MULTI_SEG_DATA_A, \
_PAL_PREC_MULTI_SEG_DATA_B)
+/* Display13 Plane Degmma Reg */
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A 0x701d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B 0x711d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A 0x702d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B 0x712d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A 0x701d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B 0x711d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_A 0x702d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_B 0x712d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_ENH_2_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_A 0x704d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_B 0x714d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_A 0x705d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_B 0x715d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_1_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_2_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_1_A 0x704d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1_B 0x714d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_A 0x705d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_B 0x715d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_1_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_2_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_2(pipe))
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 06/22] drm/i915/xelpd: Add register definitions for Plane Degamma
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add macros to define Plane Degamma registers
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 52 +++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 313432ed6196..919982c878ac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -262,6 +262,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
INTEL_INFO(dev_priv)->cursor_offsets[PIPE_A] + (reg) + \
DISPLAY_MMIO_BASE(dev_priv))
+/* Plane Gamma Registers */
+#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
#define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
#define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask)) \
@@ -11366,6 +11369,55 @@ enum skl_power_gate {
_PAL_PREC_MULTI_SEG_DATA_A, \
_PAL_PREC_MULTI_SEG_DATA_B)
+/* Display13 Plane Degmma Reg */
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A 0x701d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B 0x711d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A 0x702d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B 0x712d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A 0x701d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B 0x711d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_A 0x702d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2_B 0x712d4
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_ENH_2_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_A 0x704d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1_B 0x714d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_A 0x705d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_2_B 0x715d0
+#define _PLANE_PRE_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_1_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_1_B)
+#define _PLANE_PRE_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_INDEX_2_A, \
+ _PLANE_PRE_CSC_GAMC_INDEX_2_B)
+#define PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_PRE_CSC_GAMC_DATA_1_A 0x704d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1_B 0x714d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_A 0x705d4
+#define _PLANE_PRE_CSC_GAMC_DATA_2_B 0x715d4
+#define _PLANE_PRE_CSC_GAMC_DATA_1(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_1_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_1_B)
+#define _PLANE_PRE_CSC_GAMC_DATA_2(pipe) _PIPE(pipe, _PLANE_PRE_CSC_GAMC_DATA_2_A, \
+ _PLANE_PRE_CSC_GAMC_DATA_2_B)
+#define PLANE_PRE_CSC_GAMC_DATA(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_PRE_CSC_GAMC_DATA_2(pipe))
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 07/22] drm/i915/xelpd: Enable plane color features
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Enable and initialize plane color features.
Also initialize the color features of HDR planes.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 22 +++++++++++++++++++++-
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index 6403bd74324b..2307a2e4d73d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include <drm/drm_plane.h>
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -2093,7 +2094,6 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
}
/* FIXME input bpc? */
-__maybe_unused
static const struct drm_color_lut_range d13_degamma_hdr[] = {
/* segment 1 */
{
@@ -2144,6 +2144,26 @@ static const struct drm_color_lut_range d13_degamma_hdr[] = {
},
};
+int intel_plane_color_init(struct drm_plane *plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->dev);
+ int ret = 0;
+
+ if (DISPLAY_VER(dev_priv) >= 13) {
+ drm_plane_create_color_mgmt_properties(plane->dev, plane, 2);
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no degamma",
+ NULL, 0,
+ LUT_TYPE_DEGAMMA);
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+ d13_degamma_hdr,
+ sizeof(d13_degamma_hdr),
+ LUT_TYPE_DEGAMMA);
+ drm_plane_attach_degamma_properties(plane);
+ }
+
+ return ret;
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h b/drivers/gpu/drm/i915/display/intel_color.h
index 173727aaa24d..b8850bb1b0c9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -10,6 +10,7 @@
struct intel_crtc_state;
struct intel_crtc;
+struct drm_plane;
struct drm_property_blob;
void intel_color_init(struct intel_crtc *crtc);
@@ -21,5 +22,6 @@ int intel_color_get_gamma_bit_precision(const struct intel_crtc_state *crtc_stat
bool intel_color_lut_equal(struct drm_property_blob *blob1,
struct drm_property_blob *blob2,
u32 gamma_mode, u32 bit_precision);
+int intel_plane_color_init(struct drm_plane *plane);
#endif /* __INTEL_COLOR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be2392bbcecc..a937a20e4c49 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -391,6 +391,9 @@ struct drm_i915_display_funcs {
*/
void (*load_luts)(const struct intel_crtc_state *crtc_state);
void (*read_luts)(struct intel_crtc_state *crtc_state);
+ /* Add Plane Color callbacks */
+ void (*load_plane_csc_matrix)(const struct drm_plane_state *plane_state);
+ void (*load_plane_luts)(const struct drm_plane_state *plane_state);
};
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 07/22] drm/i915/xelpd: Enable plane color features
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Enable and initialize plane color features.
Also initialize the color features of HDR planes.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 22 +++++++++++++++++++++-
drivers/gpu/drm/i915/display/intel_color.h | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 3 +++
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index 6403bd74324b..2307a2e4d73d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include <drm/drm_plane.h>
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -2093,7 +2094,6 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
}
/* FIXME input bpc? */
-__maybe_unused
static const struct drm_color_lut_range d13_degamma_hdr[] = {
/* segment 1 */
{
@@ -2144,6 +2144,26 @@ static const struct drm_color_lut_range d13_degamma_hdr[] = {
},
};
+int intel_plane_color_init(struct drm_plane *plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->dev);
+ int ret = 0;
+
+ if (DISPLAY_VER(dev_priv) >= 13) {
+ drm_plane_create_color_mgmt_properties(plane->dev, plane, 2);
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no degamma",
+ NULL, 0,
+ LUT_TYPE_DEGAMMA);
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+ d13_degamma_hdr,
+ sizeof(d13_degamma_hdr),
+ LUT_TYPE_DEGAMMA);
+ drm_plane_attach_degamma_properties(plane);
+ }
+
+ return ret;
+}
+
void intel_color_init(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_color.h b/drivers/gpu/drm/i915/display/intel_color.h
index 173727aaa24d..b8850bb1b0c9 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -10,6 +10,7 @@
struct intel_crtc_state;
struct intel_crtc;
+struct drm_plane;
struct drm_property_blob;
void intel_color_init(struct intel_crtc *crtc);
@@ -21,5 +22,6 @@ int intel_color_get_gamma_bit_precision(const struct intel_crtc_state *crtc_stat
bool intel_color_lut_equal(struct drm_property_blob *blob1,
struct drm_property_blob *blob2,
u32 gamma_mode, u32 bit_precision);
+int intel_plane_color_init(struct drm_plane *plane);
#endif /* __INTEL_COLOR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be2392bbcecc..a937a20e4c49 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -391,6 +391,9 @@ struct drm_i915_display_funcs {
*/
void (*load_luts)(const struct intel_crtc_state *crtc_state);
void (*read_luts)(struct intel_crtc_state *crtc_state);
+ /* Add Plane Color callbacks */
+ void (*load_plane_csc_matrix)(const struct drm_plane_state *plane_state);
+ void (*load_plane_luts)(const struct drm_plane_state *plane_state);
};
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 08/22] drm/i915/xelpd: Add color capabilities of SDR planes
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Add the Color capabilities of SDR planes.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 67 ++++++++++++++++++++--
1 file changed, 63 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index 2307a2e4d73d..fd0bfdf85703 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "intel_sprite.h"
#include <drm/drm_plane.h>
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -2144,6 +2145,57 @@ static const struct drm_color_lut_range d13_degamma_hdr[] = {
},
};
+ /* FIXME input bpc? */
+static const struct drm_color_lut_range d13_degamma_sdr[] = {
+ /* segment 1 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 32,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = 0, .end = (1 << 16) - (1 << 16) / 33,
+ .min = 0, .max = (1 << 16) - 1,
+ },
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = (1 << 16) - (1 << 16) / 33, .end = 1 << 16,
+ .min = 0, .max = 1 << 16,
+ },
+ /* Segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = 1 << 16, .end = 3 << 16,
+ .min = 0, .max = (8 << 16) - 1,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = 3 << 16, .end = 7 << 16,
+ .min = 0, .max = (8 << 16) - 1,
+ },
+};
+
int intel_plane_color_init(struct drm_plane *plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -2154,10 +2206,17 @@ int intel_plane_color_init(struct drm_plane *plane)
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no degamma",
NULL, 0,
LUT_TYPE_DEGAMMA);
- ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
- d13_degamma_hdr,
- sizeof(d13_degamma_hdr),
- LUT_TYPE_DEGAMMA);
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+ d13_degamma_hdr,
+ sizeof(d13_degamma_hdr),
+ LUT_TYPE_DEGAMMA);
+ else
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane,
+ "plane degamma",
+ d13_degamma_sdr,
+ sizeof(d13_degamma_sdr),
+ LUT_TYPE_DEGAMMA);
drm_plane_attach_degamma_properties(plane);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 08/22] drm/i915/xelpd: Add color capabilities of SDR planes
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Add the Color capabilities of SDR planes.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 67 ++++++++++++++++++++--
1 file changed, 63 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index 2307a2e4d73d..fd0bfdf85703 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,6 +25,7 @@
#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "intel_sprite.h"
#include <drm/drm_plane.h>
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -2144,6 +2145,57 @@ static const struct drm_color_lut_range d13_degamma_hdr[] = {
},
};
+ /* FIXME input bpc? */
+static const struct drm_color_lut_range d13_degamma_sdr[] = {
+ /* segment 1 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 32,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = 0, .end = (1 << 16) - (1 << 16) / 33,
+ .min = 0, .max = (1 << 16) - 1,
+ },
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = (1 << 16) - (1 << 16) / 33, .end = 1 << 16,
+ .min = 0, .max = 1 << 16,
+ },
+ /* Segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = 1 << 16, .end = 3 << 16,
+ .min = 0, .max = (8 << 16) - 1,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 16, .output_bpc = 16,
+ .start = 3 << 16, .end = 7 << 16,
+ .min = 0, .max = (8 << 16) - 1,
+ },
+};
+
int intel_plane_color_init(struct drm_plane *plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -2154,10 +2206,17 @@ int intel_plane_color_init(struct drm_plane *plane)
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no degamma",
NULL, 0,
LUT_TYPE_DEGAMMA);
- ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
- d13_degamma_hdr,
- sizeof(d13_degamma_hdr),
- LUT_TYPE_DEGAMMA);
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+ d13_degamma_hdr,
+ sizeof(d13_degamma_hdr),
+ LUT_TYPE_DEGAMMA);
+ else
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane,
+ "plane degamma",
+ d13_degamma_sdr,
+ sizeof(d13_degamma_sdr),
+ LUT_TYPE_DEGAMMA);
drm_plane_attach_degamma_properties(plane);
}
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 09/22] drm/i915/xelpd: Program Plane Degamma Registers
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Extract the LUT and program plane degamma registers.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 116 +++++++++++++++++++++
drivers/gpu/drm/i915/i915_reg.h | 2 +
2 files changed, 118 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index fd0bfdf85703..62df5122309a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -126,6 +126,29 @@ static bool crtc_state_is_legacy_gamma(const struct intel_crtc_state *crtc_state
lut_is_legacy(crtc_state->hw.gamma_lut);
}
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+static u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision)
+{
+ u64 val = user_input & 0xffffffff;
+ u32 max;
+
+ if (bit_precision > 32)
+ return 0;
+
+ max = 0xffffffff >> (32 - bit_precision);
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 32) {
+ val += 1UL << (32 - bit_precision - 1);
+ val >>= 32 - bit_precision;
+ }
+
+ return ((user_input & 0xffffffff00000000) |
+ clamp_val(val, 0, max));
+}
+
/*
* When using limited range, multiply the matrix given by userspace by
* the matrix that we would use for the limited range.
@@ -2196,6 +2219,97 @@ static const struct drm_color_lut_range d13_degamma_sdr[] = {
},
};
+static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
+ struct drm_color_lut_ext *degamma_lut,
+ u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ u32 i, lut_size;
+
+ if (icl_is_hdr_plane(dev_priv, plane)) {
+ lut_size = 128;
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, 0),
+ PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (degamma_lut) {
+ for (i = 0; i < lut_size; i++) {
+ u64 word = drm_color_lut_extract_ext(degamma_lut[i].green, 24);
+ u32 lut_val = (word & 0xffffff);
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ lut_val);
+ }
+
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 131)
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ degamma_lut[i++].green);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ 1 << 24);
+ } while (i++ < 130);
+ }
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, 0), 0);
+ } else {
+ lut_size = 32;
+
+ /*
+ * First 3 planes are HDR, so reduce by 3 to get to the right
+ * SDR plane offset
+ */
+ plane = plane - 3;
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, 0),
+ PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (degamma_lut) {
+ for (i = 0; i < lut_size; i++)
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ degamma_lut[i].green);
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 35)
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ degamma_lut[i++].green);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ 1 << 16);
+ } while (i++ < 34);
+ }
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, 0), 0);
+ }
+}
+
+static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
+{
+ const struct drm_property_blob *degamma_lut_blob =
+ plane_state->degamma_lut;
+ struct drm_color_lut_ext *degamma_lut = NULL;
+
+ if (degamma_lut_blob) {
+ degamma_lut = degamma_lut_blob->data;
+ d13_program_plane_degamma_lut(plane_state, degamma_lut, 0);
+ }
+}
+
int intel_plane_color_init(struct drm_plane *plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -2217,6 +2331,8 @@ int intel_plane_color_init(struct drm_plane *plane)
d13_degamma_sdr,
sizeof(d13_degamma_sdr),
LUT_TYPE_DEGAMMA);
+
+ dev_priv->display.load_plane_luts = d13_plane_load_luts;
drm_plane_attach_degamma_properties(plane);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 919982c878ac..0c36a330734f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7232,6 +7232,7 @@ enum {
#define PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
+#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
#define PLANE_COLOR_CSC_MODE_BYPASS (0 << 17)
#define PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 (1 << 17)
#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709 (2 << 17)
@@ -11381,6 +11382,7 @@ enum skl_power_gate {
#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
_MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
_PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
+#define PLANE_PAL_PREC_AUTO_INCREMENT (1 << 10)
#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A 0x701d4
#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B 0x711d4
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 09/22] drm/i915/xelpd: Program Plane Degamma Registers
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Extract the LUT and program plane degamma registers.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 116 +++++++++++++++++++++
drivers/gpu/drm/i915/i915_reg.h | 2 +
2 files changed, 118 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index fd0bfdf85703..62df5122309a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -126,6 +126,29 @@ static bool crtc_state_is_legacy_gamma(const struct intel_crtc_state *crtc_state
lut_is_legacy(crtc_state->hw.gamma_lut);
}
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+static u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision)
+{
+ u64 val = user_input & 0xffffffff;
+ u32 max;
+
+ if (bit_precision > 32)
+ return 0;
+
+ max = 0xffffffff >> (32 - bit_precision);
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 32) {
+ val += 1UL << (32 - bit_precision - 1);
+ val >>= 32 - bit_precision;
+ }
+
+ return ((user_input & 0xffffffff00000000) |
+ clamp_val(val, 0, max));
+}
+
/*
* When using limited range, multiply the matrix given by userspace by
* the matrix that we would use for the limited range.
@@ -2196,6 +2219,97 @@ static const struct drm_color_lut_range d13_degamma_sdr[] = {
},
};
+static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
+ struct drm_color_lut_ext *degamma_lut,
+ u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ u32 i, lut_size;
+
+ if (icl_is_hdr_plane(dev_priv, plane)) {
+ lut_size = 128;
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, 0),
+ PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (degamma_lut) {
+ for (i = 0; i < lut_size; i++) {
+ u64 word = drm_color_lut_extract_ext(degamma_lut[i].green, 24);
+ u32 lut_val = (word & 0xffffff);
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ lut_val);
+ }
+
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 131)
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ degamma_lut[i++].green);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ 1 << 24);
+ } while (i++ < 130);
+ }
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, 0), 0);
+ } else {
+ lut_size = 32;
+
+ /*
+ * First 3 planes are HDR, so reduce by 3 to get to the right
+ * SDR plane offset
+ */
+ plane = plane - 3;
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, 0),
+ PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (degamma_lut) {
+ for (i = 0; i < lut_size; i++)
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ degamma_lut[i].green);
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 35)
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ degamma_lut[i++].green);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_DATA(pipe, plane, 0),
+ 1 << 16);
+ } while (i++ < 34);
+ }
+
+ intel_de_write(dev_priv, PLANE_PRE_CSC_GAMC_INDEX(pipe, plane, 0), 0);
+ }
+}
+
+static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
+{
+ const struct drm_property_blob *degamma_lut_blob =
+ plane_state->degamma_lut;
+ struct drm_color_lut_ext *degamma_lut = NULL;
+
+ if (degamma_lut_blob) {
+ degamma_lut = degamma_lut_blob->data;
+ d13_program_plane_degamma_lut(plane_state, degamma_lut, 0);
+ }
+}
+
int intel_plane_color_init(struct drm_plane *plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
@@ -2217,6 +2331,8 @@ int intel_plane_color_init(struct drm_plane *plane)
d13_degamma_sdr,
sizeof(d13_degamma_sdr),
LUT_TYPE_DEGAMMA);
+
+ dev_priv->display.load_plane_luts = d13_plane_load_luts;
drm_plane_attach_degamma_properties(plane);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 919982c878ac..0c36a330734f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7232,6 +7232,7 @@ enum {
#define PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
+#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
#define PLANE_COLOR_CSC_MODE_BYPASS (0 << 17)
#define PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 (1 << 17)
#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709 (2 << 17)
@@ -11381,6 +11382,7 @@ enum skl_power_gate {
#define PLANE_PRE_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
_MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_INDEX_ENH_1(pipe), \
_PLANE_PRE_CSC_GAMC_INDEX_ENH_2(pipe))
+#define PLANE_PAL_PREC_AUTO_INCREMENT (1 << 10)
#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_A 0x701d4
#define _PLANE_PRE_CSC_GAMC_DATA_ENH_1_B 0x711d4
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 10/22] drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Extended glk_plane_color_ctl to have plane color checks. This helps
enabling the degamma or gamma block based on user inputs.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 724e7b04f3b6..4187a670e840 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -960,6 +960,11 @@ static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
u32 plane_color_ctl = 0;
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+
+ /* FIXME needs hw.degamma_lut */
+ if (plane_state->uapi.degamma_lut)
+ plane_color_ctl |= PLANE_PRE_CSC_GAMMA_ENABLE;
+
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [RFC v2 10/22] drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Extended glk_plane_color_ctl to have plane color checks. This helps
enabling the degamma or gamma block based on user inputs.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 724e7b04f3b6..4187a670e840 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -960,6 +960,11 @@ static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
u32 plane_color_ctl = 0;
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+
+ /* FIXME needs hw.degamma_lut */
+ if (plane_state->uapi.degamma_lut)
+ plane_color_ctl |= PLANE_PRE_CSC_GAMMA_ENABLE;
+
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 11/22] drm/i915/xelpd: Initialize plane color features
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Initialize plane color features for XE_LPD.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 62e5a2a77fd4..854f37b49681 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -64,5 +64,6 @@ int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_plane_helper_add(struct intel_plane *plane);
+int intel_plane_color_init(struct drm_plane *plane);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 4187a670e840..c4e01ae4343c 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2184,6 +2184,8 @@ skl_universal_plane_create(struct drm_i915_private *dev_priv,
BIT(DRM_SCALING_FILTER_DEFAULT) |
BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
+ intel_plane_color_init(&plane->base);
+
intel_plane_helper_add(plane);
return plane;
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 11/22] drm/i915/xelpd: Initialize plane color features
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Initialize plane color features for XE_LPD.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 62e5a2a77fd4..854f37b49681 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -64,5 +64,6 @@ int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_plane_helper_add(struct intel_plane *plane);
+int intel_plane_color_init(struct drm_plane *plane);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 4187a670e840..c4e01ae4343c 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2184,6 +2184,8 @@ skl_universal_plane_create(struct drm_i915_private *dev_priv,
BIT(DRM_SCALING_FILTER_DEFAULT) |
BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
+ intel_plane_color_init(&plane->base);
+
intel_plane_helper_add(plane);
return plane;
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 12/22] drm/i915/xelpd: Load plane color luts from atomic flip
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 3 +++
drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
drivers/gpu/drm/i915/display/intel_color.c | 9 +++++++++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 47234d898549..8796fc86b2e5 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -513,6 +513,9 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
+ if (new_plane_state->uapi.color_mgmt_changed)
+ intel_color_load_plane_luts(&new_plane_state->uapi);
+
if (new_plane_state->uapi.visible ||
new_plane_state->planar_slave) {
intel_update_plane(plane, new_crtc_state, new_plane_state);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 854f37b49681..3001f4d69b4d 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -65,5 +65,6 @@ void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_plane_helper_add(struct intel_plane *plane);
int intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index 62df5122309a..f5a9af858d1b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -22,6 +22,7 @@
*
*/
+#include "intel_atomic_plane.h"
#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_types.h"
@@ -2310,6 +2311,14 @@ static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
}
}
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+ struct drm_device *dev = plane_state->plane->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->display.load_plane_luts(plane_state);
+}
+
int intel_plane_color_init(struct drm_plane *plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 12/22] drm/i915/xelpd: Load plane color luts from atomic flip
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 3 +++
drivers/gpu/drm/i915/display/intel_atomic_plane.h | 1 +
drivers/gpu/drm/i915/display/intel_color.c | 9 +++++++++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 47234d898549..8796fc86b2e5 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -513,6 +513,9 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
+ if (new_plane_state->uapi.color_mgmt_changed)
+ intel_color_load_plane_luts(&new_plane_state->uapi);
+
if (new_plane_state->uapi.visible ||
new_plane_state->planar_slave) {
intel_update_plane(plane, new_crtc_state, new_plane_state);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 854f37b49681..3001f4d69b4d 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -65,5 +65,6 @@ void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
void intel_plane_helper_add(struct intel_plane *plane);
int intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index 62df5122309a..f5a9af858d1b 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -22,6 +22,7 @@
*
*/
+#include "intel_atomic_plane.h"
#include "intel_color.h"
#include "intel_de.h"
#include "intel_display_types.h"
@@ -2310,6 +2311,14 @@ static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
}
}
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+ struct drm_device *dev = plane_state->plane->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->display.load_plane_luts(plane_state);
+}
+
int intel_plane_color_init(struct drm_plane *plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->dev);
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 13/22] drm: Add Plane CTM property
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add a blob property for plane CSC usage.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++++++++++
drivers/gpu/drm/drm_color_mgmt.c | 11 +++++++++++
include/drm/drm_plane.h | 15 +++++++++++++++
4 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 6e358067cb7a..fafb8af1c9cb 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -314,6 +314,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
if (state->degamma_lut)
drm_property_blob_get(state->degamma_lut);
+ if (state->ctm)
+ drm_property_blob_get(state->ctm);
state->color_mgmt_changed = false;
}
@@ -363,6 +365,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
drm_property_blob_put(state->fb_damage_clips);
drm_property_blob_put(state->degamma_lut);
+ drm_property_blob_put(state->ctm);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 904291b96ba9..e736fd7c1d5b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -605,6 +605,14 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->ctm_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ctm,
+ val,
+ sizeof(struct drm_color_ctm), -1,
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -676,6 +684,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+ } else if (property == plane->ctm_property) {
+ *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 29d0fc1e52b5..83832adf3adf 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -602,6 +602,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* engine, thereby making the content as linear for further color
* processing.
*
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -623,6 +627,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->degamma_lut_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "PLANE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->ctm_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index fbfada0b990d..c4ed1799ecaf 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -255,6 +255,14 @@ struct drm_plane_state {
*/
struct drm_property_blob *degamma_lut;
+ /**
+ * @ctm:
+ *
+ * Color transformation matrix. See drm_plane_enable_color_mgmt(). The
+ * blob (if not NULL) is a &struct drm_color_ctm.
+ */
+ struct drm_property_blob *ctm;
+
u8 color_mgmt_changed : 1;
};
@@ -779,6 +787,13 @@ struct drm_plane {
* used to convert the framebuffer's colors to linear gamma.
*/
struct drm_property *degamma_lut_property;
+
+ /**
+ * @plane_ctm_property: Optional Plane property to set the
+ * matrix used to convert colors after the lookup in the
+ * degamma LUT.
+ */
+ struct drm_property *ctm_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 13/22] drm: Add Plane CTM property
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add a blob property for plane CSC usage.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++++++++++
drivers/gpu/drm/drm_color_mgmt.c | 11 +++++++++++
include/drm/drm_plane.h | 15 +++++++++++++++
4 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 6e358067cb7a..fafb8af1c9cb 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -314,6 +314,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
if (state->degamma_lut)
drm_property_blob_get(state->degamma_lut);
+ if (state->ctm)
+ drm_property_blob_get(state->ctm);
state->color_mgmt_changed = false;
}
@@ -363,6 +365,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
drm_property_blob_put(state->fb_damage_clips);
drm_property_blob_put(state->degamma_lut);
+ drm_property_blob_put(state->ctm);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 904291b96ba9..e736fd7c1d5b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -605,6 +605,14 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->ctm_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ctm,
+ val,
+ sizeof(struct drm_color_ctm), -1,
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -676,6 +684,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+ } else if (property == plane->ctm_property) {
+ *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 29d0fc1e52b5..83832adf3adf 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -602,6 +602,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* engine, thereby making the content as linear for further color
* processing.
*
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -623,6 +627,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->degamma_lut_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "PLANE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->ctm_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index fbfada0b990d..c4ed1799ecaf 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -255,6 +255,14 @@ struct drm_plane_state {
*/
struct drm_property_blob *degamma_lut;
+ /**
+ * @ctm:
+ *
+ * Color transformation matrix. See drm_plane_enable_color_mgmt(). The
+ * blob (if not NULL) is a &struct drm_color_ctm.
+ */
+ struct drm_property_blob *ctm;
+
u8 color_mgmt_changed : 1;
};
@@ -779,6 +787,13 @@ struct drm_plane {
* used to convert the framebuffer's colors to linear gamma.
*/
struct drm_property *degamma_lut_property;
+
+ /**
+ * @plane_ctm_property: Optional Plane property to set the
+ * matrix used to convert colors after the lookup in the
+ * degamma LUT.
+ */
+ struct drm_property *ctm_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 14/22] drm: Add helper to attach Plane ctm property
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add a DRM helper to attach ctm property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_color_mgmt.c | 10 ++++++++++
include/drm/drm_plane.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 83832adf3adf..5c3138497b9c 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -654,6 +654,16 @@ void drm_plane_attach_degamma_properties(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
+void drm_plane_attach_ctm_property(struct drm_plane *plane)
+{
+ if (!plane->ctm_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->ctm_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_ctm_property);
+
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index c4ed1799ecaf..3d329f71d287 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -889,6 +889,7 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
int num_values);
void drm_plane_attach_degamma_properties(struct drm_plane *plane);
+void drm_plane_attach_ctm_property(struct drm_plane *plane);
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 14/22] drm: Add helper to attach Plane ctm property
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add a DRM helper to attach ctm property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_color_mgmt.c | 10 ++++++++++
include/drm/drm_plane.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 83832adf3adf..5c3138497b9c 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -654,6 +654,16 @@ void drm_plane_attach_degamma_properties(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_attach_degamma_properties);
+void drm_plane_attach_ctm_property(struct drm_plane *plane)
+{
+ if (!plane->ctm_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->ctm_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_ctm_property);
+
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index c4ed1799ecaf..3d329f71d287 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -889,6 +889,7 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
int num_values);
void drm_plane_attach_degamma_properties(struct drm_plane *plane);
+void drm_plane_attach_ctm_property(struct drm_plane *plane);
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 15/22] drm/i915/xelpd: Define Plane CSC Registers
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Define Register macros for plane CSC.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 43 +++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c36a330734f..20c1b8ddded8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7440,6 +7440,49 @@ enum {
#define PLANE_COLOR_CTL(pipe, plane) \
_MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe), _PLANE_COLOR_CTL_2(pipe))
+/* Plane CSC Registers */
+#define _PLANE_CSC_RY_GY_1_A 0x70210
+#define _PLANE_CSC_RY_GY_2_A 0x70310
+
+#define _PLANE_CSC_RY_GY_1_B 0x71210
+#define _PLANE_CSC_RY_GY_2_B 0x71310
+
+#define _PLANE_CSC_RY_GY_1(pipe) _PIPE(pipe, _PLANE_CSC_RY_GY_1_A, \
+ _PLANE_CSC_RY_GY_1_B)
+#define _PLANE_CSC_RY_GY_2(pipe) _PIPE(pipe, _PLANE_INPUT_CSC_RY_GY_2_A, \
+ _PLANE_INPUT_CSC_RY_GY_2_B)
+#define PLANE_CSC_COEFF(pipe, plane, index) _MMIO_PLANE(plane, \
+ _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \
+ _PLANE_CSC_RY_GY_2(pipe) + (index) * 4)
+
+#define _PLANE_CSC_PREOFF_HI_1_A 0x70228
+#define _PLANE_CSC_PREOFF_HI_2_A 0x70328
+
+#define _PLANE_CSC_PREOFF_HI_1_B 0x71228
+#define _PLANE_CSC_PREOFF_HI_2_B 0x71328
+
+#define _PLANE_CSC_PREOFF_HI_1(pipe) _PIPE(pipe, _PLANE_CSC_PREOFF_HI_1_A, \
+ _PLANE_CSC_PREOFF_HI_1_B)
+#define _PLANE_CSC_PREOFF_HI_2(pipe) _PIPE(pipe, _PLANE_CSC_PREOFF_HI_2_A, \
+ _PLANE_CSC_PREOFF_HI_2_B)
+#define PLANE_CSC_PREOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_PREOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_PREOFF_HI_2(pipe) + \
+ (index) * 4)
+
+#define _PLANE_CSC_POSTOFF_HI_1_A 0x70234
+#define _PLANE_CSC_POSTOFF_HI_2_A 0x70334
+
+#define _PLANE_CSC_POSTOFF_HI_1_B 0x71234
+#define _PLANE_CSC_POSTOFF_HI_2_B 0x71334
+
+#define _PLANE_CSC_POSTOFF_HI_1(pipe) _PIPE(pipe, _PLANE_CSC_POSTOFF_HI_1_A, \
+ _PLANE_CSC_POSTOFF_HI_1_B)
+#define _PLANE_CSC_POSTOFF_HI_2(pipe) _PIPE(pipe, _PLANE_CSC_POSTOFF_HI_2_A, \
+ _PLANE_CSC_POSTOFF_HI_2_B)
+#define PLANE_CSC_POSTOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_POSTOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_POSTOFF_HI_2(pipe) + \
+ (index) * 4)
+
#define _SEL_FETCH_PLANE_BASE_1_A 0x70890
#define _SEL_FETCH_PLANE_BASE_2_A 0x708B0
#define _SEL_FETCH_PLANE_BASE_3_A 0x708D0
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 15/22] drm/i915/xelpd: Define Plane CSC Registers
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Define Register macros for plane CSC.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 43 +++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0c36a330734f..20c1b8ddded8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7440,6 +7440,49 @@ enum {
#define PLANE_COLOR_CTL(pipe, plane) \
_MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe), _PLANE_COLOR_CTL_2(pipe))
+/* Plane CSC Registers */
+#define _PLANE_CSC_RY_GY_1_A 0x70210
+#define _PLANE_CSC_RY_GY_2_A 0x70310
+
+#define _PLANE_CSC_RY_GY_1_B 0x71210
+#define _PLANE_CSC_RY_GY_2_B 0x71310
+
+#define _PLANE_CSC_RY_GY_1(pipe) _PIPE(pipe, _PLANE_CSC_RY_GY_1_A, \
+ _PLANE_CSC_RY_GY_1_B)
+#define _PLANE_CSC_RY_GY_2(pipe) _PIPE(pipe, _PLANE_INPUT_CSC_RY_GY_2_A, \
+ _PLANE_INPUT_CSC_RY_GY_2_B)
+#define PLANE_CSC_COEFF(pipe, plane, index) _MMIO_PLANE(plane, \
+ _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \
+ _PLANE_CSC_RY_GY_2(pipe) + (index) * 4)
+
+#define _PLANE_CSC_PREOFF_HI_1_A 0x70228
+#define _PLANE_CSC_PREOFF_HI_2_A 0x70328
+
+#define _PLANE_CSC_PREOFF_HI_1_B 0x71228
+#define _PLANE_CSC_PREOFF_HI_2_B 0x71328
+
+#define _PLANE_CSC_PREOFF_HI_1(pipe) _PIPE(pipe, _PLANE_CSC_PREOFF_HI_1_A, \
+ _PLANE_CSC_PREOFF_HI_1_B)
+#define _PLANE_CSC_PREOFF_HI_2(pipe) _PIPE(pipe, _PLANE_CSC_PREOFF_HI_2_A, \
+ _PLANE_CSC_PREOFF_HI_2_B)
+#define PLANE_CSC_PREOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_PREOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_PREOFF_HI_2(pipe) + \
+ (index) * 4)
+
+#define _PLANE_CSC_POSTOFF_HI_1_A 0x70234
+#define _PLANE_CSC_POSTOFF_HI_2_A 0x70334
+
+#define _PLANE_CSC_POSTOFF_HI_1_B 0x71234
+#define _PLANE_CSC_POSTOFF_HI_2_B 0x71334
+
+#define _PLANE_CSC_POSTOFF_HI_1(pipe) _PIPE(pipe, _PLANE_CSC_POSTOFF_HI_1_A, \
+ _PLANE_CSC_POSTOFF_HI_1_B)
+#define _PLANE_CSC_POSTOFF_HI_2(pipe) _PIPE(pipe, _PLANE_CSC_POSTOFF_HI_2_A, \
+ _PLANE_CSC_POSTOFF_HI_2_B)
+#define PLANE_CSC_POSTOFF(pipe, plane, index) _MMIO_PLANE(plane, _PLANE_CSC_POSTOFF_HI_1(pipe) + \
+ (index) * 4, _PLANE_CSC_POSTOFF_HI_2(pipe) + \
+ (index) * 4)
+
#define _SEL_FETCH_PLANE_BASE_1_A 0x70890
#define _SEL_FETCH_PLANE_BASE_2_A 0x708B0
#define _SEL_FETCH_PLANE_BASE_3_A 0x708D0
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 16/22] drm/i915/xelpd: Enable Plane CSC
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Implement plane CSC for ICL+
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
drivers/gpu/drm/i915/display/intel_color.c | 82 +++++++++++++++++++
.../drm/i915/display/skl_universal_plane.c | 4 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 8796fc86b2e5..1637f7890f42 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -499,6 +499,7 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct skl_ddb_entry entries_y[I915_MAX_PLANES];
struct skl_ddb_entry entries_uv[I915_MAX_PLANES];
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 update_mask = new_crtc_state->update_planes;
struct intel_plane *plane;
@@ -513,8 +514,10 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
- if (new_plane_state->uapi.color_mgmt_changed)
+ if (new_plane_state->uapi.color_mgmt_changed) {
intel_color_load_plane_luts(&new_plane_state->uapi);
+ dev_priv->display.load_plane_csc_matrix(&new_plane_state->uapi);
+ }
if (new_plane_state->uapi.visible ||
new_plane_state->planar_slave) {
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index f5a9af858d1b..e9c80ed41466 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2118,6 +2118,83 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
}
}
+static void icl_load_plane_csc_matrix(const struct drm_plane_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ struct drm_color_ctm *ctm;
+ const u64 *input;
+ u16 coeffs[9] = {};
+ u16 postoff = 0;
+ int i;
+
+ if (!icl_is_hdr_plane(dev_priv, plane) || !state->ctm)
+ return;
+
+ ctm = state->ctm->data;
+ input = ctm->matrix;
+
+ /*
+ * Convert fixed point S31.32 input to format supported by the
+ * hardware.
+ */
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
+ u64 abs_coeff = ((1ULL << 63) - 1) & input[i];
+
+ /*
+ * Clamp input value to min/max supported by
+ * hardware.
+ */
+ abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_4_0 - 1);
+
+ /* sign bit */
+ if (CTM_COEFF_NEGATIVE(input[i]))
+ coeffs[i] |= 1 << 15;
+
+ if (abs_coeff < CTM_COEFF_0_125)
+ coeffs[i] |= (3 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 12);
+ else if (abs_coeff < CTM_COEFF_0_25)
+ coeffs[i] |= (2 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 11);
+ else if (abs_coeff < CTM_COEFF_0_5)
+ coeffs[i] |= (1 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 10);
+ else if (abs_coeff < CTM_COEFF_1_0)
+ coeffs[i] |= ILK_CSC_COEFF_FP(abs_coeff, 9);
+ else if (abs_coeff < CTM_COEFF_2_0)
+ coeffs[i] |= (7 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 8);
+ else
+ coeffs[i] |= (6 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 7);
+ }
+
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0),
+ coeffs[0] << 16 | coeffs[1]);
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1),
+ coeffs[2] << 16);
+
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2),
+ coeffs[3] << 16 | coeffs[4]);
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3),
+ coeffs[5] << 16);
+
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4),
+ coeffs[6] << 16 | coeffs[7]);
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5),
+ coeffs[8] << 16);
+
+ intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
+ intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
+ intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
+
+ intel_de_write(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
+ intel_de_write(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
+ intel_de_write(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
+}
+
/* FIXME input bpc? */
static const struct drm_color_lut_range d13_degamma_hdr[] = {
/* segment 1 */
@@ -2342,7 +2419,12 @@ int intel_plane_color_init(struct drm_plane *plane)
LUT_TYPE_DEGAMMA);
dev_priv->display.load_plane_luts = d13_plane_load_luts;
+ dev_priv->display.load_plane_csc_matrix = icl_load_plane_csc_matrix;
+
drm_plane_attach_degamma_properties(plane);
+
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ drm_plane_attach_ctm_property(plane);
}
return ret;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index c4e01ae4343c..61eff22a3503 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -965,6 +965,10 @@ static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
if (plane_state->uapi.degamma_lut)
plane_color_ctl |= PLANE_PRE_CSC_GAMMA_ENABLE;
+ /* FIXME needs hw.ctm */
+ if (plane_state->uapi.ctm)
+ plane_color_ctl |= PLANE_COLOR_PLANE_CSC_ENABLE;
+
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 20c1b8ddded8..ceee500e64d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7230,6 +7230,7 @@ enum {
#define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
#define PLANE_COLOR_PIPE_GAMMA_ENABLE (1 << 30) /* Pre-ICL */
#define PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
+#define PLANE_COLOR_PLANE_CSC_ENABLE (1 << 21) /* ICL+ */
#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 16/22] drm/i915/xelpd: Enable Plane CSC
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Implement plane CSC for ICL+
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
drivers/gpu/drm/i915/display/intel_color.c | 82 +++++++++++++++++++
.../drm/i915/display/skl_universal_plane.c | 4 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 8796fc86b2e5..1637f7890f42 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -499,6 +499,7 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct skl_ddb_entry entries_y[I915_MAX_PLANES];
struct skl_ddb_entry entries_uv[I915_MAX_PLANES];
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 update_mask = new_crtc_state->update_planes;
struct intel_plane *plane;
@@ -513,8 +514,10 @@ void skl_update_planes_on_crtc(struct intel_atomic_state *state,
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state, plane);
- if (new_plane_state->uapi.color_mgmt_changed)
+ if (new_plane_state->uapi.color_mgmt_changed) {
intel_color_load_plane_luts(&new_plane_state->uapi);
+ dev_priv->display.load_plane_csc_matrix(&new_plane_state->uapi);
+ }
if (new_plane_state->uapi.visible ||
new_plane_state->planar_slave) {
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index f5a9af858d1b..e9c80ed41466 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2118,6 +2118,83 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state)
}
}
+static void icl_load_plane_csc_matrix(const struct drm_plane_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ struct drm_color_ctm *ctm;
+ const u64 *input;
+ u16 coeffs[9] = {};
+ u16 postoff = 0;
+ int i;
+
+ if (!icl_is_hdr_plane(dev_priv, plane) || !state->ctm)
+ return;
+
+ ctm = state->ctm->data;
+ input = ctm->matrix;
+
+ /*
+ * Convert fixed point S31.32 input to format supported by the
+ * hardware.
+ */
+ for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
+ u64 abs_coeff = ((1ULL << 63) - 1) & input[i];
+
+ /*
+ * Clamp input value to min/max supported by
+ * hardware.
+ */
+ abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_4_0 - 1);
+
+ /* sign bit */
+ if (CTM_COEFF_NEGATIVE(input[i]))
+ coeffs[i] |= 1 << 15;
+
+ if (abs_coeff < CTM_COEFF_0_125)
+ coeffs[i] |= (3 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 12);
+ else if (abs_coeff < CTM_COEFF_0_25)
+ coeffs[i] |= (2 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 11);
+ else if (abs_coeff < CTM_COEFF_0_5)
+ coeffs[i] |= (1 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 10);
+ else if (abs_coeff < CTM_COEFF_1_0)
+ coeffs[i] |= ILK_CSC_COEFF_FP(abs_coeff, 9);
+ else if (abs_coeff < CTM_COEFF_2_0)
+ coeffs[i] |= (7 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 8);
+ else
+ coeffs[i] |= (6 << 12) |
+ ILK_CSC_COEFF_FP(abs_coeff, 7);
+ }
+
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0),
+ coeffs[0] << 16 | coeffs[1]);
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1),
+ coeffs[2] << 16);
+
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2),
+ coeffs[3] << 16 | coeffs[4]);
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3),
+ coeffs[5] << 16);
+
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4),
+ coeffs[6] << 16 | coeffs[7]);
+ intel_de_write(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5),
+ coeffs[8] << 16);
+
+ intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
+ intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
+ intel_de_write(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
+
+ intel_de_write(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
+ intel_de_write(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
+ intel_de_write(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
+}
+
/* FIXME input bpc? */
static const struct drm_color_lut_range d13_degamma_hdr[] = {
/* segment 1 */
@@ -2342,7 +2419,12 @@ int intel_plane_color_init(struct drm_plane *plane)
LUT_TYPE_DEGAMMA);
dev_priv->display.load_plane_luts = d13_plane_load_luts;
+ dev_priv->display.load_plane_csc_matrix = icl_load_plane_csc_matrix;
+
drm_plane_attach_degamma_properties(plane);
+
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ drm_plane_attach_ctm_property(plane);
}
return ret;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index c4e01ae4343c..61eff22a3503 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -965,6 +965,10 @@ static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
if (plane_state->uapi.degamma_lut)
plane_color_ctl |= PLANE_PRE_CSC_GAMMA_ENABLE;
+ /* FIXME needs hw.ctm */
+ if (plane_state->uapi.ctm)
+ plane_color_ctl |= PLANE_COLOR_PLANE_CSC_ENABLE;
+
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 20c1b8ddded8..ceee500e64d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7230,6 +7230,7 @@ enum {
#define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
#define PLANE_COLOR_PIPE_GAMMA_ENABLE (1 << 30) /* Pre-ICL */
#define PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
+#define PLANE_COLOR_PLANE_CSC_ENABLE (1 << 21) /* ICL+ */
#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 17/22] drm: Add Plane Gamma Mode property
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:38 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Add Plane Gamma Mode as a blob property. This is an enum property
with values as blob_id's and exposes the various gamma modes
supported and the lut ranges. Getting the blob id in userspace,
user can get the mode supported and also the range of gamma mode
supported with number of lut coefficients. It can then set one of
the modes using this enum property.
Lut values will be sent through a separate GAMMA_LUT blob property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++
drivers/gpu/drm/drm_color_mgmt.c | 26 ++++++++++++++++++++++++++
include/drm/drm_plane.h | 14 ++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index e736fd7c1d5b..b5abf03c5d51 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -613,6 +613,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->gamma_mode_property) {
+ state->gamma_mode = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -686,6 +688,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+ } else if (property == plane->gamma_mode_property) {
+ *val = state->gamma_mode;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 5c3138497b9c..02367e691cf3 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -606,6 +606,13 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* Blob property which allows a userspace to provide CTM coefficients
* to do color space conversion or any other enhancement by doing a
* matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_mode_property:
+ * Blob property which advertizes the possible gamma modes and
+ * lut ranges supported by the platform. This allows userspace
+ * to query and get the plane gamma color caps and choose the
+ * appropriate gamma mode and create lut values accordingly
+ *
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -634,6 +641,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->ctm_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "PLANE_GAMMA_MODE", num_values);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->gamma_mode_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -664,6 +678,16 @@ void drm_plane_attach_ctm_property(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_attach_ctm_property);
+void drm_plane_attach_gamma_properties(struct drm_plane *plane)
+{
+ if (!plane->gamma_mode_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->gamma_mode_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_gamma_properties);
+
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
@@ -676,6 +700,8 @@ int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
if (type == LUT_TYPE_DEGAMMA)
prop = plane->degamma_mode_property;
+ else
+ prop = plane->gamma_mode_property;
if (!prop)
return -EINVAL;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 3d329f71d287..9081867ecbd1 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -263,6 +263,13 @@ struct drm_plane_state {
*/
struct drm_property_blob *ctm;
+ /**
+ * @gamma_mode: This is a blob_id and exposes the platform capabilities
+ * wrt to various gamma modes and the respective lut ranges. This also
+ * helps user select a gamma mode amongst the supported ones.
+ */
+ u32 gamma_mode;
+
u8 color_mgmt_changed : 1;
};
@@ -794,6 +801,12 @@ struct drm_plane {
* degamma LUT.
*/
struct drm_property *ctm_property;
+
+ /**
+ * @gamma_mode_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to non-linear gamma.
+ */
+ struct drm_property *gamma_mode_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
@@ -890,6 +903,7 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
int num_values);
void drm_plane_attach_degamma_properties(struct drm_plane *plane);
void drm_plane_attach_ctm_property(struct drm_plane *plane);
+void drm_plane_attach_gamma_properties(struct drm_plane *plane);
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 17/22] drm: Add Plane Gamma Mode property
@ 2021-09-06 21:38 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:38 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Add Plane Gamma Mode as a blob property. This is an enum property
with values as blob_id's and exposes the various gamma modes
supported and the lut ranges. Getting the blob id in userspace,
user can get the mode supported and also the range of gamma mode
supported with number of lut coefficients. It can then set one of
the modes using this enum property.
Lut values will be sent through a separate GAMMA_LUT blob property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++
drivers/gpu/drm/drm_color_mgmt.c | 26 ++++++++++++++++++++++++++
include/drm/drm_plane.h | 14 ++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index e736fd7c1d5b..b5abf03c5d51 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -613,6 +613,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->gamma_mode_property) {
+ state->gamma_mode = val;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -686,6 +688,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+ } else if (property == plane->gamma_mode_property) {
+ *val = state->gamma_mode;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 5c3138497b9c..02367e691cf3 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -606,6 +606,13 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* Blob property which allows a userspace to provide CTM coefficients
* to do color space conversion or any other enhancement by doing a
* matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_mode_property:
+ * Blob property which advertizes the possible gamma modes and
+ * lut ranges supported by the platform. This allows userspace
+ * to query and get the plane gamma color caps and choose the
+ * appropriate gamma mode and create lut values accordingly
+ *
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -634,6 +641,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->ctm_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_ENUM,
+ "PLANE_GAMMA_MODE", num_values);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->gamma_mode_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -664,6 +678,16 @@ void drm_plane_attach_ctm_property(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_attach_ctm_property);
+void drm_plane_attach_gamma_properties(struct drm_plane *plane)
+{
+ if (!plane->gamma_mode_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->gamma_mode_property, 0);
+}
+EXPORT_SYMBOL(drm_plane_attach_gamma_properties);
+
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
@@ -676,6 +700,8 @@ int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
if (type == LUT_TYPE_DEGAMMA)
prop = plane->degamma_mode_property;
+ else
+ prop = plane->gamma_mode_property;
if (!prop)
return -EINVAL;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 3d329f71d287..9081867ecbd1 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -263,6 +263,13 @@ struct drm_plane_state {
*/
struct drm_property_blob *ctm;
+ /**
+ * @gamma_mode: This is a blob_id and exposes the platform capabilities
+ * wrt to various gamma modes and the respective lut ranges. This also
+ * helps user select a gamma mode amongst the supported ones.
+ */
+ u32 gamma_mode;
+
u8 color_mgmt_changed : 1;
};
@@ -794,6 +801,12 @@ struct drm_plane {
* degamma LUT.
*/
struct drm_property *ctm_property;
+
+ /**
+ * @gamma_mode_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to non-linear gamma.
+ */
+ struct drm_property *gamma_mode_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
@@ -890,6 +903,7 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
int num_values);
void drm_plane_attach_degamma_properties(struct drm_plane *plane);
void drm_plane_attach_ctm_property(struct drm_plane *plane);
+void drm_plane_attach_gamma_properties(struct drm_plane *plane);
int drm_plane_color_add_gamma_degamma_mode_range(struct drm_plane *plane,
const char *name,
const struct drm_color_lut_range *ranges,
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 18/22] drm: Add Plane Gamma Lut property
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:39 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add Plane Gamma Lut as a blob property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++++++++++
drivers/gpu/drm/drm_color_mgmt.c | 18 ++++++++++++++++++
include/drm/drm_plane.h | 14 ++++++++++++++
4 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index fafb8af1c9cb..7ddf6e4b956b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -316,6 +316,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
drm_property_blob_get(state->degamma_lut);
if (state->ctm)
drm_property_blob_get(state->ctm);
+ if (state->gamma_lut)
+ drm_property_blob_get(state->gamma_lut);
state->color_mgmt_changed = false;
}
@@ -366,6 +368,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
drm_property_blob_put(state->fb_damage_clips);
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
+ drm_property_blob_put(state->gamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index b5abf03c5d51..a32557a4e0d3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -615,6 +615,13 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
return ret;
} else if (property == plane->gamma_mode_property) {
state->gamma_mode = val;
+ } else if (property == plane->gamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->gamma_lut,
+ val, -1, sizeof(struct drm_color_lut_ext),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -690,6 +697,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = (state->ctm) ? state->ctm->base.id : 0;
} else if (property == plane->gamma_mode_property) {
*val = state->gamma_mode;
+ } else if (property == plane->gamma_lut_property) {
+ *val = (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 02367e691cf3..b5b3ff7f654d 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -613,6 +613,11 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* to query and get the plane gamma color caps and choose the
* appropriate gamma mode and create lut values accordingly
*
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma curve using the h/w plane degamma processing
+ * engine, thereby making the content as non-linear.
+ *
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -648,6 +653,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->gamma_mode_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "PLANE_GAMMA_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->gamma_lut_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -685,6 +697,12 @@ void drm_plane_attach_gamma_properties(struct drm_plane *plane)
drm_object_attach_property(&plane->base,
plane->gamma_mode_property, 0);
+
+ if (!plane->gamma_lut_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->gamma_lut_property, 0);
}
EXPORT_SYMBOL(drm_plane_attach_gamma_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9081867ecbd1..8b1f506bc5d3 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -270,6 +270,14 @@ struct drm_plane_state {
*/
u32 gamma_mode;
+ /* @gamma_lut:
+ *
+ * Lookup table for converting framebuffer pixel data after applying the
+ * color conversion matrix @ctm. See drm_plane_enable_color_mgmt(). The
+ * blob (if not NULL) is an array of &struct drm_color_lut_ext.
+ */
+ struct drm_property_blob *gamma_lut;
+
u8 color_mgmt_changed : 1;
};
@@ -807,6 +815,12 @@ struct drm_plane {
* used to convert the framebuffer's colors to non-linear gamma.
*/
struct drm_property *gamma_mode_property;
+
+ /**
+ * @gamma_lut_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to non-linear gamma.
+ */
+ struct drm_property *gamma_lut_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 18/22] drm: Add Plane Gamma Lut property
@ 2021-09-06 21:39 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add Plane Gamma Lut as a blob property.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 10 ++++++++++
drivers/gpu/drm/drm_color_mgmt.c | 18 ++++++++++++++++++
include/drm/drm_plane.h | 14 ++++++++++++++
4 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index fafb8af1c9cb..7ddf6e4b956b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -316,6 +316,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
drm_property_blob_get(state->degamma_lut);
if (state->ctm)
drm_property_blob_get(state->ctm);
+ if (state->gamma_lut)
+ drm_property_blob_get(state->gamma_lut);
state->color_mgmt_changed = false;
}
@@ -366,6 +368,7 @@ void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
drm_property_blob_put(state->fb_damage_clips);
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
+ drm_property_blob_put(state->gamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index b5abf03c5d51..a32557a4e0d3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -615,6 +615,13 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane,
return ret;
} else if (property == plane->gamma_mode_property) {
state->gamma_mode = val;
+ } else if (property == plane->gamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->gamma_lut,
+ val, -1, sizeof(struct drm_color_lut_ext),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (property == config->prop_fb_damage_clips) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->fb_damage_clips,
@@ -690,6 +697,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = (state->ctm) ? state->ctm->base.id : 0;
} else if (property == plane->gamma_mode_property) {
*val = state->gamma_mode;
+ } else if (property == plane->gamma_lut_property) {
+ *val = (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0;
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 02367e691cf3..b5b3ff7f654d 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -613,6 +613,11 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
* to query and get the plane gamma color caps and choose the
* appropriate gamma mode and create lut values accordingly
*
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma curve using the h/w plane degamma processing
+ * engine, thereby making the content as non-linear.
+ *
*/
int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
struct drm_plane *plane,
@@ -648,6 +653,13 @@ int drm_plane_create_color_mgmt_properties(struct drm_device *dev,
plane->gamma_mode_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "PLANE_GAMMA_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->gamma_lut_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_mgmt_properties);
@@ -685,6 +697,12 @@ void drm_plane_attach_gamma_properties(struct drm_plane *plane)
drm_object_attach_property(&plane->base,
plane->gamma_mode_property, 0);
+
+ if (!plane->gamma_lut_property)
+ return;
+
+ drm_object_attach_property(&plane->base,
+ plane->gamma_lut_property, 0);
}
EXPORT_SYMBOL(drm_plane_attach_gamma_properties);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 9081867ecbd1..8b1f506bc5d3 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -270,6 +270,14 @@ struct drm_plane_state {
*/
u32 gamma_mode;
+ /* @gamma_lut:
+ *
+ * Lookup table for converting framebuffer pixel data after applying the
+ * color conversion matrix @ctm. See drm_plane_enable_color_mgmt(). The
+ * blob (if not NULL) is an array of &struct drm_color_lut_ext.
+ */
+ struct drm_property_blob *gamma_lut;
+
u8 color_mgmt_changed : 1;
};
@@ -807,6 +815,12 @@ struct drm_plane {
* used to convert the framebuffer's colors to non-linear gamma.
*/
struct drm_property *gamma_mode_property;
+
+ /**
+ * @gamma_lut_property: Optional Plane property to set the LUT
+ * used to convert the framebuffer's colors to non-linear gamma.
+ */
+ struct drm_property *gamma_lut_property;
};
#define obj_to_plane(x) container_of(x, struct drm_plane, base)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 19/22] drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:39 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Define the structure with XE_LPD gamma lut ranges. HDR and SDR planes
have different capabilities, implemented respective structure for
the HDR planes. Degamma and GAMMA has same Lut caps for SDR planes,
extended the same.
Initialize the mode range caps as well.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 112 ++++++++++++++++++---
1 file changed, 99 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index e9c80ed41466..b4cad5c92c85 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2247,7 +2247,7 @@ static const struct drm_color_lut_range d13_degamma_hdr[] = {
};
/* FIXME input bpc? */
-static const struct drm_color_lut_range d13_degamma_sdr[] = {
+static const struct drm_color_lut_range d13_gamma_degamma_sdr[] = {
/* segment 1 */
{
.flags = (DRM_MODE_LUT_GAMMA |
@@ -2297,6 +2297,63 @@ static const struct drm_color_lut_range d13_degamma_sdr[] = {
},
};
+ /* FIXME input bpc? */
+static const struct drm_color_lut_range d13_gamma_hdr[] = {
+ /*
+ * ToDo: Add Segment 1
+ * There is an optional fine segment added with 9 lut values
+ * Will be added later
+ */
+
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 32,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 0, .end = (1 << 24) - 1,
+ .min = 0, .max = (1 << 24) - 1,
+ },
+ /* segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = (1 << 24) - 1, .end = 1 << 24,
+ .min = 0, .max = 1 << 24,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 1 << 24, .end = 3 << 24,
+ .min = 0, .max = (3 << 24),
+ },
+ /* Segment 5 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 3 << 24, .end = 7 << 24,
+ .min = 0, .max = (7 << 24),
+ },
+};
+
static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
struct drm_color_lut_ext *degamma_lut,
u32 offset)
@@ -2406,26 +2463,55 @@ int intel_plane_color_init(struct drm_plane *plane)
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no degamma",
NULL, 0,
LUT_TYPE_DEGAMMA);
- if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ if (ret)
+ return ret;
+
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no gamma",
+ NULL, 0,
+ LUT_TYPE_GAMMA);
+ if (ret)
+ return ret;
+
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id)) {
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
d13_degamma_hdr,
sizeof(d13_degamma_hdr),
LUT_TYPE_DEGAMMA);
- else
- ret = drm_plane_color_add_gamma_degamma_mode_range(plane,
- "plane degamma",
- d13_degamma_sdr,
- sizeof(d13_degamma_sdr),
+ if (ret)
+ return ret;
+
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane gamma",
+ d13_gamma_hdr,
+ sizeof(d13_gamma_hdr),
+ LUT_TYPE_GAMMA);
+ if (ret)
+ return ret;
+ } else {
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+ d13_gamma_degamma_sdr,
+ sizeof(d13_gamma_degamma_sdr),
LUT_TYPE_DEGAMMA);
+ if (ret)
+ return ret;
+
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane gamma",
+ d13_gamma_degamma_sdr,
+ sizeof(d13_gamma_degamma_sdr),
+ LUT_TYPE_GAMMA);
+ if (ret)
+ return ret;
+ }
+ }
- dev_priv->display.load_plane_luts = d13_plane_load_luts;
- dev_priv->display.load_plane_csc_matrix = icl_load_plane_csc_matrix;
+ dev_priv->display.load_plane_luts = d13_plane_load_luts;
+ dev_priv->display.load_plane_csc_matrix = icl_load_plane_csc_matrix;
- drm_plane_attach_degamma_properties(plane);
+ drm_plane_attach_degamma_properties(plane);
- if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
- drm_plane_attach_ctm_property(plane);
- }
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ drm_plane_attach_ctm_property(plane);
+
+ drm_plane_attach_gamma_properties(plane);
return ret;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 19/22] drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
@ 2021-09-06 21:39 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar, Bhanuprakash Modem
Define the structure with XE_LPD gamma lut ranges. HDR and SDR planes
have different capabilities, implemented respective structure for
the HDR planes. Degamma and GAMMA has same Lut caps for SDR planes,
extended the same.
Initialize the mode range caps as well.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 112 ++++++++++++++++++---
1 file changed, 99 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index e9c80ed41466..b4cad5c92c85 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2247,7 +2247,7 @@ static const struct drm_color_lut_range d13_degamma_hdr[] = {
};
/* FIXME input bpc? */
-static const struct drm_color_lut_range d13_degamma_sdr[] = {
+static const struct drm_color_lut_range d13_gamma_degamma_sdr[] = {
/* segment 1 */
{
.flags = (DRM_MODE_LUT_GAMMA |
@@ -2297,6 +2297,63 @@ static const struct drm_color_lut_range d13_degamma_sdr[] = {
},
};
+ /* FIXME input bpc? */
+static const struct drm_color_lut_range d13_gamma_hdr[] = {
+ /*
+ * ToDo: Add Segment 1
+ * There is an optional fine segment added with 9 lut values
+ * Will be added later
+ */
+
+ /* segment 2 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 32,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 0, .end = (1 << 24) - 1,
+ .min = 0, .max = (1 << 24) - 1,
+ },
+ /* segment 3 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = (1 << 24) - 1, .end = 1 << 24,
+ .min = 0, .max = 1 << 24,
+ },
+ /* Segment 4 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 1 << 24, .end = 3 << 24,
+ .min = 0, .max = (3 << 24),
+ },
+ /* Segment 5 */
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_REFLECT_NEGATIVE |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_REUSE_LAST |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 1,
+ .input_bpc = 24, .output_bpc = 16,
+ .start = 3 << 24, .end = 7 << 24,
+ .min = 0, .max = (7 << 24),
+ },
+};
+
static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
struct drm_color_lut_ext *degamma_lut,
u32 offset)
@@ -2406,26 +2463,55 @@ int intel_plane_color_init(struct drm_plane *plane)
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no degamma",
NULL, 0,
LUT_TYPE_DEGAMMA);
- if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ if (ret)
+ return ret;
+
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "no gamma",
+ NULL, 0,
+ LUT_TYPE_GAMMA);
+ if (ret)
+ return ret;
+
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id)) {
ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
d13_degamma_hdr,
sizeof(d13_degamma_hdr),
LUT_TYPE_DEGAMMA);
- else
- ret = drm_plane_color_add_gamma_degamma_mode_range(plane,
- "plane degamma",
- d13_degamma_sdr,
- sizeof(d13_degamma_sdr),
+ if (ret)
+ return ret;
+
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane gamma",
+ d13_gamma_hdr,
+ sizeof(d13_gamma_hdr),
+ LUT_TYPE_GAMMA);
+ if (ret)
+ return ret;
+ } else {
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane degamma",
+ d13_gamma_degamma_sdr,
+ sizeof(d13_gamma_degamma_sdr),
LUT_TYPE_DEGAMMA);
+ if (ret)
+ return ret;
+
+ ret = drm_plane_color_add_gamma_degamma_mode_range(plane, "plane gamma",
+ d13_gamma_degamma_sdr,
+ sizeof(d13_gamma_degamma_sdr),
+ LUT_TYPE_GAMMA);
+ if (ret)
+ return ret;
+ }
+ }
- dev_priv->display.load_plane_luts = d13_plane_load_luts;
- dev_priv->display.load_plane_csc_matrix = icl_load_plane_csc_matrix;
+ dev_priv->display.load_plane_luts = d13_plane_load_luts;
+ dev_priv->display.load_plane_csc_matrix = icl_load_plane_csc_matrix;
- drm_plane_attach_degamma_properties(plane);
+ drm_plane_attach_degamma_properties(plane);
- if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
- drm_plane_attach_ctm_property(plane);
- }
+ if (icl_is_hdr_plane(dev_priv, to_intel_plane(plane)->id))
+ drm_plane_attach_ctm_property(plane);
+
+ drm_plane_attach_gamma_properties(plane);
return ret;
}
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 20/22] drm/i915/xelpd: Add register definitions for Plane Gamma
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:39 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add macros to define Plane Gamma registers
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 73 +++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ceee500e64d7..fc4f8b430518 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11464,6 +11464,79 @@ enum skl_power_gate {
_MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
_PLANE_PRE_CSC_GAMC_DATA_2(pipe))
+/* Display13 Plane Gamma Reg */
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A 0x70160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B 0x71160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A 0x70260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B 0x71260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A 0x70164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B 0x71164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A 0x70264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B 0x71264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_A 0x701d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_B 0x711d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_A 0x702d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_B 0x712d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_A 0x701dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_B 0x711dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_A 0x702dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_B 0x712dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_1_A 0x704d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1_B 0x714d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_A 0x705d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_B 0x715d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_1_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_2_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_1_A 0x704dc
+#define _PLANE_POST_CSC_GAMC_DATA_1_B 0x714dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_A 0x705dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_B 0x715dc
+#define _PLANE_POST_CSC_GAMC_DATA_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_1_A, \
+ _PLANE_POST_CSC_GAMC_DATA_1_B)
+#define _PLANE_POST_CSC_GAMC_DATA_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_2_A, \
+ _PLANE_POST_CSC_GAMC_DATA_2_B)
+#define PLANE_POST_CSC_GAMC_DATA(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_2(pipe))
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 20/22] drm/i915/xelpd: Add register definitions for Plane Gamma
@ 2021-09-06 21:39 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Add macros to define Plane Gamma registers
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 73 +++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ceee500e64d7..fc4f8b430518 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11464,6 +11464,79 @@ enum skl_power_gate {
_MMIO_PLANE_GAMC(plane, i, _PLANE_PRE_CSC_GAMC_DATA_1(pipe), \
_PLANE_PRE_CSC_GAMC_DATA_2(pipe))
+/* Display13 Plane Gamma Reg */
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A 0x70160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B 0x71160
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A 0x70260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B 0x71260
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A 0x70164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B 0x71164
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A 0x70264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B 0x71264
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_SEG0_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_SEG0_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_A 0x701d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1_B 0x711d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_A 0x702d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2_B 0x712d8
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_A 0x701dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1_B 0x711dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_A 0x702dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2_B 0x712dc
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_ENH_1_A, \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_1_B)
+#define _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_ENH_2_A, \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_2_B)
+#define PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_DATA_ENH_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_ENH_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_INDEX_1_A 0x704d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1_B 0x714d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_A 0x705d8
+#define _PLANE_POST_CSC_GAMC_INDEX_2_B 0x715d8
+#define _PLANE_POST_CSC_GAMC_INDEX_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_1_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_1_B)
+#define _PLANE_POST_CSC_GAMC_INDEX_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_INDEX_2_A, \
+ _PLANE_POST_CSC_GAMC_INDEX_2_B)
+#define PLANE_POST_CSC_GAMC_INDEX(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_INDEX_1(pipe), \
+ _PLANE_POST_CSC_GAMC_INDEX_2(pipe))
+
+#define _PLANE_POST_CSC_GAMC_DATA_1_A 0x704dc
+#define _PLANE_POST_CSC_GAMC_DATA_1_B 0x714dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_A 0x705dc
+#define _PLANE_POST_CSC_GAMC_DATA_2_B 0x715dc
+#define _PLANE_POST_CSC_GAMC_DATA_1(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_1_A, \
+ _PLANE_POST_CSC_GAMC_DATA_1_B)
+#define _PLANE_POST_CSC_GAMC_DATA_2(pipe) _PIPE(pipe, _PLANE_POST_CSC_GAMC_DATA_2_A, \
+ _PLANE_POST_CSC_GAMC_DATA_2_B)
+#define PLANE_POST_CSC_GAMC_DATA(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_POST_CSC_GAMC_DATA_1(pipe), \
+ _PLANE_POST_CSC_GAMC_DATA_2(pipe))
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 21/22] drm/i915/xelpd: Program Plane Gamma Registers
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:39 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Extract the LUT and program plane gamma registers.
Enabled multi segmented lut as well.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 89 ++++++++++++++++++++++
drivers/gpu/drm/i915/i915_reg.h | 9 ++-
2 files changed, 94 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index b4cad5c92c85..e5f168a32932 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -27,6 +27,9 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_sprite.h"
+
+#include "skl_universal_plane.h"
+
#include <drm/drm_plane.h>
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -2433,16 +2436,102 @@ static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
}
}
+static void d13_program_plane_gamma_lut(const struct drm_plane_state *state,
+ struct drm_color_lut_ext *gamma_lut,
+ u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ u32 i, lut_size;
+
+ if (icl_is_hdr_plane(dev_priv, plane)) {
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+ if (gamma_lut) {
+ lut_size = 32;
+ for (i = 0; i < lut_size; i++) {
+ u64 word = drm_color_lut_extract_ext(gamma_lut[i].green, 24);
+ u32 lut_val = (word & 0xffffff);
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ lut_val);
+ }
+
+ do {
+ /* Program the max register to clamp values > 1.0. */
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ gamma_lut[i].green);
+ } while (i++ < 34);
+ } else {
+ lut_size = 32;
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ 1 << 24);
+ } while (i++ < 34);
+ }
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, 0), 0);
+ } else {
+ lut_size = 32;
+ /*
+ * First 3 planes are HDR, so reduce by 3 to get to the right
+ * SDR plane offset
+ */
+ plane = plane - 3;
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe, plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (gamma_lut) {
+ for (i = 0; i < lut_size; i++)
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ gamma_lut[i].green & 0xffff);
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 35)
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ gamma_lut[i++].green & 0x3ffff);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ (1 << 16));
+ } while (i++ < 34);
+ }
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe, plane, 0), 0);
+ }
+}
+
static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
{
const struct drm_property_blob *degamma_lut_blob =
plane_state->degamma_lut;
+ const struct drm_property_blob *gamma_lut_blob =
+ plane_state->gamma_lut;
struct drm_color_lut_ext *degamma_lut = NULL;
+ struct drm_color_lut_ext *gamma_lut = NULL;
if (degamma_lut_blob) {
degamma_lut = degamma_lut_blob->data;
d13_program_plane_degamma_lut(plane_state, degamma_lut, 0);
}
+
+ if (gamma_lut_blob) {
+ gamma_lut = gamma_lut_blob->data;
+ d13_program_plane_gamma_lut(plane_state, gamma_lut, 0);
+ }
}
void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fc4f8b430518..037b95153b86 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7230,10 +7230,11 @@ enum {
#define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
#define PLANE_COLOR_PIPE_GAMMA_ENABLE (1 << 30) /* Pre-ICL */
#define PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
-#define PLANE_COLOR_PLANE_CSC_ENABLE (1 << 21) /* ICL+ */
-#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
-#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
-#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
+#define PLANE_COLOR_PLANE_CSC_ENABLE (1 << 21) /* ICL+ */
+#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
+#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
+#define PLANE_POST_CSC_GAMMA_MULTI_SEGMENT_ENABLE (1 << 15)
+#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
#define PLANE_COLOR_CSC_MODE_BYPASS (0 << 17)
#define PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 (1 << 17)
#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709 (2 << 17)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread* [Intel-gfx] [RFC v2 21/22] drm/i915/xelpd: Program Plane Gamma Registers
@ 2021-09-06 21:39 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Extract the LUT and program plane gamma registers.
Enabled multi segmented lut as well.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/intel_color.c | 89 ++++++++++++++++++++++
drivers/gpu/drm/i915/i915_reg.h | 9 ++-
2 files changed, 94 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
index b4cad5c92c85..e5f168a32932 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -27,6 +27,9 @@
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_sprite.h"
+
+#include "skl_universal_plane.h"
+
#include <drm/drm_plane.h>
#define CTM_COEFF_SIGN (1ULL << 63)
@@ -2433,16 +2436,102 @@ static void d13_program_plane_degamma_lut(const struct drm_plane_state *state,
}
}
+static void d13_program_plane_gamma_lut(const struct drm_plane_state *state,
+ struct drm_color_lut_ext *gamma_lut,
+ u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ u32 i, lut_size;
+
+ if (icl_is_hdr_plane(dev_priv, plane)) {
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+ if (gamma_lut) {
+ lut_size = 32;
+ for (i = 0; i < lut_size; i++) {
+ u64 word = drm_color_lut_extract_ext(gamma_lut[i].green, 24);
+ u32 lut_val = (word & 0xffffff);
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ lut_val);
+ }
+
+ do {
+ /* Program the max register to clamp values > 1.0. */
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ gamma_lut[i].green);
+ } while (i++ < 34);
+ } else {
+ lut_size = 32;
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 24) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA_ENH(pipe, plane, 0),
+ 1 << 24);
+ } while (i++ < 34);
+ }
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX_ENH(pipe, plane, 0), 0);
+ } else {
+ lut_size = 32;
+ /*
+ * First 3 planes are HDR, so reduce by 3 to get to the right
+ * SDR plane offset
+ */
+ plane = plane - 3;
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe, plane, 0),
+ offset | PLANE_PAL_PREC_AUTO_INCREMENT);
+
+ if (gamma_lut) {
+ for (i = 0; i < lut_size; i++)
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ gamma_lut[i].green & 0xffff);
+ /* Program the max register to clamp values > 1.0. */
+ while (i < 35)
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ gamma_lut[i++].green & 0x3ffff);
+ } else {
+ for (i = 0; i < lut_size; i++) {
+ u32 v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0), v);
+ }
+
+ do {
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_DATA(pipe, plane, 0),
+ (1 << 16));
+ } while (i++ < 34);
+ }
+
+ intel_de_write(dev_priv, PLANE_POST_CSC_GAMC_INDEX(pipe, plane, 0), 0);
+ }
+}
+
static void d13_plane_load_luts(const struct drm_plane_state *plane_state)
{
const struct drm_property_blob *degamma_lut_blob =
plane_state->degamma_lut;
+ const struct drm_property_blob *gamma_lut_blob =
+ plane_state->gamma_lut;
struct drm_color_lut_ext *degamma_lut = NULL;
+ struct drm_color_lut_ext *gamma_lut = NULL;
if (degamma_lut_blob) {
degamma_lut = degamma_lut_blob->data;
d13_program_plane_degamma_lut(plane_state, degamma_lut, 0);
}
+
+ if (gamma_lut_blob) {
+ gamma_lut = gamma_lut_blob->data;
+ d13_program_plane_gamma_lut(plane_state, gamma_lut, 0);
+ }
}
void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fc4f8b430518..037b95153b86 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7230,10 +7230,11 @@ enum {
#define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
#define PLANE_COLOR_PIPE_GAMMA_ENABLE (1 << 30) /* Pre-ICL */
#define PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE (1 << 28)
-#define PLANE_COLOR_PLANE_CSC_ENABLE (1 << 21) /* ICL+ */
-#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
-#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
-#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
+#define PLANE_COLOR_PLANE_CSC_ENABLE (1 << 21) /* ICL+ */
+#define PLANE_COLOR_INPUT_CSC_ENABLE (1 << 20) /* ICL+ */
+#define PLANE_COLOR_PIPE_CSC_ENABLE (1 << 23) /* Pre-ICL */
+#define PLANE_POST_CSC_GAMMA_MULTI_SEGMENT_ENABLE (1 << 15)
+#define PLANE_PRE_CSC_GAMMA_ENABLE (1 << 14)
#define PLANE_COLOR_CSC_MODE_BYPASS (0 << 17)
#define PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 (1 << 17)
#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709 (2 << 17)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [RFC v2 22/22] drm/i915/xelpd: Enable plane gamma
2021-09-06 21:38 ` Uma Shankar
@ 2021-09-06 21:39 ` Uma Shankar
-1 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Enable plane gamma feature in check callbacks. Decide
based on the user input.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 61eff22a3503..139863d4e3a7 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -959,7 +959,9 @@ static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
u32 plane_color_ctl = 0;
- plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+ /* FIXME needs hw.gamma_lut */
+ if (!plane_state->uapi.gamma_lut)
+ plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
/* FIXME needs hw.degamma_lut */
if (plane_state->uapi.degamma_lut)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] [RFC v2 22/22] drm/i915/xelpd: Enable plane gamma
@ 2021-09-06 21:39 ` Uma Shankar
0 siblings, 0 replies; 154+ messages in thread
From: Uma Shankar @ 2021-09-06 21:39 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: harry.wentland, ville.syrjala, ppaalanen, brian.starkey,
sebastian, Shashank.Sharma, Uma Shankar
Enable plane gamma feature in check callbacks. Decide
based on the user input.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 61eff22a3503..139863d4e3a7 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -959,7 +959,9 @@ static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
u32 plane_color_ctl = 0;
- plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+ /* FIXME needs hw.gamma_lut */
+ if (!plane_state->uapi.gamma_lut)
+ plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
/* FIXME needs hw.degamma_lut */
if (plane_state->uapi.degamma_lut)
--
2.26.2
^ permalink raw reply related [flat|nested] 154+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for Add Support for Plane Color Lut and CSC features (rev2)
2021-09-06 21:38 ` Uma Shankar
` (24 preceding siblings ...)
(?)
@ 2021-09-06 21:57 ` Patchwork
-1 siblings, 0 replies; 154+ messages in thread
From: Patchwork @ 2021-09-06 21:57 UTC (permalink / raw)
To: Shankar, Uma; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 4874 bytes --]
== Series Details ==
Series: Add Support for Plane Color Lut and CSC features (rev2)
URL : https://patchwork.freedesktop.org/series/90825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10553 -> Patchwork_20969
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/index.html
Known issues
------------
Here are the changes found in Patchwork_20969 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271]) +18 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-skl-6600u/igt@amdgpu/amd_cs_nop@sync-fork-gfx0.html
* igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [PASS][2] -> [DMESG-WARN][3] ([i915#3925])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-rkl-guc/igt@core_hotunplug@unbind-rebind.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-rkl-guc/igt@core_hotunplug@unbind-rebind.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [PASS][4] -> [INCOMPLETE][5] ([i915#3921])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][6] ([i915#1602] / [i915#2029])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-bdw-5557u/igt@runner@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][7] ([i915#1602])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-rkl-guc/igt@runner@aborted.html
#### Possible fixes ####
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-skl-6600u: [INCOMPLETE][8] ([i915#198]) -> [PASS][9]
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/fi-skl-6600u/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/fi-skl-6600u/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925
Participating hosts (45 -> 39)
------------------------------
Missing (6): bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 bat-jsl-1
Build changes
-------------
* Linux: CI_DRM_10553 -> Patchwork_20969
CI-20190529: 20190529
CI_DRM_10553: 47b2bd2caa7b29b5741ff2521206657853b85165 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20969: 7336f11261352439ed686c7ea33cfb1d1a167788 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7336f1126135 drm/i915/xelpd: Enable plane gamma
f8a38f97382c drm/i915/xelpd: Program Plane Gamma Registers
e8c016461e9a drm/i915/xelpd: Add register definitions for Plane Gamma
757106bc29dd drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
a3fc5412d19d drm: Add Plane Gamma Lut property
ec7dd2be1f37 drm: Add Plane Gamma Mode property
c80670d0ba61 drm/i915/xelpd: Enable Plane CSC
5c841e35f0e7 drm/i915/xelpd: Define Plane CSC Registers
cccf197af1b9 drm: Add helper to attach Plane ctm property
9a0a55da5520 drm: Add Plane CTM property
7b01dd73b025 drm/i915/xelpd: Load plane color luts from atomic flip
a66cbbe88e63 drm/i915/xelpd: Initialize plane color features
d64e7e814400 drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
853f0116ea83 drm/i915/xelpd: Program Plane Degamma Registers
790f94f18205 drm/i915/xelpd: Add color capabilities of SDR planes
3a31d402f88a drm/i915/xelpd: Enable plane color features
df616ff808c3 drm/i915/xelpd: Add register definitions for Plane Degamma
d92433346e40 drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
e54bf9c1c858 drm: Add Plane Degamma Lut property
39feb4a85cab drm: Add Plane Degamma Mode property
1e2ce83e3017 drm: Add Enhanced Gamma and color lut range attributes
0bd5f1aa34e1 drm: RFC for Plane Color Hardware Pipeline
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/index.html
[-- Attachment #2: Type: text/html, Size: 5741 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* [Intel-gfx] ✗ Fi.CI.IGT: failure for Add Support for Plane Color Lut and CSC features (rev2)
2021-09-06 21:38 ` Uma Shankar
` (25 preceding siblings ...)
(?)
@ 2021-09-06 23:12 ` Patchwork
-1 siblings, 0 replies; 154+ messages in thread
From: Patchwork @ 2021-09-06 23:12 UTC (permalink / raw)
To: Shankar, Uma; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30278 bytes --]
== Series Details ==
Series: Add Support for Plane Color Lut and CSC features (rev2)
URL : https://patchwork.freedesktop.org/series/90825/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10553_full -> Patchwork_20969_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_20969_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20969_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_20969_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@sysfs_heartbeat_interval@mixed@rcs0:
- shard-skl: [PASS][3] -> [WARN][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl8/igt@sysfs_heartbeat_interval@mixed@rcs0.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl6/igt@sysfs_heartbeat_interval@mixed@rcs0.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@hibernate:
- {shard-rkl}: [PASS][5] -> [FAIL][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-6/igt@gem_eio@hibernate.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-2/igt@gem_eio@hibernate.html
Known issues
------------
Here are the changes found in Patchwork_20969_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@feature_discovery@display-2x:
- shard-tglb: NOTRUN -> [SKIP][7] ([i915#1839])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@feature_discovery@display-2x.html
* igt@gem_ctx_persistence@engines-queued:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +2 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-snb5/igt@gem_ctx_persistence@engines-queued.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#2481] / [i915#3070])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb6/igt@gem_eio@unwedge-stress.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb4/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2846])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk5/igt@gem_exec_fair@basic-deadline.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-glk3/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb5/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl3/igt@gem_exec_fair@basic-none@vcs1.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl6/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][17] -> [SKIP][18] ([fdo#109271])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl7/igt@gem_exec_fair@basic-pace@vecs0.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl3/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_exec_params@secure-non-master:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#112283])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@gem_exec_params@secure-non-master.html
* igt@gem_pread@exhaustion:
- shard-apl: NOTRUN -> [WARN][20] ([i915#2658]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl8/igt@gem_pread@exhaustion.html
* igt@gem_softpin@evict-snoop:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109312])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@gem_softpin@evict-snoop.html
* igt@gen7_exec_parse@basic-allowed:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109289])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@gen7_exec_parse@basic-allowed.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp:
- shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#1937])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl2/igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp.html
* igt@i915_suspend@forcewake:
- shard-apl: [PASS][24] -> [DMESG-WARN][25] ([i915#180]) +1 similar issue
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-apl7/igt@i915_suspend@forcewake.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl8/igt@i915_suspend@forcewake.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][26] ([fdo#111614])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_big_fb@x-tiled-64bpp-rotate-270.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][27] ([fdo#109271] / [i915#3777]) +2 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl7/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_fb@yf-tiled-32bpp-rotate-0:
- shard-iclb: [PASS][28] -> [DMESG-WARN][29] ([i915#3621])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb2/igt@kms_big_fb@yf-tiled-32bpp-rotate-0.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb1/igt@kms_big_fb@yf-tiled-32bpp-rotate-0.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-tglb: NOTRUN -> [SKIP][30] ([fdo#111615]) +1 similar issue
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- shard-snb: NOTRUN -> [SKIP][31] ([fdo#109271]) +228 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-snb2/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
* igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3886]) +15 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl7/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][33] ([i915#3689] / [i915#3886]) +1 similar issue
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium@dp-crc-multiple:
- shard-apl: NOTRUN -> [SKIP][34] ([fdo#109271] / [fdo#111827]) +26 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl6/igt@kms_chamelium@dp-crc-multiple.html
* igt@kms_chamelium@vga-hpd:
- shard-tglb: NOTRUN -> [SKIP][35] ([fdo#109284] / [fdo#111827]) +3 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_chamelium@vga-hpd.html
* igt@kms_color@pipe-a-ctm-0-75:
- shard-skl: [PASS][36] -> [DMESG-WARN][37] ([i915#1982])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl10/igt@kms_color@pipe-a-ctm-0-75.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl3/igt@kms_color@pipe-a-ctm-0-75.html
* igt@kms_color_chamelium@pipe-a-ctm-negative:
- shard-snb: NOTRUN -> [SKIP][38] ([fdo#109271] / [fdo#111827]) +11 similar issues
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-snb6/igt@kms_color_chamelium@pipe-a-ctm-negative.html
* igt@kms_color_chamelium@pipe-d-degamma:
- shard-skl: NOTRUN -> [SKIP][39] ([fdo#109271] / [fdo#111827]) +4 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl5/igt@kms_color_chamelium@pipe-d-degamma.html
* igt@kms_content_protection@dp-mst-type-0:
- shard-tglb: NOTRUN -> [SKIP][40] ([i915#3116])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_content_protection@dp-mst-type-0.html
* igt@kms_cursor_crc@pipe-a-cursor-512x170-offscreen:
- shard-tglb: NOTRUN -> [SKIP][41] ([fdo#109279] / [i915#3359])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_cursor_crc@pipe-a-cursor-512x170-offscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-512x170-rapid-movement:
- shard-tglb: NOTRUN -> [SKIP][42] ([i915#3359])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_cursor_crc@pipe-b-cursor-512x170-rapid-movement.html
* igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement:
- shard-kbl: NOTRUN -> [SKIP][43] ([fdo#109271]) +9 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl3/igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement.html
* igt@kms_cursor_edge_walk@pipe-b-64x64-right-edge:
- shard-tglb: [PASS][44] -> [INCOMPLETE][45] ([i915#2295])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb2/igt@kms_cursor_edge_walk@pipe-b-64x64-right-edge.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb1/igt@kms_cursor_edge_walk@pipe-b-64x64-right-edge.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-skl: [PASS][46] -> [FAIL][47] ([i915#2346] / [i915#533])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl5/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_cursor_legacy@pipe-d-torture-move:
- shard-skl: NOTRUN -> [SKIP][48] ([fdo#109271]) +55 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl5/igt@kms_cursor_legacy@pipe-d-torture-move.html
* igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1:
- shard-skl: [PASS][49] -> [FAIL][50] ([i915#2122])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl2/igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl5/igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1.html
* igt@kms_flip@plain-flip-ts-check@a-hdmi-a2:
- shard-glk: [PASS][51] -> [FAIL][52] ([i915#2122])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk2/igt@kms_flip@plain-flip-ts-check@a-hdmi-a2.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-glk2/igt@kms_flip@plain-flip-ts-check@a-hdmi-a2.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- shard-skl: NOTRUN -> [SKIP][53] ([fdo#109271] / [i915#2672])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-pwrite:
- shard-tglb: NOTRUN -> [SKIP][54] ([fdo#111825]) +8 similar issues
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-pwrite.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [PASS][55] -> [FAIL][56] ([i915#1188])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl10/igt@kms_hdr@bpc-switch.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl3/igt@kms_hdr@bpc-switch.html
* igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d:
- shard-apl: NOTRUN -> [SKIP][57] ([fdo#109271] / [i915#533]) +2 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl6/igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl: NOTRUN -> [FAIL][58] ([fdo#108145] / [i915#265]) +3 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl7/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
- shard-skl: NOTRUN -> [FAIL][59] ([i915#265])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][60] -> [FAIL][61] ([fdo#108145] / [i915#265])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4:
- shard-apl: NOTRUN -> [SKIP][62] ([fdo#109271] / [i915#658]) +4 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl6/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4:
- shard-tglb: NOTRUN -> [SKIP][63] ([i915#2920])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
- shard-skl: NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#658])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl5/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][65] -> [SKIP][66] ([fdo#109441]) +1 similar issue
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb1/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-tglb: NOTRUN -> [FAIL][67] ([i915#132] / [i915#3467])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_vblank@pipe-d-ts-continuation-idle:
- shard-apl: NOTRUN -> [SKIP][68] ([fdo#109271]) +292 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl2/igt@kms_vblank@pipe-d-ts-continuation-idle.html
* igt@kms_vrr@flip-dpms:
- shard-tglb: NOTRUN -> [SKIP][69] ([fdo#109502])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@kms_vrr@flip-dpms.html
* igt@nouveau_crc@pipe-c-source-rg:
- shard-tglb: NOTRUN -> [SKIP][70] ([i915#2530])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@nouveau_crc@pipe-c-source-rg.html
* igt@sysfs_clients@fair-7:
- shard-apl: NOTRUN -> [SKIP][71] ([fdo#109271] / [i915#2994]) +4 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl8/igt@sysfs_clients@fair-7.html
* igt@sysfs_clients@split-10:
- shard-tglb: NOTRUN -> [SKIP][72] ([i915#2994])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@sysfs_clients@split-10.html
* igt@sysfs_heartbeat_interval@mixed@bcs0:
- shard-skl: [PASS][73] -> [FAIL][74] ([i915#1731])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl8/igt@sysfs_heartbeat_interval@mixed@bcs0.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl6/igt@sysfs_heartbeat_interval@mixed@bcs0.html
#### Possible fixes ####
* igt@fbdev@unaligned-write:
- {shard-rkl}: [SKIP][75] ([i915#2582]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@fbdev@unaligned-write.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@fbdev@unaligned-write.html
* igt@feature_discovery@psr2:
- {shard-rkl}: [SKIP][77] ([i915#658]) -> [PASS][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@feature_discovery@psr2.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@feature_discovery@psr2.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl: [DMESG-WARN][79] ([i915#3848]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl8/igt@gem_ctx_isolation@preservation-s3@rcs0.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl1/igt@gem_ctx_isolation@preservation-s3@rcs0.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl: [DMESG-WARN][81] ([i915#180]) -> [PASS][82] +1 similar issue
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl4/igt@gem_ctx_isolation@preservation-s3@vcs0.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl3/igt@gem_ctx_isolation@preservation-s3@vcs0.html
* igt@gem_ctx_persistence@many-contexts:
- {shard-rkl}: [FAIL][83] ([i915#2410]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@gem_ctx_persistence@many-contexts.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-1/igt@gem_ctx_persistence@many-contexts.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [TIMEOUT][85] ([i915#2369] / [i915#3063] / [i915#3648]) -> [PASS][86]
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb5/igt@gem_eio@unwedge-stress.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb1/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk: [FAIL][87] ([i915#2842]) -> [PASS][88]
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk7/igt@gem_exec_fair@basic-none-vip@rcs0.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-glk5/igt@gem_exec_fair@basic-none-vip@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [FAIL][89] ([i915#2842]) -> [PASS][90] +2 similar issues
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb1/igt@gem_exec_fair@basic-pace-share@rcs0.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}: [FAIL][91] ([i915#2842]) -> [PASS][92]
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-6/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-2/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl: [FAIL][93] ([i915#2842]) -> [PASS][94]
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-kbl7/igt@gem_exec_fair@basic-pace@rcs0.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-kbl3/igt@gem_exec_fair@basic-pace@rcs0.html
* igt@gem_exec_schedule@submit-early-slice@vcs1:
- shard-tglb: [INCOMPLETE][95] ([i915#3797]) -> [PASS][96]
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-tglb7/igt@gem_exec_schedule@submit-early-slice@vcs1.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-tglb8/igt@gem_exec_schedule@submit-early-slice@vcs1.html
* igt@gem_exec_suspend@basic-s4-devices:
- {shard-rkl}: [INCOMPLETE][97] ([i915#3189] / [i915#3810]) -> [PASS][98]
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-2/igt@gem_exec_suspend@basic-s4-devices.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-1/igt@gem_exec_suspend@basic-s4-devices.html
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
- {shard-rkl}: [FAIL][99] ([i915#307]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-2/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
* igt@gem_mmap_offset@clear:
- shard-iclb: [FAIL][101] ([i915#3160]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb5/igt@gem_mmap_offset@clear.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb7/igt@gem_mmap_offset@clear.html
* igt@i915_pm_backlight@basic-brightness:
- {shard-rkl}: [SKIP][103] ([i915#3012]) -> [PASS][104]
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@i915_pm_backlight@basic-brightness.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@i915_pm_backlight@basic-brightness.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- {shard-rkl}: [SKIP][105] ([i915#1397]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-2/igt@i915_pm_rpm@modeset-lpsp-stress.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@i915_pm_rpm@modeset-lpsp-stress.html
* igt@kms_big_fb@y-tiled-16bpp-rotate-180:
- {shard-rkl}: [SKIP][107] ([i915#3638]) -> [PASS][108] +3 similar issues
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_big_fb@y-tiled-16bpp-rotate-180.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_big_fb@y-tiled-16bpp-rotate-180.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0:
- {shard-rkl}: [SKIP][109] ([i915#3721]) -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_color@pipe-b-ctm-max:
- {shard-rkl}: [SKIP][111] ([i915#1149] / [i915#1849] / [i915#4070]) -> [PASS][112] +1 similar issue
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_color@pipe-b-ctm-max.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_color@pipe-b-ctm-max.html
* igt@kms_color@pipe-c-ctm-0-75:
- shard-skl: [DMESG-WARN][113] ([i915#1982]) -> [PASS][114]
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl6/igt@kms_color@pipe-c-ctm-0-75.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl8/igt@kms_color@pipe-c-ctm-0-75.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding:
- {shard-rkl}: [SKIP][115] ([fdo#112022] / [i915#4070]) -> [PASS][116] +4 similar issues
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-apl: [DMESG-WARN][117] ([i915#180]) -> [PASS][118] +1 similar issue
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-apl2/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-apl3/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
- {shard-rkl}: [SKIP][119] ([fdo#111825] / [i915#4070]) -> [PASS][120] +5 similar issues
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-2/igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic.html
* igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl: [FAIL][121] ([i915#2346]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl7/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
* igt@kms_draw_crc@draw-method-xrgb8888-blt-ytiled:
- {shard-rkl}: [SKIP][123] ([fdo#111314]) -> [PASS][124] +3 similar issues
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_draw_crc@draw-method-xrgb8888-blt-ytiled.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_draw_crc@draw-method-xrgb8888-blt-ytiled.html
* igt@kms_fbcon_fbt@fbc-suspend:
- {shard-rkl}: [SKIP][125] ([i915#1849]) -> [PASS][126] +20 similar issues
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-2/igt@kms_fbcon_fbt@fbc-suspend.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [FAIL][127] ([i915#79]) -> [PASS][128] +1 similar issue
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl3/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl9/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1:
- shard-skl: [FAIL][129] ([i915#2122]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl10/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl3/igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1:
- shard-glk: [FAIL][131] ([i915#2122]) -> [PASS][132] +1 similar issue
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-glk2/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-glk2/igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1.html
* igt@kms_plane@plane-position-covered@pipe-b-planes:
- {shard-rkl}: [SKIP][133] ([i915#3558]) -> [PASS][134] +1 similar issue
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_plane@plane-position-covered@pipe-b-planes.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_plane@plane-position-covered@pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][135] ([fdo#108145] / [i915#265]) -> [PASS][136]
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- {shard-rkl}: [SKIP][137] ([i915#3558] / [i915#4070]) -> [PASS][138]
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_plane_multiple@atomic-pipe-a-tiling-y.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_plane_multiple@atomic-pipe-a-tiling-y.html
* igt@kms_psr@primary_blt:
- {shard-rkl}: [SKIP][139] ([i915#1072]) -> [PASS][140] +1 similar issue
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_psr@primary_blt.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_psr@primary_blt.html
* igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: [SKIP][141] ([fdo#109441]) -> [PASS][142] +1 similar issue
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb1/igt@kms_psr@psr2_primary_mmap_gtt.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html
* igt@kms_vblank@pipe-a-ts-continuation-modeset:
- {shard-rkl}: [SKIP][143] ([i915#1845]) -> [PASS][144] +11 similar issues
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-rkl-1/igt@kms_vblank@pipe-a-ts-continuation-modeset.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/shard-rkl-6/igt@kms_vblank@pipe-a-ts-continuation-modeset.html
#### Warnings ####
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: [FAIL][145] ([i915#2852]) -> [FAIL][146] ([i915#2842])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10553/shard-iclb7/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[146]: https://intel-
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20969/index.html
[-- Attachment #2: Type: text/html, Size: 33355 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread* Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
2021-09-06 21:38 ` Uma Shankar
@ 2021-10-12 11:55 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 11:55 UTC (permalink / raw)
To: Uma Shankar
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 7039 bytes --]
On Tue, 7 Sep 2021 03:08:42 +0530
Uma Shankar <uma.shankar@intel.com> wrote:
> This is how a typical display color hardware pipeline looks like:
> +-------------------------------------------+
> | RAM |
> | +------+ +---------+ +---------+ |
> | | FB 1 | | FB 2 | | FB N | |
> | +------+ +---------+ +---------+ |
> +-------------------------------------------+
> | Plane Color Hardware Block |
> +--------------------------------------------+
> | +---v-----+ +---v-------+ +---v------+ |
> | | Plane A | | Plane B | | Plane N | |
> | | DeGamma | | Degamma | | Degamma | |
> | +---+-----+ +---+-------+ +---+------+ |
> | | | | |
> | +---v-----+ +---v-------+ +---v------+ |
> | |Plane A | | Plane B | | Plane N | |
> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> | +---+-----+ +----+------+ +----+-----+ |
> | | | | |
> | +---v-----+ +----v------+ +----v-----+ |
> | | Plane A | | Plane B | | Plane N | |
> | | Gamma | | Gamma | | Gamma | |
> | +---+-----+ +----+------+ +----+-----+ |
> | | | | |
> +--------------------------------------------+
> +------v--------------v---------------v-------|
> || ||
> || Pipe Blender ||
> +--------------------+------------------------+
> | | |
> | +-----------v----------+ |
> | | Pipe DeGamma | |
> | | | |
> | +-----------+----------+ |
> | | Pipe Color |
> | +-----------v----------+ Hardware |
> | | Pipe CSC/CTM | |
> | | | |
> | +-----------+----------+ |
> | | |
> | +-----------v----------+ |
> | | Pipe Gamma | |
> | | | |
> | +-----------+----------+ |
> | | |
> +---------------------------------------------+
> |
> v
> Pipe Output
>
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data and CSC used for gamut
> conversion. It also includes Gamma support used to again non-linearize
> data as per panel supported color space. These can be utilize by user
> space to convert planes from one format to another, one color space to
> another etc.
>
> Userspace can take smart blending decisions and utilize these hardware
> supported plane color features to get accurate color profile. The same
> can help in consistent color quality from source to panel taking
> advantage of advanced color features in hardware.
>
> These patches add the property interfaces and enable helper functions.
> This series adds Intel's XE_LPD hw specific plane gamma feature. We
> can build up and add other platform/hardware specific implementation
> on top of this series.
>
> Credits: Special mention and credits to Ville Syrjala for coming up
> with a design for this feature and inputs. This series is based on
> his original design and idea.
>
> Note: Userspace support for this new UAPI will be done on Chrome in
> alignment with weston and general opensource community.
> Discussion ongoing with Harry Wentland, Pekka and community on color
> pipeline and UAPI design. Harry's RFC below:
> https://patchwork.freedesktop.org/series/89506/
> We need to converge on a common UAPI interface which caters to
> all the modern color hardware pipelines.
>
> ToDo: State readout for this feature will be added next.
>
> v2: Added UAPI description and added change in the rfc section of
> kernel Documentation folder
Hi,
thank you for this. I do believe the KMS UAPI should expose what
hardware can do (prescribed operations) rather than how they would be
often used (to realize a conversion from one space description to
another). This proposal fits quite nicely with what I have envisioned
for Weston.
I mainly went over the big picture by commenting in detail on the
proposal document, and not looking too carefully at the other
documentation or UAPI details at this time.
Unfortunately I was unable to decipher how userspace is supposed to use
the XE_LPD special gamma features.
Thanks,
pq
>
> Uma Shankar (22):
> drm: RFC for Plane Color Hardware Pipeline
> drm: Add Enhanced Gamma and color lut range attributes
> drm: Add Plane Degamma Mode property
> drm: Add Plane Degamma Lut property
> drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> drm/i915/xelpd: Add register definitions for Plane Degamma
> drm/i915/xelpd: Enable plane color features
> drm/i915/xelpd: Add color capabilities of SDR planes
> drm/i915/xelpd: Program Plane Degamma Registers
> drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> drm/i915/xelpd: Initialize plane color features
> drm/i915/xelpd: Load plane color luts from atomic flip
> drm: Add Plane CTM property
> drm: Add helper to attach Plane ctm property
> drm/i915/xelpd: Define Plane CSC Registers
> drm/i915/xelpd: Enable Plane CSC
> drm: Add Plane Gamma Mode property
> drm: Add Plane Gamma Lut property
> drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> drm/i915/xelpd: Add register definitions for Plane Gamma
> drm/i915/xelpd: Program Plane Gamma Registers
> drm/i915/xelpd: Enable plane gamma
>
> Documentation/gpu/drm-kms.rst | 90 +++
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_color.h | 2 +
> .../drm/i915/display/skl_universal_plane.c | 15 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 81 +++
> include/uapi/drm/drm_mode.h | 58 ++
> 16 files changed, 1337 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2021-10-12 11:55 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-12 11:55 UTC (permalink / raw)
To: Uma Shankar
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
[-- Attachment #1: Type: text/plain, Size: 7039 bytes --]
On Tue, 7 Sep 2021 03:08:42 +0530
Uma Shankar <uma.shankar@intel.com> wrote:
> This is how a typical display color hardware pipeline looks like:
> +-------------------------------------------+
> | RAM |
> | +------+ +---------+ +---------+ |
> | | FB 1 | | FB 2 | | FB N | |
> | +------+ +---------+ +---------+ |
> +-------------------------------------------+
> | Plane Color Hardware Block |
> +--------------------------------------------+
> | +---v-----+ +---v-------+ +---v------+ |
> | | Plane A | | Plane B | | Plane N | |
> | | DeGamma | | Degamma | | Degamma | |
> | +---+-----+ +---+-------+ +---+------+ |
> | | | | |
> | +---v-----+ +---v-------+ +---v------+ |
> | |Plane A | | Plane B | | Plane N | |
> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> | +---+-----+ +----+------+ +----+-----+ |
> | | | | |
> | +---v-----+ +----v------+ +----v-----+ |
> | | Plane A | | Plane B | | Plane N | |
> | | Gamma | | Gamma | | Gamma | |
> | +---+-----+ +----+------+ +----+-----+ |
> | | | | |
> +--------------------------------------------+
> +------v--------------v---------------v-------|
> || ||
> || Pipe Blender ||
> +--------------------+------------------------+
> | | |
> | +-----------v----------+ |
> | | Pipe DeGamma | |
> | | | |
> | +-----------+----------+ |
> | | Pipe Color |
> | +-----------v----------+ Hardware |
> | | Pipe CSC/CTM | |
> | | | |
> | +-----------+----------+ |
> | | |
> | +-----------v----------+ |
> | | Pipe Gamma | |
> | | | |
> | +-----------+----------+ |
> | | |
> +---------------------------------------------+
> |
> v
> Pipe Output
>
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data and CSC used for gamut
> conversion. It also includes Gamma support used to again non-linearize
> data as per panel supported color space. These can be utilize by user
> space to convert planes from one format to another, one color space to
> another etc.
>
> Userspace can take smart blending decisions and utilize these hardware
> supported plane color features to get accurate color profile. The same
> can help in consistent color quality from source to panel taking
> advantage of advanced color features in hardware.
>
> These patches add the property interfaces and enable helper functions.
> This series adds Intel's XE_LPD hw specific plane gamma feature. We
> can build up and add other platform/hardware specific implementation
> on top of this series.
>
> Credits: Special mention and credits to Ville Syrjala for coming up
> with a design for this feature and inputs. This series is based on
> his original design and idea.
>
> Note: Userspace support for this new UAPI will be done on Chrome in
> alignment with weston and general opensource community.
> Discussion ongoing with Harry Wentland, Pekka and community on color
> pipeline and UAPI design. Harry's RFC below:
> https://patchwork.freedesktop.org/series/89506/
> We need to converge on a common UAPI interface which caters to
> all the modern color hardware pipelines.
>
> ToDo: State readout for this feature will be added next.
>
> v2: Added UAPI description and added change in the rfc section of
> kernel Documentation folder
Hi,
thank you for this. I do believe the KMS UAPI should expose what
hardware can do (prescribed operations) rather than how they would be
often used (to realize a conversion from one space description to
another). This proposal fits quite nicely with what I have envisioned
for Weston.
I mainly went over the big picture by commenting in detail on the
proposal document, and not looking too carefully at the other
documentation or UAPI details at this time.
Unfortunately I was unable to decipher how userspace is supposed to use
the XE_LPD special gamma features.
Thanks,
pq
>
> Uma Shankar (22):
> drm: RFC for Plane Color Hardware Pipeline
> drm: Add Enhanced Gamma and color lut range attributes
> drm: Add Plane Degamma Mode property
> drm: Add Plane Degamma Lut property
> drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> drm/i915/xelpd: Add register definitions for Plane Degamma
> drm/i915/xelpd: Enable plane color features
> drm/i915/xelpd: Add color capabilities of SDR planes
> drm/i915/xelpd: Program Plane Degamma Registers
> drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> drm/i915/xelpd: Initialize plane color features
> drm/i915/xelpd: Load plane color luts from atomic flip
> drm: Add Plane CTM property
> drm: Add helper to attach Plane ctm property
> drm/i915/xelpd: Define Plane CSC Registers
> drm/i915/xelpd: Enable Plane CSC
> drm: Add Plane Gamma Mode property
> drm: Add Plane Gamma Lut property
> drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> drm/i915/xelpd: Add register definitions for Plane Gamma
> drm/i915/xelpd: Program Plane Gamma Registers
> drm/i915/xelpd: Enable plane gamma
>
> Documentation/gpu/drm-kms.rst | 90 +++
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_color.h | 2 +
> .../drm/i915/display/skl_universal_plane.c | 15 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 81 +++
> include/uapi/drm/drm_mode.h | 58 ++
> 16 files changed, 1337 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
2021-10-12 11:55 ` [Intel-gfx] " Pekka Paalanen
@ 2021-10-12 21:01 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 21:01 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 5:25 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>
> On Tue, 7 Sep 2021 03:08:42 +0530
> Uma Shankar <uma.shankar@intel.com> wrote:
>
> > This is how a typical display color hardware pipeline looks like:
> > +-------------------------------------------+
> > | RAM |
> > | +------+ +---------+ +---------+ |
> > | | FB 1 | | FB 2 | | FB N | |
> > | +------+ +---------+ +---------+ |
> > +-------------------------------------------+
> > | Plane Color Hardware Block |
> > +--------------------------------------------+
> > | +---v-----+ +---v-------+ +---v------+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | DeGamma | | Degamma | | Degamma | |
> > | +---+-----+ +---+-------+ +---+------+ |
> > | | | | |
> > | +---v-----+ +---v-------+ +---v------+ |
> > | |Plane A | | Plane B | | Plane N | |
> > | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > | +---+-----+ +----+------+ +----+-----+ |
> > | | | | |
> > | +---v-----+ +----v------+ +----v-----+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | Gamma | | Gamma | | Gamma | |
> > | +---+-----+ +----+------+ +----+-----+ |
> > | | | | |
> > +--------------------------------------------+
> > +------v--------------v---------------v-------|
> > || ||
> > || Pipe Blender ||
> > +--------------------+------------------------+
> > | | |
> > | +-----------v----------+ |
> > | | Pipe DeGamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | Pipe Color |
> > | +-----------v----------+ Hardware |
> > | | Pipe CSC/CTM | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > | +-----------v----------+ |
> > | | Pipe Gamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > +---------------------------------------------+
> > |
> > v
> > Pipe Output
> >
> > This patch series adds properties for plane color features. It adds
> > properties for degamma used to linearize data and CSC used for gamut
> > conversion. It also includes Gamma support used to again non-linearize
> > data as per panel supported color space. These can be utilize by user
> > space to convert planes from one format to another, one color space to
> > another etc.
> >
> > Userspace can take smart blending decisions and utilize these hardware
> > supported plane color features to get accurate color profile. The same
> > can help in consistent color quality from source to panel taking
> > advantage of advanced color features in hardware.
> >
> > These patches add the property interfaces and enable helper functions.
> > This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > can build up and add other platform/hardware specific implementation
> > on top of this series.
> >
> > Credits: Special mention and credits to Ville Syrjala for coming up
> > with a design for this feature and inputs. This series is based on his
> > original design and idea.
> >
> > Note: Userspace support for this new UAPI will be done on Chrome in
> > alignment with weston and general opensource community.
> > Discussion ongoing with Harry Wentland, Pekka and community on color
> > pipeline and UAPI design. Harry's RFC below:
> > https://patchwork.freedesktop.org/series/89506/
> > We need to converge on a common UAPI interface which caters to all the
> > modern color hardware pipelines.
> >
> > ToDo: State readout for this feature will be added next.
> >
> > v2: Added UAPI description and added change in the rfc section of
> > kernel Documentation folder
>
> Hi,
>
> thank you for this. I do believe the KMS UAPI should expose what hardware can do
> (prescribed operations) rather than how they would be often used (to realize a
> conversion from one space description to another). This proposal fits quite nicely
> with what I have envisioned for Weston.
> I mainly went over the big picture by commenting in detail on the proposal
> document, and not looking too carefully at the other documentation or UAPI details
> at this time.
Thanks Pekka for the feedback.
> Unfortunately I was unable to decipher how userspace is supposed to use the
> XE_LPD special gamma features.
I will include the details on how userspace should actually get this through a sample
IGT reference, that should help make this clear.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> >
> > Uma Shankar (22):
> > drm: RFC for Plane Color Hardware Pipeline
> > drm: Add Enhanced Gamma and color lut range attributes
> > drm: Add Plane Degamma Mode property
> > drm: Add Plane Degamma Lut property
> > drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> > drm/i915/xelpd: Add register definitions for Plane Degamma
> > drm/i915/xelpd: Enable plane color features
> > drm/i915/xelpd: Add color capabilities of SDR planes
> > drm/i915/xelpd: Program Plane Degamma Registers
> > drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> > drm/i915/xelpd: Initialize plane color features
> > drm/i915/xelpd: Load plane color luts from atomic flip
> > drm: Add Plane CTM property
> > drm: Add helper to attach Plane ctm property
> > drm/i915/xelpd: Define Plane CSC Registers
> > drm/i915/xelpd: Enable Plane CSC
> > drm: Add Plane Gamma Mode property
> > drm: Add Plane Gamma Lut property
> > drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> > drm/i915/xelpd: Add register definitions for Plane Gamma
> > drm/i915/xelpd: Program Plane Gamma Registers
> > drm/i915/xelpd: Enable plane gamma
> >
> > Documentation/gpu/drm-kms.rst | 90 +++
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> > drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> > drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> > drivers/gpu/drm/i915/display/intel_color.h | 2 +
> > .../drm/i915/display/skl_universal_plane.c | 15 +-
> > drivers/gpu/drm/i915/i915_drv.h | 3 +
> > drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 81 +++
> > include/uapi/drm/drm_mode.h | 58 ++
> > 16 files changed, 1337 insertions(+), 6 deletions(-) create mode
> > 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2021-10-12 21:01 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2021-10-12 21:01 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-gfx, dri-devel, harry.wentland, ville.syrjala,
brian.starkey, sebastian, Shashank.Sharma
> -----Original Message-----
> From: Pekka Paalanen <ppaalanen@gmail.com>
> Sent: Tuesday, October 12, 2021 5:25 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>
> On Tue, 7 Sep 2021 03:08:42 +0530
> Uma Shankar <uma.shankar@intel.com> wrote:
>
> > This is how a typical display color hardware pipeline looks like:
> > +-------------------------------------------+
> > | RAM |
> > | +------+ +---------+ +---------+ |
> > | | FB 1 | | FB 2 | | FB N | |
> > | +------+ +---------+ +---------+ |
> > +-------------------------------------------+
> > | Plane Color Hardware Block |
> > +--------------------------------------------+
> > | +---v-----+ +---v-------+ +---v------+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | DeGamma | | Degamma | | Degamma | |
> > | +---+-----+ +---+-------+ +---+------+ |
> > | | | | |
> > | +---v-----+ +---v-------+ +---v------+ |
> > | |Plane A | | Plane B | | Plane N | |
> > | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > | +---+-----+ +----+------+ +----+-----+ |
> > | | | | |
> > | +---v-----+ +----v------+ +----v-----+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | Gamma | | Gamma | | Gamma | |
> > | +---+-----+ +----+------+ +----+-----+ |
> > | | | | |
> > +--------------------------------------------+
> > +------v--------------v---------------v-------|
> > || ||
> > || Pipe Blender ||
> > +--------------------+------------------------+
> > | | |
> > | +-----------v----------+ |
> > | | Pipe DeGamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | Pipe Color |
> > | +-----------v----------+ Hardware |
> > | | Pipe CSC/CTM | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > | +-----------v----------+ |
> > | | Pipe Gamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > +---------------------------------------------+
> > |
> > v
> > Pipe Output
> >
> > This patch series adds properties for plane color features. It adds
> > properties for degamma used to linearize data and CSC used for gamut
> > conversion. It also includes Gamma support used to again non-linearize
> > data as per panel supported color space. These can be utilize by user
> > space to convert planes from one format to another, one color space to
> > another etc.
> >
> > Userspace can take smart blending decisions and utilize these hardware
> > supported plane color features to get accurate color profile. The same
> > can help in consistent color quality from source to panel taking
> > advantage of advanced color features in hardware.
> >
> > These patches add the property interfaces and enable helper functions.
> > This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > can build up and add other platform/hardware specific implementation
> > on top of this series.
> >
> > Credits: Special mention and credits to Ville Syrjala for coming up
> > with a design for this feature and inputs. This series is based on his
> > original design and idea.
> >
> > Note: Userspace support for this new UAPI will be done on Chrome in
> > alignment with weston and general opensource community.
> > Discussion ongoing with Harry Wentland, Pekka and community on color
> > pipeline and UAPI design. Harry's RFC below:
> > https://patchwork.freedesktop.org/series/89506/
> > We need to converge on a common UAPI interface which caters to all the
> > modern color hardware pipelines.
> >
> > ToDo: State readout for this feature will be added next.
> >
> > v2: Added UAPI description and added change in the rfc section of
> > kernel Documentation folder
>
> Hi,
>
> thank you for this. I do believe the KMS UAPI should expose what hardware can do
> (prescribed operations) rather than how they would be often used (to realize a
> conversion from one space description to another). This proposal fits quite nicely
> with what I have envisioned for Weston.
> I mainly went over the big picture by commenting in detail on the proposal
> document, and not looking too carefully at the other documentation or UAPI details
> at this time.
Thanks Pekka for the feedback.
> Unfortunately I was unable to decipher how userspace is supposed to use the
> XE_LPD special gamma features.
I will include the details on how userspace should actually get this through a sample
IGT reference, that should help make this clear.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> >
> > Uma Shankar (22):
> > drm: RFC for Plane Color Hardware Pipeline
> > drm: Add Enhanced Gamma and color lut range attributes
> > drm: Add Plane Degamma Mode property
> > drm: Add Plane Degamma Lut property
> > drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> > drm/i915/xelpd: Add register definitions for Plane Degamma
> > drm/i915/xelpd: Enable plane color features
> > drm/i915/xelpd: Add color capabilities of SDR planes
> > drm/i915/xelpd: Program Plane Degamma Registers
> > drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> > drm/i915/xelpd: Initialize plane color features
> > drm/i915/xelpd: Load plane color luts from atomic flip
> > drm: Add Plane CTM property
> > drm: Add helper to attach Plane ctm property
> > drm/i915/xelpd: Define Plane CSC Registers
> > drm/i915/xelpd: Enable Plane CSC
> > drm: Add Plane Gamma Mode property
> > drm: Add Plane Gamma Lut property
> > drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> > drm/i915/xelpd: Add register definitions for Plane Gamma
> > drm/i915/xelpd: Program Plane Gamma Registers
> > drm/i915/xelpd: Enable plane gamma
> >
> > Documentation/gpu/drm-kms.rst | 90 +++
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> > drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> > drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> > drivers/gpu/drm/i915/display/intel_color.h | 2 +
> > .../drm/i915/display/skl_universal_plane.c | 15 +-
> > drivers/gpu/drm/i915/i915_drv.h | 3 +
> > drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 81 +++
> > include/uapi/drm/drm_mode.h | 58 ++
> > 16 files changed, 1337 insertions(+), 6 deletions(-) create mode
> > 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
2021-10-12 21:01 ` [Intel-gfx] " Shankar, Uma
@ 2021-10-26 15:02 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:02 UTC (permalink / raw)
To: Shankar, Uma, Pekka Paalanen
Cc: intel-gfx, dri-devel, ville.syrjala, brian.starkey, sebastian,
Shashank.Sharma, Cyr, Aric, Vitaly Prosyak
On 2021-10-12 17:01, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Pekka Paalanen <ppaalanen@gmail.com>
>> Sent: Tuesday, October 12, 2021 5:25 PM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>>
>> On Tue, 7 Sep 2021 03:08:42 +0530
>> Uma Shankar <uma.shankar@intel.com> wrote:
>>
>>> This is how a typical display color hardware pipeline looks like:
>>> +-------------------------------------------+
>>> | RAM |
>>> | +------+ +---------+ +---------+ |
>>> | | FB 1 | | FB 2 | | FB N | |
>>> | +------+ +---------+ +---------+ |
>>> +-------------------------------------------+
>>> | Plane Color Hardware Block |
>>> +--------------------------------------------+
>>> | +---v-----+ +---v-------+ +---v------+ |
>>> | | Plane A | | Plane B | | Plane N | |
>>> | | DeGamma | | Degamma | | Degamma | |
>>> | +---+-----+ +---+-------+ +---+------+ |
>>> | | | | |
>>> | +---v-----+ +---v-------+ +---v------+ |
>>> | |Plane A | | Plane B | | Plane N | |
>>> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
>>> | +---+-----+ +----+------+ +----+-----+ |
>>> | | | | |
>>> | +---v-----+ +----v------+ +----v-----+ |
>>> | | Plane A | | Plane B | | Plane N | |
>>> | | Gamma | | Gamma | | Gamma | |
>>> | +---+-----+ +----+------+ +----+-----+ |
>>> | | | | |
>>> +--------------------------------------------+
>>> +------v--------------v---------------v-------|
>>> || ||
>>> || Pipe Blender ||
>>> +--------------------+------------------------+
>>> | | |
>>> | +-----------v----------+ |
>>> | | Pipe DeGamma | |
>>> | | | |
>>> | +-----------+----------+ |
>>> | | Pipe Color |
>>> | +-----------v----------+ Hardware |
>>> | | Pipe CSC/CTM | |
>>> | | | |
>>> | +-----------+----------+ |
>>> | | |
>>> | +-----------v----------+ |
>>> | | Pipe Gamma | |
>>> | | | |
>>> | +-----------+----------+ |
>>> | | |
>>> +---------------------------------------------+
>>> |
>>> v
>>> Pipe Output
>>>
>>> This patch series adds properties for plane color features. It adds
>>> properties for degamma used to linearize data and CSC used for gamut
>>> conversion. It also includes Gamma support used to again non-linearize
>>> data as per panel supported color space. These can be utilize by user
>>> space to convert planes from one format to another, one color space to
>>> another etc.
>>>
>>> Userspace can take smart blending decisions and utilize these hardware
>>> supported plane color features to get accurate color profile. The same
>>> can help in consistent color quality from source to panel taking
>>> advantage of advanced color features in hardware.
>>>
>>> These patches add the property interfaces and enable helper functions.
>>> This series adds Intel's XE_LPD hw specific plane gamma feature. We
>>> can build up and add other platform/hardware specific implementation
>>> on top of this series.
>>>
>>> Credits: Special mention and credits to Ville Syrjala for coming up
>>> with a design for this feature and inputs. This series is based on his
>>> original design and idea.
>>>
>>> Note: Userspace support for this new UAPI will be done on Chrome in
>>> alignment with weston and general opensource community.
>>> Discussion ongoing with Harry Wentland, Pekka and community on color
>>> pipeline and UAPI design. Harry's RFC below:
>>> https://patchwork.freedesktop.org/series/89506/>>>> We need to converge on a common UAPI interface which caters to all the
>>> modern color hardware pipelines.
>>>
>>> ToDo: State readout for this feature will be added next.
>>>
>>> v2: Added UAPI description and added change in the rfc section of
>>> kernel Documentation folder
>>
>> Hi,
>>
>> thank you for this. I do believe the KMS UAPI should expose what hardware can do
>> (prescribed operations) rather than how they would be often used (to realize a
>> conversion from one space description to another). This proposal fits quite nicely
>> with what I have envisioned for Weston.
>
It's taken me a while but I am starting to agree with the prescriptive approach to
expose HW functionality. One thing we'll want to be careful of is to make sure
this isn't tied to specific HW more than it needs to be. I'll comment in other
places of this patchset to elaborate.
What's making me come around, i.e. change from a prescriptive (these are the
input/output/blending spaces/formats) to a descriptive (these are the LUTs and
CTMs) approach?
1) The prescriptive way has no good way of dealing with gamut and tone mapping.
To do so we would need explicit OOTFs and CTMs or 3D LUTs anyways.
2) The prescriptive way provides no semblance of guarantee that transforms
are equivalent when the compositor uses shaders transforms and composition
vs when the compositor uses KMS transforms and composition.
3) Policy about treatment of surfaces/planes and blending is best left with
the compositor (for the above reasons).
>> I mainly went over the big picture by commenting in detail on the proposal
>> document, and not looking too carefully at the other documentation or UAPI details
>> at this time.
>
> Thanks Pekka for the feedback.
>
>> Unfortunately I was unable to decipher how userspace is supposed to use the
>> XE_LPD special gamma features.
>
> I will include the details on how userspace should actually get this through a sample
> IGT reference, that should help make this clear.
>
It looks like with your current definitions each userspace compositor (Weston, kwin,
mutter, wlroots, Chrome's compositor, Android's compositor, etc.) would need to learn
how to program the XE_LPD LUTs as well as AMD LUTs. Would these definitions change
in future Intel HW generations? Would this mean all compositors would need to learn
again how to program the future LUT format?
Other options would be to give userspace a generic LUT with 4k FP16 entries and then
re-map that to the HW LUT in the kernel driver.
I might be missing some of the nuances of the XE_LPD LUT but it seems to me that the
main difference between different PWL implementations is the distribution of the
points used to define the LUT. Maybe a more generic PWL implementation could have
a kernel driver report one (or more) PWL point distributions. We could encode these
as enums and pre-defined arrays in a UAPI header. That way the compositor could have
a single, generic implementation of programming PWL in FP16 and the kernel driver
would only need to remap the FP16 to the HW-internal format, which is a trivial
conversion. Using this approach compositors would implement PWL support once and won't
have to touch it again in the future. Is there anything that would make this approach
a bad idea for Intel HW (or other HW)? (Credit for this idea goes to Vitaly)
Harry
> Regards,
> Uma Shankar
>
>>
>> Thanks,
>> pq
>>
>>>
>>> Uma Shankar (22):
>>> drm: RFC for Plane Color Hardware Pipeline
>>> drm: Add Enhanced Gamma and color lut range attributes
>>> drm: Add Plane Degamma Mode property
>>> drm: Add Plane Degamma Lut property
>>> drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
>>> drm/i915/xelpd: Add register definitions for Plane Degamma
>>> drm/i915/xelpd: Enable plane color features
>>> drm/i915/xelpd: Add color capabilities of SDR planes
>>> drm/i915/xelpd: Program Plane Degamma Registers
>>> drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
>>> drm/i915/xelpd: Initialize plane color features
>>> drm/i915/xelpd: Load plane color luts from atomic flip
>>> drm: Add Plane CTM property
>>> drm: Add helper to attach Plane ctm property
>>> drm/i915/xelpd: Define Plane CSC Registers
>>> drm/i915/xelpd: Enable Plane CSC
>>> drm: Add Plane Gamma Mode property
>>> drm: Add Plane Gamma Lut property
>>> drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
>>> drm/i915/xelpd: Add register definitions for Plane Gamma
>>> drm/i915/xelpd: Program Plane Gamma Registers
>>> drm/i915/xelpd: Enable plane gamma
>>>
>>> Documentation/gpu/drm-kms.rst | 90 +++
>>> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
>>> drivers/gpu/drm/drm_atomic.c | 1 +
>>> drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
>>> drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
>>> drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
>>> .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
>>> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
>>> drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
>>> drivers/gpu/drm/i915/display/intel_color.h | 2 +
>>> .../drm/i915/display/skl_universal_plane.c | 15 +-
>>> drivers/gpu/drm/i915/i915_drv.h | 3 +
>>> drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
>>> include/drm/drm_mode_object.h | 2 +-
>>> include/drm/drm_plane.h | 81 +++
>>> include/uapi/drm/drm_mode.h | 58 ++
>>> 16 files changed, 1337 insertions(+), 6 deletions(-) create mode
>>> 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2021-10-26 15:02 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2021-10-26 15:02 UTC (permalink / raw)
To: Shankar, Uma, Pekka Paalanen
Cc: intel-gfx, dri-devel, ville.syrjala, brian.starkey, sebastian,
Shashank.Sharma, Cyr, Aric, Vitaly Prosyak
On 2021-10-12 17:01, Shankar, Uma wrote:
>
>
>> -----Original Message-----
>> From: Pekka Paalanen <ppaalanen@gmail.com>
>> Sent: Tuesday, October 12, 2021 5:25 PM
>> To: Shankar, Uma <uma.shankar@intel.com>
>> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
>> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
>> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>>
>> On Tue, 7 Sep 2021 03:08:42 +0530
>> Uma Shankar <uma.shankar@intel.com> wrote:
>>
>>> This is how a typical display color hardware pipeline looks like:
>>> +-------------------------------------------+
>>> | RAM |
>>> | +------+ +---------+ +---------+ |
>>> | | FB 1 | | FB 2 | | FB N | |
>>> | +------+ +---------+ +---------+ |
>>> +-------------------------------------------+
>>> | Plane Color Hardware Block |
>>> +--------------------------------------------+
>>> | +---v-----+ +---v-------+ +---v------+ |
>>> | | Plane A | | Plane B | | Plane N | |
>>> | | DeGamma | | Degamma | | Degamma | |
>>> | +---+-----+ +---+-------+ +---+------+ |
>>> | | | | |
>>> | +---v-----+ +---v-------+ +---v------+ |
>>> | |Plane A | | Plane B | | Plane N | |
>>> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
>>> | +---+-----+ +----+------+ +----+-----+ |
>>> | | | | |
>>> | +---v-----+ +----v------+ +----v-----+ |
>>> | | Plane A | | Plane B | | Plane N | |
>>> | | Gamma | | Gamma | | Gamma | |
>>> | +---+-----+ +----+------+ +----+-----+ |
>>> | | | | |
>>> +--------------------------------------------+
>>> +------v--------------v---------------v-------|
>>> || ||
>>> || Pipe Blender ||
>>> +--------------------+------------------------+
>>> | | |
>>> | +-----------v----------+ |
>>> | | Pipe DeGamma | |
>>> | | | |
>>> | +-----------+----------+ |
>>> | | Pipe Color |
>>> | +-----------v----------+ Hardware |
>>> | | Pipe CSC/CTM | |
>>> | | | |
>>> | +-----------+----------+ |
>>> | | |
>>> | +-----------v----------+ |
>>> | | Pipe Gamma | |
>>> | | | |
>>> | +-----------+----------+ |
>>> | | |
>>> +---------------------------------------------+
>>> |
>>> v
>>> Pipe Output
>>>
>>> This patch series adds properties for plane color features. It adds
>>> properties for degamma used to linearize data and CSC used for gamut
>>> conversion. It also includes Gamma support used to again non-linearize
>>> data as per panel supported color space. These can be utilize by user
>>> space to convert planes from one format to another, one color space to
>>> another etc.
>>>
>>> Userspace can take smart blending decisions and utilize these hardware
>>> supported plane color features to get accurate color profile. The same
>>> can help in consistent color quality from source to panel taking
>>> advantage of advanced color features in hardware.
>>>
>>> These patches add the property interfaces and enable helper functions.
>>> This series adds Intel's XE_LPD hw specific plane gamma feature. We
>>> can build up and add other platform/hardware specific implementation
>>> on top of this series.
>>>
>>> Credits: Special mention and credits to Ville Syrjala for coming up
>>> with a design for this feature and inputs. This series is based on his
>>> original design and idea.
>>>
>>> Note: Userspace support for this new UAPI will be done on Chrome in
>>> alignment with weston and general opensource community.
>>> Discussion ongoing with Harry Wentland, Pekka and community on color
>>> pipeline and UAPI design. Harry's RFC below:
>>> https://patchwork.freedesktop.org/series/89506/>>>> We need to converge on a common UAPI interface which caters to all the
>>> modern color hardware pipelines.
>>>
>>> ToDo: State readout for this feature will be added next.
>>>
>>> v2: Added UAPI description and added change in the rfc section of
>>> kernel Documentation folder
>>
>> Hi,
>>
>> thank you for this. I do believe the KMS UAPI should expose what hardware can do
>> (prescribed operations) rather than how they would be often used (to realize a
>> conversion from one space description to another). This proposal fits quite nicely
>> with what I have envisioned for Weston.
>
It's taken me a while but I am starting to agree with the prescriptive approach to
expose HW functionality. One thing we'll want to be careful of is to make sure
this isn't tied to specific HW more than it needs to be. I'll comment in other
places of this patchset to elaborate.
What's making me come around, i.e. change from a prescriptive (these are the
input/output/blending spaces/formats) to a descriptive (these are the LUTs and
CTMs) approach?
1) The prescriptive way has no good way of dealing with gamut and tone mapping.
To do so we would need explicit OOTFs and CTMs or 3D LUTs anyways.
2) The prescriptive way provides no semblance of guarantee that transforms
are equivalent when the compositor uses shaders transforms and composition
vs when the compositor uses KMS transforms and composition.
3) Policy about treatment of surfaces/planes and blending is best left with
the compositor (for the above reasons).
>> I mainly went over the big picture by commenting in detail on the proposal
>> document, and not looking too carefully at the other documentation or UAPI details
>> at this time.
>
> Thanks Pekka for the feedback.
>
>> Unfortunately I was unable to decipher how userspace is supposed to use the
>> XE_LPD special gamma features.
>
> I will include the details on how userspace should actually get this through a sample
> IGT reference, that should help make this clear.
>
It looks like with your current definitions each userspace compositor (Weston, kwin,
mutter, wlroots, Chrome's compositor, Android's compositor, etc.) would need to learn
how to program the XE_LPD LUTs as well as AMD LUTs. Would these definitions change
in future Intel HW generations? Would this mean all compositors would need to learn
again how to program the future LUT format?
Other options would be to give userspace a generic LUT with 4k FP16 entries and then
re-map that to the HW LUT in the kernel driver.
I might be missing some of the nuances of the XE_LPD LUT but it seems to me that the
main difference between different PWL implementations is the distribution of the
points used to define the LUT. Maybe a more generic PWL implementation could have
a kernel driver report one (or more) PWL point distributions. We could encode these
as enums and pre-defined arrays in a UAPI header. That way the compositor could have
a single, generic implementation of programming PWL in FP16 and the kernel driver
would only need to remap the FP16 to the HW-internal format, which is a trivial
conversion. Using this approach compositors would implement PWL support once and won't
have to touch it again in the future. Is there anything that would make this approach
a bad idea for Intel HW (or other HW)? (Credit for this idea goes to Vitaly)
Harry
> Regards,
> Uma Shankar
>
>>
>> Thanks,
>> pq
>>
>>>
>>> Uma Shankar (22):
>>> drm: RFC for Plane Color Hardware Pipeline
>>> drm: Add Enhanced Gamma and color lut range attributes
>>> drm: Add Plane Degamma Mode property
>>> drm: Add Plane Degamma Lut property
>>> drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
>>> drm/i915/xelpd: Add register definitions for Plane Degamma
>>> drm/i915/xelpd: Enable plane color features
>>> drm/i915/xelpd: Add color capabilities of SDR planes
>>> drm/i915/xelpd: Program Plane Degamma Registers
>>> drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
>>> drm/i915/xelpd: Initialize plane color features
>>> drm/i915/xelpd: Load plane color luts from atomic flip
>>> drm: Add Plane CTM property
>>> drm: Add helper to attach Plane ctm property
>>> drm/i915/xelpd: Define Plane CSC Registers
>>> drm/i915/xelpd: Enable Plane CSC
>>> drm: Add Plane Gamma Mode property
>>> drm: Add Plane Gamma Lut property
>>> drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
>>> drm/i915/xelpd: Add register definitions for Plane Gamma
>>> drm/i915/xelpd: Program Plane Gamma Registers
>>> drm/i915/xelpd: Enable plane gamma
>>>
>>> Documentation/gpu/drm-kms.rst | 90 +++
>>> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
>>> drivers/gpu/drm/drm_atomic.c | 1 +
>>> drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
>>> drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
>>> drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
>>> .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
>>> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
>>> drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
>>> drivers/gpu/drm/i915/display/intel_color.h | 2 +
>>> .../drm/i915/display/skl_universal_plane.c | 15 +-
>>> drivers/gpu/drm/i915/i915_drv.h | 3 +
>>> drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
>>> include/drm/drm_mode_object.h | 2 +-
>>> include/drm/drm_plane.h | 81 +++
>>> include/uapi/drm/drm_mode.h | 58 ++
>>> 16 files changed, 1337 insertions(+), 6 deletions(-) create mode
>>> 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>>>
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
2021-10-26 15:02 ` [Intel-gfx] " Harry Wentland
@ 2021-10-27 8:18 ` Pekka Paalanen
-1 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-27 8:18 UTC (permalink / raw)
To: Harry Wentland
Cc: Shankar, Uma, intel-gfx, dri-devel, ville.syrjala, brian.starkey,
sebastian, Shashank.Sharma, Cyr, Aric, Vitaly Prosyak
[-- Attachment #1: Type: text/plain, Size: 9704 bytes --]
On Tue, 26 Oct 2021 11:02:31 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-10-12 17:01, Shankar, Uma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Pekka Paalanen <ppaalanen@gmail.com>
> >> Sent: Tuesday, October 12, 2021 5:25 PM
> >> To: Shankar, Uma <uma.shankar@intel.com>
> >> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> >> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
> >>
> >> On Tue, 7 Sep 2021 03:08:42 +0530
> >> Uma Shankar <uma.shankar@intel.com> wrote:
> >>
> >>> This is how a typical display color hardware pipeline looks like:
> >>> +-------------------------------------------+
> >>> | RAM |
> >>> | +------+ +---------+ +---------+ |
> >>> | | FB 1 | | FB 2 | | FB N | |
> >>> | +------+ +---------+ +---------+ |
> >>> +-------------------------------------------+
> >>> | Plane Color Hardware Block |
> >>> +--------------------------------------------+
> >>> | +---v-----+ +---v-------+ +---v------+ |
> >>> | | Plane A | | Plane B | | Plane N | |
> >>> | | DeGamma | | Degamma | | Degamma | |
> >>> | +---+-----+ +---+-------+ +---+------+ |
> >>> | | | | |
> >>> | +---v-----+ +---v-------+ +---v------+ |
> >>> | |Plane A | | Plane B | | Plane N | |
> >>> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> >>> | +---+-----+ +----+------+ +----+-----+ |
> >>> | | | | |
> >>> | +---v-----+ +----v------+ +----v-----+ |
> >>> | | Plane A | | Plane B | | Plane N | |
> >>> | | Gamma | | Gamma | | Gamma | |
> >>> | +---+-----+ +----+------+ +----+-----+ |
> >>> | | | | |
> >>> +--------------------------------------------+
> >>> +------v--------------v---------------v-------|
> >>> || ||
> >>> || Pipe Blender ||
> >>> +--------------------+------------------------+
> >>> | | |
> >>> | +-----------v----------+ |
> >>> | | Pipe DeGamma | |
> >>> | | | |
> >>> | +-----------+----------+ |
> >>> | | Pipe Color |
> >>> | +-----------v----------+ Hardware |
> >>> | | Pipe CSC/CTM | |
> >>> | | | |
> >>> | +-----------+----------+ |
> >>> | | |
> >>> | +-----------v----------+ |
> >>> | | Pipe Gamma | |
> >>> | | | |
> >>> | +-----------+----------+ |
> >>> | | |
> >>> +---------------------------------------------+
> >>> |
> >>> v
> >>> Pipe Output
> >>>
> >>> This patch series adds properties for plane color features. It adds
> >>> properties for degamma used to linearize data and CSC used for gamut
> >>> conversion. It also includes Gamma support used to again non-linearize
> >>> data as per panel supported color space. These can be utilize by user
> >>> space to convert planes from one format to another, one color space to
> >>> another etc.
> >>>
> >>> Userspace can take smart blending decisions and utilize these hardware
> >>> supported plane color features to get accurate color profile. The same
> >>> can help in consistent color quality from source to panel taking
> >>> advantage of advanced color features in hardware.
> >>>
> >>> These patches add the property interfaces and enable helper functions.
> >>> This series adds Intel's XE_LPD hw specific plane gamma feature. We
> >>> can build up and add other platform/hardware specific implementation
> >>> on top of this series.
> >>>
> >>> Credits: Special mention and credits to Ville Syrjala for coming up
> >>> with a design for this feature and inputs. This series is based on his
> >>> original design and idea.
> >>>
> >>> Note: Userspace support for this new UAPI will be done on Chrome in
> >>> alignment with weston and general opensource community.
> >>> Discussion ongoing with Harry Wentland, Pekka and community on color
> >>> pipeline and UAPI design. Harry's RFC below:
> >>> https://patchwork.freedesktop.org/series/89506/>>>> We need to converge on a common UAPI interface which caters to all the
> >>> modern color hardware pipelines.
> >>>
> >>> ToDo: State readout for this feature will be added next.
> >>>
> >>> v2: Added UAPI description and added change in the rfc section of
> >>> kernel Documentation folder
> >>
> >> Hi,
> >>
> >> thank you for this. I do believe the KMS UAPI should expose what hardware can do
> >> (prescribed operations) rather than how they would be often used (to realize a
> >> conversion from one space description to another). This proposal fits quite nicely
> >> with what I have envisioned for Weston.
> >
>
> It's taken me a while but I am starting to agree with the prescriptive approach to
> expose HW functionality. One thing we'll want to be careful of is to make sure
> this isn't tied to specific HW more than it needs to be. I'll comment in other
> places of this patchset to elaborate.
>
> What's making me come around, i.e. change from a prescriptive (these are the
> input/output/blending spaces/formats) to a descriptive (these are the LUTs and
> CTMs) approach?
>
> 1) The prescriptive way has no good way of dealing with gamut and tone mapping.
> To do so we would need explicit OOTFs and CTMs or 3D LUTs anyways.
>
> 2) The prescriptive way provides no semblance of guarantee that transforms
> are equivalent when the compositor uses shaders transforms and composition
> vs when the compositor uses KMS transforms and composition.
>
> 3) Policy about treatment of surfaces/planes and blending is best left with
> the compositor (for the above reasons).
Hi Harry,
I think we might have confusion there about prescriptive vs.
descriptive, but I understand what you mean, and yes, those are my
points too.
> >> I mainly went over the big picture by commenting in detail on the proposal
> >> document, and not looking too carefully at the other documentation or UAPI details
> >> at this time.
> >
> > Thanks Pekka for the feedback.
> >
> >> Unfortunately I was unable to decipher how userspace is supposed to use the
> >> XE_LPD special gamma features.
> >
> > I will include the details on how userspace should actually get this through a sample
> > IGT reference, that should help make this clear.
> >
>
> It looks like with your current definitions each userspace compositor (Weston, kwin,
> mutter, wlroots, Chrome's compositor, Android's compositor, etc.) would need to learn
> how to program the XE_LPD LUTs as well as AMD LUTs. Would these definitions change
> in future Intel HW generations? Would this mean all compositors would need to learn
> again how to program the future LUT format?
>
> Other options would be to give userspace a generic LUT with 4k FP16 entries and then
> re-map that to the HW LUT in the kernel driver.
Do you want to run the optimisation algorithm to map the generic LUT to
hardware specific optimised representation in the kernel driver?
Wouldn't that be too much?
To me this seems like the perfect starting point for a libcamera
equivalent to KMS. Feed the generic LUT to the lib, and get whatever
the hardware-driver-specific KMS UAPI needs. Perhaps even with an error
measure, so that a compositor can evaluate whether the mapping is
accurate enough or if it needs to fall back.
> I might be missing some of the nuances of the XE_LPD LUT but it seems to me that the
> main difference between different PWL implementations is the distribution of the
> points used to define the LUT. Maybe a more generic PWL implementation could have
> a kernel driver report one (or more) PWL point distributions. We could encode these
> as enums and pre-defined arrays in a UAPI header. That way the compositor could have
> a single, generic implementation of programming PWL in FP16 and the kernel driver
> would only need to remap the FP16 to the HW-internal format, which is a trivial
> conversion. Using this approach compositors would implement PWL support once and won't
> have to touch it again in the future. Is there anything that would make this approach
> a bad idea for Intel HW (or other HW)? (Credit for this idea goes to Vitaly)
I think that is also a workable solution. If that happens, it seems
likely that a library for that optimisation will appear.
It has just one shortcoming: the compositor has no idea of the
precision as there is no way to get an error measure for how much the
FP16->internal conversion loses precision.
But maybe that is never significant? Or could we have some precision
guarantees otherwise?
I'm thinking of hard-core professional color users who wouldn't
normally trust off-loading to KMS at all, at least not on-demand
off-loading where you are never sure if you are looking at SW or KMS
composition.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2021-10-27 8:18 ` Pekka Paalanen
0 siblings, 0 replies; 154+ messages in thread
From: Pekka Paalanen @ 2021-10-27 8:18 UTC (permalink / raw)
To: Harry Wentland
Cc: Shankar, Uma, intel-gfx, dri-devel, ville.syrjala, brian.starkey,
sebastian, Shashank.Sharma, Cyr, Aric, Vitaly Prosyak
[-- Attachment #1: Type: text/plain, Size: 9704 bytes --]
On Tue, 26 Oct 2021 11:02:31 -0400
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2021-10-12 17:01, Shankar, Uma wrote:
> >
> >
> >> -----Original Message-----
> >> From: Pekka Paalanen <ppaalanen@gmail.com>
> >> Sent: Tuesday, October 12, 2021 5:25 PM
> >> To: Shankar, Uma <uma.shankar@intel.com>
> >> Cc: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >> harry.wentland@amd.com; ville.syrjala@linux.intel.com; brian.starkey@arm.com;
> >> sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> >> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
> >>
> >> On Tue, 7 Sep 2021 03:08:42 +0530
> >> Uma Shankar <uma.shankar@intel.com> wrote:
> >>
> >>> This is how a typical display color hardware pipeline looks like:
> >>> +-------------------------------------------+
> >>> | RAM |
> >>> | +------+ +---------+ +---------+ |
> >>> | | FB 1 | | FB 2 | | FB N | |
> >>> | +------+ +---------+ +---------+ |
> >>> +-------------------------------------------+
> >>> | Plane Color Hardware Block |
> >>> +--------------------------------------------+
> >>> | +---v-----+ +---v-------+ +---v------+ |
> >>> | | Plane A | | Plane B | | Plane N | |
> >>> | | DeGamma | | Degamma | | Degamma | |
> >>> | +---+-----+ +---+-------+ +---+------+ |
> >>> | | | | |
> >>> | +---v-----+ +---v-------+ +---v------+ |
> >>> | |Plane A | | Plane B | | Plane N | |
> >>> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> >>> | +---+-----+ +----+------+ +----+-----+ |
> >>> | | | | |
> >>> | +---v-----+ +----v------+ +----v-----+ |
> >>> | | Plane A | | Plane B | | Plane N | |
> >>> | | Gamma | | Gamma | | Gamma | |
> >>> | +---+-----+ +----+------+ +----+-----+ |
> >>> | | | | |
> >>> +--------------------------------------------+
> >>> +------v--------------v---------------v-------|
> >>> || ||
> >>> || Pipe Blender ||
> >>> +--------------------+------------------------+
> >>> | | |
> >>> | +-----------v----------+ |
> >>> | | Pipe DeGamma | |
> >>> | | | |
> >>> | +-----------+----------+ |
> >>> | | Pipe Color |
> >>> | +-----------v----------+ Hardware |
> >>> | | Pipe CSC/CTM | |
> >>> | | | |
> >>> | +-----------+----------+ |
> >>> | | |
> >>> | +-----------v----------+ |
> >>> | | Pipe Gamma | |
> >>> | | | |
> >>> | +-----------+----------+ |
> >>> | | |
> >>> +---------------------------------------------+
> >>> |
> >>> v
> >>> Pipe Output
> >>>
> >>> This patch series adds properties for plane color features. It adds
> >>> properties for degamma used to linearize data and CSC used for gamut
> >>> conversion. It also includes Gamma support used to again non-linearize
> >>> data as per panel supported color space. These can be utilize by user
> >>> space to convert planes from one format to another, one color space to
> >>> another etc.
> >>>
> >>> Userspace can take smart blending decisions and utilize these hardware
> >>> supported plane color features to get accurate color profile. The same
> >>> can help in consistent color quality from source to panel taking
> >>> advantage of advanced color features in hardware.
> >>>
> >>> These patches add the property interfaces and enable helper functions.
> >>> This series adds Intel's XE_LPD hw specific plane gamma feature. We
> >>> can build up and add other platform/hardware specific implementation
> >>> on top of this series.
> >>>
> >>> Credits: Special mention and credits to Ville Syrjala for coming up
> >>> with a design for this feature and inputs. This series is based on his
> >>> original design and idea.
> >>>
> >>> Note: Userspace support for this new UAPI will be done on Chrome in
> >>> alignment with weston and general opensource community.
> >>> Discussion ongoing with Harry Wentland, Pekka and community on color
> >>> pipeline and UAPI design. Harry's RFC below:
> >>> https://patchwork.freedesktop.org/series/89506/>>>> We need to converge on a common UAPI interface which caters to all the
> >>> modern color hardware pipelines.
> >>>
> >>> ToDo: State readout for this feature will be added next.
> >>>
> >>> v2: Added UAPI description and added change in the rfc section of
> >>> kernel Documentation folder
> >>
> >> Hi,
> >>
> >> thank you for this. I do believe the KMS UAPI should expose what hardware can do
> >> (prescribed operations) rather than how they would be often used (to realize a
> >> conversion from one space description to another). This proposal fits quite nicely
> >> with what I have envisioned for Weston.
> >
>
> It's taken me a while but I am starting to agree with the prescriptive approach to
> expose HW functionality. One thing we'll want to be careful of is to make sure
> this isn't tied to specific HW more than it needs to be. I'll comment in other
> places of this patchset to elaborate.
>
> What's making me come around, i.e. change from a prescriptive (these are the
> input/output/blending spaces/formats) to a descriptive (these are the LUTs and
> CTMs) approach?
>
> 1) The prescriptive way has no good way of dealing with gamut and tone mapping.
> To do so we would need explicit OOTFs and CTMs or 3D LUTs anyways.
>
> 2) The prescriptive way provides no semblance of guarantee that transforms
> are equivalent when the compositor uses shaders transforms and composition
> vs when the compositor uses KMS transforms and composition.
>
> 3) Policy about treatment of surfaces/planes and blending is best left with
> the compositor (for the above reasons).
Hi Harry,
I think we might have confusion there about prescriptive vs.
descriptive, but I understand what you mean, and yes, those are my
points too.
> >> I mainly went over the big picture by commenting in detail on the proposal
> >> document, and not looking too carefully at the other documentation or UAPI details
> >> at this time.
> >
> > Thanks Pekka for the feedback.
> >
> >> Unfortunately I was unable to decipher how userspace is supposed to use the
> >> XE_LPD special gamma features.
> >
> > I will include the details on how userspace should actually get this through a sample
> > IGT reference, that should help make this clear.
> >
>
> It looks like with your current definitions each userspace compositor (Weston, kwin,
> mutter, wlroots, Chrome's compositor, Android's compositor, etc.) would need to learn
> how to program the XE_LPD LUTs as well as AMD LUTs. Would these definitions change
> in future Intel HW generations? Would this mean all compositors would need to learn
> again how to program the future LUT format?
>
> Other options would be to give userspace a generic LUT with 4k FP16 entries and then
> re-map that to the HW LUT in the kernel driver.
Do you want to run the optimisation algorithm to map the generic LUT to
hardware specific optimised representation in the kernel driver?
Wouldn't that be too much?
To me this seems like the perfect starting point for a libcamera
equivalent to KMS. Feed the generic LUT to the lib, and get whatever
the hardware-driver-specific KMS UAPI needs. Perhaps even with an error
measure, so that a compositor can evaluate whether the mapping is
accurate enough or if it needs to fall back.
> I might be missing some of the nuances of the XE_LPD LUT but it seems to me that the
> main difference between different PWL implementations is the distribution of the
> points used to define the LUT. Maybe a more generic PWL implementation could have
> a kernel driver report one (or more) PWL point distributions. We could encode these
> as enums and pre-defined arrays in a UAPI header. That way the compositor could have
> a single, generic implementation of programming PWL in FP16 and the kernel driver
> would only need to remap the FP16 to the HW-internal format, which is a trivial
> conversion. Using this approach compositors would implement PWL support once and won't
> have to touch it again in the future. Is there anything that would make this approach
> a bad idea for Intel HW (or other HW)? (Credit for this idea goes to Vitaly)
I think that is also a workable solution. If that happens, it seems
likely that a library for that optimisation will appear.
It has just one shortcoming: the compositor has no idea of the
precision as there is no way to get an error measure for how much the
FP16->internal conversion loses precision.
But maybe that is never significant? Or could we have some precision
guarantees otherwise?
I'm thinking of hard-core professional color users who wouldn't
normally trust off-loading to KMS at all, at least not on-demand
off-loading where you are never sure if you are looking at SW or KMS
composition.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
2021-09-06 21:38 ` Uma Shankar
@ 2022-02-02 16:11 ` Harry Wentland
-1 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2022-02-02 16:11 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, Shashank.Sharma
On 2021-09-06 17:38, Uma Shankar wrote:
> This is how a typical display color hardware pipeline looks like:
> +-------------------------------------------+
> | RAM |
> | +------+ +---------+ +---------+ |
> | | FB 1 | | FB 2 | | FB N | |
> | +------+ +---------+ +---------+ |
> +-------------------------------------------+
> | Plane Color Hardware Block |
> +--------------------------------------------+
> | +---v-----+ +---v-------+ +---v------+ |
> | | Plane A | | Plane B | | Plane N | |
> | | DeGamma | | Degamma | | Degamma | |
> | +---+-----+ +---+-------+ +---+------+ |
> | | | | |
> | +---v-----+ +---v-------+ +---v------+ |
> | |Plane A | | Plane B | | Plane N | |
> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> | +---+-----+ +----+------+ +----+-----+ |
> | | | | |
> | +---v-----+ +----v------+ +----v-----+ |
> | | Plane A | | Plane B | | Plane N | |
> | | Gamma | | Gamma | | Gamma | |
> | +---+-----+ +----+------+ +----+-----+ |
We've had a number of discussions on naming for these properties but I
don't think we've arrived at a consensus. It has come up repeatedly,
though, that gamma/degamma might be misleading terms.
I've opened a ticket on gitlab to help track this item and would like
it if we could discuss the merits of different naming schemes over
there:
https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7
Uma, I tried to tag you but don't see you on gitlab.freedesktop.org.
Harry
> | | | | |
> +--------------------------------------------+
> +------v--------------v---------------v-------|
> || ||
> || Pipe Blender ||
> +--------------------+------------------------+
> | | |
> | +-----------v----------+ |
> | | Pipe DeGamma | |
> | | | |
> | +-----------+----------+ |
> | | Pipe Color |
> | +-----------v----------+ Hardware |
> | | Pipe CSC/CTM | |
> | | | |
> | +-----------+----------+ |
> | | |
> | +-----------v----------+ |
> | | Pipe Gamma | |
> | | | |
> | +-----------+----------+ |
> | | |
> +---------------------------------------------+
> |
> v
> Pipe Output
>
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data and CSC used for gamut
> conversion. It also includes Gamma support used to again non-linearize
> data as per panel supported color space. These can be utilize by user
> space to convert planes from one format to another, one color space to
> another etc.
>
> Userspace can take smart blending decisions and utilize these hardware
> supported plane color features to get accurate color profile. The same
> can help in consistent color quality from source to panel taking
> advantage of advanced color features in hardware.
>
> These patches add the property interfaces and enable helper functions.
> This series adds Intel's XE_LPD hw specific plane gamma feature. We
> can build up and add other platform/hardware specific implementation
> on top of this series.
>
> Credits: Special mention and credits to Ville Syrjala for coming up
> with a design for this feature and inputs. This series is based on
> his original design and idea.
>
> Note: Userspace support for this new UAPI will be done on Chrome in
> alignment with weston and general opensource community.
> Discussion ongoing with Harry Wentland, Pekka and community on color
> pipeline and UAPI design. Harry's RFC below:
> https://patchwork.freedesktop.org/series/89506/
> We need to converge on a common UAPI interface which caters to
> all the modern color hardware pipelines.
>
> ToDo: State readout for this feature will be added next.
>
> v2: Added UAPI description and added change in the rfc section of
> kernel Documentation folder
>
> Uma Shankar (22):
> drm: RFC for Plane Color Hardware Pipeline
> drm: Add Enhanced Gamma and color lut range attributes
> drm: Add Plane Degamma Mode property
> drm: Add Plane Degamma Lut property
> drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> drm/i915/xelpd: Add register definitions for Plane Degamma
> drm/i915/xelpd: Enable plane color features
> drm/i915/xelpd: Add color capabilities of SDR planes
> drm/i915/xelpd: Program Plane Degamma Registers
> drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> drm/i915/xelpd: Initialize plane color features
> drm/i915/xelpd: Load plane color luts from atomic flip
> drm: Add Plane CTM property
> drm: Add helper to attach Plane ctm property
> drm/i915/xelpd: Define Plane CSC Registers
> drm/i915/xelpd: Enable Plane CSC
> drm: Add Plane Gamma Mode property
> drm: Add Plane Gamma Lut property
> drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> drm/i915/xelpd: Add register definitions for Plane Gamma
> drm/i915/xelpd: Program Plane Gamma Registers
> drm/i915/xelpd: Enable plane gamma
>
> Documentation/gpu/drm-kms.rst | 90 +++
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_color.h | 2 +
> .../drm/i915/display/skl_universal_plane.c | 15 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 81 +++
> include/uapi/drm/drm_mode.h | 58 ++
> 16 files changed, 1337 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2022-02-02 16:11 ` Harry Wentland
0 siblings, 0 replies; 154+ messages in thread
From: Harry Wentland @ 2022-02-02 16:11 UTC (permalink / raw)
To: Uma Shankar, intel-gfx, dri-devel; +Cc: sebastian, ppaalanen
On 2021-09-06 17:38, Uma Shankar wrote:
> This is how a typical display color hardware pipeline looks like:
> +-------------------------------------------+
> | RAM |
> | +------+ +---------+ +---------+ |
> | | FB 1 | | FB 2 | | FB N | |
> | +------+ +---------+ +---------+ |
> +-------------------------------------------+
> | Plane Color Hardware Block |
> +--------------------------------------------+
> | +---v-----+ +---v-------+ +---v------+ |
> | | Plane A | | Plane B | | Plane N | |
> | | DeGamma | | Degamma | | Degamma | |
> | +---+-----+ +---+-------+ +---+------+ |
> | | | | |
> | +---v-----+ +---v-------+ +---v------+ |
> | |Plane A | | Plane B | | Plane N | |
> | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> | +---+-----+ +----+------+ +----+-----+ |
> | | | | |
> | +---v-----+ +----v------+ +----v-----+ |
> | | Plane A | | Plane B | | Plane N | |
> | | Gamma | | Gamma | | Gamma | |
> | +---+-----+ +----+------+ +----+-----+ |
We've had a number of discussions on naming for these properties but I
don't think we've arrived at a consensus. It has come up repeatedly,
though, that gamma/degamma might be misleading terms.
I've opened a ticket on gitlab to help track this item and would like
it if we could discuss the merits of different naming schemes over
there:
https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7
Uma, I tried to tag you but don't see you on gitlab.freedesktop.org.
Harry
> | | | | |
> +--------------------------------------------+
> +------v--------------v---------------v-------|
> || ||
> || Pipe Blender ||
> +--------------------+------------------------+
> | | |
> | +-----------v----------+ |
> | | Pipe DeGamma | |
> | | | |
> | +-----------+----------+ |
> | | Pipe Color |
> | +-----------v----------+ Hardware |
> | | Pipe CSC/CTM | |
> | | | |
> | +-----------+----------+ |
> | | |
> | +-----------v----------+ |
> | | Pipe Gamma | |
> | | | |
> | +-----------+----------+ |
> | | |
> +---------------------------------------------+
> |
> v
> Pipe Output
>
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data and CSC used for gamut
> conversion. It also includes Gamma support used to again non-linearize
> data as per panel supported color space. These can be utilize by user
> space to convert planes from one format to another, one color space to
> another etc.
>
> Userspace can take smart blending decisions and utilize these hardware
> supported plane color features to get accurate color profile. The same
> can help in consistent color quality from source to panel taking
> advantage of advanced color features in hardware.
>
> These patches add the property interfaces and enable helper functions.
> This series adds Intel's XE_LPD hw specific plane gamma feature. We
> can build up and add other platform/hardware specific implementation
> on top of this series.
>
> Credits: Special mention and credits to Ville Syrjala for coming up
> with a design for this feature and inputs. This series is based on
> his original design and idea.
>
> Note: Userspace support for this new UAPI will be done on Chrome in
> alignment with weston and general opensource community.
> Discussion ongoing with Harry Wentland, Pekka and community on color
> pipeline and UAPI design. Harry's RFC below:
> https://patchwork.freedesktop.org/series/89506/
> We need to converge on a common UAPI interface which caters to
> all the modern color hardware pipelines.
>
> ToDo: State readout for this feature will be added next.
>
> v2: Added UAPI description and added change in the rfc section of
> kernel Documentation folder
>
> Uma Shankar (22):
> drm: RFC for Plane Color Hardware Pipeline
> drm: Add Enhanced Gamma and color lut range attributes
> drm: Add Plane Degamma Mode property
> drm: Add Plane Degamma Lut property
> drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> drm/i915/xelpd: Add register definitions for Plane Degamma
> drm/i915/xelpd: Enable plane color features
> drm/i915/xelpd: Add color capabilities of SDR planes
> drm/i915/xelpd: Program Plane Degamma Registers
> drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> drm/i915/xelpd: Initialize plane color features
> drm/i915/xelpd: Load plane color luts from atomic flip
> drm: Add Plane CTM property
> drm: Add helper to attach Plane ctm property
> drm/i915/xelpd: Define Plane CSC Registers
> drm/i915/xelpd: Enable Plane CSC
> drm: Add Plane Gamma Mode property
> drm: Add Plane Gamma Lut property
> drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> drm/i915/xelpd: Add register definitions for Plane Gamma
> drm/i915/xelpd: Program Plane Gamma Registers
> drm/i915/xelpd: Enable plane gamma
>
> Documentation/gpu/drm-kms.rst | 90 +++
> Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_color.h | 2 +
> .../drm/i915/display/skl_universal_plane.c | 15 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 81 +++
> include/uapi/drm/drm_mode.h | 58 ++
> 16 files changed, 1337 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
>
^ permalink raw reply [flat|nested] 154+ messages in thread
* RE: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
2022-02-02 16:11 ` [Intel-gfx] " Harry Wentland
@ 2022-02-03 17:22 ` Shankar, Uma
-1 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2022-02-03 17:22 UTC (permalink / raw)
To: Harry Wentland, intel-gfx, dri-devel; +Cc: sebastian, Shashank.Sharma
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Harry
> Wentland
> Sent: Wednesday, February 2, 2022 9:42 PM
> To: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > This is how a typical display color hardware pipeline looks like:
> > +-------------------------------------------+
> > | RAM |
> > | +------+ +---------+ +---------+ |
> > | | FB 1 | | FB 2 | | FB N | |
> > | +------+ +---------+ +---------+ |
> > +-------------------------------------------+
> > | Plane Color Hardware Block |
> > +--------------------------------------------+
> > | +---v-----+ +---v-------+ +---v------+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | DeGamma | | Degamma | | Degamma | |
> > | +---+-----+ +---+-------+ +---+------+ |
> > | | | | |
> > | +---v-----+ +---v-------+ +---v------+ |
> > | |Plane A | | Plane B | | Plane N | |
> > | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > | +---+-----+ +----+------+ +----+-----+ |
> > | | | | |
> > | +---v-----+ +----v------+ +----v-----+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | Gamma | | Gamma | | Gamma | |
> > | +---+-----+ +----+------+ +----+-----+ |
>
> We've had a number of discussions on naming for these properties but I don't think
> we've arrived at a consensus. It has come up repeatedly, though, that
> gamma/degamma might be misleading terms.
>
> I've opened a ticket on gitlab to help track this item and would like it if we could
> discuss the merits of different naming schemes over
> there:
>
> https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7
>
> Uma, I tried to tag you but don't see you on gitlab.freedesktop.org.
Thanks Harry for creating the issue. I have replied there and we can discuss and
finalize the UAPI.
Regards,
Uma Shankar
> Harry
>
> > | | | | |
> > +--------------------------------------------+
> > +------v--------------v---------------v-------|
> > || ||
> > || Pipe Blender ||
> > +--------------------+------------------------+
> > | | |
> > | +-----------v----------+ |
> > | | Pipe DeGamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | Pipe Color |
> > | +-----------v----------+ Hardware |
> > | | Pipe CSC/CTM | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > | +-----------v----------+ |
> > | | Pipe Gamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > +---------------------------------------------+
> > |
> > v
> > Pipe Output
> >
> > This patch series adds properties for plane color features. It adds
> > properties for degamma used to linearize data and CSC used for gamut
> > conversion. It also includes Gamma support used to again non-linearize
> > data as per panel supported color space. These can be utilize by user
> > space to convert planes from one format to another, one color space to
> > another etc.
> >
> > Userspace can take smart blending decisions and utilize these hardware
> > supported plane color features to get accurate color profile. The same
> > can help in consistent color quality from source to panel taking
> > advantage of advanced color features in hardware.
> >
> > These patches add the property interfaces and enable helper functions.
> > This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > can build up and add other platform/hardware specific implementation
> > on top of this series.
> >
> > Credits: Special mention and credits to Ville Syrjala for coming up
> > with a design for this feature and inputs. This series is based on his
> > original design and idea.
> >
> > Note: Userspace support for this new UAPI will be done on Chrome in
> > alignment with weston and general opensource community.
> > Discussion ongoing with Harry Wentland, Pekka and community on color
> > pipeline and UAPI design. Harry's RFC below:
> > https://patchwork.freedesktop.org/series/89506/
> > We need to converge on a common UAPI interface which caters to all the
> > modern color hardware pipelines.
> >
> > ToDo: State readout for this feature will be added next.
> >
> > v2: Added UAPI description and added change in the rfc section of
> > kernel Documentation folder
> >
> > Uma Shankar (22):
> > drm: RFC for Plane Color Hardware Pipeline
> > drm: Add Enhanced Gamma and color lut range attributes
> > drm: Add Plane Degamma Mode property
> > drm: Add Plane Degamma Lut property
> > drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> > drm/i915/xelpd: Add register definitions for Plane Degamma
> > drm/i915/xelpd: Enable plane color features
> > drm/i915/xelpd: Add color capabilities of SDR planes
> > drm/i915/xelpd: Program Plane Degamma Registers
> > drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> > drm/i915/xelpd: Initialize plane color features
> > drm/i915/xelpd: Load plane color luts from atomic flip
> > drm: Add Plane CTM property
> > drm: Add helper to attach Plane ctm property
> > drm/i915/xelpd: Define Plane CSC Registers
> > drm/i915/xelpd: Enable Plane CSC
> > drm: Add Plane Gamma Mode property
> > drm: Add Plane Gamma Lut property
> > drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> > drm/i915/xelpd: Add register definitions for Plane Gamma
> > drm/i915/xelpd: Program Plane Gamma Registers
> > drm/i915/xelpd: Enable plane gamma
> >
> > Documentation/gpu/drm-kms.rst | 90 +++
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> > drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> > drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> > drivers/gpu/drm/i915/display/intel_color.h | 2 +
> > .../drm/i915/display/skl_universal_plane.c | 15 +-
> > drivers/gpu/drm/i915/i915_drv.h | 3 +
> > drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 81 +++
> > include/uapi/drm/drm_mode.h | 58 ++
> > 16 files changed, 1337 insertions(+), 6 deletions(-) create mode
> > 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
^ permalink raw reply [flat|nested] 154+ messages in thread
* Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
@ 2022-02-03 17:22 ` Shankar, Uma
0 siblings, 0 replies; 154+ messages in thread
From: Shankar, Uma @ 2022-02-03 17:22 UTC (permalink / raw)
To: Harry Wentland, intel-gfx, dri-devel; +Cc: sebastian
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Harry
> Wentland
> Sent: Wednesday, February 2, 2022 9:42 PM
> To: Shankar, Uma <uma.shankar@intel.com>; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: sebastian@sebastianwick.net; Shashank.Sharma@amd.com
> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > This is how a typical display color hardware pipeline looks like:
> > +-------------------------------------------+
> > | RAM |
> > | +------+ +---------+ +---------+ |
> > | | FB 1 | | FB 2 | | FB N | |
> > | +------+ +---------+ +---------+ |
> > +-------------------------------------------+
> > | Plane Color Hardware Block |
> > +--------------------------------------------+
> > | +---v-----+ +---v-------+ +---v------+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | DeGamma | | Degamma | | Degamma | |
> > | +---+-----+ +---+-------+ +---+------+ |
> > | | | | |
> > | +---v-----+ +---v-------+ +---v------+ |
> > | |Plane A | | Plane B | | Plane N | |
> > | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
> > | +---+-----+ +----+------+ +----+-----+ |
> > | | | | |
> > | +---v-----+ +----v------+ +----v-----+ |
> > | | Plane A | | Plane B | | Plane N | |
> > | | Gamma | | Gamma | | Gamma | |
> > | +---+-----+ +----+------+ +----+-----+ |
>
> We've had a number of discussions on naming for these properties but I don't think
> we've arrived at a consensus. It has come up repeatedly, though, that
> gamma/degamma might be misleading terms.
>
> I've opened a ticket on gitlab to help track this item and would like it if we could
> discuss the merits of different naming schemes over
> there:
>
> https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7
>
> Uma, I tried to tag you but don't see you on gitlab.freedesktop.org.
Thanks Harry for creating the issue. I have replied there and we can discuss and
finalize the UAPI.
Regards,
Uma Shankar
> Harry
>
> > | | | | |
> > +--------------------------------------------+
> > +------v--------------v---------------v-------|
> > || ||
> > || Pipe Blender ||
> > +--------------------+------------------------+
> > | | |
> > | +-----------v----------+ |
> > | | Pipe DeGamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | Pipe Color |
> > | +-----------v----------+ Hardware |
> > | | Pipe CSC/CTM | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > | +-----------v----------+ |
> > | | Pipe Gamma | |
> > | | | |
> > | +-----------+----------+ |
> > | | |
> > +---------------------------------------------+
> > |
> > v
> > Pipe Output
> >
> > This patch series adds properties for plane color features. It adds
> > properties for degamma used to linearize data and CSC used for gamut
> > conversion. It also includes Gamma support used to again non-linearize
> > data as per panel supported color space. These can be utilize by user
> > space to convert planes from one format to another, one color space to
> > another etc.
> >
> > Userspace can take smart blending decisions and utilize these hardware
> > supported plane color features to get accurate color profile. The same
> > can help in consistent color quality from source to panel taking
> > advantage of advanced color features in hardware.
> >
> > These patches add the property interfaces and enable helper functions.
> > This series adds Intel's XE_LPD hw specific plane gamma feature. We
> > can build up and add other platform/hardware specific implementation
> > on top of this series.
> >
> > Credits: Special mention and credits to Ville Syrjala for coming up
> > with a design for this feature and inputs. This series is based on his
> > original design and idea.
> >
> > Note: Userspace support for this new UAPI will be done on Chrome in
> > alignment with weston and general opensource community.
> > Discussion ongoing with Harry Wentland, Pekka and community on color
> > pipeline and UAPI design. Harry's RFC below:
> > https://patchwork.freedesktop.org/series/89506/
> > We need to converge on a common UAPI interface which caters to all the
> > modern color hardware pipelines.
> >
> > ToDo: State readout for this feature will be added next.
> >
> > v2: Added UAPI description and added change in the rfc section of
> > kernel Documentation folder
> >
> > Uma Shankar (22):
> > drm: RFC for Plane Color Hardware Pipeline
> > drm: Add Enhanced Gamma and color lut range attributes
> > drm: Add Plane Degamma Mode property
> > drm: Add Plane Degamma Lut property
> > drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> > drm/i915/xelpd: Add register definitions for Plane Degamma
> > drm/i915/xelpd: Enable plane color features
> > drm/i915/xelpd: Add color capabilities of SDR planes
> > drm/i915/xelpd: Program Plane Degamma Registers
> > drm/i915/xelpd: Add plane color check to glk_plane_color_ctl
> > drm/i915/xelpd: Initialize plane color features
> > drm/i915/xelpd: Load plane color luts from atomic flip
> > drm: Add Plane CTM property
> > drm: Add helper to attach Plane ctm property
> > drm/i915/xelpd: Define Plane CSC Registers
> > drm/i915/xelpd: Enable Plane CSC
> > drm: Add Plane Gamma Mode property
> > drm: Add Plane Gamma Lut property
> > drm/i915/xelpd: Define and Initialize Plane Gamma Lut range
> > drm/i915/xelpd: Add register definitions for Plane Gamma
> > drm/i915/xelpd: Program Plane Gamma Registers
> > drm/i915/xelpd: Enable plane gamma
> >
> > Documentation/gpu/drm-kms.rst | 90 +++
> > Documentation/gpu/rfc/drm_color_pipeline.rst | 167 ++++++
> > drivers/gpu/drm/drm_atomic.c | 1 +
> > drivers/gpu/drm/drm_atomic_state_helper.c | 12 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 38 ++
> > drivers/gpu/drm/drm_color_mgmt.c | 177 +++++-
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> > drivers/gpu/drm/i915/display/intel_color.c | 513 ++++++++++++++++++
> > drivers/gpu/drm/i915/display/intel_color.h | 2 +
> > .../drm/i915/display/skl_universal_plane.c | 15 +-
> > drivers/gpu/drm/i915/i915_drv.h | 3 +
> > drivers/gpu/drm/i915/i915_reg.h | 176 +++++-
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 81 +++
> > include/uapi/drm/drm_mode.h | 58 ++
> > 16 files changed, 1337 insertions(+), 6 deletions(-) create mode
> > 100644 Documentation/gpu/rfc/drm_color_pipeline.rst
> >
^ permalink raw reply [flat|nested] 154+ messages in thread