linux-kernel - [PATCH 0/6] Refactor the vkms to accept new formats

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211005201637.58563-1-igormtorrente@gmail.com>
Date:   Tue,  5 Oct 2021 17:16:31 -0300
From:   Igor Matheus Andrade Torrente <igormtorrente@...il.com>
To:     rodrigosiqueiramelo@...il.com, melissa.srw@...il.com
Cc:     Igor Matheus Andrade Torrente <igormtorrente@...il.com>,
        hamohammed.sa@...il.com, daniel@...ll.ch, airlied@...ux.ie,
        contact@...rsion.fr, leandro.ribeiro@...labora.com,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        lkcamp@...ts.libreplanetbr.org
Subject: [PATCH 0/6] Refactor the vkms to accept new formats

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*"

New tests passing
-------------------
- pipe-A-cursor-size-change
- pipe-A-cursor-alpha-transparent

Tests and Performance Regressions
-------------------------------------
This pack of tests is failing:
- pipe-A-cursor-*-rapid-movement

This is expected since there are more operations per pixel than before.
And consequently, the compositing is way slower than before.

My micro-profiling shows these ranges to the completion of each
compositing in the .*kms_cursor_crc.* tests:

|      Frametime     |
|:-------:|:--------:|
|  before |   after  |
| 8~20 ms | 32~56 ms |

Hence, further optimizations will be required.

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.

My question is, is this behavior acceptable?

[1] https://lists.freedesktop.org/archives/igt-dev/2021-October/036125.html

Igor Matheus Andrade Torrente (6):
  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: vkms: Prepare `vkms_wb_encoder_atomic_check` to accept multiple
    formats
  drm: vkms: Refactor the plane composer to accept new formats

 drivers/gpu/drm/vkms/vkms_composer.c  | 275 ++++++++++++++------------
 drivers/gpu/drm/vkms/vkms_drv.c       |   5 +-
 drivers/gpu/drm/vkms/vkms_drv.h       |  12 +-
 drivers/gpu/drm/vkms/vkms_formats.h   | 125 ++++++++++++
 drivers/gpu/drm/vkms/vkms_writeback.c |  27 ++-
 5 files changed, 304 insertions(+), 140 deletions(-)
 create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h

-- 
2.30.2