[Libva] [PATCH] vaBeginPicture: allow processing surfaces exported to dmabuf

[Julien Isorce]

Hi Zhao,

You was right I can free the derived image and still be able to do further
VPP on the surface. Also the exported dmabuf is still usable.

The patch in gstreamer-vaapi is :
https://github.com/CapOM/gstreamer-vaapi/commit/46a673d2396ac4c60d4adc5dd608ddd67d01856b
It is still ongoing so I have not submitted it for review.

So the patch "vaBeginPicture: allow processing surfaces exported to dmabuf"
for vaapi-intel-driver is not needed.
Thx for your help.

Cheers
Julien


On 29 September 2015 at 09:09, Julien Isorce <julien.isorce at gmail.com>
wrote:

> Hi Zhao,
>
> Thx for the answer. Here are the reason why I moved the safety to app
> handling:
>
> Use case is gstreamer-vaapi:
> Ex: gstvaapipostproc ! dmabuf_rgbx ! glimagesink
>
> Vpp output a rgbx va surface and export it as dmabuf with
> vaAcquireBufferHandle. As it manages a pool of gst buffers, it exports N
> surface only one time when starting. So that when processing (feeding
> output va surfaces) they are already exported. Which means derived first.
>
> II think it is more efficient than releasing/ re-exporting each time. And
> it seems this is how gstreamer-vaapi is designed.
> I can try to see if I can still free the derived image + calling
> vaReleaseBufferHandle but keep the FD valid in the gst buffer for usage
> along the run . And still be able to import it through eglcreateimage in
> glimagesink.
>
> Cheers
> Julien
>
>
> On Tuesday, 29 September 2015, Zhao Yakui <yakui.zhao at intel.com> wrote:
>
>> On 09/29/2015 06:05 AM, Julien Isorce wrote:
>>
>>> is_surface_busy looks for locked or derived.
>>> If VPP and surface is not locked it should only check fail
>>> for derived if it is not exported to dmabuf.
>>>
>>> XXX: maybe checking CODEC_PROC + not locked is enough
>>> to allow processing.
>>>
>>
>> Hi, Julien
>>
>>     What is the main concern of checking the surface_busy for VPP? what
>> is the usage scenario?
>>
>>     When one surface is exported or derived, maybe other components are
>> using them. In such case it is difficult to synchronize between multiple
>> components. So currently it uses the safe mode to assure that the surface
>> is not accessed.
>>
>>     If you want to use the derived surface for the further VPP, I suggest
>> that you can free the derived image.
>>
>> thanks.
>>   Yakui
>>
>>
>>> Signed-off-by: Julien Isorce<j.isorce at samsung.com>
>>> ---
>>>   src/i965_drv_video.c | 24 ++++++++++++++++++++++--
>>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
>>> index bf599d6..0d6f513 100644
>>> --- a/src/i965_drv_video.c
>>> +++ b/src/i965_drv_video.c
>>> @@ -2610,8 +2610,28 @@ i965_BeginPicture(VADriverContextP ctx,
>>>       obj_config = obj_context->obj_config;
>>>       ASSERT_RET(obj_config, VA_STATUS_ERROR_INVALID_CONFIG);
>>>
>>> -    if (is_surface_busy(i965, obj_surface))
>>> -        return VA_STATUS_ERROR_SURFACE_BUSY;
>>> +    if (obj_context->codec_type == CODEC_PROC) {
>>> +        if (obj_surface->locked_image_id != VA_INVALID_ID)
>>> +            return VA_STATUS_ERROR_SURFACE_BUSY;
>>> +
>>> +        if (obj_surface->derived_image_id != VA_INVALID_ID) {
>>> +            /* Allow derived surface exported to dmabuf. */
>>> +            struct object_buffer *obj_buffer = NULL;
>>> +            struct object_image *obj_image =
>>> IMAGE(obj_surface->derived_image_id);
>>> +            if (!obj_image)
>>> +                return VA_STATUS_ERROR_INVALID_IMAGE;
>>> +
>>> +            obj_buffer = BUFFER(obj_image->image.buf);
>>> +            if (!obj_buffer)
>>> +                return VA_STATUS_ERROR_INVALID_BUFFER;
>>> +
>>> +            if (obj_buffer->export_state.mem_type !=
>>> VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME)
>>> +                return VA_STATUS_ERROR_SURFACE_BUSY;
>>> +        }
>>> +    } else {
>>> +        if (is_surface_busy(i965, obj_surface))
>>> +            return VA_STATUS_ERROR_SURFACE_BUSY;
>>> +    }
>>>
>>>       if (obj_context->codec_type == CODEC_PROC) {
>>>           obj_context->codec_state.proc.current_render_target =
>>> render_target;
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20151005/a6f6923e/attachment.html>