12:33conan_kudo[d]: could someone look at this? https://gitlab.freedesktop.org/drm/nouveau/-/issues/385
16:03dwlsalmeida[d]: Btw, for what `VkFormats` should we advertise `VK_FORMAT_FEATURE_VIDEO_DECODE_OUTPUT_BIT_KHR` and friends?
16:03dwlsalmeida[d]: I have this hack here, which works, since I am using `NV12`
16:03dwlsalmeida[d]: @@ -139,6 +143,13 @@ nvk_get_image_format_features(struct nvk_physical_device *pdev,
16:03dwlsalmeida[d]: if (cosited_chroma)
16:03dwlsalmeida[d]: features |= VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT;
16:03dwlsalmeida[d]: + /* add the video formats. TODO: is there anything else that should be here? */
16:03dwlsalmeida[d]: + if (p_format == PIPE_FORMAT_NV12 || p_format == PIPE_FORMAT_P010 ||
16:03dwlsalmeida[d]: + p_format == PIPE_FORMAT_P012 || p_format == PIPE_FORMAT_P016 ||
16:03dwlsalmeida[d]: + p_format == PIPE_FORMAT_IYUV) {
16:03dwlsalmeida[d]: + features |= VK_FORMAT_FEATURE_VIDEO_DECODE_OUTPUT_BIT_KHR;
16:03dwlsalmeida[d]: + features |= VK_FORMAT_FEATURE_VIDEO_DECODE_DPB_BIT_KHR;
16:03dwlsalmeida[d]: + }
16:03dwlsalmeida[d]: return features;
16:03dwlsalmeida[d]: }
16:04dwlsalmeida[d]: but maybe we should check for more YUV formats?
16:04dwlsalmeida[d]: cc mohamexiety[d] btw
16:05awilfox[d]: Wait, nvk on NV12?
16:10mohamexiety[d]: awilfox[d]: the YUV format not the graphics arch
16:11mohamexiety[d]: dwlsalmeida[d]: honestly I don't remember there being any issues disallowing us from setting that bit for all the YUV formats. I guess if the decoder/encoder block doesn't support certain ones, but I don't know which ones if that's the case
16:13dwlsalmeida[d]: Valentine Burley 5 months ago (July 18th, 2024 10:37 AM)
16:13dwlsalmeida[d]: vulkan/format: Translate two 420_UNORM formats properly
16:13dwlsalmeida[d]: VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM and VK_FORMAT_G8_B8R8_2PLANE_420_UNORM were being
16:13dwlsalmeida[d]: translated to IYUV and NV12 formats which, in PIPE_FORMAT parlance, are auto-converted
16:13dwlsalmeida[d]: formats, not raw data formats.
16:13dwlsalmeida[d]: Use the raw data formats like everything else.
16:13dwlsalmeida[d]: Not sure I get this commit
16:14dwlsalmeida[d]: isn't `VK_FORMAT_G8_B8R8_2PLANE_420_UNORM` essentially `PIPE_FORMAT_NV12` anyways?
16:15dwlsalmeida[d]: mohamexiety[d]: Averne, Dave, do you guys know anything about this? I see that for ANV and RADV this feature is not set for all YUV formats
16:24dwlsalmeida[d]: actually, thinking about this a bit more from a video codec perspective, expecting the codec hw to take all YUV formats is kind of wild
16:33avhe[d]: dwlsalmeida[d]: afaik the hardware supports only semiplanar formats (NV12, P010, P012), and NV24 for 4:4:4 subsampling (supported for hevc in newer cards)
16:34avhe[d]: <https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/nvdec_drv.h#L942> all codec structures have this field
16:36dwlsalmeida[d]: interestingly, GStreamer's `nvh264dec` only advertises `NV12` for its source caps, i.e.: https://gstreamer.freedesktop.org/documentation/nvcodec/nvh264dec.html#src
16:38linkmauve: Maybe it got written before support for the Hi10p profile, and never updated once Nvidia added it.
16:42linkmauve: Ah, on the other side, v4l2slvp8dec is also wrong, it advertises P010 and NV12_10LE40_4L4 despite the VP8 format not supporting anything but 8-bit.
16:44dwlsalmeida[d]: avhe[d]: not seeing it for hevc, for example https://github.com/NVIDIA/open-gpu-doc/blob/be7c626456eb9beebe61f0f99cc855215d04ddb3/classes/video/nvdec_drv.h#L353
16:44dwlsalmeida[d]: linkmauve: I'll let Nicolas know so he can fix it..
16:45avhe[d]: dwlsalmeida[d]: yeah because nvdec only supports 8-bit for h264, if you look at nvvp9dec or nvh265dec you will see additional formats and depths
16:45linkmauve: Thanks. :)
16:48avhe[d]: dwlsalmeida[d]: true, looks like i misremembered. there's another mechanism for specifying the bit depth (the disp_output_mode field)
16:49avhe[d]: i'm not sure how 12-bit and 4:4:4 support work since i never looked at it, but it goes in those additional substructures at the end of the main one
16:53dwlsalmeida[d]: unsigned char disp_output_mode; // 0: Rec.709 8 bit, 1: Rec.709 10 bit, 2: Rec.709 10 bits -> 8 bit, 3: Rec.2020 10 bit -> 8 bit
16:53dwlsalmeida[d]: Wait, what exactly is `Rec. 709 10 bit`
16:54dwlsalmeida[d]: I was expecting the fourcc for a specific YUV format instead
17:04avhe[d]: i believe those names are misleading, 0 and 1 won't do any post-processing (not converting bt2020 to bt709 for instance), then 2 and 3 are for dithering down to 8-bit (which also requires binding an additional buffer to the DISPLAY_BUF registers)
17:15dwlsalmeida[d]: ok, I still do not see a way to switch, say to P010 in HEVC
17:17dwlsalmeida[d]: I guess for a first version we can just advertise NV12 support and let it be, `vulkanh265dec` doesn't even support anything else either
17:20dwlsalmeida[d]: I guess we can always ask for a 10bit decode using ffmpeg `nvdec` hwaccel, and then trace that using Averne's tracer
17:28avhe[d]: my nvtegra ffmpeg backend supports 10-bit if you want to check it out <https://github.com/averne/FFmpeg/blob/nvtegra/libavcodec/nvtegra_hevc.c#L250-L267>
17:31avhe[d]: i just match `disp_output_mode` with the bit depth requested by the application, fill the relevant fields (`bit_depth_luma/chroma`, etc) and that's it
17:34dwlsalmeida[d]: ok, so either NV12 (i.e. `output == 0`), or P010 (`output == 1`) right
17:35dwlsalmeida[d]: in which case, what about everything else from this list?
17:35dwlsalmeida[d]: https://gstreamer.freedesktop.org/documentation/nvcodec/nvh265dec.html#src
17:57asdqueerfromeu[d]: awilfox[d]: That would be a 🔺 project
18:00avhe[d]: dwlsalmeida[d]: not certain, i'd be surprised if GBR was happening entirely within nvdec though
18:01avhe[d]: i'd P012 probably also uses `output == 1`, and Y444 needs stuff from the v1 subsubstructure, but again i've never had a good look at those features
18:01avhe[d]: i'd say*
19:57airlied[d]: I'd just copy the format the prop driver exposes
20:39valentineburley[d]: dwlsalmeida[d]: `PIPE_FORMAT_NV12` is a non-colorspace-converted YUV pipe format and `PIPE_FORMAT_G8_B8R8_420_UNORM` is an RGB pipe format.
20:39valentineburley[d]: That commit was needed for some (mobile) hardware that can't do CSC
23:00karolherbst[d]: skeggsb9778: maybe something for you to look into? https://gitlab.freedesktop.org/drm/nouveau/-/issues/402
23:00karolherbst[d]: reporter spent quite some time it seems to figure out what broke and why