Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

From: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: "Sascha Hauer" <s.hauer@pengutronix.de>,
	dri-devel@lists.freedesktop.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	kernel@pengutronix.de, "Andy Yan" <andy.yan@rock-chips.com>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Lucas Stach" <lst@pengutronix.de>
Subject: Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support
Date: Tue, 12 Apr 2022 12:14:41 +0200	[thread overview]
Message-ID: <EF0F8E87-2618-4E5E-807D-259FEEC0FB24@gmail.com> (raw)
In-Reply-To: <e2ef484b60fe9c5fc077240a26bd18275974dc4a.camel@pengutronix.de>

> Wiadomość napisana przez Lucas Stach <l.stach@pengutronix.de> w dniu 12.04.2022, o godz. 10:10:
> 
> This could be both a Mesa/Panfrost or application issue. The
> application is supposed to try to allocate with a arbitrary chosen
> format and the valid modifiers queried from the plane it wants to put
> the surface on. However I'm not sure if all applications have a
> fallback path in place to try another format swizzling if the surface
> allocation fails.

This is good remark imho.
I think we have this fallback.
I'll try verify this.

Generalising a bit - I think we my consider following cases:

a\ format is correctly negotiated and signalled to consumer/provider but we don't see expected results (=correct screen seen by user)
b\ format was correctly negotiated but consumer/provider failed using signalled format (i.e. due bug in implementation)
c\ consumer or provider advertising - in reality unsupported format (false positive) - so negotiation resulting with signalling efficiently non-working format

Sascha says (in today's email):

"Here is your problem. The cluster windows only allow AFBC compressed
formats. AR24 is supported by the cluster windows, but not by the GPU,
see panfrost_afbc_format() in Mesa:"

I'm reading this as case c\ as Sascha said "negotiated format is not supported by GPU" ....but this format was negotiated.

......but for sure Sascha is much better than me here in subject - so i'm might be wrong here

> Now there are two possible failures here:
> 
> 1. The application feeds a wrong modifier list to the GBM
> implementation, as it may have queried another plane in the assumption
> that supported modifiers are uniform across all planes.
> 

This will be cardinal design error.
(keeping in mind we have multiple producers (GPU/video decoder) and multiple consumers (base & overlay DRM planes)

> 2. The GBM implementation (Panfrost) actually allocates a surface
> instead of failing the allocation, even if it does not support any
> combination of the provided format and modifier list.
> 

Testing Sacha patch (see today's email from Sascha) i'm getting

Qt: EGL Error : Could not create the egl surface: error = 0x3009

i'm reading this as: Qt tries allocate EGL surface and EGL returns error.

or i'm wrong?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel