Currently the work-flow is: VASurface -> vaDeriveImage -> VAImageBufferType -> VABufferID -> vaAcquireBufferHandle -> 1 dmabuf FD value. This only work if the underlying memory is contiguous. But if the VASurface is backed by at least 2 non-contiguous memory (for example one for each NV12 plane) then it would require to export each plane with a different dmabuf FD value. I think a solution could be to create to either create a new equivalent function vaAcquireBufferHandle2 that takes a plane id into parameter. Or a new member in VABufferInfo. Or a new function that vaGetPlaneBufferID(VAImageID img, int plane, VABufferID *out_buf). Note that in vdpau it is supported: struct VdpSurfaceDMABufDesc { /* DMA-buf file descriptor */ uint32_t handle; /* Width in pixel */ uint32_t width; /* Height in pixel */ uint32_t height; /* Offset in bytes */ uint32_t offset; /* Stride in bytes */ uint32_t stride; /* VDP_RGBA_FORMAT_* as defined in the VDPAU spec and above. */ uint32_t format; }; VdpStatus VdpVideoSurfaceDMABuf( VdpVideoSurface surface, VdpVideoSurfacePlane plane, struct VdpSurfaceDMABufDesc * result)
Yes, this is an isssue for use cases where we split off the y/u/v into separate planes and then we require three FD. It's on my list of changes. I agree, this is a needed change.
(In reply to Julien Isorce from comment #0) > Currently the work-flow is: > > VASurface -> vaDeriveImage -> VAImageBufferType -> VABufferID -> > vaAcquireBufferHandle -> 1 dmabuf FD value. > > This only work if the underlying memory is contiguous. But if the VASurface > is backed by at least 2 non-contiguous memory (for example one for each NV12 > plane) then it would require to export each plane with a different dmabuf FD > value. > Do you mean a VA surface is backed with two different buffer objects in your driver? In libva-intel-driver each surface is created with only one GEM buffer object, so the same dmabuf FD is exported for all planes. You can get the layer out via the derived image.
(In reply to Sean V Kelley from comment #1) > Yes, this is an isssue for use cases where we split off the y/u/v into > separate planes and then we require three FD. It's on my list of changes. > > I agree, this is a needed change. I am glad to hear that. Thx (In reply to haihao from comment #2) > Do you mean a VA surface is backed with two different buffer objects in your > driver? In libva-intel-driver each surface is created with only one GEM > buffer object, so the same dmabuf FD is exported for all planes. You can get > the layer out via the derived image. Yes
Julien, Can you work under the existing constraints of VA Surface or do you need something more? My requirements are different as they pertain to ChromeOS. Thanks, Sean
(In reply to Sean V Kelley from comment #4) > Julien, > > Can you work under the existing constraints of VA Surface or do you need > something more? > Hi, I currently workaround it with an extra step: gstvaapipostproc to convert it to RGB since I know it will be one contiguous memory in that case. Then I export it a dmabuf and import into an EGLImage later on through gstglimagesink. So currently in vaapi mesa gallium I only allow to derive_image for RGB surfaces. > My requirements are different as they pertain to ChromeOS. > > Thanks, > > Sean I still need this change. What has changed since #1 ? :) Thx!
Hi Julien, In ChromeOS we would always have to convert a decoded video surface (YUV) to RGB format for composition. That in itself incurs a cost. Hardware overlays which supported YUV and newer platforms with display out support for YUV needed ways to work with graphics stack and video stack for textures. So we looked into Sub-bo handling for planar fb formats. It was an idea about the kernel exposing the buffer objects of rendered surfaces (Y and UV) as contiguous in memory. This would avoid conversion on the export side and also make GL import easier with existing hardware. However, short the kernel managing that, we could modify the UMD to better expose the planes with non-contiguous memory. The fundamental requirement was that we be able to import a single buffer into EGL so we can do texture sampling on it, but we also need to be able to reference individual buffers in the YUV buffer for the video decoder. Your issue is quite similar. What we need are multi-planar functions/access for different bo handles in the sharing of non-contiguous memory by the UMD. Sean
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.