[PATCH i-g-t v3 5/7] benchmarks/kms_fb_stress: Don't paint the FB's if the format is DRM_FORMAT_RGB565

[Pekka Paalanen]

On Thu, 21 Mar 2024 12:14:17 -0300
Arthur Grillo <arthurgrillo at riseup.net> wrote:

> On 20/03/24 12:36, Pekka Paalanen wrote:
> > On Thu, 07 Mar 2024 16:41:07 -0300
> > Arthur Grillo <arthurgrillo at riseup.net> wrote:
> >   
> >> Cairo does not fully support the RGB565 due to some stride issues.
> >> So, don't paint the FB's if the format is DRM_FORMAT_RGB565.  
> > 
> > Cairo, as it is based on Pixman, requires stride to be divisible by
> > sizeof(uint32_t). Pixman makes use of that requirement to go faster.
> > 
> > It probably wouldn't hurt if VKMS happened to have the same convention?  
> 
> By not supporting too? Or converting the plane to have strides divisible
> by sizeof(uint32_t) before doing the format conversion?

The DRM driver decides what stride a dumb buffer shall have, so VKMS
could just make the stride to meet Pixman's requirements. I don't
recall if userspace can suggest a stride when allocating a dumb buffer.

If userspace allocates the buffer via some other API, the it is
userspace's own responsibility to make sure the stride is good for
whatever userspace wants to do with it, that is, use it with both
Pixman/Cairo and VKMS.

> > 
> > Anyway, it would be better to test the stride, not format. Maybe IGT
> > should grow a function to check if it can paint with a specific stride
> > & format?  
> 
> If the stride issue is the only thing that decides if a format can be
> painted, I think I can create this function.

Would be best if one could simply try to use a buffer and then handle
failure gracefully when expected.

Btw. it came to my mind, Cairo supports very few pixel formats and
none of them are YUV. So maybe depending on Cairo in IGT in the first
place is not a good decision?

Pixman supports a lot more formats, but I'm unsure of its YUV support,
and it has its own stride requirements due to hand-written assembly
functions to accelerate chosen operations, and maybe the C code paths
too. Pixman might not be a good option either.

If IGT needs to be able to fill buffers of any format with any stride...
and it will need that in order to make sure drivers/hardware process
all pixel formats correctly by CRC or writeback.

Doesn't IGT already have something more featureful than Cairo for
filling buffers?


Thanks,
pq

> >   
> >>
> >> Signed-off-by: Arthur Grillo <arthurgrillo at riseup.net>
> >> ---
> >>  benchmarks/kms_fb_stress.c | 55 ++++++++++++++++++++++++++++++++++------------
> >>  1 file changed, 41 insertions(+), 14 deletions(-)  
> > 
> > Thanks,
> > pq  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/igt-dev/attachments/20240322/c0a1c93b/attachment.sig>