[Intel-gfx] [PATCH 00/13] RFC: pipelined fencing

[Daniel Vetter]

ickle asked me to explain why I can drop the flush_domains parameter from
i915_add_request.

Old way of moving objects onto the active list and associating them with a
reques:

1. i915_add_request + store the returned seqno somewhere
2. i915_gem_object_move_to_active (with the stored seqno as parameter)

For the current users, this is all fine. But I'd like associated objects
(and fence regs) with the requests deep down in the execbuf call-chain. I
thought about three ways of implementing this.

a) Don't care, just emit request when we need a new seqno. When heavily
pipelining fence reg changes, this would have caused tons of superflous
request.

b) Thread all changed fences, objects, whatever through the execbuf-maze,
so that when emit a request, we can store the new seqno at all the right
places.

c) Kill that seqno-threading-around business by simply storing the next
seqno, i.e. allow 2. to be done before 1. in the above sequence.

I've decided to implement c) (in patch 2). All the rest (most of the first
part) is just fall-out that resulted from this small conceptual change.

* We can handle the flushing list processing where we actually emit flush
  (i915_gem_flush and i915_retire_commands) instead of in
  i915_add_request. The code makes IMHO more sense this way (and
  i915_add_request looses the flush_domains parameter, obviously).
  Patch 3 and 5.

* We can avoid emitting unnecessary request. IMHO there's no point in
  emitting more than one request per batchbuffer (with or without an
  corresponding irq). Patch 4.

* By enforcing 2. before 1. ordering in the above sequence the seqno
  argument of i915_gem_object_move_to_active is redundant and can be
  dropped. Patch 8.

Patch 7 is a result of all this. Patch 6 slept accidently in the middle of
all this, it's just a code cleanup in preparation of the stuff from patch
9 onwards.

Hope this clarifies things, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48