[PATCH 0/9] drm/syncobj: Add full-featured wait support (v2)

Jason Ekstrand jason at jlekstrand.net
Wed Aug 16 20:10:17 UTC 2017


On Wed, Aug 16, 2017 at 9:53 AM, Christian König <christian.koenig at amd.com>
wrote:

> [SNIP]
>
>> See a wait_queue is a callback mechanism anyway, so you are wrapping a
>>> callback mechanism inside another callback mechanism and that makes not
>>> really much sense.
>>>
>>
>> Fair enough.  There is one little snag though:  We need to wait on sync
>> objects and fences at the same time in order for WAIT_ANY | WAIT_FOR_SUBMIT
>> to work.  I see two options here:
>>
>>  1) Convert dma-fence to use waitqueue instead of its callback mechanism
>> and add a wait_queue_any.  A quick grep for dma_fence_add_callback says
>> that this would affect four drivers.
>>
>
> The more I think about it, the less sense using waitqueues makes.  The
> fundamental problem here is that the event we are waiting on is actually
> the concatenation of two events: submit and signal.  Since we are waiting
> on several of these pairs of concatenated events simultaneously, the only
> two options we have are to either combine them into one event (the proxy
> approach) or to implement a wait which is capable of handling both at the
> same time.  I don't see a way to do the latter with wait queues.
>
>
> Agree completely.
>
> Essentially we would need to enable wait_event_* to wait for multiple
> events and then convert all the fence callback stuff to wait_event
> structures.
>
> But that is certainly outside the scope of this patchset, so feel free to
> go ahead with the approach of waiting manually (but please without the
> bugs).
>

Well, the patches I sent last night should do just that.  It's mostly the
original approach but with the bugfixes from versions 3 and 4.  Modulo
finding additional bugs, I think they should be good to go.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170816/fccedd59/attachment.html>


More information about the dri-devel mailing list