After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796626 - vaapi: Add GEM buffer support
vaapi: Add GEM buffer support
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-19 07:13 UTC by Fei
Modified: 2018-11-03 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Fei 2018-06-19 07:13:05 UTC
This is an Intel feature requirement.

The video driver's vaCreateSurfaces2 driver entrypoint shall accept a VASurfaceAttribMemoryType attribute value of VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_PRIME. This attribute will instruct the driver to use the buffer whose Prime file descriptor is stored in the VASurfaceAttribExternalBufferDescriptor as the backing buffer for the new VASurface.
Comment 1 sreerenj 2018-06-20 02:10:47 UTC
The basic infrastructure code is already there for KERNEL_PRIME buffer.I don't know how we test this feature :)
Write a source element which can output GEM buffer id?
Do we have any upstream GL element which can output GEM buffer?
Do we need specific caps-negotiation?
Comment 2 Nicolas Dufresne (ndufresne) 2018-06-20 14:03:24 UTC
Can someone explain how is this related to GStreamer, it's so vague that I was temped to close this bug (and the others) either away. Answer those two questions, and we may be able to keep track or this.

What is the issue you are facing ?
What do you expect do happen instead?
Comment 3 Víctor Manuel Jáquez Leal 2018-06-20 14:19:18 UTC
The first problem is that attribute value isn't yet defined in va.h:

https://github.com/intel/libva/blob/master/va/va.h#L1265

and I can't find any issue discussing its merge.
Comment 4 sreerenj 2018-06-20 17:55:26 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #3)
> The first problem is that attribute value isn't yet defined in va.h:
> 
> https://github.com/intel/libva/blob/master/va/va.h#L1265
> 
> and I can't find any issue discussing its merge.

I think Fei misspelled it:
VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_DRM
Comment 5 sreerenj 2018-06-20 18:06:34 UTC
(In reply to Nicolas Dufresne (ndufresne) from comment #2)
> Can someone explain how is this related to GStreamer, it's so vague that I
> was temped to close this bug (and the others) either away. Answer those two
> questions, and we may be able to keep track or this.
> 
> What is the issue you are facing?
> What do you expect do happen instead?

VA-API allows creating a vaSurface from,
a: VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME (dmabuf)
b: VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_DRM (gem buffer)

We have proper negotiation support for dmabuf in gst-vaapi. For gem buf, there are internal methods implemented in gstreamer-vaapi to export gem-buffer-id to vaSurface. But no test case to test it. And no specific caps negotiation too.

IIRC, Using cluttersink with EGL (GLTextureUploadMeta) was using the va-surface-to-gem-buffer path. But I don't know whether it is still working.
Comment 6 Soon, Thean Siew 2018-06-22 03:05:20 UTC
This feature should be related to dmabuf, not gem buffer where the correct attribute should be VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME. I believe gst-vaapi should already have proper support on VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME. Maybe remaining work is related to the new DRM PRIME API?
Comment 7 Nicolas Dufresne (ndufresne) 2018-06-22 03:19:45 UTC
This is still pretty vague. Give me a reason to keep this bug open and managed by the community please, otherwise I believe it should close as invalid tomorrow. There is clearly close door discussion behind the creation of this issue.
Comment 8 sreerenj 2018-06-22 19:22:24 UTC
I believe the request is like this:

Assume there is an upstream element which can provide gem_buffer handle,
then gst-vaapi can bind it to vaSurface similar to what we do for dmabuf and avoid the copy.

Second use case: assume there is a downstream element which can work on gembuffer handle (eg: get eglimage from the gembuffer id), then gst-vaapi can extract the gem-buffer-id from vasurface and export it to downstream (similar to dmabuf).

Now questions:
1: Is there any customer using gem-buffer like this without using dmabuf?
2: We have dmabuf which should work for any use case, so do we really need it other than just for a feature completeness ? :)
Comment 9 Nicolas Dufresne (ndufresne) 2018-06-22 20:37:22 UTC
DmaBuf sharing is still missing modifiers.  But indeed, it does not seems very useful to have GEM, ION or other handles that are dmabuf compatible. Also, it's not because VAAPI have it that we must use it. I would discourage adding this extra layer of complexity without a use case.
Comment 10 GStreamer system administrator 2018-11-03 15:55:19 UTC
-- 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/102.