Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
vaapipostproc: implement the negotiation of memory:DMABuf in sink pad
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.