status-im
/
Vulkan-Docs
mirror of https://github.com/status-im/Vulkan-Docs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fix random markup (#935)

This commit is contained in:
Petr Kraus 2019-03-19 08:38:42 +01:00 committed by Jon Leech
parent 476e3f422d
commit f4d8a49e87
24 changed files with 88 additions and 88 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
appendices/VK_KHR_descriptor_update_template.txt
View File

@ -17,8 +17,8 @@ include::meta/VK_KHR_descriptor_update_template.txt[]
Applications may wish to update a fixed set of descriptors in a large number
of descriptors sets very frequently, i.e. during initializaton phase or if
it's required to rebuild descriptor sets for each frame.
For those cases it's also not unlikely that all information required to
it is required to rebuild descriptor sets for each frame.
For those cases it is also not unlikely that all information required to
update a single descriptor set is stored in a single struct.
This extension provides a way to update a fixed set of descriptors in a
single slink:VkDescriptorSet with a pointer to a user defined data structure

2
appendices/VK_KHR_incremental_present.txt
View File

@ -25,7 +25,7 @@ of rectangular, modified regions of each image to present.
This should be used in situations where an application is only changing a
small portion of the presentable images within a swapchain, since it enables
the presentation engine to avoid wasting time presenting parts of the
surface that haven't changed.
surface that have not changed.
This extension is leveraged from the `EGL_KHR_swap_buffers_with_damage`
extension.

2
appendices/VK_KHR_maintenance3.txt
View File

@ -21,7 +21,7 @@ The new features are as follows:
* A limit on the maximum number of descriptors that are supported in a
single descriptor set layout.
Some implementations have a limit on the total size of descriptors in a
set, which can't be expressed in terms of the limits in Vulkan 1.0.
set, which cannot be expressed in terms of the limits in Vulkan 1.0.
* A limit on the maximum size of a single memory allocation.
Some platforms have kernel interfaces that limit the maximum size of an
allocation.

2
appendices/VK_KHR_shader_draw_parameters.txt
View File

@ -80,7 +80,7 @@ None.
All functionality in this extension is included in core Vulkan 1.1, however
a <<features-shaderDrawParameters,feature bit was added>> to distinguish
whether it's actually available or not.
whether it is actually available or not.
=== Issues

4
appendices/VK_KHR_shader_float16_int8.txt
View File

@ -30,9 +30,9 @@ pname:shaderInt8 which directly map to the code:Float16 and the code:Int8
SPIR-V capabilities.
The `VK_KHR_shader_float16_int8` extension also specifies precision
requirements for half-precision floating-point SPIR-V operations.
This extension doesn't enable use of 8-bit integer types or 16-bit
This extension does not enable use of 8-bit integer types or 16-bit
floating-point types in any <<interfaces-iointerfaces, shader input and
output interfaces>> and therefore doesn't supersede the
output interfaces>> and therefore does not supersede the
`<<VK_KHR_8bit_storage>>` or `<<VK_KHR_16bit_storage>>` extensions.
=== New Enum Constants

8
appendices/memorymodel.txt
View File

