On Fri, 2014-05-09 at 07:57 -0600, Moore, Anthony W wrote:
> Hello,

Hi, Moore

    Thanks for your sample code. 
    Your suggestion is helpful.

Thanks.
    Yakui
> 
> If you're goal is to call vaSyncSurface instead of vaPutSurface in mplayer 
> without modifying the program you can try creating a shared object with the 
> code below then use LD_PRELOAD to call this version of vaPutSurface which 
> calls vaSyncSurface..
> 
> LD_PRELOAD=trap_va.so mplayer
> 
> ---
> #define _GNU_SOURCE
> 
> #include <va/va.h>
> #include <X11/Xlib.h>
> #include <dlfcn.h>
> #include <unistd.h>
> 
> 
> VAStatus (*next_vaSyncSurface) (
>     VADisplay dpy,
>     VASurfaceID surface       
> ) = NULL;
> 
> 
> VAStatus vaPutSurface (
>     VADisplay dpy,
>     VASurfaceID surface,      
>     Drawable draw, /* X Drawable */
>     short srcx,
>     short srcy,
>     unsigned short srcw,
>     unsigned short srch,
>     short destx,
>     short desty,
>     unsigned short destw,
>     unsigned short desth,
>     VARectangle *cliprects, /* client supplied destination clip list */
>     unsigned int number_cliprects, /* number of clip rects in the clip list */
>     unsigned int flags /* PutSurface flags */
>     )
> {
>       if(next_vaSyncSurface == NULL )
>           next_vaSyncSurface = dlsym(RTLD_NEXT, "vaSyncSurface");
>     return next_vaSyncSurface(dpy, surface);
> 
> }
> 
> // gcc -fPIC -shared trap_va.c -Wl,-shared,-soname,libtrap_va.so-ldl
> --
> 
> -----Original Message-----
> From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of Gwenole 
> Beauchesne
> Sent: Friday, May 9, 2014 3:38 AM
> To: Zhao, Yakui
> Cc: libva@lists.freedesktop.org
> Subject: Re: [Libva] [PATCH Libva-intel-driver] Add one option of bypassing 
> rendering function to test decoding
> 
> Hi,
> 
> 2014-05-08 10:24 GMT+02:00 Zhao Yakui <yakui.z...@intel.com>:
> > On Thu, 2014-05-08 at 02:14 -0600, Yuan, Shengquan wrote:
> >> Yes, va_x11.c has the code. It looks I just checked a wrong file.
> >
> > It doesn't matter.
> >
> >>
> >> I think its application's responsibility to call vaSyncSurface to make 
> >> sure the decoding on the surface is completed before it calls vaPutSurface 
> >> for display.
> >
> > Understand your concern.
> > But in fact most application doesn't care the sync between decoding 
> > and vaPutSurface and they won't call the vaSyncSurface explicitly. 
> > Instead the low level driver can handle the sync(And the sync is 
> > implicitly handled).
> 
> I believe it has always been the intention to have the VA driver implicitly 
> sync, and more efficiently, the surface before performing the rendering 
> operations in the vaPutSurface() implementation.
> 
> > So my proposal is to call the vaSyncSurface for the dummy vaPutSurface.
> 
> I'd prefer not, but as per what I wrote just above, that could be a 
> reasonable enough median solution. i.e. if we already have a means at the 
> libva level to disable vaPutSurface(), then we would still need to honour 
> this behaviour (sync) when putsurface is disabled.
> 
> However, please describe your initial intentions with disabling 
> vaPutSurface(), there are probably more appropriate means to achieve this 
> right into the application itself (e.g. per-VO option), or use a more 
> appropriate one for decode-only purposes for instance (e.g.
> `ffmpeg' tool itself).
> 
> Thanks,
> Gwenole.
> 
> >> -----Original Message-----
> >> From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf Of 
> >> Zhao Yakui
> >> Sent: Thursday, May 08, 2014 4:10 PM
> >> To: Yuan, Shengquan
> >> Cc: libva@lists.freedesktop.org
> >> Subject: Re: [Libva] [PATCH Libva-intel-driver] Add one option of 
> >> bypassing rendering function to test decoding
> >>
> >> On Thu, 2014-05-08 at 01:09 -0600, Yuan, Shengquan wrote:
> >> > export LIBVA_FOOL_POSTP=1
> >> >
> >> > Unfortunately, it is not handled in x11/va_x11.c: vaPutSurface
> >> >
> >> > We may need similar codes as android/va_androi.c:vaPutSurface for 
> >> > va_x11.c:vaPutSurface
> >> >
> >> >     if (fool_postp)
> >> >         return VA_STATUS_SUCCESS;
> >>
> >> Thanks for your suggestion.
> >> Now the "LIBVA_FOOL_POSTP=1" can be used for bypassing vaPutSurface in 
> >> x11/va_x11.c and android/va_android.c.
> >>
> >> Of course IMO it will make sense that the vaSyncSurface is also called 
> >> instead of real dummy vaPutSurface when the LIBVA_FOOL_POSTP is set.
> >> (This is to assure that the previous decoding is finished).
> >>
> >> Thanks.
> >>     Yakui
> >>
> >> >
> >> > Thanks
> >> > -Austin
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Libva [mailto:libva-boun...@lists.freedesktop.org] On Behalf 
> >> > Of Zhao Yakui
> >> > Sent: Tuesday, May 06, 2014 12:50 PM
> >> > To: Xu, Guangxin
> >> > Cc: z...@freedesktop.org; libva@lists.freedesktop.org
> >> > Subject: Re: [Libva] [PATCH Libva-intel-driver] Add one option of 
> >> > bypassing rendering function to test decoding
> >> >
> >> > On Mon, 2014-05-05 at 22:44 -0600, Xu, Guangxin wrote:
> >> > > Hi Yakui
> >> > > This will introduce side effect to normal case. It will search string 
> >> > > in environment list. No matter INTEL_DECODE_BENCH defined or not.
> >> >
> >> > Maybe the getenv("INTEL_DECODE_BENCH") will cost some time as it 
> >> > searches env list. But compared with the time of rendering/decoding 
> >> > operation, the cost time can almost be ignored.
> >> >
> >> > >
> >> > >
> >> > > -----Original Message-----
> >> > > From: Libva [mailto:libva-boun...@lists.freedesktop.org] On 
> >> > > Behalf Of Zhao Yakui
> >> > > Sent: Tuesday, May 6, 2014 12:36 PM
> >> > > To: Xiang, Haihao
> >> > > Cc: z...@freedesktop.org; libva@lists.freedesktop.org
> >> > > Subject: Re: [Libva] [PATCH Libva-intel-driver] Add one option of 
> >> > > bypassing rendering function to test decoding
> >> > >
> >> > > On Mon, 2014-05-05 at 22:19 -0600, Xiang, Haihao wrote:
> >> > > > It would be better not to call vaPutSurface() in your benchmark 
> >> > > > if you want to ignore rendering.
> >> > >
> >> > > Thanks for your review.
> >> > >
> >> > > It is also one solution. Currently the bench test is based on the 
> >> > > mplayer-vaapi. In such case it is not easy to bypass the vaPutSurface.
> >> > > At the same time it also needs to add the function of waiting for the 
> >> > > completion of decoding.
> >> > >
> >> > > >
> >> > > > Thanks
> >> > > > Haihao
> >> > > >
> >> > > >
> >> > > > > From: Zhao Yakui <yakui.z...@intel.com>
> >> > > > >
> >> > > > > Signed-off-by: Zhao Yakui <yakui.z...@intel.com>
> >> > > > > ---
> >> > > > >  src/i965_drv_video.h  | 3 +++  src/i965_output_dri.c | 4 
> >> > > > > ++++
> >> > > > >  2 files changed, 7 insertions(+)
> >> > > > >
> >> > > > > diff --git a/src/i965_drv_video.h b/src/i965_drv_video.h 
> >> > > > > index
> >> > > > > 0e32f7d..70755d2 100644
> >> > > > > --- a/src/i965_drv_video.h
> >> > > > > +++ b/src/i965_drv_video.h
> >> > > > > @@ -432,6 +432,9 @@ extern VAStatus 
> >> > > > > i965_CreateSurfaces(VADriverContextP ctx,
> >> > > > >                      int format,
> >> > > > >                      int num_surfaces,
> >> > > > >                      VASurfaceID *surfaces);
> >> > > > > +extern VAStatus i965_SyncSurface(VADriverContextP ctx,
> >> > > > > +                                 VASurfaceID render_target);
> >> > > > > +
> >> > > > >
> >> > > > >  #define I965_SURFACE_MEM_NATIVE             0
> >> > > > >  #define I965_SURFACE_MEM_GEM_FLINK          1
> >> > > > > diff --git a/src/i965_output_dri.c b/src/i965_output_dri.c 
> >> > > > > index
> >> > > > > 717ee9a..645a7d1 100644
> >> > > > > --- a/src/i965_output_dri.c
> >> > > > > +++ b/src/i965_output_dri.c
> >> > > > > @@ -140,6 +140,10 @@ i965_put_surface_dri(
> >> > > > >      if (!obj_surface || !obj_surface->bo)
> >> > > > >          return VA_STATUS_SUCCESS;
> >> > > > >
> >> > > > > +    if (getenv("INTEL_DECODE_BENCH")) {
> >> > > > > +        i965_SyncSurface(ctx, surface);
> >> > > > > +        return VA_STATUS_SUCCESS;
> >> > > > > +    }
> >> > > > >      _i965LockMutex(&i965->render_mutex);
> >> > > > >
> >> > > > >      dri_drawable = dri_vtable->get_drawable(ctx, 
> >> > > > > (Drawable)draw);
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Libva mailing list
> >> > > Libva@lists.freedesktop.org
> >> > > http://lists.freedesktop.org/mailman/listinfo/libva
> >> >
> >> >
> >> > _______________________________________________
> >> > Libva mailing list
> >> > Libva@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/libva
> >>
> >>
> >> _______________________________________________
> >> Libva mailing list
> >> Libva@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/libva
> >
> >
> > _______________________________________________
> > Libva mailing list
> > Libva@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libva
> _______________________________________________
> Libva mailing list
> Libva@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libva


_______________________________________________
Libva mailing list
Libva@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libva

Reply via email to