76 lines
3.1 KiB
Plaintext
76 lines
3.1 KiB
Plaintext
Motivation:
|
||
|
||
In complicated DMA pipelines such as graphics (multimedia, camera, gpu, display)
|
||
a consumer of a buffer needs to know when the producer has finished producing
|
||
it. Likewise the producer needs to know when the consumer is finished with the
|
||
buffer so it can reuse it. A particular buffer may be consumed by multiple
|
||
consumers which will retain the buffer for different amounts of time. In
|
||
addition, a consumer may consume multiple buffers atomically.
|
||
The sync framework adds an API which allows synchronization between the
|
||
producers and consumers in a generic way while also allowing platforms which
|
||
have shared hardware synchronization primitives to exploit them.
|
||
|
||
Goals:
|
||
* provide a generic API for expressing synchronization dependencies
|
||
* allow drivers to exploit hardware synchronization between hardware
|
||
blocks
|
||
* provide a userspace API that allows a compositor to manage
|
||
dependencies.
|
||
* provide rich telemetry data to allow debugging slowdowns and stalls of
|
||
the graphics pipeline.
|
||
|
||
Objects:
|
||
* sync_timeline
|
||
* sync_pt
|
||
* sync_fence
|
||
|
||
sync_timeline:
|
||
|
||
A sync_timeline is an abstract monotonically increasing counter. In general,
|
||
each driver/hardware block context will have one of these. They can be backed
|
||
by the appropriate hardware or rely on the generic sw_sync implementation.
|
||
Timelines are only ever created through their specific implementations
|
||
(i.e. sw_sync.)
|
||
|
||
sync_pt:
|
||
|
||
A sync_pt is an abstract value which marks a point on a sync_timeline. Sync_pts
|
||
have a single timeline parent. They have 3 states: active, signaled, and error.
|
||
They start in active state and transition, once, to either signaled (when the
|
||
timeline counter advances beyond the sync_pt’s value) or error state.
|
||
|
||
sync_fence:
|
||
|
||
Sync_fences are the primary primitives used by drivers to coordinate
|
||
synchronization of their buffers. They are a collection of sync_pts which may
|
||
or may not have the same timeline parent. A sync_pt can only exist in one fence
|
||
and the fence's list of sync_pts is immutable once created. Fences can be
|
||
waited on synchronously or asynchronously. Two fences can also be merged to
|
||
create a third fence containing a copy of the two fences’ sync_pts. Fences are
|
||
backed by file descriptors to allow userspace to coordinate the display pipeline
|
||
dependencies.
|
||
|
||
Use:
|
||
|
||
A driver implementing sync support should have a work submission function which:
|
||
* takes a fence argument specifying when to begin work
|
||
* asynchronously queues that work to kick off when the fence is signaled
|
||
* returns a fence to indicate when its work will be done.
|
||
* signals the returned fence once the work is completed.
|
||
|
||
Consider an imaginary display driver that has the following API:
|
||
/*
|
||
* assumes buf is ready to be displayed.
|
||
* blocks until the buffer is on screen.
|
||
*/
|
||
void display_buffer(struct dma_buf *buf);
|
||
|
||
The new API will become:
|
||
/*
|
||
* will display buf when fence is signaled.
|
||
* returns immediately with a fence that will signal when buf
|
||
* is no longer displayed.
|
||
*/
|
||
struct sync_fence* display_buffer(struct dma_buf *buf,
|
||
struct sync_fence *fence);
|