On 2021-10-27 04:00, Pekka Paalanen wrote:
> On Tue, 26 Oct 2021 11:36:33 -0400
> Harry Wentland <harry.wentl...@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
>
