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

["Christian König" <christian.koenig@amd.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2520 bytes --]

Am 21.08.2017 um 23:42 schrieb Jason Ekstrand:
>
>
> On Wed, Aug 16, 2017 at 1:10 PM, Jason Ekstrand <jason@jlekstrand.net 
> <mailto:jason@jlekstrand.net>> wrote:
>
>     On Wed, Aug 16, 2017 at 9:53 AM, Christian König
>     <christian.koenig@amd.com <mailto:christian.koenig@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.
>
> ping?
I just way to much to do at the moment (as usually). Feel free to add an 
Acked-by: Christian König <christian.koenig@amd.com> to the patches in 
the meantime, but an detailed review would have to wait a bit.

Sorry for the delay,
Christian.

[-- Attachment #1.2: Type: text/html, Size: 7645 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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