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 <[email protected]> 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 <[email protected]> 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<[email protected]> >>> --- >>> 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; >>> >> >>
_______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
