linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Introduce fences for N:M completion variables
@ 2016-06-24  9:08 Chris Wilson
  2016-06-24  9:08 ` [PATCH 1/9] lib: Add kselftests for async-domains Chris Wilson
                   ` (9 more replies)
  0 siblings, 10 replies; 24+ messages in thread
From: Chris Wilson @ 2016-06-24  9:08 UTC (permalink / raw)
  To: linux-kernel

struct completion allows for multiple waiters on a single event.
However, frequently we want to wait on multiple events. For example in
job processing, we need to wait for all prerequisite tasks to complete
before proceeding. Such dependency tracking is common to many situations.
In dma-buf, we already have a mechanism in place for tracking
dependencies between tasks and across drivers, the fence. Each fence is
a fixed point on a timeline that the hardware is processing (though the
hardware may be executing from multiple timelines concurrently). Each
fence may wait on any other fence (and for native fences the wait may be
executed on the device, but otherwise the signaling and forward progress
of the inter-fence serialisation is provided by the drivers themselves).
The added complexity of hardware interaction makes the dma-buf fence
unwieldy as a drop-in extension of struct completion. Enter kfence.

The kfence is intended to be as easy to use as a struct completion in
order to provide barriers in a DAG of tasks. It can provide
serialisation with other software events just as easily as it can mix in
dma-fences and be used to construct an event-driven state machine.

The tasks I have applied kfence to are:

 * providing fine-grained dependency and concurrent execution for the
   global initcalls. Drivers are currently creatively using the fixed
   initcall phases to solve dependency problems. Knowing which initcall
   can be executed in parallel helps speed up the boot process. Though
   not as much as removing the barrier after initramfs!

 * providing fine-grained dependency and concurrent execution for
   load/resume within a module (within the overall global async
   execution). Trying to parallelise a driver between discovery and
   hardware setup is hard to retrofit and will be challenging to
   maintain without a mechanism by which we can describe the dependencies
   of each phase upon each other (and hw state) and then let the
   hardware resolve the order in which to execute the phases. We want a
   declarative syntax?

 * providing asynchronous execution of GPU rendering (for a mix of
   inter-device rendering and inter-engine without hardware scheduling).
   This mixes dma-fences with an event-driven state machine. Here, the
   kfence primarily serves as a collection of dma-fences.

 * providing asynchronous execution of atomic modesetting,
   mixing the current usage of struct completion with dma-fences into
   one consistent framework 

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2016-07-17 13:00 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-24  9:08 Introduce fences for N:M completion variables Chris Wilson
2016-06-24  9:08 ` [PATCH 1/9] lib: Add kselftests for async-domains Chris Wilson
2016-06-24  9:08 ` [PATCH 2/9] async: Introduce kfence, a N:M completion mechanism Chris Wilson
2016-07-13  9:38   ` Peter Zijlstra
2016-07-13 10:20     ` Chris Wilson
2016-07-13 11:02       ` Daniel Vetter
2016-07-13 10:26   ` Peter Zijlstra
2016-06-24  9:08 ` [PATCH 3/9] async: Extend kfence to allow struct embedding Chris Wilson
2016-07-13 10:31   ` Peter Zijlstra
2016-06-24  9:08 ` [PATCH 4/9] async: Extend kfences for listening on DMA fences Chris Wilson
2016-06-24  9:08 ` [PATCH 5/9] async: Wrap hrtimer to provide a time source for a kfence Chris Wilson
2016-07-13 10:32   ` Peter Zijlstra
2016-06-24  9:08 ` [PATCH 6/9] async: Add a convenience wrapper for waiting on implicit dma-buf Chris Wilson
2016-06-24  9:08 ` [PATCH 7/9] async: Add support for explicit fine-grained barriers Chris Wilson
2016-06-24  9:08 ` [PATCH 8/9] async: Add execution barriers Chris Wilson
2016-06-24  9:08 ` [PATCH 9/9] async: Introduce a dependency resolver for parallel execution Chris Wilson
2016-07-17 12:58 ` Introduce fences for N:M completion variables [v2] Chris Wilson
2016-07-17 12:58   ` [PATCH v2 1/7] kfence: Introduce kfence, a N:M completion mechanism Chris Wilson
2016-07-17 12:58   ` [PATCH v2 2/7] kfence: Wrap hrtimer to provide a time source for a kfence Chris Wilson
2016-07-17 12:58   ` [PATCH v2 3/7] kfence: Extend kfences for listening on DMA fences Chris Wilson
2016-07-17 12:58   ` [PATCH v2 4/7] async: Add kselftests for async-domains Chris Wilson
2016-07-17 12:58   ` [PATCH v2 5/7] async: Add support for explicit fine-grained barriers Chris Wilson
2016-07-17 12:58   ` [PATCH v2 6/7] async: Add execution barriers Chris Wilson
2016-07-17 12:58   ` [PATCH v2 7/7] async: Introduce a dependency resolver for parallel execution Chris Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).