GNOME Bugzilla – Bug 797010
vaapipostproc: implement the negotiation of memory:DMABuf in sink pad
Last modified: 2018-11-03 15:55:39 UTC
In order to import tiled buffers vaapipostproc should negotiate memory:DMABUf in its sink pad For more information see: https://lists.freedesktop.org/archives/gstreamer-devel/2018-August/068973.html
Created attachment 373508 [details] [review] Patch. Adds DMA buffer input pad type to gstvaapipostproc. Hello. We wrote a patch that allows the vaapipostproc plugin to accept input data in the DMABuf format. Is it possible to add it to the repository in the future?
I'd like to hold on this effort until we get a clearer view on Intel on how to address the issues cause by the implicit usage of modifiers. As it is now, these DMABuf cannot be imported anywhere else then into another VAAPI component using the same GPU. This unfortunate design decision breaks random use cases.
(In reply to Nicolas Dufresne (ndufresne) from comment #2) > I'd like to hold on this effort until we get a clearer view on Intel on how > to address the issues cause by the implicit usage of modifiers. As it is > now, these DMABuf cannot be imported anywhere else then into another VAAPI > component using the same GPU. This unfortunate design decision breaks random > use cases. Isn't it better then nothing? Personally I need this not to send dmabuf anywhere, but to transform DMABuf into VASurface without unnecessary copying. Again, GL already *does* export DMABuf, this fix only adds the possibility of accepting DMABuf to vaapipostproc. This is unfortunate that gstreamer could not ensure that vaapi and GL are using the same device, but I do use them on the same device and I don't want to copy memory twice from and to GPU.
Feel free to manage your own copy for you own needs. I'm just trying to do my job of making sure we have an answers for the general use cases. I can show you screenshot of what sad users will see when they hit that issue, it's not viewable. These is problems in the DMABuf support design inside VAAPI, and we need to find a way to prevent these from breaking video playback on random people machine, or to get that fixed by the VAAPI folks. If it's not you carrying this, it will need to be someone else. A typical user is a PC owner with NVIDIA + Intel Accelerator. It is quite possible this user will want to use Intel VAAPI, because NVDEC isn't shipped by distro, combined with their fast NVIDIA GPU. With Intel implementation of DMABuf, this does not fail, but does not render anything viewable.
So, I had a bit of time to look around, Vaapi gained support for this by introducing VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME_2. We should port all DMABuf exportation usage to that. There is a new export method, which will provide the modififers. Then we can in a first place fail the export if there is a modififers and eventually expose the exported buffers with the modifiers. On the VPP side, I bet we can influence the modifiers that will be used somehow, I haven't search yet.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/105.