dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: christian.koenig@amd.com, Chunming Zhou <david1.zhou@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	jason@jlekstrand.net, Tobias.Hector@amd.com
Subject: Re: [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4
Date: Sat, 30 Mar 2019 14:09:17 +0000	[thread overview]
Message-ID: <5f93be6c-5038-3409-d98d-55d50a62854c@intel.com> (raw)
In-Reply-To: <5a435812-41f9-c2a6-d2cd-0b2ee1c76e52@gmail.com>

On 28/03/2019 15:18, Christian König wrote:
> Am 28.03.19 um 14:50 schrieb Lionel Landwerlin:
>> On 25/03/2019 08:32, Chunming Zhou wrote:
>>> From: Christian König <ckoenig.leichtzumerken@gmail.com>
>>>
>>> Use the dma_fence_chain object to create a timeline of fence objects
>>> instead of just replacing the existing fence.
>>>
>>> v2: rebase and cleanup
>>> v3: fix garbage collection parameters
>>> v4: add unorder point check, print a warn calltrace
>>>
>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>> ---
>>>   drivers/gpu/drm/drm_syncobj.c | 39 
>>> +++++++++++++++++++++++++++++++++++
>>>   include/drm/drm_syncobj.h     |  5 +++++
>>>   2 files changed, 44 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_syncobj.c 
>>> b/drivers/gpu/drm/drm_syncobj.c
>>> index 5329e66598c6..19a9ce638119 100644
>>> --- a/drivers/gpu/drm/drm_syncobj.c
>>> +++ b/drivers/gpu/drm/drm_syncobj.c
>>> @@ -122,6 +122,45 @@ static void drm_syncobj_remove_wait(struct 
>>> drm_syncobj *syncobj,
>>>       spin_unlock(&syncobj->lock);
>>>   }
>>>   +/**
>>> + * drm_syncobj_add_point - add new timeline point to the syncobj
>>> + * @syncobj: sync object to add timeline point do
>>> + * @chain: chain node to use to add the point
>>> + * @fence: fence to encapsulate in the chain node
>>> + * @point: sequence number to use for the point
>>> + *
>>> + * Add the chain node as new timeline point to the syncobj.
>>> + */
>>> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
>>> +               struct dma_fence_chain *chain,
>>> +               struct dma_fence *fence,
>>> +               uint64_t point)
>>> +{
>>> +    struct syncobj_wait_entry *cur, *tmp;
>>> +    struct dma_fence *prev;
>>> +
>>> +    dma_fence_get(fence);
>>> +
>>> +    spin_lock(&syncobj->lock);
>>> +
>>> +    prev = drm_syncobj_fence_get(syncobj);
>>> +    /* You are adding an unorder point to timeline, which could 
>>> cause payload returned from query_ioctl is 0! */
>>> +    WARN_ON_ONCE(prev && prev->seqno >= point);
>>
>>
>> I think the WARN/BUG macros should only fire when there is an issue 
>> with programming from within the kernel.
>>
>> But this particular warning can be triggered by an application.
>>
>>
>> Probably best to just remove it?
>
> Yeah, that was also my argument against it.
>
> Key point here is that we still want to note somehow that userspace 
> did something wrong and returning an error is not an option.
>
> Maybe just use DRM_ERROR with a static variable to print the message 
> only once.
>
> Christian.

I don't really see any point in printing an error once. If you run your 
application twice you end up thinking there was an issue just on the 
first run but it's actually always wrong.


Unless we're willing to take the syncobj lock for longer periods of time 
when adding points, I guess we'll have to defer validation to validation 
layers.


-Lionel

>
>>
>>
>> -Lionel
>>
>>
>>> +    dma_fence_chain_init(chain, prev, fence, point);
>>> +    rcu_assign_pointer(syncobj->fence, &chain->base);
>>> +
>>> +    list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node) {
>>> +        list_del_init(&cur->node);
>>> +        syncobj_wait_syncobj_func(syncobj, cur);
>>> +    }
>>> +    spin_unlock(&syncobj->lock);
>>> +
>>> +    /* Walk the chain once to trigger garbage collection */
>>> +    dma_fence_chain_for_each(fence, prev);
>>> +    dma_fence_put(prev);
>>> +}
>>> +EXPORT_SYMBOL(drm_syncobj_add_point);
>>> +
>>>   /**
>>>    * drm_syncobj_replace_fence - replace fence in a sync object.
>>>    * @syncobj: Sync object to replace fence in
>>> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
>>> index 0311c9fdbd2f..6cf7243a1dc5 100644
>>> --- a/include/drm/drm_syncobj.h
>>> +++ b/include/drm/drm_syncobj.h
>>> @@ -27,6 +27,7 @@
>>>   #define __DRM_SYNCOBJ_H__
>>>     #include <linux/dma-fence.h>
>>> +#include <linux/dma-fence-chain.h>
>>>     struct drm_file;
>>>   @@ -112,6 +113,10 @@ drm_syncobj_fence_get(struct drm_syncobj 
>>> *syncobj)
>>>     struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
>>>                        u32 handle);
>>> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
>>> +               struct dma_fence_chain *chain,
>>> +               struct dma_fence *fence,
>>> +               uint64_t point);
>>>   void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>>>                      struct dma_fence *fence);
>>>   int drm_syncobj_find_fence(struct drm_file *file_private,
>>
>>
>
>

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

  parent reply	other threads:[~2019-03-30 14:09 UTC|newest]

Thread overview: 28+ 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 [this message]
     [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
     [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
     [not found]               ` <b5bfbd8f-24df-ba45-5715-8c2dd4c0e60c-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-30 14:05                 ` Lionel Landwerlin
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
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:50   ` [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4 Chunming Zhou
2019-03-20  5:47 [PATCH 1/9] dma-buf: add new dma_fence_chain container v6 Chunming Zhou
     [not found] ` <20190320054724.14636-1-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2019-03-20  5:47   ` [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4 Chunming Zhou
2019-03-15 12:09 [PATCH 1/9] dma-buf: add new dma_fence_chain container v5 Chunming Zhou
2019-03-15 12:09 ` [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4 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=5f93be6c-5038-3409-d98d-55d50a62854c@intel.com \
    --to=lionel.g.landwerlin@intel.com \
    --cc=Tobias.Hector@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=david1.zhou@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    /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;
as well as URLs for NNTP newsgroup(s).