On 08/01/2016 22:05, Chris Wilson wrote:
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.
I don't understand what you mean. Who is not limited by a single
timeline? The point is that the current seqno values cannot be used as
there is no guarantee that they will increment globally once things like
a scheduler and pre-emption arrive. Whereas, the fence internal
implementation makes various assumptions about the linearity of the
timeline. External users do not want to care about timelines or seqnos
at all, they just want the fence API to work as documented.
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).
This patch is not attempting to implement per context seqno values. That
can be done as future work. This patch is doing the simplest, least
invasive implementation in order to make external fences work.
The retirment ordered requests lists are moved from the engine to the
context and retirement cleanup are restricted to the context.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
