[Intel-gfx] [PATCH 06/42] drm/i915: Support asynchronous waits on struct fence from i915_gem_request
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Sat Oct 8 08:23:25 UTC 2016
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
More information about the Intel-gfx
mailing list