Vulkan-Docs/doc/specs/vulkan/man/VkMemoryBarrier.txt

189 lines
9.6 KiB
Plaintext

// Copyright (c) 2014-2016 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
VkMemoryBarrier(3)
==================
Name
----
VkMemoryBarrier - Structure specifying a memory barrier
C Specification
---------------
// refBegin VkMemoryBarrier - Structure specifying a memory barrier
The sname:VkMemoryBarrier structure is defined as:
include::../api/structs/VkMemoryBarrier.txt[]
Members
-------
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:srcAccessMask is a bitmask of the classes of memory accesses
performed by the first set of commands that will participate in
the dependency.
* pname:dstAccessMask is a bitmask of the classes of memory accesses
performed by the second set of commands that will participate in
the dependency.
Description
-----------
pname:srcAccessMask and pname:dstAccessMask, along with pname:srcStageMask
and pname:dstStageMask from flink:vkCmdPipelineBarrier, define the two
halves of a memory dependency and an execution dependency. Memory accesses
using the set of access types in pname:srcAccessMask performed in pipeline
stages in pname:srcStageMask by the first set of commands must: complete and
be available to later commands. The side effects of the first set of
commands will be visible to memory accesses using the set of access types in
pname:dstAccessMask performed in pipeline stages in pname:dstStageMask by
the second set of commands. If the barrier is by-region, these requirements
only apply to invocations within the same framebuffer-space region, for
pipeline stages that perform framebuffer-space work. The execution
dependency guarantees that execution of work by the destination stages of
the second set of commands will not begin until execution of work by the
source stages of the first set of commands has completed.
A common type of memory dependency is to avoid a read-after-write hazard. In
this case, the source access mask and stages will include writes from a
particular stage, and the destination access mask and stages will indicate
how those writes will be read in subsequent commands. However, barriers can:
also express write-after-read dependencies and write-after-write
dependencies, and are even useful to express read-after-read dependencies
across an image layout change.
// refBegin VkAccessFlagBits - Bitmask specifying classes of memory access the will participate in a memory barrier dependency
Bits which can: be set in slink:VkMemoryBarrier::pname:srcAccessMask and
slink:VkMemoryBarrier::pname:dstAccessMask include:
[[synchronization-access-flags]]
include::../api/enums/VkAccessFlagBits.txt[]
* ename:VK_ACCESS_INDIRECT_COMMAND_READ_BIT indicates that the access is
an indirect command structure read as part of an indirect drawing
command.
* ename:VK_ACCESS_INDEX_READ_BIT indicates that the access is an index
buffer read.
* ename:VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT indicates that the access is a
read via the vertex input bindings.
* ename:VK_ACCESS_UNIFORM_READ_BIT indicates that the access is a read via
a uniform buffer or dynamic uniform buffer descriptor.
* ename:VK_ACCESS_INPUT_ATTACHMENT_READ_BIT indicates that the access is a
read via an input attachment descriptor.
* ename:VK_ACCESS_SHADER_READ_BIT indicates that the access is a read from
a shader via any other descriptor type.
* ename:VK_ACCESS_SHADER_WRITE_BIT indicates that the access is a write
or atomic from a shader via the same descriptor types as in
ename:VK_ACCESS_SHADER_READ_BIT.
* ename:VK_ACCESS_COLOR_ATTACHMENT_READ_BIT indicates that the access is a
read via a color attachment.
* ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT indicates that the access is
a write via a color or resolve attachment.
* ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT indicates that the
access is a read via a depth/stencil attachment.
* ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT indicates that the
access is a write via a depth/stencil attachment.
* ename:VK_ACCESS_TRANSFER_READ_BIT indicates that the access is a read
from a transfer (copy, blit, resolve, etc.) operation. For the complete
set of transfer operations, see
<<synchronization-transfer,ename:VK_PIPELINE_STAGE_TRANSFER_BIT>>.
* ename:VK_ACCESS_TRANSFER_WRITE_BIT indicates that the access is a write
from a transfer (copy, blit, resolve, etc.) operation. For the complete
set of transfer operations, see
<<synchronization-transfer,ename:VK_PIPELINE_STAGE_TRANSFER_BIT>>.
* ename:VK_ACCESS_HOST_READ_BIT indicates that the access is a read via
the host.
* ename:VK_ACCESS_HOST_WRITE_BIT indicates that the access is a write via
the host.
* ename:VK_ACCESS_MEMORY_READ_BIT indicates that the access is a read via
a non-specific unit attached to the memory. This unit may: be external
to the Vulkan device or otherwise not part of the core Vulkan pipeline.
When included in pname:dstAccessMask, all writes using access types in
pname:srcAccessMask performed by pipeline stages in pname:srcStageMask
must: be visible in memory.
* ename:VK_ACCESS_MEMORY_WRITE_BIT indicates that the access is a write
via a non-specific unit attached to the memory. This unit may: be
external to the Vulkan device or otherwise not part of the core Vulkan
pipeline. When included in pname:srcAccessMask, all access types in
pname:dstAccessMask from pipeline stages in pname:dstStageMask will
observe the side effects of commands that executed before the barrier.
When included in pname:dstAccessMask all writes using access types in
pname:srcAccessMask performed by pipeline stages in pname:srcStageMask
must: be visible in memory.
Color attachment reads and writes are automatically (without memory or
execution dependencies) coherent and ordered against themselves and each
other for a given sample within a subpass of a render pass instance,
executing in <<fundamentals-queueoperation-apiorder,API order>>. Similarly,
depth/stencil attachment reads and writes are automatically coherent and
ordered against themselves and each other in the same circumstances.
Shader reads and/or writes through two variables (in the same or different
shader invocations) decorated with code:Coherent and which use the same
image view or buffer view are automatically coherent with each other, but
require execution dependencies if a specific order is desired. Similarly,
shader atomic operations are coherent with each other and with code:Coherent
variables. Non-code:Coherent shader memory accesses require memory
dependencies for writes to be available and reads to be visible.
Certain memory access types are only supported on queues that support a
particular set of operations. The following table lists, for each access
flag, which queue capability flag must: be supported by the queue. When
multiple flags are enumerated in the second column of the table it means
that the access type is supported on the queue if it supports any of the
listed capability flags. For further details on queue capabilities see
<<devsandqueues-physical-device-enumeration,Physical Device Enumeration>>
and <<devsandqueues-queues,Queues>>.
.Supported access flags
[width="100%",cols="67%,33%",options="header",align="center"]
|========================================
|Access flag | Required queue capability flag
|ename:VK_ACCESS_INDIRECT_COMMAND_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT or ename:VK_QUEUE_COMPUTE_BIT
|ename:VK_ACCESS_INDEX_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_UNIFORM_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT or ename:VK_QUEUE_COMPUTE_BIT
|ename:VK_ACCESS_INPUT_ATTACHMENT_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_SHADER_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT or ename:VK_QUEUE_COMPUTE_BIT
|ename:VK_ACCESS_SHADER_WRITE_BIT | ename:VK_QUEUE_GRAPHICS_BIT or ename:VK_QUEUE_COMPUTE_BIT
|ename:VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT | ename:VK_QUEUE_GRAPHICS_BIT
|ename:VK_ACCESS_TRANSFER_READ_BIT | ename:VK_QUEUE_GRAPHICS_BIT, ename:VK_QUEUE_COMPUTE_BIT or ename:VK_QUEUE_TRANSFER_BIT
|ename:VK_ACCESS_TRANSFER_WRITE_BIT | ename:VK_QUEUE_GRAPHICS_BIT, ename:VK_QUEUE_COMPUTE_BIT or ename:VK_QUEUE_TRANSFER_BIT
|ename:VK_ACCESS_HOST_READ_BIT | None
|ename:VK_ACCESS_HOST_WRITE_BIT | None
|ename:VK_ACCESS_MEMORY_READ_BIT | None
|ename:VK_ACCESS_MEMORY_WRITE_BIT | None
|========================================
include::../validity/structs/VkMemoryBarrier.txt[]
See Also
--------
elink:VkAccessFlags, elink:VkStructureType, flink:vkCmdPipelineBarrier, flink:vkCmdWaitEvents
Document Notes
--------------
For more information, see the Vulkan Specification at URL
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#VkMemoryBarrier
This page is extracted from the Vulkan Specification.
Fixes and changes should be made to the Specification,not directly.
include::footer.txt[]