diff options
author | Andres Rodriguez <[email protected]> | 2017-12-14 00:24:46 -0500 |
---|---|---|
committer | Andres Rodriguez <[email protected]> | 2018-01-30 15:13:49 -0500 |
commit | d34c2cf3e6498d3b337117180f3151c719fda5b6 (patch) | |
tree | 4c3e808975e018b02d1cbcb5f08f8e17e8f19db3 /src/gallium/docs/source/context.rst | |
parent | 458f89be78b8aaba200e2a8640871b921e346bb2 (diff) |
gallium: add fence_server_signal() v2
Calling this function will emit a fence signal operation into the
GPU's command stream.
v2: documentation typos
Signed-off-by: Andres Rodriguez <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Diffstat (limited to 'src/gallium/docs/source/context.rst')
-rw-r--r-- | src/gallium/docs/source/context.rst | 31 |
1 files changed, 31 insertions, 0 deletions
diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst index 0ac73402422..e8e80dcbc39 100644 --- a/src/gallium/docs/source/context.rst +++ b/src/gallium/docs/source/context.rst @@ -567,7 +567,38 @@ by a single pipe_screen and is not shared with another process. (i.e. you shouldn't use it to flush caches explicitly if you want to e.g. use the resource for texturing) +Fences +^^^^^^ +``pipe_fence_handle``, and related methods, are used to synchronize +execution between multiple parties. Examples include CPU <-> GPU synchronization, +renderer <-> windowing system, multiple external APIs, etc. + +A ``pipe_fence_handle`` can either be 'one time use' or 're-usable'. A 'one time use' +fence behaves like a traditional GPU fence. Once it reaches the signaled state it +is forever considered to be signaled. + +Once a re-usable ``pipe_fence_handle`` becomes signaled, it can be reset +back into an unsignaled state. The ``pipe_fence_handle`` will be reset to +the unsignaled state by performing a wait operation on said object, i.e. +``fence_server_sync``. As a corollary to this behaviour, a re-usable +``pipe_fence_handle`` can only have one waiter. + +This behaviour is useful in producer <-> consumer chains. It helps avoid +unecessarily sharing a new ``pipe_fence_handle`` each time a new frame is +ready. Instead, the fences are exchanged once ahead of time, and access is synchronized +through GPU signaling instead of direct producer <-> consumer communication. + +``fence_server_sync`` inserts a wait command into the GPU's command stream. + +``fence_server_signal`` inserts a signal command into the GPU's command stream. + +There are no guarantees that the wait/signal commands will be flushed when +calling ``fence_server_sync`` or ``fence_server_signal``. An explicit +call to ``flush`` is required to make sure the commands are emitted to the GPU. + +The Gallium implementation may implicitly ``flush`` the command stream during a +``fence_server_sync`` or ``fence_server_signal`` call if necessary. Resource Busy Queries ^^^^^^^^^^^^^^^^^^^^^ |