[PATCH v2 0/8] Add new formats support to vkms

[Pekka Paalanen]

On Tue, 26 Oct 2021 08:34:00 -0300
Igor Torrente <igormtorrente at gmail.com> wrote:

> Summary
> =======
> This series of patches refactor some vkms components in order to introduce
> new formats to the planes and writeback connector.
> 
> Now in the blend function, the plane's pixels are converted to ARGB16161616
> and then blended together.
> 
> The CRC is calculated based on the ARGB1616161616 buffer. And if required,
> this buffer is copied/converted to the writeback buffer format.
> 
> And to handle the pixel conversion, new functions were added to convert
> from a specific format to ARGB16161616 (the reciprocal is also true).
> 
> Tests
> =====
> This patch series was tested using the following igt tests:
> -t ".*kms_plane.*"
> -t ".*kms_writeback.*"
> -t ".*kms_cursor_crc*"
> -t ".*kms_flip.*"
> 
> New tests passing
> -------------------
> - pipe-A-cursor-size-change
> - pipe-A-cursor-alpha-transparent
> 
> Performance
> -----------
> Following some optimization proposed by Pekka Paalanen, now the code
> runs way faster than V1 and slightly faster than the current implementation.
> 
> |                          Frametime                          |
> |:---------------:|:---------:|:--------------:|:------------:|
> |  implmentation  |  Current  |  Per-pixel(V1) | Per-line(V2) |
> | frametime range |  8~22 ms  |    32~56 ms    |    6~19 ms   |
> |     Average     |  10.0 ms  |     35.8 ms    |    8.6 ms    |

Wow, that's much better than I expected.

What is your benchmark? That is, what program do you use and what
operations does it trigger to produce these measurements? What are the
sizes of all the planes/buffers involved? What kind of CPU was this ran
on?


Thanks,
pq

> 
> Writeback test
> --------------
> During the development of this patch series, I discovered that the
> writeback-check-output test wasn't filling the plane correctly.
> 
> So, currently, this patch series is failing in this test. But I sent a
> patch to igt to fix it[1].
> 
> XRGB to ARGB behavior
> =====================
> During the development, I decided to always fill the alpha channel of
> the output pixel whenever the conversion from a format without an alpha
> channel to ARGB16161616 is necessary. Therefore, I ignore the value
> received from the XRGB and overwrite the value with 0xFFFF.
> 
> ---
> Igor Torrente (8):
>   drm: vkms: Replace the deprecated drm_mode_config_init
>   drm: vkms: Alloc the compose frame using vzalloc
>   drm: vkms: Replace hardcoded value of `vkms_composer.map` to
>     DRM_FORMAT_MAX_PLANES
>   drm: vkms: Add fb information to `vkms_writeback_job`
>   drm: drm_atomic_helper: Add a new helper to deal with the writeback
>     connector validation
>   drm: vkms: Refactor the plane composer to accept new formats
>   drm: vkms: Exposes ARGB_1616161616 and adds XRGB_16161616 formats
>   drm: vkms: Add support to the RGB565 format
> 
>  drivers/gpu/drm/drm_atomic_helper.c   |  47 ++++
>  drivers/gpu/drm/vkms/vkms_composer.c  | 329 +++++++++++++++-----------
>  drivers/gpu/drm/vkms/vkms_drv.c       |   6 +-
>  drivers/gpu/drm/vkms/vkms_drv.h       |  14 +-
>  drivers/gpu/drm/vkms/vkms_formats.h   | 252 ++++++++++++++++++++
>  drivers/gpu/drm/vkms/vkms_plane.c     |  17 +-
>  drivers/gpu/drm/vkms/vkms_writeback.c |  33 ++-
>  include/drm/drm_atomic_helper.h       |   3 +
>  8 files changed, 545 insertions(+), 156 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
> 

-------------- 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/dri-devel/attachments/20211109/7bd0de6f/attachment.sig>