@ -482,7 +482,7 @@ visibility>> operations may: be required for writes to be
NOTE: Happens-before is not transitive, but each of program-order and
inter-thread-happens-before<SC> are transitive.
These can be thought of as covering the "`single-threaded`" case and the
"`multi-threaded`" case, and it's not necessary (and not valid) to form
"`multi-threaded`" case, and it is not necessary (and not valid) to form
chains between the two.
[[memory-model-availability-visibility]]
@ -561,7 +561,7 @@ to all (agent,reference,L) tuples included in its destination scope.
If write W~2~ happens-after W, and their sets of memory locations overlap,
then W will not be available/visible to all agents/references for those
memory locations that overlap (and future AV/DOM/VIS ops can't revive W's
memory locations that overlap (and future AV/DOM/VIS ops cannot revive W's
write to those locations).
Availability, memory domain, and visibility operations are treated like
@ -717,8 +717,8 @@ X is _location-ordered_ before Y for a location L in M if and only if any of
the following is true:
* A~X~ == A~Y~ and R~X~ == R~Y~ and X->Y
** NOTE: this case means no availability/visibility ops required when it's
the same (agent,reference).
** NOTE: this case means no availability/visibility ops required when it
is the same (agent,reference).
* X is a read, both X and Y are non-private, and X->Y
* X is a read, and X (transitively) system-synchronizes with Y

2
appendices/spirvenv.txt
View File

@ -967,7 +967,7 @@ ifdef::VK_KHR_shader_float_controls[]
* By default, the implementation may: perform optimizations on half,
single, or double-precision floating-point instructions respectively
that ignore sign of a zero, or assume that arguments and results are not
[eq]##Nan##s or latexmath:[\pm\infty], this doesn't apply to
[eq]##Nan##s or latexmath:[\pm\infty], this does not apply to
code:OpIsNan and code:OpIsInf, which must: always correctly detect
[eq]##Nan##s and latexmath:[\pm\infty].
If the entry point is declared with the code:SignedZeroInfNanPreserve

2
appendices/versions.txt
View File

@ -13,7 +13,7 @@ These consist of some amount of additional functionality added to the core
API, potentially including both new functionality and functionality
<<extendingvulkan-compatibility-promotions,promoted>> from extensions.
It's possible to build the specification for earlier versions, but to aid
It is possible to build the specification for earlier versions, but to aid
readability of the latest versions, this appendix gives an overview of the
changes as compared to earlier versions.

2
chapters/VK_GOOGLE_display_timing/PresentTimeInfo.txt
View File

@ -62,6 +62,6 @@ include::../../api/structs/VkPresentTimeGOOGLE.txt[]
A value of zero specifies that the presentation engine may: display the
image at any time.
This is useful when the application desires to provide pname:presentID,
but doesn't need a specific pname:desiredPresentTime.
but does not need a specific pname:desiredPresentTime.
--

6
chapters/VK_GOOGLE_display_timing/queries.txt
View File

@ -12,7 +12,7 @@ This avoids the visual anomaly known as tearing.
However, synchronizing the presentation of images with the RC does not
prevent all forms of visual anomalies.
Stuttering occurs when the geometry for each presentable image isn't
Stuttering occurs when the geometry for each presentable image is not
accurately positioned for when that image will be displayed.
The geometry may appear to move too little some RCs, and too much for
others.
@ -96,8 +96,8 @@ It will therefore position the geometry of a new image 16.67ms later than
the previous image.
Let's say that this application is running on slower hardware, so that it
actually takes 20ms to render each new image.
This will create visual anomalies, because the images won't be displayed to
the user every 16.67ms, nor every 20ms.
This will create visual anomalies, because the images will not be displayed
to the user every 16.67ms, nor every 20ms.
In this case, it is better for the application to adjust its target IPD to
33.33ms (i.e. a 2X multiplier of pname:refreshDuration), and tell the
presentation engine to not present images any sooner than every 33.33ms.

14
chapters/VK_KHR_swapchain/wsi.txt
View File

@ -589,16 +589,16 @@ endif::VK_KHR_swapchain_mutable_format[]
all other bits are unset
endif::VK_VERSION_1_1,VK_KHR_device_group,VK_KHR_swapchain_mutable_format[]
| pname:imageType | ename:VK_IMAGE_TYPE_2D
| pname:format | `pCreateInfo->imageFormat`
| pname:extent | `{pCreateInfo->imageExtent.width, pCreateInfo->imageExtent.height, 1}`
| pname:format | pname:pCreateInfo\->pname:imageFormat
| pname:extent | {pname:pCreateInfo\->pname:imageExtent.width, pname:pCreateInfo\->pname:imageExtent.height, `1`}
| pname:mipLevels | 1
| pname:arrayLayers | `pCreateInfo->imageArrayLayers`
| pname:arrayLayers | pname:pCreateInfo\->pname:imageArrayLayers
| pname:samples | ename:VK_SAMPLE_COUNT_1_BIT
| pname:tiling | ename:VK_IMAGE_TILING_OPTIMAL
| pname:usage | `pCreateInfo->imageUsage`
| pname:sharingMode | `pCreateInfo->imageSharingMode`
| pname:queueFamilyIndexCount | `pCreateInfo->queueFamilyIndexCount`
| pname:pQueueFamilyIndices | `pCreateInfo->pQueueFamilyIndices`
| pname:usage | pname:pCreateInfo\->pname:imageUsage
| pname:sharingMode | pname:pCreateInfo\->pname:imageSharingMode
| pname:queueFamilyIndexCount | pname:pCreateInfo\->pname:queueFamilyIndexCount
| pname:pQueueFamilyIndices | pname:pCreateInfo\->pname:pQueueFamilyIndices
| pname:initialLayout | ename:VK_IMAGE_LAYOUT_UNDEFINED
|====

2
chapters/clears.txt
View File

@ -389,7 +389,7 @@ described for flink:vkCreateRenderPass.
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkClearAttachment-aspectMask-02246]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT for any index etext:i.
endif::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkClearAttachment-clearValue-00021]]
pname:clearValue must: be a valid sname:VkClearValue union

