public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <pekka.paalanen@collabora.com>
To: Harry Wentland <harry.wentland@amd.com>
Cc: "Michel Dänzer" <michel.daenzer@mailbox.org>,
	"Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>, "Leo Li" <sunpeng.li@amd.com>,
	"Rodrigo Siqueira" <siqueira@igalia.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Daniel Stone" <daniels@collabora.com>,
	"Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	amd-gfx@lists.freedesktop.org, kernel@collabora.com,
	"Derek Foreman" <derek.foreman@collabora.com>,
	"Marius Vlad" <marius.vlad@collabora.com>
Subject: Re: [PATCH v5 0/3] Add "link bpc" DRM property
Date: Tue, 31 Mar 2026 13:28:22 +0300	[thread overview]
Message-ID: <20260331132822.5ac57253@fluorite> (raw)
In-Reply-To: <7461820c-e3ab-40f5-98d2-9878e60ba2ad@amd.com>

[-- Attachment #1: Type: text/plain, Size: 3040 bytes --]

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?

> 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.

> 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.

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.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-03-31 10:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 12:28 [PATCH v5 0/3] Add "link bpc" DRM property Nicolas Frattaroli
2026-03-19 12:28 ` [PATCH v5 1/3] drm/connector: Add a 'link bpc' property Nicolas Frattaroli
2026-03-19 12:28 ` [PATCH v5 2/3] drm/connector: hdmi: Add support for " Nicolas Frattaroli
2026-03-19 12:28 ` [PATCH v5 3/3] drm/amd/display: " Nicolas Frattaroli
2026-03-20 14:32 ` [PATCH v5 0/3] Add "link bpc" DRM property Michel Dänzer
2026-03-20 18:02   ` Nicolas Frattaroli
2026-03-23 10:55     ` Michel Dänzer
2026-03-23 12:05       ` Nicolas Frattaroli
2026-03-23 14:38         ` Michel Dänzer
2026-03-23 16:55           ` Nicolas Frattaroli
2026-03-23 17:27             ` Michel Dänzer
2026-03-24 15:25               ` Nicolas Frattaroli
2026-03-24 16:44                 ` Michel Dänzer
2026-03-26 12:17                   ` Nicolas Frattaroli
2026-03-30 16:57                     ` Michel Dänzer
2026-03-30 18:52                       ` Harry Wentland
2026-03-31 12:50                         ` Pekka Paalanen
2026-03-31 17:47                           ` Harry Wentland
2026-04-01  8:40                             ` Daniel Stone
2026-04-01 11:10                               ` Ville Syrjälä
2026-04-01 11:43                                 ` Daniel Stone
2026-04-01 12:46                               ` Nicolas Frattaroli
2026-04-02 17:06                                 ` Harry Wentland
2026-04-01 13:57                               ` Ville Syrjälä
2026-04-01 14:17                                 ` Daniel Stone
2026-04-02 17:01                               ` Harry Wentland
2026-03-26 13:53                   ` Pekka Paalanen
2026-03-30 19:01                     ` Harry Wentland
2026-03-31 10:28                       ` Pekka Paalanen [this message]
2026-03-31 17:37                         ` Harry Wentland
2026-03-31  8:01                     ` Michel Dänzer
2026-03-31 12:38                       ` Pekka Paalanen
2026-03-31 12:56                         ` Michel Dänzer
2026-03-31 14:21                           ` Pekka Paalanen
2026-04-01  7:46                             ` Michel Dänzer
     [not found]     ` <CAEsyxyhnALbkaF+9nav8FkW5gcJdtTw5CHhK3Hf8f=fymFiOKw@mail.gmail.com>
2026-03-23 11:44       ` Michel Dänzer
2026-04-01 11:57 ` Xaver Hugl
2026-04-01 12:11   ` Ville Syrjälä
2026-04-01 12:25     ` Daniel Stone
2026-04-01 12:56       ` Ville Syrjälä
2026-04-01 12:14   ` Nicolas Frattaroli
2026-04-03 10:23     ` Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260331132822.5ac57253@fluorite \
    --to=pekka.paalanen@collabora.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniels@collabora.com \
    --cc=derek.foreman@collabora.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marius.vlad@collabora.com \
    --cc=michel.daenzer@mailbox.org \
    --cc=mripard@kernel.org \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=simona@ffwll.ch \
    --cc=siqueira@igalia.com \
    --cc=sunpeng.li@amd.com \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox