[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 if you got a student/interim with free time that would certainly be
a nice cleanup task to start on kernel work.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