2
chapters/cmdbuffers.txt
View File

@ -1020,7 +1020,7 @@ See <<devsandqueues-lost-device,Lost Device>>.
pname:pSubmits must: have been allocated from a sname:VkCommandPool that
was created for the same queue family pname:queue belongs to.
* [[VUID-vkQueueSubmit-pSubmits-02207]]
If any element of pname:pSubmits->pname:pCommandBuffers includes a
If any element of pname:pSubmits\->pname:pCommandBuffers includes a
<<synchronization-queue-transfers-acquire, Queue Family Transfer Acquire
Operation>>, there must: exist a previously submitted
<<synchronization-queue-transfers-release, Queue Family Transfer Release

2
chapters/copies.txt
View File

@ -837,7 +837,7 @@ include::../api/structs/VkImageSubresourceLayers.txt[]
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkImageSubresourceLayers-aspectMask-02247]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT for any index etext:i.
endif::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkImageSubresourceLayers-layerCount-01700]]
pname:layerCount must: be greater than 0

4
chapters/descriptorsets.txt
View File

@ -2164,7 +2164,7 @@ ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
If a call to fname:vkAllocateDescriptorSets would cause the total number of
descriptor sets allocated from the pool to exceed the value of
slink:VkDescriptorPoolCreateInfo::pname:maxSets used to create
pname:pAllocateInfo->pname:descriptorPool, then the allocation may: fail due
pname:pAllocateInfo\->pname:descriptorPool, then the allocation may: fail due
to lack of space in the descriptor pool.
Similarly, the allocation may: fail due to lack of space if the call to
fname:vkAllocateDescriptorSets would cause the number of any given
@ -4008,7 +4008,7 @@ code:PhysicalStorageBufferEXT storage class.
For example, this value can: be stored in a uniform buffer, and the shader
can: read the value from the uniform buffer and use it to do a dependent
read/write to this buffer.
A value of zero is reserved as a "null" pointer and must: not be returned as
A value of zero is reserved as a "`null`" pointer and must: not be returned as
a valid buffer device address.
All loads, stores, and atomics in a shader through
code:PhysicalStorageBufferEXT pointers must: access addresses in the address

16
chapters/dispatch.txt
View File

@ -126,10 +126,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDispatch-filterCubicMinmax-02610]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -280,10 +280,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDispatchIndirect-filterCubicMinmax-02612]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]

56
chapters/drawing.txt
View File

@ -720,10 +720,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDraw-filterCubicMinmax-02614]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -932,10 +932,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDrawIndexed-filterCubicMinmax-02616]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -1152,10 +1152,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDrawIndirect-filterCubicMinmax-02618]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -1406,10 +1406,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDrawIndirectCountKHR-filterCubicMinmax-02620]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -1815,10 +1815,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDrawIndexedIndirect-filterCubicMinmax-02622]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -2077,10 +2077,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDrawIndexedIndirectCountKHR-filterCubicMinmax-02624]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]
@ -2500,10 +2500,10 @@ ifdef::VK_EXT_filter_cubic[]
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
* [[VUID-vkCmdDrawIndirectByteCountEXT-filterCubicMinmax-02626]]
Any slink:VkImageView being sampled with ename:VK_FILTER_CUBIC_EXT with
a reduction mode of either VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command must: have
a elink:VkImageViewType and format that supports cubic filtering
together with minmax filtering, as specified by
a reduction mode of either ename:VK_SAMPLER_REDUCTION_MODE_MIN_EXT or
ename:VK_SAMPLER_REDUCTION_MODE_MAX_EXT as a result of this command
must: have a elink:VkImageViewType and format that supports cubic
filtering together with minmax filtering, as specified by
sname:VkFilterCubicImageViewImageFormatPropertiesEXT::pname:filterCubicMinmax
returned by fname:vkGetPhysicalDeviceImageFormatProperties2
endif::VK_EXT_filter_cubic[]

8
chapters/extensions.txt
View File

@ -33,7 +33,7 @@ ifdef::VK_VERSION_1_1[]
Applications usually interface to Vulkan using a loader that implements only
instance-level functionality, passing device-level functionality to
implementations of the full Vulkan API on the system.
In some circumstances, as these may be implemented independently, it's
In some circumstances, as these may be implemented independently, it is
possible that the loader and device implementations on a given installation
will support different versions.
To allow for this and call out when it happens, the Vulkan specification
@ -557,7 +557,7 @@ guarantees.
A difference in the patch version indicates that a set of bug fixes or
clarifications have been made to the Specification.
Informative enums returned by Vulkan commands that won't affect the runtime
Informative enums returned by Vulkan commands that will not affect the runtime
behavior of a valid application may be added in a patch version (e.g.
elink:VkVendorId).
@ -674,7 +674,7 @@ limited to the following:
[NOTE]
.Note
====
If extension functionality is promoted, there's no guarantee of direct
If extension functionality is promoted, there is no guarantee of direct
compatibility, however it should require little effort to port code from the
original feature to the promoted one.
@ -730,7 +730,7 @@ Rather than duplication of all the documentation and definitions, the
specification instead identifies the identical commands and types as
_aliases_ of one another.
Each alias is mentioned together with the definition it aliases, with the
older aliases marked as "equivalents".
older aliases marked as "`equivalents`".
Each alias of the same command has identical behavior, and each alias of the
same type has identical meaning - they can be used interchangably in an
application with no compatibility issues.

2
chapters/interfaces.txt
View File

@ -590,7 +590,7 @@ In this case the variable must: be typed as code:OpTypeStruct and cannot: be
aggregated into arrays of that type.
Further, the code:Offset decoration for any member of such a variable must:
not cause the space required for that variable to extend outside the range
[eq]#[0,maxInlineUniformBlockSize)#.
[eq]#[0,pname:maxInlineUniformBlockSize)#.
endif::VK_EXT_inline_uniform_block[]
Variables identified with a storage class of code:UniformConstant and a

2
chapters/memory.txt
View File

@ -3081,7 +3081,7 @@ endif::VK_VERSION_1_1[]
|====
1::
Vulkan doesn't differentiate between
Vulkan does not differentiate between
code:AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM and
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM: they both behave as
ename:VK_FORMAT_R8G8B8A8_UNORM.

2
chapters/primsrast.txt
View File

@ -582,7 +582,7 @@ The first array contains one element per sample where each element stores an
index to the second array defining the _fragment mask_ of the pixel.
The second array contains one element per _color fragment_ and each element
stores a unique color value in the format of the image.
With this compression technique it's not always necessary to actually use
With this compression technique it is not always necessary to actually use
unique storage locations for each color sample: when multiple samples share
the same color value the fragment mask may: have two samples referring to
the same color fragment.

8
chapters/renderpass.txt
View File

