From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7759E3D8903 for ; Tue, 31 Mar 2026 10:28:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774952923; cv=none; b=G7AIU7mFpPMH/4BoyuzBkXXwdqIdlwDfOLGH+FzD/ttGwNhXZHUZEBk1+dNuiTl+Os0ZVvmvA8BK5J9JcBWVFqMJM1t3dSw1/blwywftSnuIpVrPmozBQ4tzTgTBJ9XqcsBquA22+I64QeSRIxR58tNeb+EsJ1RDr/x59owH/Z0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774952923; c=relaxed/simple; bh=aOnw8uG1bF/umdq2HHno0LlsuApV4JZmSR7Oe9w5svA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dbSIuxJbwQAkaoEyBlulBc2U1bYbiHtytyQ07obD4fUvd9IOqfoUy63RT947q2NIHIZds2/nNVWCBDSdtug5sUVV/eH/jhCmY/rIZZtABS7T8D8EPLuNGDv1CdjGuNc4Gsxw5/J4UkKI65J1MGU6GxY2BiuJa70B6QNYJFoE0Rk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=qNeGW2RE; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="qNeGW2RE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1774952915; bh=aOnw8uG1bF/umdq2HHno0LlsuApV4JZmSR7Oe9w5svA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qNeGW2RErsqXeMjsQ3E8PrMQRzMa+Yp76N5P1LLboHDi6Zpd2W/+DGRsCZ3OtmOPK LToNk635P9lUBJOMTXVUfvgm0+e9jqIlgwrw9h+j2b74h+YPpH1ClalH5yxB04yPEc HBMzebO1ft3z1BphfVDTvctmXwwUaTWmGq1HKEZanMzt1ss9MEZXGpfe07oLeAbEpa 3ml7WQRAHjX6lS71doegTKYUTLsgSGFxgl9N/wNYdAQA+Ngcygg+wFQkH4hJYmWP1z yMG+tEoV1OUFFDSuvihVCVeoUhJuEj5JLLW7+9OeiBaFSIaAEKLfM7XRgOx17Mdc0i Tv0PTBZRI6g7A== Received: from fluorite (unknown [194.136.85.206]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pq) by bali.collaboradmins.com (Postfix) with ESMTPSA id 7E1C117E5F0E; Tue, 31 Mar 2026 12:28:34 +0200 (CEST) Date: Tue, 31 Mar 2026 13:28:22 +0300 From: Pekka Paalanen To: Harry Wentland Cc: Michel =?UTF-8?B?RMOkbnplcg==?= , Nicolas Frattaroli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Leo Li , Rodrigo Siqueira , Alex Deucher , Christian =?UTF-8?B?S8O2bmln?= , Ville =?UTF-8?B?U3lyasOkbMOk?= , Daniel Stone , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, kernel@collabora.com, Derek Foreman , Marius Vlad Subject: Re: [PATCH v5 0/3] Add "link bpc" DRM property Message-ID: <20260331132822.5ac57253@fluorite> In-Reply-To: <7461820c-e3ab-40f5-98d2-9878e60ba2ad@amd.com> References: <20260319-link-bpc-v5-0-5306cd04a708@collabora.com> <8676926.T7Z3S40VBb@workhorse> <4265353.aeNJFYEL58@workhorse> <254c20a4-cce3-4c8e-9902-514586f3e694@mailbox.org> <20260326155305.736b4e64@fluorite> <7461820c-e3ab-40f5-98d2-9878e60ba2ad@amd.com> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/MQ0.wLD4iLWOheFBMvZLWA3"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Sig_/MQ0.wLD4iLWOheFBMvZLWA3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 30 Mar 2026 15:01:33 -0400 Harry Wentland wrote: > On 2026-03-26 09:53, Pekka Paalanen wrote: > > Hi Michel, > >=20 > > I have some opinions as well. > >=20 > > On Tue, 24 Mar 2026 17:44:21 +0100 > > Michel D=C3=A4nzer wrote: > > =20 > >> 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. =20 > >=20 > > 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. > >=20 > > Or course, assuming lossy compression is not too lossy. Maybe > > lossy compression should be forbidden by default unless explicitly > > enabled by userspace? > > =20 >=20 > 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. >=20 > 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 --Sig_/MQ0.wLD4iLWOheFBMvZLWA3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmnLocYACgkQI1/ltBGq qqfF3A//fu8zKlepmLlixQNDwd9W3lIa3DZF6Upro7OFw4TcpYJLyh/3g6aDXwo4 TftqKM0s6MHZXjqSE6+2YCoMD6a/QGi0TFL0nRRwk3RbZHENIbHjmxyBhAXewRIJ he55NjcSzxq8C+FXB7yllHu/G6rUX0arA+QVC9nkv4aztAe2A3DyzpRGtnVluIWQ P//C7WT8aiTmSuMjjs6ptSyX/cC7jIkHBKy8F0TZgSyYfvMMbWdDT/N95ZcyaaNc z2lmCNmBW1+Z6UtfhfN11vsbBNadGMJREeqVoYDuU5rloF2+XONS6jOiNZR8+jse ooCvIZbjV9sjd+uvCUkogdK379m6nmuA0ggxfvrbPsckTwxf0hffo0OCSGKpsbe+ pXzJlldGQqk+66Q44XMWEogPcfiDSo7r5Cy081+o35ncViC58J2Jox4rWcl2OZFa xKK/fBJB4pFc4aY5HxDq5hsFHjtHnsvwCB10APWHch/TGATjAWaK7r0vZRUPq9X6 p9wul7w6Fmge5eWga+tKi2HYQK83FsUNqhw9s432V67F17HMnFNqxxi4ZjOoyY1d yeTr22/UH6vqHiDOH8Q+WElU2aRdxX7tGg+H841l+N0dwh9PeoXsXx8N0fD+ufax PPfSqvXlkNrqc/0r2wS4k1SQzhdStg1kctT2p/35z4LwJsAdBPw= =qMax -----END PGP SIGNATURE----- --Sig_/MQ0.wLD4iLWOheFBMvZLWA3--