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

[Chris Wilson]

On Sat, Oct 08, 2016 at 09:23:25AM +0100, Tvrtko Ursulin wrote:
> 
> 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?

No. sync_file is a fence-array (in normal signal-on-all mode) or a
single fence (which via merging sync_files can not be another fence-array,
though the sync_file could be constructed pointing to a single fence-array
fence). If that is a signal-on-any fence, it is broken if the sync_file
is ever merged.... And reviewing the existing code, no one should be
creating sync_file from a signal-on-any fence-array. There is no ABI to
allow the user to create signal-on-any sync_file. I'm feeling safer that
there are quite a few issues to resolve before signal-on-any fences are
allowed to pollute the sync_file ABI.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre