Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland <harry.wentland@amd.com>]

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
>