@ -237,7 +237,7 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
* [[VUID-VkRenderPassCreateInfo-pNext-02512]]
If the pname:pNext chain includes an instance of
slink:VkRenderPassMultiviewCreateInfo, for any element of
pname:pDependencies with a pname:dependencyFlags member that doesn't
pname:pDependencies with a pname:dependencyFlags member that does not
include ename:VK_DEPENDENCY_VIEW_LOCAL_BIT, the corresponding element of
the pname:pViewOffsets member of that
slink:VkRenderPassMultiviewCreateInfo instance must: be `0`
@ -367,7 +367,7 @@ Unlike pipeline barriers, a subpass dependency can: potentially have a
different view mask in the source subpass and the destination subpass.
If the dependency is view-local, then each view ([eq]#dstView#) in the
destination subpass depends on the view [eq]#dstView {plus}
pViewOffsets[dependency]# in the source subpass.
pname:pViewOffsets[dependency]# in the source subpass.
If there is not such a view in the source subpass, then this dependency does
not affect that view in the destination subpass.
If the dependency is not view-local, then all views in the destination
@ -680,7 +680,7 @@ endif::VK_KHR_maintenance2[]
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkInputAttachmentAspectReference-aspectMask-02250]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT for any index etext:i.
endif::VK_EXT_image_drm_format_modifier[]
****
@ -1355,7 +1355,7 @@ ifdef::editing-notes[]
====
The following two alleged implicit dependencies are practically no-ops, as
the operations they describe are already guaranteed by semaphores and
submission order (so they're almost entirely no-ops on their own).
submission order (so they are almost entirely no-ops on their own).
The *only* reason they exist is because it simplifies reasoning about where
<<renderpass-layout-transitions, automatic layout transitions>> happen.
Further rewrites of this chapter could potentially remove the need for

16
chapters/resources.txt
View File

@ -1748,9 +1748,9 @@ include::../api/structs/VkImageDrmFormatModifierExplicitCreateInfoEXT.txt[]
* pname:pPlaneLayouts is an array of slink:VkSubresourceLayout structures
that describe the image's _memory planes_.
The i^th^ member of pname:pPlaneLayouts describes the layout of the image's
i^th^ _memory plane_ (that is,
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT).
The etext:i^th^ member of pname:pPlaneLayouts describes the layout of the
image's etext:i^th^ _memory plane_ (that is,
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT).
In each element of pname:pPlaneLayouts, the implementation must: ignore
pname:size.
The implementation calculates the size of each plane, which the application
@ -2129,8 +2129,8 @@ ifdef::VK_EXT_image_drm_format_modifier[]
If the pname:tiling of the pname:image is
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, then the pname:aspectMask
member of pname:pSubresource must: be
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT and the index __i__
must: be less than the
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT and the index etext:i must:
be less than the
<<VkDrmFormatModifierPropertiesEXT,pname:drmFormatModifierPlaneCount>>
associated with the image's
<<VkImageCreateInfo,pname:format>> and
@ -2261,8 +2261,8 @@ endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ifdef::VK_EXT_image_drm_format_modifier[]
If the image's tiling is ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, then
the pname:aspectMask member of sname:VkImageSubresource must: be one of
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT, where the maximum allowed
plane index __i__ is defined by the
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT, where the maximum allowed
plane index etext:i is defined by the
<<VkDrmFormatModifierPropertiesEXT,pname:drmFormatModifierPlaneCount>>
associated with the image's <<VkImageCreateInfo,pname:format>> and
<<glossary-drm-format-modifier,modifier>>.
@ -3633,7 +3633,7 @@ endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ifdef::VK_EXT_image_drm_format_modifier[]
* [[VUID-VkImageSubresourceRange-aspectMask-02278]]
pname:aspectMask must: not include
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT for any index __i__.
etext:VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT for any index etext:i.
endif::VK_EXT_image_drm_format_modifier[]
****

8
chapters/synchronization.txt
View File

@ -4580,10 +4580,10 @@ include::../api/protos/vkGetCalibratedTimestampsEXT.txt[]
The maximum deviation may: vary between calls to
fname:vkGetCalibratedTimestampsEXT even for the same set of time domains due
to implementation and platform specific reasons.
It's the application's responsibility to assess whether the returned maximum
deviation makes the timestamp values suitable for any particular purpose and
can: choose to re-issue the timestamp calibration call pursuing a lower
devation value.
It is the application's responsibility to assess whether the returned
maximum deviation makes the timestamp values suitable for any particular
purpose and can: choose to re-issue the timestamp calibration call pursuing
a lower devation value.
====
Calibrated timestamp values can: be extrapolated to estimate future