Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Thu, Aug 3, 2017 at 11:15 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-08-03 19:06:02)
> > I'm not concerned about what happens to racy clients.  They get what
> they get.
> > What concerns me is what happens if somehow the fence is replaced and
> deleted
> > before i915_gem_request_await_dma_fence takes it's reference.  Can this
> cause
> > the kernel to segfault?
>
> Gotcha, yup nothing prevents that.
>
> fence = dma_fence_get_rcu_safe(>fence);
> if (!fence)
> return -EINVAL;
>
> err = await_fence();
> dma_fence_put(fence);
> if (err < 0)
> return;
>
> Happy?
>

Assuming dma_fence_get_rcu_safe does what I think it does, then yes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Add support for drm syncobjs

[Chris Wilson]

Quoting Jason Ekstrand (2017-08-03 19:06:02)
> I'm not concerned about what happens to racy clients.  They get what they 
> get. 
> What concerns me is what happens if somehow the fence is replaced and deleted
> before i915_gem_request_await_dma_fence takes it's reference.  Can this cause
> the kernel to segfault?

Gotcha, yup nothing prevents that.

fence = dma_fence_get_rcu_safe(>fence);
if (!fence)
return -EINVAL;

err = await_fence();
dma_fence_put(fence);
if (err < 0)
return;

Happy?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Thu, Aug 3, 2017 at 10:00 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-07-05 22:15:09)
> > On Wed, Jul 5, 2017 at 2:13 PM, Jason Ekstrand 
> wrote:
> >
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf.  It does so by hijacking the currently unused
> cliprects
> > pointer to instead point to an array of i915_gem_exec_fence structs
> > which containe a DRM syncobj and a flags parameter which specifies
> > whether to wait on it or to signal it.  This implementation
> > theoretically allows for both flags to be set in which case it waits
> on
> > the dma_fence that was in the syncobj and then immediately replaces
> it
> > with the dma_fence from the current execbuf.
> >
> > v2:
> >  - Rebase on new syncobj API
> > v3:
> >  - Pull everything out into helpers
> >  - Do all allocation in gem_execbuffer2
> >  - Pack the flags in the bottom 2 bits of the drm_syncobj*
>
> Just noticed, no sign off. Could you please check
> https://developercertificate.org/ and apply your Signed-off-by, just a
> reply will do.
>

Sorry, not familiar with the kernel...

Signed-off-by: Jason Ekstrand 


