Re: [PATCH 06/42] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 07/10/2016 17:37, Chris Wilson wrote:
On Fri, Oct 07, 2016 at 05:16:17PM +0100, Tvrtko Ursulin wrote:
On 07/10/2016 17:12, Chris Wilson wrote:
2. Can child be another array?
Yes, but we don't want to recurse (or at least need to bound the
recursion).
In that case could the array have been created in the signal_on_any
mode and how would we handle that?
Hmm. Not along our paths, I think. The only fence-array we have are from
sync-file which are signal-on-all (except... in the case of where it
wraps a single fence, that fence could be a composite). signal-on-any is
icky, to be complete we should not decompose it into its elements -
however, whether or not a fence-array is operating in signal_on_any mode
is not stored. So at the moment, the best I can do is offer a comment.

Yes signal-on-any sounds extremely weird. It mandates you decompose 3rd party fences in all cases, with recursion.

The only user of it at the moment is amdgpu waiting for the first of
many VM manager to become available, not something we'll see
immediately via sync-file.

So userspace cannot engineer it to happen with some funky operations before giving us a fence?

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux