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

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

On 2026-03-31 06:28, Pekka Paalanen wrote:
> On Mon, 30 Mar 2026 15:01:33 -0400
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2026-03-26 09:53, Pekka Paalanen wrote:
>>> Hi Michel,
>>>
>>> I have some opinions as well.
>>>
>>> On Tue, 24 Mar 2026 17:44:21 +0100
>>> Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>>>   
>>>> 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.  
>>>
>>> That is ok. Compositors need to understand what the numbers mean, how
>>> reliable they are, and act accordingly. Knowing the lower bound for
>>> link precision is already useful as it guarantees a minimum precision.
>>> It is up to the compositors to decide how they communicate this.
>>>
>>> Or course, assuming lossy compression is not too lossy. Maybe
>>> lossy compression should be forbidden by default unless explicitly
>>> enabled by userspace?
>>>   
>>
>> I disagree. While technically lossy, DSC is perceptually lossless, at
>> least according to the designers of DSC. If I'm not mistaken this is
>> all based on extensive studies.
>>
>> The decision to enable DSC or not has an impact on the power consumption
>> of the HW, in ways that are often nuanced. Userspace has no way to know
>> or understand these nuances. This should be in control of the driver.
> 
> I guess time will tell.
> 
> Are you saying that enabling DSC might have disadvantages aside from
> image quality?
> 

The opposite; enabling DSC might have advantages, in particular in power
efficiency. And image quality impacts are negligible or (perceptually)
non-existant, from my understanding. Afaik, Apple, which prides itself
on image quality and being a platform for content producers, enables DSC
by default on their systems.

>> At most I could see a "never do DSC or dither" toggle, if one is really
>> concerned about this, but I don't realistically see use-cases where this
>> would improve user experience, even for users that care about color work
>> and correctness.
> 
> I'm not familiar with DSC, so I cannot criticise it. Dithering OTOH
> seems to be obviously suspect though.
> 
> Temporal dithering - what if your refresh rate is 30 Hz for some movie
> playback?
> 
> Spatial dithering - what if you have a low-resolution screen?
> 
> I would not assume that dithering is always ok, and always achieves its
> theoretical results.
> 

Quite possibly, but we haven't really seen complaints about dither other
than in scenarios where people explictly test that input pixels equal
output pixels exactly.

>> The YCbCr420 case is different. We probably want a way for userspace to
>> understand that half 3/4 of chroma values are being tossed out. This
>> would be significant for RGB content but insignificant for YCbCr420
>> content.
> 
> Do you mean full resolution vs. chroma sub-sampled to 2x2 blocks? I
> would again not assume "insignificant", because it depends on the
> picture content and angular pixel density (can you see individual
> pixels at your viewing distance). Gray-scale text will be fine, but
> colored text is another question.
> 

Yes. I think downgrading an output to YCbCr420 (chroma sub-sampled to
2x2 blocks) is a significant image quality impact.

> I'm fine with proceeding with these assumptions, as long as it is
> acknowledged that these assumptions might turn out false later and have
> a contingency plan.
> 

I guess that goes to Michel's question about what's expected of
compositors here and whether there is clarity... I'm not sure
I really have an answer on that other than documenting our
expectations.

Harry

> 
> Thanks,
> pq