[igt-dev] [PATCH i-g-t v2 08/10] tests/i915/exec_fence: add timeline fence tests

[Chris Wilson]

Quoting Lionel Landwerlin (2019-11-22 16:03:16)
> On 22/11/2019 17:51, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-11-22 15:43:11)
> >> On 22/11/2019 17:26, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2019-11-22 13:02:58)
> >>>> We can now give a tuple (handle, point_value) for timeline semaphores.
> >>>>
> >>>> v2: Fix up syncobj-timeline-repeat test (Lionel)
> >>>>       Update following kernel rename
> >>>>
> >>>> v3: Add more ordering tests for syncobj/buffer handle state (Chris)
> >>> Another question, do we worry about sw_sync imported fences being
> >>> handles differently to native?
> >>> -Chris
> >> What do you mean by differently?
> > We have is_i915_fence() with branching paths for internal/external, and
> > within the syncobj timeline mixed fence contexts cause a hard barrier,
> > so may present interesting effects at the uAPI layer?
> 
> 
> Well... same issues with an array of i915 fences right?
> 
> 
> I guess fence_set_priority() could be adjusted to deal with 
> dma-fence-chain like it does with dma-fence-array.

No, either it's a chain of fence or it's just a list (and shouldn't be
calling itself a chain ;). If it is a chain with dependencies along the
chain, then we already have the information for priority inheritance.
Except dma-fence-chain doesn't _guarantee_ that is the case and leaves
it up to the caller to provide order across fence_contexts (within a
fence_context it the seqno are meant to be ordered, and if the caller
tries to use them out-of-order for syncpts within a dma-fence-chain it
goes into the broken chain path same as for switching fence_contexts).
-Chris