On 15/01/24 12:06, Sebastian Wick wrote: > On Wed, Jan 10, 2024 at 02:44:00PM -0300, Arthur Grillo wrote: >> This patchset aims to add support for additional buffer YUV formats. >> More specifically, it adds support to: >> >> Semi-planar formats: >> >> - NV12 >> - NV16 >> - NV24 >> - NV21 >> - NV61 >> - NV42 >> >> Planar formats: >> >> - YUV440 >> - YUV422 >> - YUV444 >> - YVU440 >> - YVU422 >> - YVU444 >> >> These formats have more than one plane, and most have chroma >> subsampling. These properties don't have support on VKMS, so I had to >> work on this before. >> >> To ensure that the conversions from YUV to RGB are working, I wrote a >> KUnit test. As the work from Harry on creating KUnit tests on VKMS[1] is >> not yet merged, I took the setup part (Kconfig entry and .kunitfile) >> from it. >> >> Furthermore, I couldn't find any sources with the conversion matrices, >> so I had to work out the values myself based on the ITU papers[2][3][4]. >> So, I'm not 100% sure if the values are accurate. I'd appreciate some >> input if anyone has more knowledge in this area. > > H.273 CICP [1] has concise descriptions of the required values for most > widely used formats and the colour python framework [2] also can be used > to quickly get to the desired information most of the time. > > [1]: https://www.itu.int/rec/T-REC-H.273 > [2]: https://www.colour-science.org/ I want to thank you for suggesting the python framework, it helped immensely now that I'm changing the precision from 8-bit to 32-bit[1]. If I'd known about this framework while developing this patch, I would've saved myself a few weeks of pain and suffering recreating a part of this library XD. [1]: https://lore.kernel.org/all/b23da076-0bfb-48b2-9386-383a6dec1868@xxxxxxxxxx/ Best Regards, ~Arthur Grillo > >> Also, I used two IGT tests to check if the formats were having a correct >> conversion (all with the --extended flag): >> >> - kms_plane@pixel_format >> - kms_plane@pixel_format_source_clamping. >> >> The nonsubsampled formats don't have support on IGT, so I sent a patch >> fixing this[5]. >> >> Currently, this patchset does not add those formats to the writeback, as >> it would require a rewrite of how the conversions are done (similar to >> what was done on a previous patch[6]). So, I would like to review this >> patchset before I start the work on this other part. >> >> [1]: https://lore.kernel.org/all/20231108163647.106853-5-harry.wentland@xxxxxxx/ >> [2]: https://www.itu.int/rec/R-REC-BT.601-7-201103-I/en >> [3]: https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en >> [4]: https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en >> [5]: https://lists.freedesktop.org/archives/igt-dev/2024-January/066937.html >> [6]: https://lore.kernel.org/dri-devel/20230414135151.75975-2-mcanal@xxxxxxxxxx/ >> >> Signed-off-by: Arthur Grillo <arthurgrillo@xxxxxxxxxx> >> --- >> Changes in v2: >> - Use EXPORT_SYMBOL_IF_KUNIT instead of including the .c test >> file (Maxime) >> - Link to v1: https://lore.kernel.org/r/20240105-vkms-yuv-v1-0-34c4cd3455e0@xxxxxxxxxx >> >> --- >> Arthur Grillo (7): >> drm/vkms: Use drm_frame directly >> drm/vkms: Add support for multy-planar framebuffers >> drm/vkms: Add range and encoding properties to pixel_read function >> drm/vkms: Add chroma subsampling >> drm/vkms: Add YUV support >> drm/vkms: Drop YUV formats TODO >> drm/vkms: Create KUnit tests for YUV conversions >> >> 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 | 156 ++++++++++++++++ >> drivers/gpu/drm/vkms/vkms_drv.h | 6 +- >> drivers/gpu/drm/vkms/vkms_formats.c | 247 ++++++++++++++++++++++---- >> drivers/gpu/drm/vkms/vkms_formats.h | 9 + >> drivers/gpu/drm/vkms/vkms_plane.c | 26 ++- >> drivers/gpu/drm/vkms/vkms_writeback.c | 5 - >> 11 files changed, 426 insertions(+), 49 deletions(-) >> --- >> base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f >> change-id: 20231226-vkms-yuv-6f7859f32df8 >> >> Best regards, >> -- >> Arthur Grillo <arthurgrillo@xxxxxxxxxx> >> >
