Re: [PATCH v2 0/7] Add YUV formats to VKMS

2024-02-29 Thread Arthur Grillo



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-383a6dec1...@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.wentl...@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-mca...@igalia.com/

 Signed-off-by: Arthur Grillo 
 ---
 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-34c4cd345...@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 

>>>
>>
> 


Re: [PATCH v2 0/7] Add YUV formats to VKMS

2024-02-29 Thread Sebastian Wick
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-383a6dec1...@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.wentl...@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-mca...@igalia.com/
> >>
> >> Signed-off-by: Arthur Grillo 
> >> ---
> >> 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-34c4cd345...@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 
> >>
> > 
> 



Re: [PATCH v2 0/7] Add YUV formats to VKMS

2024-02-28 Thread Arthur Grillo



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-383a6dec1...@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.wentl...@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-mca...@igalia.com/
>>
>> Signed-off-by: Arthur Grillo 
>> ---
>> 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-34c4cd345...@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 
>>
> 


Re: [PATCH v2 0/7] Add YUV formats to VKMS

2024-01-15 Thread Sebastian Wick
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.wentl...@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-mca...@igalia.com/
> 
> Signed-off-by: Arthur Grillo 
> ---
> 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-34c4cd345...@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 
> 



[PATCH v2 0/7] Add YUV formats to VKMS

2024-01-10 Thread Arthur Grillo
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.wentl...@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-mca...@igalia.com/

Signed-off-by: Arthur Grillo 
---
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-34c4cd345...@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