> > +static int await_fence_array(struct i915_execbuffer *eb,
> > +struct drm_syncobj **fences)
> > +{
> > +   const unsigned int nfences = eb->args->num_cliprects;
> > +   unsigned int n;
> > +   int err;
> > +
> > +   for (n = 0; n < nfences; n++) {
> > +   struct drm_syncobj *syncobj;
> > +   unsigned int flags;
> > +
> > +   syncobj = ptr_unpack_bits(fences[n], , 2);
> > +   if (!(flags & I915_EXEC_FENCE_WAIT))
> > +   continue;
> > +
> > +   err = i915_gem_request_await_dma_fence(eb->request,
> > +
> syncobj->fence);
> >
> >
> > Is there a race here?  What happens if some other process replaces the
> fence
> > between the syncobj->fence lookup and gem_request_await_dma_fence taking
> its
> > reference?
>
> Yes. It's inherently racy be via from objects, dmabuf or explicit
> fences. We obtain a snapshot of fences, and the only condition we must
> impose is that they are not cyclic - i.e. we must complete the snapshot
> of all fences before exposing our new >fence to the world.
>
> As to the race where the fence pointed to may change whilst we inspect
> it, there is nothing we can do to prevent that nor define what the right
> behaviour is. It is up to userspace to apply its own execution barriers
> if it requires strict control over the ordering of fences, i.e. what
> does if mean if client B changed the fence whilst client A was
> executing? Should client A use the original fence or the new fence? If
> it matters, the two clients need to coordinate usage of their shared fence.
>

I'm not concerned about what happens to racy clients.  They get what they
get.  What concerns me is what happens if somehow the fence is replaced and
deleted before i915_gem_request_await_dma_fence takes it's reference.  Can
this cause the kernel to segfault?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Add support for drm syncobjs

[Chris Wilson]

Quoting Jason Ekstrand (2017-07-05 22:15:09)
> On Wed, Jul 5, 2017 at 2:13 PM, Jason Ekstrand  wrote:
> 
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf.  It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM syncobj and a flags parameter which specifies
> whether to wait on it or to signal it.  This implementation
> theoretically allows for both flags to be set in which case it waits on
> the dma_fence that was in the syncobj and then immediately replaces it
> with the dma_fence from the current execbuf.
> 
> v2:
>  - Rebase on new syncobj API
> v3:
>  - Pull everything out into helpers
>  - Do all allocation in gem_execbuffer2
>  - Pack the flags in the bottom 2 bits of the drm_syncobj*

Just noticed, no sign off. Could you please check
https://developercertificate.org/ and apply your Signed-off-by, just a
reply will do.

> +static int await_fence_array(struct i915_execbuffer *eb,
> +                            struct drm_syncobj **fences)
> +{
> +       const unsigned int nfences = eb->args->num_cliprects;
> +       unsigned int n;
> +       int err;
> +
> +       for (n = 0; n < nfences; n++) {
> +               struct drm_syncobj *syncobj;
> +               unsigned int flags;
> +
> +               syncobj = ptr_unpack_bits(fences[n], , 2);
> +               if (!(flags & I915_EXEC_FENCE_WAIT))
> +                       continue;
> +
> +               err = i915_gem_request_await_dma_fence(eb->request,
> +                                                      syncobj->fence);
> 
> 
> Is there a race here?  What happens if some other process replaces the fence
> between the syncobj->fence lookup and gem_request_await_dma_fence taking its
> reference?

Yes. It's inherently racy be via from objects, dmabuf or explicit
fences. We obtain a snapshot of fences, and the only condition we must
impose is that they are not cyclic - i.e. we must complete the snapshot
of all fences before exposing our new >fence to the world.

As to the race where the fence pointed to may change whilst we inspect
it, there is nothing we can do to prevent that nor define what the right
behaviour is. It is up to userspace to apply its own execution barriers
if it requires strict control over the ordering of fences, i.e. what
does if mean if client B changed the fence whilst client A was
executing? Should client A use the original fence or the new fence? If
it matters, the two clients need to coordinate usage of their shared fence.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 2:13 PM, Jason Ekstrand  wrote:

> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf.  It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM syncobj and a flags parameter which specifies
> whether to wait on it or to signal it.  This implementation
> theoretically allows for both flags to be set in which case it waits on
> the dma_fence that was in the syncobj and then immediately replaces it
> with the dma_fence from the current execbuf.
>
> v2:
>  - Rebase on new syncobj API
> v3:
>  - Pull everything out into helpers
>  - Do all allocation in gem_execbuffer2
>  - Pack the flags in the bottom 2 bits of the drm_syncobj*
> ---
>  drivers/gpu/drm/i915/i915_drv.c|   3 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 141
> -
>  include/uapi/drm/i915_drm.h|  30 +-
>  3 files changed, 166 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_
> drv.c
> index 9167a73..e6f7f49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
> case I915_PARAM_HAS_EXEC_FENCE:
> case I915_PARAM_HAS_EXEC_CAPTURE:
> case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> /* For the time being all of these are always true;
>  * if some supported hardware does not have one of these
>  * features this value needs to be provided from
> @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
>  */
> .driver_features =
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME |
> -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_SYNCOBJ,
> .release = i915_driver_release,
> .open = i915_driver_open,
> .lastclose = i915_driver_lastclose,
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 929f275..4f97649 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -33,6 +33,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include "i915_drv.h"
>  #include "i915_gem_clflush.h"
> @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct
> drm_i915_gem_execbuffer2 *exec)
> return false;
>
> /* Kernel clipping was a DRI1 misfeature */
> -   if (exec->num_cliprects || exec->cliprects_ptr)
> -   return false;
> +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> +   if (exec->num_cliprects || exec->cliprects_ptr)
> +   return false;
> +   }
>
> if (exec->DR4 == 0x) {
> DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> @@ -2114,11 +2117,120 @@ eb_select_engine(struct drm_i915_private
> *dev_priv,
> return engine;
>  }
>
> +static void __free_fence_array(struct drm_syncobj **fences, unsigned int
> n)
> +{
> +   while (n--)
> +   drm_syncobj_put(ptr_mask_bits(fences[n], 2));
> +   kvfree(fences);
> +}
> +
> +static struct drm_syncobj **get_fence_array(struct
> drm_i915_gem_execbuffer2 *args,
> +   struct drm_file *file)
> +{
> +   const unsigned int nfences = args->num_cliprects;
> +   struct drm_i915_gem_exec_fence __user *user;
> +   struct drm_syncobj **fences;
> +   unsigned int n;
> +   int err;
> +
> +   if (!(args->flags & I915_EXEC_FENCE_ARRAY))
> +   return NULL;
> +
> +   if (nfences > SIZE_MAX / sizeof(*fences))
> +   return ERR_PTR(-EINVAL);
> +
> +   user = u64_to_user_ptr(args->cliprects_ptr);
> +   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> +   return ERR_PTR(-EFAULT);
> +
> +   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
> +   __GFP_NOWARN | GFP_TEMPORARY);
> +   if (!fences)
> +   return ERR_PTR(-ENOMEM);
> +
> +   for (n = 0; n < nfences; n++) {
> +   struct drm_i915_gem_exec_fence fence;
> +   struct drm_syncobj *syncobj;
> +
> +   if (__copy_from_user(, user++, sizeof(fence))) {
> +   err = -EFAULT;
> +   goto err;
> +   }
> +
> +   syncobj = drm_syncobj_find(file, fence.handle);
> +   if (!syncobj) {
> +   DRM_DEBUG("Invalid syncobj handle provided\n");
> +   err = -EINVAL;
> +   goto err;
> +   }
> +
> +   fences[n] = 

Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 11:42 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-07-05 19:32:21)
> > On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson 
> wrote:
> >
> > Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > > This commit adds support for waiting on or signaling DRM syncobjs
> as
> > > part of execbuf.  It does so by hijacking the currently unused
> cliprects
> > > pointer to instead point to an array of i915_gem_exec_fence structs
> > > which containe a DRM syncobj and a flags parameter which specifies
> > > whether to wait on it or to signal it.  This implementation
> > > theoretically allows for both flags to be set in which case it
> waits on
> > > the dma_fence that was in the syncobj and then immediately
> replaces it
> > > with the dma_fence from the current execbuf.
> > >
> > > Cc: Chris Wilson 
> > > ---
> > >
> > > Ideally, I'd like to get whatever kernel reviewing and/or merging
> is
> > > required to land the userspace bits ASAP.  That said, I understand
> that
> > > this is my first kernel patch and it's liable to have a few rounds
> of
> > > review before going in.  :-)
> > >
> > > The mesa branch for using this in Vulkan can be found here:
> > >
> > > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/
> anv-syncobj
> > >
> > >  drivers/gpu/drm/i915/i915_drv.c|  3 +-
> > >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97
> > --
> > >  include/uapi/drm/i915_drm.h| 30 -
> > >  3 files changed, 121 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_
> > drv.c
> > > index 9167a73..e6f7f49 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device
> *dev, void
> > *data,
> > > case I915_PARAM_HAS_EXEC_FENCE:
> > > case I915_PARAM_HAS_EXEC_CAPTURE:
> > > case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> > > +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> > > /* For the time being all of these are always true;
> > >  * if some supported hardware does not have one of
> these
> > >  * features this value needs to be provided from
> > > @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
> > >  */
> > > .driver_features =
> > > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> > DRIVER_PRIME |
> > > -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> > > +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> > DRIVER_SYNCOBJ,
> > > .release = i915_driver_release,
> > > .open = i915_driver_open,
> > > .lastclose = i915_driver_lastclose,
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm
> > /i915/i915_gem_execbuffer.c
> > > index 929f275..81b7b7b 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -33,6 +33,7 @@
> > >
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "i915_drv.h"
> > >  #include "i915_gem_clflush.h"
> > > @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(
> struct
> > drm_i915_gem_execbuffer2 *exec)
> > > return false;
> > >
> > > /* Kernel clipping was a DRI1 misfeature */
> > > -   if (exec->num_cliprects || exec->cliprects_ptr)
> > > -   return false;
> > > +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> > > +   if (exec->num_cliprects || exec->cliprects_ptr)
> > > +   return false;
> > > +   }
> > >
> > > if (exec->DR4 == 0x) {
> > > DRM_DEBUG("UXA submitting garbage DR4, fixing
> up\n");
> > > @@ -2118,12 +2121,15 @@ static int
> > >  i915_gem_do_execbuffer(struct drm_device *dev,
> > >struct drm_file *file,
> > >struct drm_i915_gem_execbuffer2 *args,
> > > -  struct drm_i915_gem_exec_object2 *exec)
> > > +  struct drm_i915_gem_exec_object2 *exec,
> > > +  struct drm_i915_gem_exec_fence *fences)
> > >  {
> > > struct i915_execbuffer eb;
> > > struct dma_fence *in_fence = NULL;
> > > struct sync_file *out_fence = NULL;
> > > +   struct drm_syncobj **syncobjs = NULL;
> > > int out_fence_fd = -1;
> > > +   unsigned int i;
> > > int err;
> >

Re: [PATCH] i915: Add support for drm syncobjs

[Chris Wilson]

Quoting Jason Ekstrand (2017-07-05 19:32:21)
> On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson  
> wrote:
> 
> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf.  It does so by hijacking the currently unused cliprects
> > pointer to instead point to an array of i915_gem_exec_fence structs
> > which containe a DRM syncobj and a flags parameter which specifies
> > whether to wait on it or to signal it.  This implementation
> > theoretically allows for both flags to be set in which case it waits on
> > the dma_fence that was in the syncobj and then immediately replaces it
> > with the dma_fence from the current execbuf.
> >
> > Cc: Chris Wilson 
> > ---
> >
> > Ideally, I'd like to get whatever kernel reviewing and/or merging is
> > required to land the userspace bits ASAP.  That said, I understand that
> > this is my first kernel patch and it's liable to have a few rounds of
> > review before going in.  :-)
> >
> > The mesa branch for using this in Vulkan can be found here:
> >
> > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj
> >
> >  drivers/gpu/drm/i915/i915_drv.c            |  3 +-
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97
> --
> >  include/uapi/drm/i915_drm.h                | 30 -
> >  3 files changed, 121 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> b/drivers/gpu/drm/i915/i915_
> drv.c
> > index 9167a73..e6f7f49 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, 
> void
> *data,
> >         case I915_PARAM_HAS_EXEC_FENCE:
> >         case I915_PARAM_HAS_EXEC_CAPTURE:
> >         case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> > +       case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> >                 /* For the time being all of these are always true;
> >                  * if some supported hardware does not have one of these
> >                  * features this value needs to be provided from
> > @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
> >          */
> >         .driver_features =
> >             DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME |
> > -           DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> > +           DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_SYNCOBJ,
> >         .release = i915_driver_release,
> >         .open = i915_driver_open,
> >         .lastclose = i915_driver_lastclose,
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm
> /i915/i915_gem_execbuffer.c
> > index 929f275..81b7b7b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -33,6 +33,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_drv.h"
> >  #include "i915_gem_clflush.h"
> > @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct
> drm_i915_gem_execbuffer2 *exec)
> >                 return false;
> >
> >         /* Kernel clipping was a DRI1 misfeature */
> > -       if (exec->num_cliprects || exec->cliprects_ptr)
> > -               return false;
> > +       if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> > +               if (exec->num_cliprects || exec->cliprects_ptr)
> > +                       return false;
> > +       }
> >
> >         if (exec->DR4 == 0x) {
> >                 DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> > @@ -2118,12 +2121,15 @@ static int
> >  i915_gem_do_execbuffer(struct drm_device *dev,
> >                        struct drm_file *file,
> >                        struct drm_i915_gem_execbuffer2 *args,
> > -                      struct drm_i915_gem_exec_object2 *exec)
> > +                      struct drm_i915_gem_exec_object2 *exec,
> > +                      struct drm_i915_gem_exec_fence *fences)
> >  {
> >         struct i915_execbuffer eb;
> >         struct dma_fence *in_fence = NULL;
> >         struct sync_file *out_fence = NULL;
> > +       struct drm_syncobj **syncobjs = NULL;
> >         int out_fence_fd = -1;
> > +       unsigned int i;
> >         int err;
> >
> >         BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
> > @@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >                 }
> >         }
> >
> > +       if (args->flags & I915_EXEC_FENCE_ARRAY) {
> > +               syncobjs = 

Re: [PATCH] i915: Add support for drm syncobjs

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson 
wrote:

> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf.  It does so by hijacking the currently unused cliprects
> > pointer to instead point to an array of i915_gem_exec_fence structs
> > which containe a DRM syncobj and a flags parameter which specifies
> > whether to wait on it or to signal it.  This implementation
> > theoretically allows for both flags to be set in which case it waits on
> > the dma_fence that was in the syncobj and then immediately replaces it
> > with the dma_fence from the current execbuf.
> >
> > Cc: Chris Wilson 
> > ---
> >
> > Ideally, I'd like to get whatever kernel reviewing and/or merging is
> > required to land the userspace bits ASAP.  That said, I understand that
> > this is my first kernel patch and it's liable to have a few rounds of
> > review before going in.  :-)
> >
> > The mesa branch for using this in Vulkan can be found here:
> >
> > https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj
> >
> >  drivers/gpu/drm/i915/i915_drv.c|  3 +-
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97
> --
> >  include/uapi/drm/i915_drm.h| 30 -
> >  3 files changed, 121 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> > index 9167a73..e6f7f49 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev,
> void *data,
> > case I915_PARAM_HAS_EXEC_FENCE:
> > case I915_PARAM_HAS_EXEC_CAPTURE:
> > case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> > +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> > /* For the time being all of these are always true;
> >  * if some supported hardware does not have one of these
> >  * features this value needs to be provided from
> > @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
> >  */
> > .driver_features =
> > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME |
> > -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> > +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_SYNCOBJ,
> > .release = i915_driver_release,
> > .open = i915_driver_open,
> > .lastclose = i915_driver_lastclose,
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 929f275..81b7b7b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -33,6 +33,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_drv.h"
> >  #include "i915_gem_clflush.h"
> > @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct
> drm_i915_gem_execbuffer2 *exec)
> > return false;
> >
> > /* Kernel clipping was a DRI1 misfeature */
> > -   if (exec->num_cliprects || exec->cliprects_ptr)
> > -   return false;
> > +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> > +   if (exec->num_cliprects || exec->cliprects_ptr)
> > +   return false;
> > +   }
> >
> > if (exec->DR4 == 0x) {
> > DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> > @@ -2118,12 +2121,15 @@ static int
> >  i915_gem_do_execbuffer(struct drm_device *dev,
> >struct drm_file *file,
> >struct drm_i915_gem_execbuffer2 *args,
> > -  struct drm_i915_gem_exec_object2 *exec)
> > +  struct drm_i915_gem_exec_object2 *exec,
> > +  struct drm_i915_gem_exec_fence *fences)
> >  {
> > struct i915_execbuffer eb;
> > struct dma_fence *in_fence = NULL;
> > struct sync_file *out_fence = NULL;
> > +   struct drm_syncobj **syncobjs = NULL;
> > int out_fence_fd = -1;
> > +   unsigned int i;
> > int err;
> >
> > BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
> > @@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > }
> > }
> >
> > +   if (args->flags & I915_EXEC_FENCE_ARRAY) {
> > +   syncobjs = kvmalloc_array(args->num_cliprects,
> > + sizeof(*syncobjs),
> > + __GFP_NOWARN | GFP_TEMPORARY |
> > + __GFP_ZERO);
> > +   if (syncobjs == NULL) {
> > +   DRM_DEBUG("Failed to allocate array of %d
> syncobjs\n",
> > + args->num_cliprects);
> > +   err = -ENOMEM;
> > +

Re: [PATCH] i915: Add support for drm syncobjs

[Chris Wilson]

Quoting Jason Ekstrand (2017-07-05 18:21:22)
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf.  It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM syncobj and a flags parameter which specifies
> whether to wait on it or to signal it.  This implementation
> theoretically allows for both flags to be set in which case it waits on
> the dma_fence that was in the syncobj and then immediately replaces it
> with the dma_fence from the current execbuf.
> 
> Cc: Chris Wilson 
> ---
> 
> Ideally, I'd like to get whatever kernel reviewing and/or merging is
> required to land the userspace bits ASAP.  That said, I understand that
> this is my first kernel patch and it's liable to have a few rounds of
> review before going in.  :-)
> 
> The mesa branch for using this in Vulkan can be found here:
> 
> https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/anv-syncobj
> 
>  drivers/gpu/drm/i915/i915_drv.c|  3 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 97 
> --
>  include/uapi/drm/i915_drm.h| 30 -
>  3 files changed, 121 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9167a73..e6f7f49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
> case I915_PARAM_HAS_EXEC_FENCE:
> case I915_PARAM_HAS_EXEC_CAPTURE:
> case I915_PARAM_HAS_EXEC_BATCH_FIRST:
> +   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
> /* For the time being all of these are always true;
>  * if some supported hardware does not have one of these
>  * features this value needs to be provided from
> @@ -2734,7 +2735,7 @@ static struct drm_driver driver = {
>  */
> .driver_features =
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
> -   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
> +   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
> .release = i915_driver_release,
> .open = i915_driver_open,
> .lastclose = i915_driver_lastclose,
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 929f275..81b7b7b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -33,6 +33,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_drv.h"
>  #include "i915_gem_clflush.h"
> @@ -1882,8 +1883,10 @@ static bool i915_gem_check_execbuffer(struct 
> drm_i915_gem_execbuffer2 *exec)
> return false;
>  
> /* Kernel clipping was a DRI1 misfeature */
> -   if (exec->num_cliprects || exec->cliprects_ptr)
> -   return false;
> +   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
> +   if (exec->num_cliprects || exec->cliprects_ptr)
> +   return false;
> +   }
>  
> if (exec->DR4 == 0x) {
> DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
> @@ -2118,12 +2121,15 @@ static int
>  i915_gem_do_execbuffer(struct drm_device *dev,
>struct drm_file *file,
>struct drm_i915_gem_execbuffer2 *args,
> -  struct drm_i915_gem_exec_object2 *exec)
> +  struct drm_i915_gem_exec_object2 *exec,
> +  struct drm_i915_gem_exec_fence *fences)
>  {
> struct i915_execbuffer eb;
> struct dma_fence *in_fence = NULL;
> struct sync_file *out_fence = NULL;
> +   struct drm_syncobj **syncobjs = NULL;
> int out_fence_fd = -1;
> +   unsigned int i;
> int err;
>  
> BUILD_BUG_ON(__EXEC_OBJECT_INTERNAL_FLAGS &
> @@ -2186,9 +2192,30 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> }
> }
>  
> +   if (args->flags & I915_EXEC_FENCE_ARRAY) {
> +   syncobjs = kvmalloc_array(args->num_cliprects,
> + sizeof(*syncobjs),
> + __GFP_NOWARN | GFP_TEMPORARY |
> + __GFP_ZERO);
> +   if (syncobjs == NULL) {
> +   DRM_DEBUG("Failed to allocate array of %d syncobjs\n",
> + args->num_cliprects);
> +   err = -ENOMEM;
> +   goto err_out_fence;
> +   }
> +   for (i = 0; i < args->num_cliprects; i++) {
> +   syncobjs[i] = drm_syncobj_find(file, 
> fences[i].handle);
> +   if (!syncobjs[i]) {
> +