| Message ID | 20240110-vkms-yuv-v2-0-952fcaa5a193@riseup.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add YUV formats to VKMS | expand |
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/ > 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@amd.com/ > [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@igalia.com/ > > Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> > --- > 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@riseup.net > > --- > 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@riseup.net> >
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@riseup.net/ 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@amd.com/ >> [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@igalia.com/ >> >> Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> >> --- >> 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@riseup.net >> >> --- >> 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@riseup.net> >> >
On Wed, Feb 28, 2024 at 08:42:41PM -0300, Arthur Grillo wrote: > > > 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. I'm glad this is useful for you! We also used it for our color-and-hdr project https://gitlab.freedesktop.org/pq/color-and-hdr/. > [1]: https://lore.kernel.org/all/b23da076-0bfb-48b2-9386-383a6dec1868@riseup.net/ > > 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@amd.com/ > >> [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@igalia.com/ > >> > >> Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> > >> --- > >> 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@riseup.net > >> > >> --- > >> 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@riseup.net> > >> > > >
On 29/02/24 14:52, Sebastian Wick wrote: > On Wed, Feb 28, 2024 at 08:42:41PM -0300, Arthur Grillo wrote: >> >> >> 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. > > I'm glad this is useful for you! We also used it for our color-and-hdr > project https://gitlab.freedesktop.org/pq/color-and-hdr/. Cool project! I'll be sure to give look! Best Regards, ~Arthur Grillo > >> [1]: https://lore.kernel.org/all/b23da076-0bfb-48b2-9386-383a6dec1868@riseup.net/ >> >> 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@amd.com/ >>>> [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@igalia.com/ >>>> >>>> Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> >>>> --- >>>> 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@riseup.net >>>> >>>> --- >>>> 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@riseup.net> >>>> >>> >> >
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. 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@amd.com/ [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@igalia.com/ Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> --- 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@riseup.net --- 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,