AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Chunming Zhou <zhoucm1@amd.com>,
	"Zhou, David(ChunMing)" <David1.Zhou@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"jason@jlekstrand.net" <jason@jlekstrand.net>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"Hector, Tobias" <Tobias.Hector@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v5
Date: Thu, 28 Mar 2019 13:33:00 +0000	[thread overview]
Message-ID: <b5bfbd8f-24df-ba45-5715-8c2dd4c0e60c@intel.com> (raw)
In-Reply-To: <ccd342b9-5b2b-042e-c63a-1090592c0a1b@amd.com>

On 28/03/2019 13:08, Chunming Zhou wrote:
> 在 2019/3/28 20:53, Lionel Landwerlin 写道:
>> On 25/03/2019 08:32, Chunming Zhou wrote:
>>> v2: individually allocate chain array, since chain node is free
>>> independently.
>>> v3: all existing points must be already signaled before cpu perform
>>> signal operation,
>>>       so add check condition for that.
>>> v4: remove v3 change and add checking to prevent out-of-order
>>> v5: unify binary and timeline
>>>
>>> Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
>>> Cc: Tobias Hector <Tobias.Hector@amd.com>
>>> Cc: Jason Ekstrand <jason@jlekstrand.net>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>> ---
>>>    drivers/gpu/drm/drm_internal.h |  2 +
>>>    drivers/gpu/drm/drm_ioctl.c    |  2 +
>>>    drivers/gpu/drm/drm_syncobj.c  | 73 ++++++++++++++++++++++++++++++++++
>>>    include/uapi/drm/drm.h         |  1 +
>>>    4 files changed, 78 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_internal.h
>>> b/drivers/gpu/drm/drm_internal.h
>>> index dd11ae5f1eef..d9a483a5fce0 100644
>>> --- a/drivers/gpu/drm/drm_internal.h
>>> +++ b/drivers/gpu/drm/drm_internal.h
>>> @@ -190,6 +190,8 @@ int drm_syncobj_reset_ioctl(struct drm_device
>>> *dev, void *data,
>>>                    struct drm_file *file_private);
>>>    int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
>>>                     struct drm_file *file_private);
>>> +int drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void
>>> *data,
>>> +                      struct drm_file *file_private);
>>>    int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
>>>                    struct drm_file *file_private);
>>>    diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>>> index 92b3b7b2fd81..d337f161909c 100644
>>> --- a/drivers/gpu/drm/drm_ioctl.c
>>> +++ b/drivers/gpu/drm/drm_ioctl.c
>>> @@ -696,6 +696,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>>>                  DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>>        DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
>>>                  DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>> +    DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL,
>>> drm_syncobj_timeline_signal_ioctl,
>>> +              DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>>        DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
>>>                  DRM_UNLOCKED|DRM_RENDER_ALLOW),
>>>        DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE,
>>> drm_crtc_get_sequence_ioctl, DRM_UNLOCKED),
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>>> b/drivers/gpu/drm/drm_syncobj.c
>>> index ee2d66e047e7..099596190845 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -1183,6 +1183,79 @@ drm_syncobj_signal_ioctl(struct drm_device
>>> *dev, void *data,
>>>        return ret;
>>>    }
>>>    +int
>>> +drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
>>> +                  struct drm_file *file_private)
>>> +{
>>> +    struct drm_syncobj_timeline_array *args = data;
>>> +    struct drm_syncobj **syncobjs;
>>> +    struct dma_fence_chain **chains;
>>> +    uint64_t *points;
>>> +    uint32_t i, j;
>>> +    int ret;
>>> +
>>> +    if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>>> +        return -EOPNOTSUPP;
>>> +
>>> +    if (args->pad != 0)
>>> +        return -EINVAL;
>>> +
>>> +    if (args->count_handles == 0)
>>> +        return -EINVAL;
>>> +
>>> +    ret = drm_syncobj_array_find(file_private,
>>> +                     u64_to_user_ptr(args->handles),
>>> +                     args->count_handles,
>>> +                     &syncobjs);
>>> +    if (ret < 0)
>>> +        return ret;
>>> +
>>> +    points = kmalloc_array(args->count_handles, sizeof(*points),
>>> +                   GFP_KERNEL);
>>> +    if (!points) {
>>> +        ret = -ENOMEM;
>>> +        goto out;
>>> +    }
>>> +    if (!u64_to_user_ptr(args->points)) {
>>> +        memset(points, 0, args->count_handles * sizeof(uint64_t));
>>> +    } else if (copy_from_user(points, u64_to_user_ptr(args->points),
>>> +                  sizeof(uint64_t) * args->count_handles)) {
>>> +        ret = -EFAULT;
>>> +        goto err_points;
>>> +    }
>>> +
>>> +    chains = kmalloc_array(args->count_handles, sizeof(void *),
>>> GFP_KERNEL);
>>> +    if (!chains) {
>>> +        ret = -ENOMEM;
>>> +        goto err_points;
>>> +    }
>>> +    for (i = 0; i < args->count_handles; i++) {
>>> +        chains[i] = kzalloc(sizeof(struct dma_fence_chain),
>>> GFP_KERNEL);
>>> +        if (!chains[i]) {
>>> +            for (j = 0; j < i; j++)
>>> +                kfree(chains[j]);
>>> +            ret = -ENOMEM;
>>> +            goto err_chains;
>>> +        }
>>> +    }
>>> +
>>> +    for (i = 0; i < args->count_handles; i++) {
>>> +        struct dma_fence *fence = dma_fence_get_stub();
>>> +
>>> +        drm_syncobj_add_point(syncobjs[i], chains[i],
>>> +                      fence, points[i]);
>>> +        dma_fence_put(fence);
>>> +    }
>>
>> I think I found an issue where the implementation doesn't match what
>> the spec requires on host signaling.
>>
>> Consider the following :
>>
>>
>> Timeline semaphore has a value of 4.
>>
>> A device submits a commands to signal point 5.
>>
>> The host signals point 6.
>>
>>
>> The value of the timeline will remain 4 until the device commands
>> complete, at which point it will change to 6.
>>
>> But the specification seems to say that the timeline value should be 6
>> once the host signaling completes.
>>
>>
>> The only option that I see working would be to add point 6 in the
>> timeline and wait on that point to complete.
>>
>>
>> Christian, David, what do you think?
> This is exactly what I said before, see V3 comment in the patch head.
>
> But Jeson said this should be guranteed by user and application.
>
> Btw, if we wait all previous points completion this ioctl could be blocked.
>
>
> -David


I haven't seen anything that explicitly forbids that in the spec.

Trying to get a clarification.


-Lionel


>
>
>>
>> Thanks,
>>
>>
>> -Lionel
>>
>>
>>> +err_chains:
>>> +    kfree(chains);
>>> +err_points:
>>> +    kfree(points);
>>> +out:
>>> +    drm_syncobj_array_free(syncobjs, args->count_handles);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>>    int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
>>>                    struct drm_file *file_private)
>>>    {
>>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>>> index e8d0d6b51875..236b01a1fabf 100644
>>> --- a/include/uapi/drm/drm.h
>>> +++ b/include/uapi/drm/drm.h
>>> @@ -943,6 +943,7 @@ extern "C" {
>>>    #define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT    DRM_IOWR(0xCA, struct
>>> drm_syncobj_timeline_wait)
>>>    #define DRM_IOCTL_SYNCOBJ_QUERY        DRM_IOWR(0xCB, struct
>>> drm_syncobj_timeline_array)
>>>    #define DRM_IOCTL_SYNCOBJ_TRANSFER    DRM_IOWR(0xCC, struct
>>> drm_syncobj_transfer)
>>> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL    DRM_IOWR(0xCD, struct
>>> drm_syncobj_timeline_array)
>>>      /**
>>>     * Device specific ioctls should only be in their respective headers
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-03-28 13:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25  8:32 [PATCH 1/9] dma-buf: add new dma_fence_chain container v7 Chunming Zhou
2019-03-25  8:32 ` [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4 Chunming Zhou
     [not found]   ` <20190325083224.2983-2-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-03-28 13:50     ` Lionel Landwerlin
     [not found]       ` <1e6783f1-8db6-47b5-2083-724257a53f84-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-28 15:18         ` Christian König
2019-03-28 15:34           ` Michel Dänzer
2019-03-30 14:09           ` Lionel Landwerlin
     [not found]             ` <5f93be6c-5038-3409-d98d-55d50a62854c-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-04-01  3:54               ` Zhou, David(ChunMing)
2019-04-01  8:19                 ` Lionel Landwerlin
     [not found]                   ` <f8e0e0af-c917-af05-9aa8-cecbbfcf73f9-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-04-01  8:50                     ` zhoucm1
     [not found]                       ` <0674a0a5-7311-55c9-3634-2e96b89e2caa-5C7GfCeVMHo@public.gmane.org>
2019-04-01  9:05                         ` Lionel Landwerlin
     [not found]                           ` <5dd6ae07-24d4-db2b-cc3f-80150e1b0ea6-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-04-01  9:10                             ` Koenig, Christian
2019-04-15 18:54                               ` Dave Airlie
2019-04-15 18:56                                 ` Koenig, Christian
     [not found]                                   ` <01c86eb6-0e76-86c7-7437-f1d88419b4ae-5C7GfCeVMHo@public.gmane.org>
2019-04-15 19:06                                     ` Daniel Vetter
2019-03-25  8:32 ` [PATCH 5/9] drm/syncobj: use the timeline point in drm_syncobj_find_fence v4 Chunming Zhou
2019-03-25  8:32 ` [PATCH 6/9] drm/amdgpu: add timeline support in amdgpu CS v3 Chunming Zhou
     [not found] ` <20190325083224.2983-1-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-03-25  8:32   ` [PATCH 3/9] drm/syncobj: add support for timeline point wait v8 Chunming Zhou
2019-03-25  8:32   ` [PATCH 4/9] drm/syncobj: add timeline payload query ioctl v6 Chunming Zhou
2019-03-25  8:32   ` [PATCH 7/9] drm/syncobj: add transition iotcls between binary and timeline v2 Chunming Zhou
2019-03-25  8:32   ` [PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v5 Chunming Zhou
     [not found]     ` <20190325083224.2983-8-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-03-28 12:53       ` Lionel Landwerlin
     [not found]         ` <d24ee0d0-f044-38ca-6b8d-fcb98cb47d1a-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-28 13:08           ` Chunming Zhou
2019-03-28 13:33             ` Lionel Landwerlin [this message]
     [not found]               ` <b5bfbd8f-24df-ba45-5715-8c2dd4c0e60c-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-30 14:05                 ` Lionel Landwerlin
2019-03-25  8:32 ` [PATCH 9/9] drm/amdgpu: update version for timeline syncobj support in amdgpu Chunming Zhou
  -- strict thread matches above, loose matches on Subject: below --
2019-04-01  9:50 [PATCH 0/9] *** timeline syncobj support *** Chunming Zhou
     [not found] ` <20190401095103.9592-1-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-04-01  9:51   ` [PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v5 Chunming Zhou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b5bfbd8f-24df-ba45-5715-8c2dd4c0e60c@intel.com \
    --to=lionel.g.landwerlin@intel.com \
    --cc=Christian.Koenig@amd.com \
    --cc=David1.Zhou@amd.com \
    --cc=Tobias.Hector@amd.com \
    --cc=airlied@redhat.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=zhoucm1@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox