Re: [PATCH v5 0/3] Add "link bpc" DRM property

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

On 2026-03-30 12:57, Michel Dänzer wrote:
> On 3/26/26 13:17, Nicolas Frattaroli wrote:
>> On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote:
>>> On 3/24/26 16:25, Nicolas Frattaroli wrote:
>>>> On Monday, 23 March 2026 18:27:41 Central European Standard Time Michel Dänzer wrote:
>>>>> On 3/23/26 17:55, Nicolas Frattaroli wrote:
>>>>>>
>>>>>> "Someone might not understand its purpose" is, in my eyes, not a valid reason to
>>>>>> not have this property, [...]
>>>>> Per my previous posts, that's not my concern.
>>>>
>>>> Then what is your concern?
>>>
>>> Per my previous posts, my concerns are:
>>>
>>> * The meaning of the "link bpc" property value isn't defined well
>>> enough vs things like dithering or DSC, which will likely result in
>>> compositors / users overestimating what value they need / want,
>>> resulting in compositors spuriously rejecting configurations which 
>>> would work perfectly fine, and/or spurious issue reports.
>>
>> Dithering and DSC are supposed to be transparent, no?
> 
> Not really, no. They achieve higher "effective" (as perceived by the user) bpc using a lower physical bpc.
> 
> 
>> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits.
> 
> If DSC encodes user-perceived 10 bpc at a lower physical bpc, and the "link bpc" property reports 10, that would satisfy my concern for DSC.
> 

Conceptually I would understand DSC to not effect the reported bpc, so
a 10bpc output bpc would be reported as 10bpc via the property, but
DSC would compress that down to a lower value on the wire.

Dithering wouldn't do that. An 8bpc output would be reported as 8bpc
even if dithering makes it perceptually look like 10bpc.

I can understand the challenge of how to intelligently use it to
report anything back to users. I could see some compositors being happy
to use the bpc alone, while others might want to know dithering and/or
DSC state (compression ratio?) as well.

Harry

> Are you sure that's the case though?
> 
> I would be quite surprised if this was correspondingly the case for dithering.
> 
> Either way, the "link bpc" semantics regarding these should be explicitly documented.
> 
> 
>> No compositor would care about the compressed-to actual bit depth on
>> the wire being 9 bits on the intake of a DSC decoder, it's not relevant
>> for their use case, they're not decoding DSC.
>>
>> Making it consider DSC as part of the link bpc would lead to what you
>> describe, since now compositors would need to know the compression
>> algorithms of every single display protocol to correctly determine
>> whether unintended degradation has happened. Ignoring DSC, which is
>> what I am doing, would not do that.
> 
> Sounds like you misunderstood my concern.
> 
> 
>>> With my compositor developer hat on, what I'd want to know is something
>>> like: "How many bits of information can be passed over the link, allowing
>>> the display to present it in a way which can be perceived by the user?"
>>> With dithering or DSC, that would be a higher value than the physical
>>> link bpc.
>>
>> You're assuming link-bpc isn't precisely that.
> 
> I'm not assuming, I'm asking for this to be clarified.
> 
> 
>> [...], you seem to be obsessed [...]
> 
> Not sure why you keep attacking me personally. I'm not trying to shoot down your proposal, I'm trying to prevent potential flaws I see with it. A bit more cooperative attitude would be nice.
> 
> 
>>>> If all you want is a clearer description of the property in the comment that
>>>> accompanies it, then I can do that, and I said I agree with this point.
>>>
>>> Patch 3 would need to take dithering & DSC into account as well.
>>
>> There is no patch 3,
> 
> The start of this thread is the cover letter of a 3-patch series.
> 
> 
>> and I will not break the feedback loop semantics of this property to please you.
> 
> More ad hominem.
> 
> 
>>>> But you seem to be arguing from a position of not wanting the property to
>>>> exist at all, [...]
>>>
>>> I'm not. However, per the first concern above, a not-well-defined
>>> property could be worse than none.
>>
>> So should I remove max-bpc as well? It's not well defined after all.
> 
> This isn't a good-faith argument either. Nobody asked for that.
> 
>