On Fri, Jan 08, 2016 at 06:47:24PM +0000, John.C.Harrison@xxxxxxxxx wrote: > From: John Harrison <John.C.Harrison@xxxxxxxxx> > > The fence object used inside the request structure requires a sequence > number. Although this is not used by the i915 driver itself, it could > potentially be used by non-i915 code if the fence is passed outside of > the driver. This is the intention as it allows external kernel drivers > and user applications to wait on batch buffer completion > asynchronously via the dma-buff fence API. That doesn't make any sense as they are not limited by a single timeline. > To ensure that such external users are not confused by strange things > happening with the seqno, this patch adds in a per context timeline > that can provide a guaranteed in-order seqno value for the fence. This > is safe because the scheduler will not re-order batch buffers within a > context - they are considered to be mutually dependent. You haven't added per-context breadcrumbs. What we need for being able to execute requests from parallel timelines, but with requests within a timeline being ordered, is a per-context page where we can emit the per-context issued breadcrumb. Then instead of looking up the current HW seqno in a global page, the request just looks at the current context HW seqno in the context seq, just i915_seqno_passed(*req->p_context_seqno, req->seqno). The retirment ordered requests lists are moved from the engine to the context and retirement cleanup are restricted to the context. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
