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

Piotr Oniszczuk piotr.oniszczuk at gmail.com
Tue Apr 12 03:14:41 PDT 2022



> Wiadomość napisana przez Lucas Stach <l.stach at 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?




More information about the linux-arm-kernel mailing list