AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Koenig,
	Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>,
	"Zhou,
	David(ChunMing)" <David1.Zhou-5C7GfCeVMHo@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: Dave Airlie <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Daniel Rakos <Daniel.Rakos-5C7GfCeVMHo@public.gmane.org>,
	Jason Ekstrand <jason-fQELhIk9awXprZlt/sZkLg@public.gmane.org>
Subject: Re: [PATCH 06/11] drm/syncobj: add timeline payload query ioctl v4
Date: Mon, 18 Feb 2019 11:40:49 +0000	[thread overview]
Message-ID: <a7e461ab-ebca-c5d2-b59f-4d4e3c1fda45@intel.com> (raw)
In-Reply-To: <4becddef-3bb3-5a66-34d4-95cced896939-5C7GfCeVMHo@public.gmane.org>

On 18/02/2019 07:28, Koenig, Christian wrote:
> Am 18.02.19 um 04:10 schrieb zhoucm1:
>>
>> On 2019年02月17日 03:22, Christian König wrote:
>>> Am 15.02.19 um 20:31 schrieb Lionel Landwerlin via amd-gfx:
>>>> On 07/12/2018 09:55, Chunming Zhou wrote:
>>>>> user mode can query timeline payload.
>>>>> v2: check return value of copy_to_user
>>>>> v3: handle querying entry by entry
>>>>> v4: rebase on new chain container, simplify interface
>>>>>
>>>>> Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
>>>>> Cc: Daniel Rakos <Daniel.Rakos@amd.com>
>>>>> Cc: Jason Ekstrand <jason@jlekstrand.net>
>>>>> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>> Cc: Christian König <christian.koenig@amd.com>
>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>> ---
>>>>>    drivers/gpu/drm/drm_internal.h |  2 ++
>>>>>    drivers/gpu/drm/drm_ioctl.c    |  2 ++
>>>>>    drivers/gpu/drm/drm_syncobj.c  | 43
>>>>> ++++++++++++++++++++++++++++++++++
>>>>>    include/uapi/drm/drm.h         | 10 ++++++++
>>>>>    4 files changed, 57 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_internal.h
>>>>> b/drivers/gpu/drm/drm_internal.h
>>>>> index 18b41e10195c..dab4d5936441 100644
>>>>> --- a/drivers/gpu/drm/drm_internal.h
>>>>> +++ b/drivers/gpu/drm/drm_internal.h
>>>>> @@ -184,6 +184,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_query_ioctl(struct drm_device *dev, void *data,
>>>>> +                struct drm_file *file_private);
>>>>>      /* drm_framebuffer.c */
>>>>>    void drm_framebuffer_print_info(struct drm_printer *p, unsigned
>>>>> int indent,
>>>>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>>>>> index a9a17ed35cc4..7578ef6dc1d1 100644
>>>>> --- a/drivers/gpu/drm/drm_ioctl.c
>>>>> +++ b/drivers/gpu/drm/drm_ioctl.c
>>>>> @@ -681,6 +681,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_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),
>>>>>        DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
>>>>> drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
>>>>>        DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE,
>>>>> drm_mode_create_lease_ioctl, DRM_MASTER|DRM_UNLOCKED),
>>>>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>>>>> b/drivers/gpu/drm/drm_syncobj.c
>>>>> index 348079bb0965..f97fa00ca1d0 100644
>>>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>>>> @@ -1061,3 +1061,46 @@ drm_syncobj_signal_ioctl(struct drm_device
>>>>> *dev, void *data,
>>>>>          return ret;
>>>>>    }
>>>>> +
>>>>> +int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
>>>>> +                struct drm_file *file_private)
>>>>> +{
>>>>> +    struct drm_syncobj_timeline_array *args = data;
>>>>> +    struct drm_syncobj **syncobjs;
>>>>> +    uint64_t __user *points = u64_to_user_ptr(args->points);
>>>>> +    uint32_t i;
>>>>> +    int ret;
>>>>> +
>>>>> +    if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>>>>> +        return -ENODEV;
>>>>> +
>>>>> +    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;
>>>>> +
>>>>> +    for (i = 0; i < args->count_handles; i++) {
>>>>> +        struct dma_fence_chain *chain;
>>>>> +        struct dma_fence *fence;
>>>>> +        uint64_t point;
>>>>> +
>>>>> +        fence = drm_syncobj_fence_get(syncobjs[i]);
>>>>> +        chain = to_dma_fence_chain(fence);
>>>>> +        point = chain ? fence->seqno : 0;
>>>>
>>>> Sorry, I don' t want to sound annoying, but this looks like this
>>>> could report values going backward.
>>> Well please be annoying as much as you can :) But yeah all that stuff
>>> has been discussed before as well.
>>>
>>>> Anything add a point X to a timeline that has reached value Y with X
>>>> < Y would trigger that.
>>> Yes, that can indeed happen.
>> trigger what? when adding x (x < y), then return 0 when query?
>> Why would this happen?
>> No, syncobj->fence should always be there and the last chain node, if
>> it is ever added.
> Well maybe Lionel should clarify a bit what he means?
>
> I thought he is concerned that the call could return values where X < Y,
> but that doesn't seem to be the case.
>
> Christian.


I meant something like this :


t = create_timeline_syncobj()

signal(t, 2)

query(t) => 2

signal(t, 1)

query(t) => 1


-Lionel



>
>> -David
>>> But adding a timeline point X which is before the already added point
>>> Y is illegal in the first place :)
>>>
>>> So when the application does something stupid and breaks it can just
>>> keep the pieces.
>>>
>>> In the kernel we still do the most defensive thing and sync to
>>> everything in this case.
>>>
>>> I'm just not sure if we should print an error into syslog or just
>>> continue silently.
>>>
>>> Regards,
>>> Christian.
>>>
>>>> Either through the submission or userspace signaling or importing
>>>> another syncpoint's fence.
>>>>
>>>>
>>>> -Lionel
>>>>
>>>>
>>>>> +        ret = copy_to_user(&points[i], &point, sizeof(uint64_t));
>>>>> +        ret = ret ? -EFAULT : 0;
>>>>> +        if (ret)
>>>>> +            break;
>>>>> +    }
>>>>> +    drm_syncobj_array_free(syncobjs, args->count_handles);
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>>>>> index 0092111d002c..b2c36f2b2599 100644
>>>>> --- a/include/uapi/drm/drm.h
>>>>> +++ b/include/uapi/drm/drm.h
>>>>> @@ -767,6 +767,14 @@ struct drm_syncobj_array {
>>>>>        __u32 pad;
>>>>>    };
>>>>>    +struct drm_syncobj_timeline_array {
>>>>> +    __u64 handles;
>>>>> +    __u64 points;
>>>>> +    __u32 count_handles;
>>>>> +    __u32 pad;
>>>>> +};
>>>>> +
>>>>> +
>>>>>    /* Query current scanout sequence number */
>>>>>    struct drm_crtc_get_sequence {
>>>>>        __u32 crtc_id;        /* requested crtc_id */
>>>>> @@ -924,6 +932,8 @@ extern "C" {
>>>>>    #define DRM_IOCTL_MODE_REVOKE_LEASE    DRM_IOWR(0xC9, struct
>>>>> drm_mode_revoke_lease)
>>>>>      #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)
>>>>> +
>>>>>    /**
>>>>>     * Device specific ioctls should only be in their respective headers
>>>>>     * The device specific ioctl range is from 0x40 to 0x9f.
>>>>
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2019-02-18 11:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07  9:55 [PATCH 01/11] dma-buf: make fence sequence numbers 64 bit v2 Chunming Zhou
2018-12-07  9:55 ` [PATCH 02/11] dma-buf: add new dma_fence_chain container v4 Chunming Zhou
2019-02-15 14:23   ` Lionel Landwerlin via dri-devel
     [not found]     ` <6c2adaf5-6871-20be-a26d-182f8ca8ab8a-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-02-15 14:32       ` Koenig, Christian
     [not found]         ` <e170ceed-fdb7-8b4a-93d7-e565641390b3-5C7GfCeVMHo@public.gmane.org>
2019-02-15 15:52           ` Lionel Landwerlin via amd-gfx
     [not found]             ` <bbae2023-8dee-692e-9549-40779a202587-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-02-15 16:39               ` Christian König via amd-gfx
2019-02-15 16:49             ` Jason Ekstrand
     [not found]               ` <CAOFGe96HUkzHPJKYT-07X3vMvCRD-=Hba1=Ke24qt_PY2vn0YQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-02-15 17:51                 ` Christian König via amd-gfx
     [not found]                   ` <a0b27d87-50f2-56ce-1db7-5a1dc005a798-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-15 18:16                     ` Jason Ekstrand
     [not found]                       ` <CAOFGe9611MqmsvdvZS4_vuJjrrUAmjK5-41Z6tpaxTHJsB8CwA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-02-15 18:33                         ` Koenig, Christian
     [not found]                           ` <f933f9ec-6e69-f9df-f12f-5f1844a2ad37-5C7GfCeVMHo@public.gmane.org>
2019-02-15 19:11                             ` Jason Ekstrand
2018-12-07  9:55 ` [PATCH 03/11] drm/syncobj: remove drm_syncobj_cb and cleanup Chunming Zhou
     [not found] ` <20181207095601.2058-1-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2018-12-07  9:55   ` [PATCH 04/11] drm/syncobj: add new drm_syncobj_add_point interface v2 Chunming Zhou
2018-12-07  9:55   ` [PATCH 06/11] drm/syncobj: add timeline payload query ioctl v4 Chunming Zhou
     [not found]     ` <20181207095601.2058-6-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-02-15 19:31       ` Lionel Landwerlin via amd-gfx
     [not found]         ` <157f8231-57e2-0492-de5d-f9ba4761c4c9-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-02-16 19:22           ` Christian König via amd-gfx
     [not found]             ` <a24728a8-5b80-e746-a1f2-6555cd817e99-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-18  3:10               ` zhoucm1
     [not found]                 ` <eae060f6-6493-ef71-ed9d-52d7dd768b03-5C7GfCeVMHo@public.gmane.org>
2019-02-18  7:28                   ` Koenig, Christian
     [not found]                     ` <4becddef-3bb3-5a66-34d4-95cced896939-5C7GfCeVMHo@public.gmane.org>
2019-02-18 11:40                       ` Lionel Landwerlin [this message]
2018-12-07  9:55   ` [PATCH 07/11] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3 Chunming Zhou
2018-12-07  9:55   ` [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline Chunming Zhou
2018-12-07 11:28     ` Koenig, Christian
     [not found]     ` <20181207095601.2058-9-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-02-15 14:28       ` Lionel Landwerlin via amd-gfx
2019-02-18 10:35         ` zhoucm1
2019-02-18 11:01           ` Koenig, Christian
     [not found]             ` <27a38e11-0c77-4340-aac9-b02e816c6f58-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2019-02-18 12:07               ` Lionel Landwerlin
     [not found]                 ` <83890a08-769a-b52a-f2f6-9fe425f2562c-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-02-18 17:01                   ` Koenig, Christian
     [not found]                     ` <64c548d0-b062-f937-30a5-5a4d3f296f91-5C7GfCeVMHo@public.gmane.org>
2019-02-19 10:46                       ` zhoucm1
     [not found]                         ` <c2c12849-d26b-3212-40ca-682d6f8006fa-5C7GfCeVMHo@public.gmane.org>
2019-02-19 11:29                           ` Lionel Landwerlin
2019-02-19 11:32                           ` Koenig, Christian
2019-02-20  4:53                             ` zhoucm1
2019-02-20  7:59                               ` Koenig, Christian
     [not found]                                 ` <976d7032-1cde-0427-ce56-38c2ac8881ec-5C7GfCeVMHo@public.gmane.org>
2019-02-20  8:10                                   ` zhoucm1
     [not found]                                     ` <730eaa42-d852-e9d8-7756-43fb256a466f-5C7GfCeVMHo@public.gmane.org>
2019-02-20  8:24                                       ` Koenig, Christian
2018-12-07  9:56   ` [PATCH 11/11] drm/amdgpu: update version for timeline syncobj support in amdgpu Chunming Zhou
2018-12-07  9:55 ` [PATCH 05/11] drm/syncobj: add support for timeline point wait v8 Chunming Zhou
2018-12-07  9:55 ` [PATCH 08/11] drm/amdgpu: add timeline support in amdgpu CS v2 Chunming Zhou
2018-12-07  9:56 ` [PATCH 10/11] drm/syncobj: add timeline signal ioctl for syncobj Chunming Zhou
     [not found]   ` <20181207095601.2058-10-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2018-12-07 11:31     ` Christian König
2018-12-07 13:09       ` Chunming Zhou
     [not found]         ` <8c34aaf0-13b3-4070-f4ef-076fe1ab3197-5C7GfCeVMHo@public.gmane.org>
2018-12-07 13:14           ` Koenig, Christian

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=a7e461ab-ebca-c5d2-b59f-4d4e3c1fda45@intel.com \
    --to=lionel.g.landwerlin-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=Daniel.Rakos-5C7GfCeVMHo@public.gmane.org \
    --cc=David1.Zhou-5C7GfCeVMHo@public.gmane.org \
    --cc=airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=jason-fQELhIk9awXprZlt/sZkLg@public.gmane.org \
    /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