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

[Julien Isorce]

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/20150929/dde4e1c4/attachment.html>