[FFmpeg-devel] [PATCH V3 3/5] libavutil/hwcontext_vulkan: Allocate vkFrame in one memory

[Chen, Wenbin]

> 26 Nov 2021, 03:54 by wenbin.chen at intel.com:
> 
> > The vaapi can import external frame, but the planes of the external
> > frames should be in the same drm object. A new option
> "contiguous_planes"
> > is added to device. This flag tells device to allocate places in one
> > memory. When device is derived from vaapi this flag will be enabled.
> > A new flag frame_flag is also added to AVVulkanFramesContext. User
> > can use this flag to force enable or disable this behaviour.
> > A new variable "offset "is added to AVVKFrame. It describe describe the
> > offset from the memory currently bound to the VkImage.
> >
> > Signed-off-by: Wenbin Chen <wenbin.chen at intel.com>
> >
> 
> Why is a new offset variable needed?
> vkGetImageSubresourceLayout is valid for DRM tiled images.
> According to the specs,
> "If the image’s tiling is VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT,
> then vkGetImageSubresourceLayout describes one memory plane of the
> image. If the image’s tiling is
> VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT and the image is non-
> linear, then the returned layout has an implementation-dependent meaning;
> the vendor of the image’s DRM format modifier may provide documentation
> that explains how to interpret the returned layout.".
> 
> Isn't this what you already have in the offset field?

The offset we get from vkGetImageSubresourceLayout is from the start of the image or plane.
The offset drm_object need is from the start of the memory, and vkGetImageSubresourceLayout
cannot get this information. I add a new offset variable because I allocate all planes in one memory 
not because I use VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".