Am 21.08.2017 um 23:42 schrieb Jason Ekstrand:
On Wed, Aug 16, 2017 at 1:10 PM, Jason Ekstrand <ja...@jlekstrand.net
<mailto:ja...@jlekstrand.net>> wrote:
On Wed, Aug 16, 2017 at 9:53 AM, Christian König
<christian.koe...@amd.com <mailto:christian.koe...@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.koe...@amd.com> to the patches in
the meantime, but an detailed review would have to wait a bit.
Sorry for the delay,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
