Hi, According to libva document (http://01org.github.io/libva_staging_doxygen/group__api__core.html#ga4af3... 10aefeb4ca4315e2c7cbd653), Surfaces are bound to a context if passing them as an argument when creating the context. Seeing intel-vaapi-driver code, the surfaces are just stored in object_context.render_targets. A surface processed by vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified in vaBeginPicture(). (object_context.current_render_target) It looks like a surface can be processed using a context by being specified in vaBeginPicture(), even if it is not bound to the context. Here, my questions are below. What is the advantage of binding? In what circumstances do we need to associate the context with surfaces? In which scenarios passing surfaces to vaCreateContext is required, and in which it is not?

-----Original Message----- From: Hirokazu Honda [mailto:hiroh@chromium.org] Sent: Friday, June 30, 2017 5:14 PM To: Xiang, Haihao <haihao.xiang(a)intel.com&gt; Cc: intel-vaapi-media(a)lists.01.org Subject: Re: [intel-vaapi-media] The advantage of binding between Surface and Context. Hi Xiang, What is inconvenient if a surface is used between different contexts? Will a bug happen in such case? Best, Hirokazu Honda On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: > > Hi Honda, > > The comment that a surface is bound to a given context and it can't be > used to created for another context was added initially for decode > pipeline. It is inconvenient when a surface is used between different > contexts, e.g. a surface is the output of VPP, then this surface is > used as input of encode pipeline. We ever discussed this topic on > libva(a)list.freedesktop.org, and render_targets is taken as a hint only > to the driver now, which means the surfaces used in the given context > aren't limited to render_targets. We will update va.h in libva2 > > Thanks > Haihao > > >> Hi, >> >> According to libva document >> (http://01org.github.io/libva_staging_doxygen/group__api__core.html#g >> a4af336e4 >> 10aefeb4ca4315e2c7cbd653), >> Surfaces are bound to a context if passing them as an argument when >> creating the context. >> Seeing intel-vaapi-driver code, the surfaces are just stored in >> object_context.render_targets. >> >> A surface processed by >> vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified in >> vaBeginPicture(). (object_context.current_render_target) >> It looks like a surface can be processed using a context by being >> specified in vaBeginPicture(), even if it is not bound to the context. >> >> Here, my questions are below. >> What is the advantage of binding? >> In what circumstances do we need to associate the context with surfaces? >> In which scenarios passing surfaces to vaCreateContext is required, >> and in which it is not? > > >> >> Best Regards, >> Hirokazu Honda >> _______________________________________________ >> intel-vaapi-media mailing list >> intel-vaapi-media(a)lists.01.org >> https://lists.01.org/mailman/listinfo/intel-vaapi-media

Hi Xiang, Thanks for updating first. No bug happens even in the present implementation, when a surface is bound to multiple contexts. Right?

Then, let me return my first question: What is the advantage of binding Surface to Context? If surface can be bound to multiple surfaces, bounding does not add any limitation to Surface and Context. If no limitation causes, it sounds there is actually no difference between bounding and no bounding.

Hi, I am sorry for digging up this old thread. I am wondering we need to call vaSyncSurface() on a surface when the surface is passed from context A to context B. IIUC, surfaces are not bound to context and operations on a surface are not also bound to a context? cc: kamesan@, who asked me first. kamesan@ passed a surface from context for mjpeg decode to context for vpp. [1] [1] https://chromium-review.googlesource.com/c/chromium/src/+/1558746/22/medi... Best, -Hiro On Mon, Jul 10, 2017 at 3:02 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: > > > > Hi Xiang, > > > > Thanks for updating first. > > No bug happens even in the present implementation, when a surface is > > bound to multiple contexts. Right? > > Yes for our driver. > > > Then, let me return my first question: What is the advantage of > > binding Surface to Context? > > If surface can be bound to multiple surfaces, bounding does not add > > any limitation to Surface and Context. > > If no limitation causes, it sounds there is actually no difference > > between bounding and no bounding. > > Yes. > > > > > > Thanks, > > Hirokazu Honda > > > > On Fri, Jun 30, 2017 at 11:01 PM, Xiang, Haihao < haihao.xiang(a)intel.com&gt; > > wrote: > > > Hi Hirokazu, > > > > > > A surface should be able to be used in different contexts, but according to > > > the comment below in va.h, a surface can't be shared between two contexts. > > > This requirement is not reasonable for transcoding pipeline. so we will > > > update va.h in libva2 to remove this limitation and don't require the > > > surface to be tied to a given context. > > > > > > * Surfaces will be bound to a context when the context is created. Once > > > * a surface is bound to a given context, it cannot be used to create > > > * another context. The association is removed when the context is destroyed > > > > > > Thanks > > > Haihao > > > > > > > > > > -----Original Message----- > > > > From: Hirokazu Honda [mailto:hiroh@chromium.org] > > > > Sent: Friday, June 30, 2017 5:14 PM > > > > To: Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > Cc: intel-vaapi-media(a)lists.01.org > > > > Subject: Re: [intel-vaapi-media] The advantage of binding between Surface > > > > and Context. > > > > > > > > Hi Xiang, > > > > > > > > What is inconvenient if a surface is used between different contexts? > > > > Will a bug happen in such case? > > > > > > > > Best, > > > > Hirokazu Honda > > > > > > > > On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao < haihao.xiang(a)intel.com&gt; > > > > wrote: > > > > > > > > > > Hi Honda, > > > > > > > > > > The comment that a surface is bound to a given context and it can't be > > > > > used to created for another context was added initially for decode > > > > > pipeline. It is inconvenient when a surface is used between different > > > > > contexts, e.g. a surface is the output of VPP, then this surface is > > > > > used as input of encode pipeline. We ever discussed this topic on > > > > > libva(a)list.freedesktop.org, and render_targets is taken as a hint only > > > > > to the driver now, which means the surfaces used in the given context > > > > > aren't limited to render_targets. We will update va.h in libva2 > > > > > > > > > > Thanks > > > > > Haihao > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > According to libva document > > > > > > ( http://01org.github.io/libva_staging_doxygen/group__api__core.html#g > > > > > > a4af336e4 > > > > > > 10aefeb4ca4315e2c7cbd653), > > > > > > Surfaces are bound to a context if passing them as an argument when > > > > > > creating the context. > > > > > > Seeing intel-vaapi-driver code, the surfaces are just stored in > > > > > > object_context.render_targets. > > > > > > > > > > > > A surface processed by > > > > > > vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified in > > > > > > vaBeginPicture(). (object_context.current_render_target) > > > > > > It looks like a surface can be processed using a context by being > > > > > > specified in vaBeginPicture(), even if it is not bound to the context. > > > > > > > > > > > > Here, my questions are below. > > > > > > What is the advantage of binding? > > > > > > In what circumstances do we need to associate the context with > > > > > > surfaces? > > > > > > In which scenarios passing surfaces to vaCreateContext is required, > > > > > > and in which it is not? > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > Hirokazu Honda > > > > > > _______________________________________________ > > > > > > intel-vaapi-media mailing list > > > > > > intel-vaapi-media(a)lists.01.org > > > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media _______________________________________________ intel-vaapi-media mailing list intel-vaapi-media(a)lists.01.org https://lists.01.org/mailman/listinfo/intel-vaapi-media

> Hi Xiang, > > Thanks for updating first. > No bug happens even in the present implementation, when a surface is > bound to multiple contexts. Right? Yes for our driver. > Then, let me return my first question: What is the advantage of > binding Surface to Context? > If surface can be bound to multiple surfaces, bounding does not add > any limitation to Surface and Context. > If no limitation causes, it sounds there is actually no difference > between bounding and no bounding. Yes. > > Thanks, > Hirokazu Honda > > On Fri, Jun 30, 2017 at 11:01 PM, Xiang, Haihao <haihao.xiang@intel.com<mailto:haihao.xiang@intel.com>> > wrote: > > Hi Hirokazu, > > > > A surface should be able to be used in different contexts, but according to > > the comment below in va.h, a surface can't be shared between two contexts. > > This requirement is not reasonable for transcoding pipeline. so we will > > update va.h in libva2 to remove this limitation and don't require the > > surface to be tied to a given context. > > > > * Surfaces will be bound to a context when the context is created. Once > > * a surface is bound to a given context, it cannot be used to create > > * another context. The association is removed when the context is destroyed > > > > Thanks > > Haihao > > > > > > > -----Original Message----- > > > From: Hirokazu Honda [mailto:hiroh@chromium.org<mailto:hiroh@chromium.org>] > > > Sent: Friday, June 30, 2017 5:14 PM > > > To: Xiang, Haihao <haihao.xiang@intel.com<mailto:haihao.xiang@intel.com>> > > > Cc: intel-vaapi-media@lists.01.org<mailto:intel-vaapi-media@lists.01.org> > > > Subject: Re: [intel-vaapi-media] The advantage of binding between Surface > > > and Context. > > > > > > Hi Xiang, > > > > > > What is inconvenient if a surface is used between different contexts? > > > Will a bug happen in such case? > > > > > > Best, > > > Hirokazu Honda > > > > > > On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao <haihao.xiang@intel.com<mailto:haihao.xiang@intel.com>> > > > wrote: > > > > > > > > Hi Honda, > > > > > > > > The comment that a surface is bound to a given context and it can't be > > > > used to created for another context was added initially for decode > > > > pipeline. It is inconvenient when a surface is used between different > > > > contexts, e.g. a surface is the output of VPP, then this surface is > > > > used as input of encode pipeline. We ever discussed this topic on > > > > libva@list.freedesktop.org<mailto:libva@list.freedesktop.org>, and render_targets is taken as a hint only > > > > to the driver now, which means the surfaces used in the given context > > > > aren't limited to render_targets. We will update va.h in libva2 > > > > > > > > Thanks > > > > Haihao > > > > > > > > > > > > > Hi, > > > > > > > > > > According to libva document > > > > > (http://01org.github.io/libva_staging_doxygen/group__api__core.html#g > > > > > a4af336e4 > > > > > 10aefeb4ca4315e2c7cbd653), > > > > > Surfaces are bound to a context if passing them as an argument when > > > > > creating the context. > > > > > Seeing intel-vaapi-driver code, the surfaces are just stored in > > > > > object_context.render_targets. > > > > > > > > > > A surface processed by > > > > > vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified in > > > > > vaBeginPicture(). (object_context.current_render_target) > > > > > It looks like a surface can be processed using a context by being > > > > > specified in vaBeginPicture(), even if it is not bound to the context. > > > > > > > > > > Here, my questions are below. > > > > > What is the advantage of binding? > > > > > In what circumstances do we need to associate the context with > > > > > surfaces? > > > > > In which scenarios passing surfaces to vaCreateContext is required, > > > > > and in which it is not? > > > > > > > > > > > > > > > > > > Best Regards, > > > > > Hirokazu Honda > > > > > _______________________________________________ > > > > > intel-vaapi-media mailing list > > > > > intel-vaapi-media@lists.01.org<mailto:intel-vaapi-media@lists.01.org> > > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media

If the content of this surface is read in both context A and B, vaSyncSurfaces is not needed.

BTW on Intel platform, you may not call vaSyncSurface() because the underlying drivers handle synchronization between different contexts. In general, vaSyncSurfaces() is required when a surface is passed from context A to context B to make sure the operation in context A is finished. If the content of this surface is read in both context A and B, vaSyncSurfaces is not needed. Thanks Haihao I'm wondering if we should take the comment in [1] as an indication that we should do vaSyncSurfaces(). It's not clear what it means by the application making sure the operations on the surface are synchronized. [1] https://github.com/intel/libva/blob/master/va/va.h#L1214-L1216 On Thu, Jun 6, 2019 at 12:49 AM Hirokazu Honda <hiroh(a)chromium.org&gt; wrote: Hi, I am sorry for digging up this old thread. I am wondering we need to call vaSyncSurface() on a surface when the surface is passed from context A to context B. IIUC, surfaces are not bound to context and operations on a surface are not also bound to a context? cc: kamesan@, who asked me first. kamesan@ passed a surface from context for mjpeg decode to context for vpp. [1] [1] https://chromium-review.googlesource.com/c/chromium/src/+/1558746/22/medi... Best, -Hiro On Mon, Jul 10, 2017 at 3:02 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: > > > > Hi Xiang, > > > > Thanks for updating first. > > No bug happens even in the present implementation, when a surface is > > bound to multiple contexts. Right? > > Yes for our driver. > > > Then, let me return my first question: What is the advantage of > > binding Surface to Context? > > If surface can be bound to multiple surfaces, bounding does not add > > any limitation to Surface and Context. > > If no limitation causes, it sounds there is actually no difference > > between bounding and no bounding. > > Yes. > > > > > > Thanks, > > Hirokazu Honda > > > > On Fri, Jun 30, 2017 at 11:01 PM, Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > wrote: > > > Hi Hirokazu, > > > > > > A surface should be able to be used in different contexts, but according to > > > the comment below in va.h, a surface can't be shared between two contexts. > > > This requirement is not reasonable for transcoding pipeline. so we will > > > update va.h in libva2 to remove this limitation and don't require the > > > surface to be tied to a given context. > > > > > > * Surfaces will be bound to a context when the context is created. Once > > > * a surface is bound to a given context, it cannot be used to create > > > * another context. The association is removed when the context is destroyed > > > > > > Thanks > > > Haihao > > > > > > > > > > -----Original Message----- > > > > From: Hirokazu Honda [mailto:hiroh@chromium.org] > > > > Sent: Friday, June 30, 2017 5:14 PM > > > > To: Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > Cc: intel-vaapi-media(a)lists.01.org > > > > Subject: Re: [intel-vaapi-media] The advantage of binding between Surface > > > > and Context. > > > > > > > > Hi Xiang, > > > > > > > > What is inconvenient if a surface is used between different contexts? > > > > Will a bug happen in such case? > > > > > > > > Best, > > > > Hirokazu Honda > > > > > > > > On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > wrote: > > > > > > > > > > Hi Honda, > > > > > > > > > > The comment that a surface is bound to a given context and it can't be > > > > > used to created for another context was added initially for decode > > > > > pipeline. It is inconvenient when a surface is used between different > > > > > contexts, e.g. a surface is the output of VPP, then this surface is > > > > > used as input of encode pipeline. We ever discussed this topic on > > > > > libva(a)list.freedesktop.org, and render_targets is taken as a hint only > > > > > to the driver now, which means the surfaces used in the given context > > > > > aren't limited to render_targets. We will update va.h in libva2 > > > > > > > > > > Thanks > > > > > Haihao > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > According to libva document > > > > > > (http://01org.github.io/libva_staging_doxygen/group__api__core.html#g > > > > > > a4af336e4 > > > > > > 10aefeb4ca4315e2c7cbd653), > > > > > > Surfaces are bound to a context if passing them as an argument when > > > > > > creating the context. > > > > > > Seeing intel-vaapi-driver code, the surfaces are just stored in > > > > > > object_context.render_targets. > > > > > > > > > > > > A surface processed by > > > > > > vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified in > > > > > > vaBeginPicture(). (object_context.current_render_target) > > > > > > It looks like a surface can be processed using a context by being > > > > > > specified in vaBeginPicture(), even if it is not bound to the context. > > > > > > > > > > > > Here, my questions are below. > > > > > > What is the advantage of binding? > > > > > > In what circumstances do we need to associate the context with > > > > > > surfaces? > > > > > > In which scenarios passing surfaces to vaCreateContext is required, > > > > > > and in which it is not? > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > Hirokazu Honda > > > > > > _______________________________________________ > > > > > > intel-vaapi-media mailing list > > > > > > intel-vaapi-media(a)lists.01.org > > > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media _______________________________________________ intel-vaapi-media mailing list intel-vaapi-media(a)lists.01.org https://lists.01.org/mailman/listinfo/intel-vaapi-media

> Hi Haihao. > > > If the content of this surface is read in both context A and B, > > vaSyncSurfaces is not needed. > > Could you explain this? What is read meant here and why vaSyncSurface > is not needed in the case? Context A and Context B may read-access the same surface. In this case, we needn't call vaSyncSurface to make sure the operation in A is done before using the same surface in B. > > On Tue, Jun 11, 2019 at 1:57 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: > > > > > > BTW on Intel platform, you may not call vaSyncSurface() because the > > underlying drivers handle synchronization between different contexts. > > > > > > In general, vaSyncSurfaces() is required when a surface is passed from > > context A to context B to make sure the operation in context A is finished. > > If the content of this surface is read in both context A and B, > > vaSyncSurfaces is not needed. > > > > Thanks > > Haihao > > > > > > I'm wondering if we should take the comment in [1] as an indication that we > > should do vaSyncSurfaces(). It's not clear what it means by the application > > making sure the operations on the surface are synchronized. > > > > [1] https://github.com/intel/libva/blob/master/va/va.h#L1214-L1216 > > > > On Thu, Jun 6, 2019 at 12:49 AM Hirokazu Honda <hiroh(a)chromium.org&gt; wrote: > > > > Hi, I am sorry for digging up this old thread. > > > > I am wondering we need to call vaSyncSurface() on a surface when the > > surface is passed from context A to context B. > > IIUC, surfaces are not bound to context and operations on a surface > > are not also bound to a context? > > > > cc: kamesan@, who asked me first. kamesan@ passed a surface from > > context for mjpeg decode to context for vpp. [1] > > [1] > > https://chromium-review.googlesource.com/c/chromium/src/+/1558746/22/medi... > > > > Best, > > -Hiro > > > > > > On Mon, Jul 10, 2017 at 3:02 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > wrote: > > > > > > > > > > Hi Xiang, > > > > > > > > Thanks for updating first. > > > > No bug happens even in the present implementation, when a surface is > > > > bound to multiple contexts. Right? > > > > > > Yes for our driver. > > > > > > > Then, let me return my first question: What is the advantage of > > > > binding Surface to Context? > > > > If surface can be bound to multiple surfaces, bounding does not add > > > > any limitation to Surface and Context. > > > > If no limitation causes, it sounds there is actually no difference > > > > between bounding and no bounding. > > > > > > Yes. > > > > > > > > > > > > > > Thanks, > > > > Hirokazu Honda > > > > > > > > On Fri, Jun 30, 2017 at 11:01 PM, Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > wrote: > > > > > Hi Hirokazu, > > > > > > > > > > A surface should be able to be used in different contexts, but > > > > > according to > > > > > the comment below in va.h, a surface can't be shared between two > > > > > contexts. > > > > > This requirement is not reasonable for transcoding pipeline. so we > > > > > will > > > > > update va.h in libva2 to remove this limitation and don't require the > > > > > surface to be tied to a given context. > > > > > > > > > > * Surfaces will be bound to a context when the context is created. > > > > > Once > > > > > * a surface is bound to a given context, it cannot be used to create > > > > > * another context. The association is removed when the context is > > > > > destroyed > > > > > > > > > > Thanks > > > > > Haihao > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Hirokazu Honda [mailto:hiroh@chromium.org] > > > > > > Sent: Friday, June 30, 2017 5:14 PM > > > > > > To: Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > > > Cc: intel-vaapi-media(a)lists.01.org > > > > > > Subject: Re: [intel-vaapi-media] The advantage of binding between > > > > > > Surface > > > > > > and Context. > > > > > > > > > > > > Hi Xiang, > > > > > > > > > > > > What is inconvenient if a surface is used between different > > > > > > contexts? > > > > > > Will a bug happen in such case? > > > > > > > > > > > > Best, > > > > > > Hirokazu Honda > > > > > > > > > > > > On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao < > > > > > > haihao.xiang(a)intel.com&gt; > > > > > > wrote: > > > > > > > > > > > > > > Hi Honda, > > > > > > > > > > > > > > The comment that a surface is bound to a given context and it > > > > > > > can't be > > > > > > > used to created for another context was added initially for decode > > > > > > > pipeline. It is inconvenient when a surface is used between > > > > > > > different > > > > > > > contexts, e.g. a surface is the output of VPP, then this surface > > > > > > > is > > > > > > > used as input of encode pipeline. We ever discussed this topic on > > > > > > > libva(a)list.freedesktop.org, and render_targets is taken as a hint > > > > > > > only > > > > > > > to the driver now, which means the surfaces used in the given > > > > > > > context > > > > > > > aren't limited to render_targets. We will update va.h in libva2 > > > > > > > > > > > > > > Thanks > > > > > > > Haihao > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > According to libva document > > > > > > > > ( > > > > > > > > http://01org.github.io/libva_staging_doxygen/group__api__core.html#g > > > > > > > > a4af336e4 > > > > > > > > 10aefeb4ca4315e2c7cbd653), > > > > > > > > Surfaces are bound to a context if passing them as an argument > > > > > > > > when > > > > > > > > creating the context. > > > > > > > > Seeing intel-vaapi-driver code, the surfaces are just stored in > > > > > > > > object_context.render_targets. > > > > > > > > > > > > > > > > A surface processed by > > > > > > > > vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified > > > > > > > > in > > > > > > > > vaBeginPicture(). (object_context.current_render_target) > > > > > > > > It looks like a surface can be processed using a context by > > > > > > > > being > > > > > > > > specified in vaBeginPicture(), even if it is not bound to the > > > > > > > > context. > > > > > > > > > > > > > > > > Here, my questions are below. > > > > > > > > What is the advantage of binding? > > > > > > > > In what circumstances do we need to associate the context with > > > > > > > > surfaces? > > > > > > > > In which scenarios passing surfaces to vaCreateContext is > > > > > > > > required, > > > > > > > > and in which it is not? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > Hirokazu Honda > > > > > > > > _______________________________________________ > > > > > > > > intel-vaapi-media mailing list > > > > > > > > intel-vaapi-media(a)lists.01.org > > > > > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media > > > > _______________________________________________ > > intel-vaapi-media mailing list > > intel-vaapi-media(a)lists.01.org > > https://lists.01.org/mailman/listinfo/intel-vaapi-media

Hiro, As you may already know, chromeos disabled the vaSyncSurface in intel-vaapi-driver with a custom patch. https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/... Your questions are still valid though :) On 6/11/19 7:22 PM, Hirokazu Honda wrote: > Do you mean the context has only read permission? > For example, > Context A (read/write) > Context B (read only) > Context C (read/only). > > A -> B (vaSync is necessary) > B -> C (vaSync is not necessary) > Therefore, A -> (vaSync) -> B -> C > > Is it correct? > > On Wed, Jun 12, 2019 at 11:59 AM Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: >> >>> Hi Haihao. >>> >>>> If the content of this surface is read in both context A and B, >>>> vaSyncSurfaces is not needed. >>> Could you explain this? What is read meant here and why vaSyncSurface >>> is not needed in the case? >> Context A and Context B may read-access the same surface. In this case, we >> needn't call vaSyncSurface to make sure the operation in A is done before using >> the same surface in B. >> >>> On Tue, Jun 11, 2019 at 1:57 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: >>>> >>>> BTW on Intel platform, you may not call vaSyncSurface() because the >>>> underlying drivers handle synchronization between different contexts. >>>> >>>> >>>> In general, vaSyncSurfaces() is required when a surface is passed from >>>> context A to context B to make sure the operation in context A is finished. >>>> If the content of this surface is read in both context A and B, >>>> vaSyncSurfaces is not needed. >>>> >>>> Thanks >>>> Haihao >>>> >>>> >>>> I'm wondering if we should take the comment in [1] as an indication that we >>>> should do vaSyncSurfaces(). It's not clear what it means by the application >>>> making sure the operations on the surface are synchronized. >>>> >>>> [1] https://github.com/intel/libva/blob/master/va/va.h#L1214-L1216 >>>> >>>> On Thu, Jun 6, 2019 at 12:49 AM Hirokazu Honda <hiroh(a)chromium.org&gt; wrote: >>>> >>>> Hi, I am sorry for digging up this old thread. >>>> >>>> I am wondering we need to call vaSyncSurface() on a surface when the >>>> surface is passed from context A to context B. >>>> IIUC, surfaces are not bound to context and operations on a surface >>>> are not also bound to a context? >>>> >>>> cc: kamesan@, who asked me first. kamesan@ passed a surface from >>>> context for mjpeg decode to context for vpp. [1] >>>> [1] >>>> https://chromium-review.googlesource.com/c/chromium/src/+/1558746/22/medi... >>>> >>>> Best, >>>> -Hiro >>>> >>>> >>>> On Mon, Jul 10, 2017 at 3:02 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; >>>> wrote: >>>>> >>>>>> Hi Xiang, >>>>>> >>>>>> Thanks for updating first. >>>>>> No bug happens even in the present implementation, when a surface is >>>>>> bound to multiple contexts. Right? >>>>> Yes for our driver. >>>>> >>>>>> Then, let me return my first question: What is the advantage of >>>>>> binding Surface to Context? >>>>>> If surface can be bound to multiple surfaces, bounding does not add >>>>>> any limitation to Surface and Context. >>>>>> If no limitation causes, it sounds there is actually no difference >>>>>> between bounding and no bounding. >>>>> Yes. >>>>> >>>>> >>>>>> Thanks, >>>>>> Hirokazu Honda >>>>>> >>>>>> On Fri, Jun 30, 2017 at 11:01 PM, Xiang, Haihao <haihao.xiang(a)intel.com&gt; >>>>>> wrote: >>>>>>> Hi Hirokazu, >>>>>>> >>>>>>> A surface should be able to be used in different contexts, but >>>>>>> according to >>>>>>> the comment below in va.h, a surface can't be shared between two >>>>>>> contexts. >>>>>>> This requirement is not reasonable for transcoding pipeline. so we >>>>>>> will >>>>>>> update va.h in libva2 to remove this limitation and don't require the >>>>>>> surface to be tied to a given context. >>>>>>> >>>>>>> * Surfaces will be bound to a context when the context is created. >>>>>>> Once >>>>>>> * a surface is bound to a given context, it cannot be used to create >>>>>>> * another context. The association is removed when the context is >>>>>>> destroyed >>>>>>> >>>>>>> Thanks >>>>>>> Haihao >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hirokazu Honda [mailto:hiroh@chromium.org] >>>>>>>> Sent: Friday, June 30, 2017 5:14 PM >>>>>>>> To: Xiang, Haihao <haihao.xiang(a)intel.com&gt; >>>>>>>> Cc: intel-vaapi-media(a)lists.01.org >>>>>>>> Subject: Re: [intel-vaapi-media] The advantage of binding between >>>>>>>> Surface >>>>>>>> and Context. >>>>>>>> >>>>>>>> Hi Xiang, >>>>>>>> >>>>>>>> What is inconvenient if a surface is used between different >>>>>>>> contexts? >>>>>>>> Will a bug happen in such case? >>>>>>>> >>>>>>>> Best, >>>>>>>> Hirokazu Honda >>>>>>>> >>>>>>>> On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao < >>>>>>>> haihao.xiang(a)intel.com&gt; >>>>>>>> wrote: >>>>>>>>> Hi Honda, >>>>>>>>> >>>>>>>>> The comment that a surface is bound to a given context and it >>>>>>>>> can't be >>>>>>>>> used to created for another context was added initially for decode >>>>>>>>> pipeline. It is inconvenient when a surface is used between >>>>>>>>> different >>>>>>>>> contexts, e.g. a surface is the output of VPP, then this surface >>>>>>>>> is >>>>>>>>> used as input of encode pipeline. We ever discussed this topic on >>>>>>>>> libva(a)list.freedesktop.org, and render_targets is taken as a hint >>>>>>>>> only >>>>>>>>> to the driver now, which means the surfaces used in the given >>>>>>>>> context >>>>>>>>> aren't limited to render_targets. We will update va.h in libva2 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Haihao >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> According to libva document >>>>>>>>>> ( >>>>>>>>>> http://01org.github.io/libva_staging_doxygen/group__api__core.html#g >>>>>>>>>> a4af336e4 >>>>>>>>>> 10aefeb4ca4315e2c7cbd653), >>>>>>>>>> Surfaces are bound to a context if passing them as an argument >>>>>>>>>> when >>>>>>>>>> creating the context. >>>>>>>>>> Seeing intel-vaapi-driver code, the surfaces are just stored in >>>>>>>>>> object_context.render_targets. >>>>>>>>>> >>>>>>>>>> A surface processed by >>>>>>>>>> vaBeginPicture()-vaRenderPicture()-vaEndPicture() are specified >>>>>>>>>> in >>>>>>>>>> vaBeginPicture(). (object_context.current_render_target) >>>>>>>>>> It looks like a surface can be processed using a context by >>>>>>>>>> being >>>>>>>>>> specified in vaBeginPicture(), even if it is not bound to the >>>>>>>>>> context. >>>>>>>>>> >>>>>>>>>> Here, my questions are below. >>>>>>>>>> What is the advantage of binding? >>>>>>>>>> In what circumstances do we need to associate the context with >>>>>>>>>> surfaces? >>>>>>>>>> In which scenarios passing surfaces to vaCreateContext is >>>>>>>>>> required, >>>>>>>>>> and in which it is not? >>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Hirokazu Honda >>>>>>>>>> _______________________________________________ >>>>>>>>>> intel-vaapi-media mailing list >>>>>>>>>> intel-vaapi-media(a)lists.01.org >>>>>>>>>> https://lists.01.org/mailman/listinfo/intel-vaapi-media >>>> _______________________________________________ >>>> intel-vaapi-media mailing list >>>> intel-vaapi-media(a)lists.01.org >>>> https://lists.01.org/mailman/listinfo/intel-vaapi-media > _______________________________________________ > intel-vaapi-media mailing list > intel-vaapi-media(a)lists.01.org > https://lists.01.org/mailman/listinfo/intel-vaapi-media -- Thanks Sree _______________________________________________ intel-vaapi-media mailing list intel-vaapi-media(a)lists.01.org https://lists.01.org/mailman/listinfo/intel-vaapi-media

> Do you mean the context has only read permission? > For example, > Context A (read/write) > Context B (read only) > Context C (read/only). > > A -> B (vaSync is necessary) > B -> C (vaSync is not necessary) > Therefore, A -> (vaSync) -> B -> C > > Is it correct? Yes. > > On Wed, Jun 12, 2019 at 11:59 AM Xiang, Haihao <haihao.xiang(a)intel.com&gt; wrote: > > > > > > > Hi Haihao. > > > > > > > If the content of this surface is read in both context A and B, > > > > vaSyncSurfaces is not needed. > > > > > > Could you explain this? What is read meant here and why vaSyncSurface > > > is not needed in the case? > > > > Context A and Context B may read-access the same surface. In this case, we > > needn't call vaSyncSurface to make sure the operation in A is done before > > using > > the same surface in B. > > > > > > > > On Tue, Jun 11, 2019 at 1:57 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > wrote: > > > > > > > > > > > > BTW on Intel platform, you may not call vaSyncSurface() because the > > > > underlying drivers handle synchronization between different contexts. > > > > > > > > > > > > In general, vaSyncSurfaces() is required when a surface is passed from > > > > context A to context B to make sure the operation in context A is > > > > finished. > > > > If the content of this surface is read in both context A and B, > > > > vaSyncSurfaces is not needed. > > > > > > > > Thanks > > > > Haihao > > > > > > > > > > > > I'm wondering if we should take the comment in [1] as an indication that > > > > we > > > > should do vaSyncSurfaces(). It's not clear what it means by the > > > > application > > > > making sure the operations on the surface are synchronized. > > > > > > > > [1] https://github.com/intel/libva/blob/master/va/va.h#L1214-L1216 > > > > > > > > On Thu, Jun 6, 2019 at 12:49 AM Hirokazu Honda <hiroh(a)chromium.org&gt; > > > > wrote: > > > > > > > > Hi, I am sorry for digging up this old thread. > > > > > > > > I am wondering we need to call vaSyncSurface() on a surface when the > > > > surface is passed from context A to context B. > > > > IIUC, surfaces are not bound to context and operations on a surface > > > > are not also bound to a context? > > > > > > > > cc: kamesan@, who asked me first. kamesan@ passed a surface from > > > > context for mjpeg decode to context for vpp. [1] > > > > [1] > > > > https://chromium-review.googlesource.com/c/chromium/src/+/1558746/22/medi... > > > > > > > > Best, > > > > -Hiro > > > > > > > > > > > > On Mon, Jul 10, 2017 at 3:02 PM Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > wrote: > > > > > > > > > > > > > > > > Hi Xiang, > > > > > > > > > > > > Thanks for updating first. > > > > > > No bug happens even in the present implementation, when a surface is > > > > > > bound to multiple contexts. Right? > > > > > > > > > > Yes for our driver. > > > > > > > > > > > Then, let me return my first question: What is the advantage of > > > > > > binding Surface to Context? > > > > > > If surface can be bound to multiple surfaces, bounding does not add > > > > > > any limitation to Surface and Context. > > > > > > If no limitation causes, it sounds there is actually no difference > > > > > > between bounding and no bounding. > > > > > > > > > > Yes. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Hirokazu Honda > > > > > > > > > > > > On Fri, Jun 30, 2017 at 11:01 PM, Xiang, Haihao < > > > > > > haihao.xiang(a)intel.com&gt; > > > > > > wrote: > > > > > > > Hi Hirokazu, > > > > > > > > > > > > > > A surface should be able to be used in different contexts, but > > > > > > > according to > > > > > > > the comment below in va.h, a surface can't be shared between two > > > > > > > contexts. > > > > > > > This requirement is not reasonable for transcoding pipeline. so we > > > > > > > will > > > > > > > update va.h in libva2 to remove this limitation and don't require > > > > > > > the > > > > > > > surface to be tied to a given context. > > > > > > > > > > > > > > * Surfaces will be bound to a context when the context is > > > > > > > created. > > > > > > > Once > > > > > > > * a surface is bound to a given context, it cannot be used to > > > > > > > create > > > > > > > * another context. The association is removed when the context is > > > > > > > destroyed > > > > > > > > > > > > > > Thanks > > > > > > > Haihao > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hirokazu Honda [mailto:hiroh@chromium.org] > > > > > > > > Sent: Friday, June 30, 2017 5:14 PM > > > > > > > > To: Xiang, Haihao <haihao.xiang(a)intel.com&gt; > > > > > > > > Cc: intel-vaapi-media(a)lists.01.org > > > > > > > > Subject: Re: [intel-vaapi-media] The advantage of binding > > > > > > > > between > > > > > > > > Surface > > > > > > > > and Context. > > > > > > > > > > > > > > > > Hi Xiang, > > > > > > > > > > > > > > > > What is inconvenient if a surface is used between different > > > > > > > > contexts? > > > > > > > > Will a bug happen in such case? > > > > > > > > > > > > > > > > Best, > > > > > > > > Hirokazu Honda > > > > > > > > > > > > > > > > On Fri, Jun 30, 2017 at 11:45 AM, Xiang, Haihao < > > > > > > > > haihao.xiang(a)intel.com&gt; > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Honda, > > > > > > > > > > > > > > > > > > The comment that a surface is bound to a given context and it > > > > > > > > > can't be > > > > > > > > > used to created for another context was added initially for > > > > > > > > > decode > > > > > > > > > pipeline. It is inconvenient when a surface is used between > > > > > > > > > different > > > > > > > > > contexts, e.g. a surface is the output of VPP, then this > > > > > > > > > surface > > > > > > > > > is > > > > > > > > > used as input of encode pipeline. We ever discussed this topic > > > > > > > > > on > > > > > > > > > libva(a)list.freedesktop.org, and render_targets is taken as a > > > > > > > > > hint > > > > > > > > > only > > > > > > > > > to the driver now, which means the surfaces used in the given > > > > > > > > > context > > > > > > > > > aren't limited to render_targets. We will update va.h in > > > > > > > > > libva2 > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Haihao > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > According to libva document > > > > > > > > > > ( > > > > > > > > > > http://01org.github.io/libva_staging_doxygen/group__api__core.html#g > > > > > > > > > > a4af336e4 > > > > > > > > > > 10aefeb4ca4315e2c7cbd653), > > > > > > > > > > Surfaces are bound to a context if passing them as an > > > > > > > > > > argument > > > > > > > > > > when > > > > > > > > > > creating the context. > > > > > > > > > > Seeing intel-vaapi-driver code, the surfaces are just stored > > > > > > > > > > in > > > > > > > > > > object_context.render_targets. > > > > > > > > > > > > > > > > > > > > A surface processed by > > > > > > > > > > vaBeginPicture()-vaRenderPicture()-vaEndPicture() are > > > > > > > > > > specified > > > > > > > > > > in > > > > > > > > > > vaBeginPicture(). (object_context.current_render_target) > > > > > > > > > > It looks like a surface can be processed using a context by > > > > > > > > > > being > > > > > > > > > > specified in vaBeginPicture(), even if it is not bound to > > > > > > > > > > the > > > > > > > > > > context. > > > > > > > > > > > > > > > > > > > > Here, my questions are below. > > > > > > > > > > What is the advantage of binding? > > > > > > > > > > In what circumstances do we need to associate the context > > > > > > > > > > with > > > > > > > > > > surfaces? > > > > > > > > > > In which scenarios passing surfaces to vaCreateContext is > > > > > > > > > > required, > > > > > > > > > > and in which it is not? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > Hirokazu Honda > > > > > > > > > > _______________________________________________ > > > > > > > > > > intel-vaapi-media mailing list > > > > > > > > > > intel-vaapi-media(a)lists.01.org > > > > > > > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media > > > > > > > > _______________________________________________ > > > > intel-vaapi-media mailing list > > > > intel-vaapi-media(a)lists.01.org > > > > https://lists.01.org/mailman/listinfo/intel-vaapi-media