[PATCH v4 00/14] drm/vkms: Reimplement line-per-line pixel conversion for plane reading
Louis Chauvet
louis.chauvet at bootlin.com
Mon Mar 4 15:28:05 UTC 2024
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
It can be divided in three parts:
- PATCH 1 to 4: no functional change is intended, only some formatting and
documenting (PATCH 2 is taken from [2])
- PATCH 5 to 8: Some preparation work not directly related to the
line-by-line algorithm
- PATCH 9: main patch for this series, it reintroduce the
line-by-line algorithm
- PATCH 10 to 13: taken from Arthur's series [2], with sometimes
adaptation to use the pixel-by-pixel algorithm.
The PATCH 9 aims to restore the line-by-line pixel reading algorithm. It
was introduced in 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
accept new formats") but removed in 8ba1648567e2 ("drm: vkms: Refactor the
plane composer to accept new formats") in a over-simplification effort.
At this time, nobody noticed the performance impact of this commit. After
the first iteration of my series, poeple notice performance impact, and it
was the case. Pekka suggested to reimplement the line-by-line algorithm.
Expiriments on my side shown great improvement for the line-by-line
algorithm, and the performances are the same as the original line-by-line
algorithm. I targeted my effort to make the code working for all the
rotations and translations. The usage of helpers from drm_rect_* avoid
reimplementing existing logic.
The only "complex" part remaining is the clipping of the coordinate to
avoid reading/writing outside of src/dst. Thus I added a lot of comments
to help when someone will want to add some features (framebuffer resizing
for example).
The YUV part is not mandatory for this series, but as my first effort was
to help the integration of YUV, I decided to rebase Arthur's series on
mine to help. I took [3], [4], [5] and [6] and adapted them to use the
line-by-line reading. They were also updated to use 32.32 fixed point
values for yuv conversion instead of 8.8 fixed points.
My series was mainly tested with:
- kms_plane (for color conversions)
- kms_rotation_crc (for rotations of planes)
- kms_cursor_crc (for translations)
The benchmark used to measure the improvment was done with:
- kms_fb_stress
[1]: https://lore.kernel.org/r/20240201-yuv-v1-0-3ca376f27632@bootlin.com
[2]: https://lore.kernel.org/all/20240110-vkms-yuv-v2-0-952fcaa5a193@riseup.net/
[3]: https://lore.kernel.org/all/20240110-vkms-yuv-v2-3-952fcaa5a193@riseup.net/
[4]: https://lore.kernel.org/all/20240110-vkms-yuv-v2-5-952fcaa5a193@riseup.net/
[5]: https://lore.kernel.org/all/20240110-vkms-yuv-v2-6-952fcaa5a193@riseup.net/
[6]: https://lore.kernel.org/all/20240110-vkms-yuv-v2-7-952fcaa5a193@riseup.net/
To: Rodrigo Siqueira <rodrigosiqueiramelo at gmail.com>
To: Melissa Wen <melissa.srw at gmail.com>
To: Maíra Canal <mairacanal at riseup.net>
To: Haneen Mohammed <hamohammed.sa at gmail.com>
To: Daniel Vetter <daniel at ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
To: Maxime Ripard <mripard at kernel.org>
To: Thomas Zimmermann <tzimmermann at suse.de>
To: David Airlie <airlied at gmail.com>
To: arthurgrillo at riseup.net
To: Jonathan Corbet <corbet at lwn.net>
To: pekka.paalanen at haloniitty.fi
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Cc: jeremie.dautheribes at bootlin.com
Cc: miquel.raynal at bootlin.com
Cc: thomas.petazzoni at bootlin.com
Cc: seanpaul at google.com
Cc: marcheu at google.com
Cc: nicolejadeyee at google.com
Signed-off-by: Louis Chauvet <louis.chauvet at bootlin.com>
Note: after my changes, those tests seems to pass, so [7] may need
updating (I did not check, it was maybe already the case):
- kms_cursor_legacy at flip-vs-cursor-atomic
- kms_pipe_crc_basic at nonblocking-crc
- kms_pipe_crc_basic at nonblocking-crc-frame-sequence
- kms_writeback at writeback-pixel-formats
- kms_writeback at writeback-invalid-parameters
- kms_flip at flip-vs-absolute-wf_vblank-interruptible
And those tests pass, I did not investigate why the runners fails:
- kms_flip at flip-vs-expired-vblank-interruptible
- kms_flip at flip-vs-expired-vblank
- kms_flip at plain-flip-fb-recreate
- kms_flip at plain-flip-fb-recreate-interruptible
- kms_flip at plain-flip-ts-check-interruptible
- kms_cursor_legacy at cursorA-vs-flipA-toggle
- kms_pipe_crc_basic at nonblocking-crc
- kms_prop_blob at invalid-get-prop
- kms_flip at flip-vs-absolute-wf_vblank-interruptible
- kms_invalid_mode at zero-hdisplay
- kms_invalid_mode at bad-vtotal
- kms_cursor_crc.* (everything is SUCCEED or SKIP, but no fails)
[7]: https://lore.kernel.org/all/20240201065346.801038-1-vignesh.raman@collabora.com/
Changes in v4:
- PATCH 3/14: Update comments for get_pixel_* functions
- PATCH 4/14: Add WARN when trying to get unsupported pixel_* functions
- PATCH 5/14: Create dummy pixel reader/writer to avoid NULL
function pointers and kernel OOPS
- PATCH 6/14: Added the usage of const pointers when needed
- PATCH 7/14: Extraction of pixel accessors modification
- PATCH 8/14: Extraction of the blending function modification
- PATCH 9/14: Extraction of the pixel_read_direction enum
- PATCH 10/14: Update direction_for_rotation documentation
- PATCH 10/14: Rename conversion functions to be explicit
- PATCH 10/14: Replace while(count) by while(out_pixel<end) in read_line
callbacks. It avoid a new variable+addition in the composition hot path.
- PATCH 11/14: Rename conversion functions to be explicit
- PATCH 11/14: Update the documentation for get_subsampling_offset
- PATCH 11/14: Add the matrix_conversion structure to remove a test from
the hot path.
- PATCH 11/14: Upadate matrix values to use 32.32 fixed floats for
conversion
- PATCH 12/14: Update commit message
- PATCH 14/14: Change kunit expected value
- Link to v3: https://lore.kernel.org/r/20240226-yuv-v3-0-ff662f0994db@bootlin.com
Changes in v3:
- Correction of remaining git-rebase artefacts
- Added Pekka in copy of this patch
- Link to v2: https://lore.kernel.org/r/20240223-yuv-v2-0-aa6be2827bb7@bootlin.com
Changes in v2:
- Rebased the series on top of drm-misc/drm-misc-net
- Extract the typedef for pixel_read/pixel_write
- Introduce the line-by-line algorithm per pixel format
- Add some documentation for existing and new code
- Port the series [1] to use line-by-line algorithm
- Link to v1: https://lore.kernel.org/r/20240201-yuv-v1-0-3ca376f27632@bootlin.com
---
Arthur Grillo (5):
drm/vkms: Use drm_frame directly
drm/vkms: Add YUV support
drm/vkms: Add range and encoding properties to the plane
drm/vkms: Drop YUV formats TODO
drm/vkms: Create KUnit tests for YUV conversions
Louis Chauvet (9):
drm/vkms: Code formatting
drm/vkms: write/update the documentation for pixel conversion and pixel write functions
drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions
drm/vkms: Add dummy pixel_read/pixel_write callbacks to avoid NULL pointers
drm/vkms: Use const for input pointers in pixel_read an pixel_write functions
drm/vkms: Update pixels accessor to support packed and multi-plane formats.
drm/vkms: Avoid computing blending limits inside pre_mul_alpha_blend
drm/vkms: Introduce pixel_read_direction enum
drm/vkms: Re-introduce line-per-line composition algorithm
Documentation/gpu/vkms.rst | 3 +-
drivers/gpu/drm/vkms/Kconfig | 15 +
drivers/gpu/drm/vkms/Makefile | 1 +
drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
drivers/gpu/drm/vkms/tests/Makefile | 3 +
drivers/gpu/drm/vkms/tests/vkms_format_test.c | 158 ++++++
drivers/gpu/drm/vkms/vkms_composer.c | 251 ++++++--
drivers/gpu/drm/vkms/vkms_crtc.c | 6 +-
drivers/gpu/drm/vkms/vkms_drv.c | 3 +-
drivers/gpu/drm/vkms/vkms_drv.h | 86 ++-
drivers/gpu/drm/vkms/vkms_formats.c | 790 ++++++++++++++++++++++----
drivers/gpu/drm/vkms/vkms_formats.h | 12 +-
drivers/gpu/drm/vkms/vkms_plane.c | 45 +-
drivers/gpu/drm/vkms/vkms_writeback.c | 5 -
14 files changed, 1167 insertions(+), 215 deletions(-)
---
base-commit: c079e2e113f2ec2803ba859bbb442a6ab82c96bd
change-id: 20240201-yuv-1337d90d9576
Best regards,
--
Louis Chauvet <louis.chauvet at bootlin.com>
More information about the dri-devel
mailing list