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

Change log for March 25, 2016 Vulkan 1.0.7 spec update: 

* Bump API patch number and header version number to 7 for this
    update.

Github Issues:

  * Fix slink:VkSpecializationMapEntry example to avoid C/C++ strict
    aliasing issues (public issue 14).

  * Clarify the meaning of "matching" in flink:vkCmdBindDescriptorSets
    validity language (public issue 33).

  * Add stub reference pages so xrefs to not-yet-written pages don't
    generate 404 errors. However, the actual content of these pages
    still needs to be filled in as time allows (public issue 44, but
    does not close that issue out).

  * Remove incorrect validity statement for
    flink:vkGetImageSparseMemoryRequirements (public issue 85).

  * Reword the
    <<features-limits-bufferImageGranularity,bufferImageGranularity>>
    feature in terms of "aliasing", and clarify that it applies to
    bindings in the same memory object (public issue 90).

  * Clarify the relationship of the slink:VkPhysicalDeviceLimits
    pname:maxViewportDimensions and pname:viewportBoundsRange limits
    (public issue 92).

  * Specify sparse unbound texture replacement in the
    <<textures-texel-replacement,Texel Replacement>> section
    independently of robust buffer access language (public issue 100).

  * Add the <<fundamentals-architecture-model,Architecture Model>>
    section to explain architecture constraints Vulkan has chosen to
    accept in order to enable portable and performant code (public issue
    122).

  * State that an object must not be destroyed until *all* (not *any*)
    uses of that object have completed (public issue 123).

  * Minor editorial cleanup (public issues 129, 134, 146, 148).

  * Add validity language for layer and extension names to
    slink:VkDeviceCreateInfo matching that used for
    slink:VkInstanceCreateInfo (public issue 130).

  * Clean up terminology for the case when the bits set in one bitmask
    are a subset of the bits set in another bitmask (public issue 138).

  * Document that input attachments are UniformConstant not Input, in
    the <<interfaces-inputattachment,Fragment Input Attachment
    Interface>> section (public glslang bug 169).

Internal Issues:

  * Add max enum values to "flag bits" enums (internal issue #136).

  * Clarify language around the various uses of the term "block" in the
    <<appendix-compressedtex-bc,Block Compressed Image Formats>> section
    (internal issue #202).

  * Removed "expand" dependency from <enums> groups in vk.xml and added
    auto-generation code in the scripts to infer it instead, to ensure
    consistency. This caused renaming of sname:VkColorSpaceKHR and
    sname:VkPresentModeKHR etext:BEGIN_RANGE (etc.) tokens, but those
    tokens are metadata, not part of the API, and the Vulkan WG is OK
    with this change. This change adds ranges to two additional enums
    that were missing them due to not defining the "expand" attribute
    (internal issue 217).

  * Tweak makefile to generate ref page nroff (.3) files in the right
    output directory, working around an a2x limitation (internal issue
    223).

Other Commits:

  * Add validity requirements for flink:vkCmdCopyQueryPoolResults
    pname:dstBuffer parameter.

  * Fix ref page build to generate .3 targets in the right output
    directory.
This commit is contained in:
Jon Leech 2016-03-25 02:25:04 -07:00
parent 13f85fac1a
commit 8c3c9b4c85
284 changed files with 7887 additions and 849 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
ChangeLog.txt
View File

@ -273,3 +273,89 @@ Other Commits:
* Update GL_KHR_vulkan_glsl so push_constants do not have descriptor
sets.
-----------------------------------------------------
Change log for March 25, 2016 Vulkan 1.0.7 spec update:
* Bump API patch number and header version number to 7 for this
update.
Github Issues:
* Fix slink:VkSpecializationMapEntry example to avoid C/C++ strict
aliasing issues (public issue 14).
* Clarify the meaning of "matching" in flink:vkCmdBindDescriptorSets
validity language (public issue 33).
* Add stub reference pages so xrefs to not-yet-written pages don't
generate 404 errors. However, the actual content of these pages
still needs to be filled in as time allows (public issue 44, but
does not close that issue out).
* Remove incorrect validity statement for
flink:vkGetImageSparseMemoryRequirements (public issue 85).
* Reword the
<<features-limits-bufferImageGranularity,bufferImageGranularity>>
feature in terms of "aliasing", and clarify that it applies to
bindings in the same memory object (public issue 90).
* Clarify the relationship of the slink:VkPhysicalDeviceLimits
pname:maxViewportDimensions and pname:viewportBoundsRange limits
(public issue 92).
* Specify sparse unbound texture replacement in the
<<textures-texel-replacement,Texel Replacement>> section
independently of robust buffer access language (public issue 100).
* Add the <<fundamentals-architecture-model,Architecture Model>>
section to explain architecture constraints Vulkan has chosen to
accept in order to enable portable and performant code (public issue
122).
* State that an object must not be destroyed until *all* (not *any*)
uses of that object have completed (public issue 123).
* Minor editorial cleanup (public issues 129, 134, 146, 148).
* Add validity language for layer and extension names to
slink:VkDeviceCreateInfo matching that used for
slink:VkInstanceCreateInfo (public issue 130).
* Clean up terminology for the case when the bits set in one bitmask
are a subset of the bits set in another bitmask (public issue 138).
* Document that input attachments are UniformConstant not Input, in
the <<interfaces-inputattachment,Fragment Input Attachment
Interface>> section (public glslang bug 169).
Internal Issues:
* Add max enum values to "flag bits" enums (internal issue #136).
* Clarify language around the various uses of the term "block" in the
<<appendix-compressedtex-bc,Block Compressed Image Formats>> section
(internal issue #202).
* Removed "expand" dependency from <enums> groups in vk.xml and added
auto-generation code in the scripts to infer it instead, to ensure
consistency. This caused renaming of sname:VkColorSpaceKHR and
sname:VkPresentModeKHR etext:BEGIN_RANGE (etc.) tokens, but those
tokens are metadata, not part of the API, and the Vulkan WG is OK
with this change. This change adds ranges to two additional enums
that were missing them due to not defining the "expand" attribute
(internal issue 217).
* Tweak makefile to generate ref page nroff (.3) files in the right
output directory, working around an a2x limitation (internal issue
223).
Other Commits:
* Add validity requirements for flink:vkCmdCopyQueryPoolResults
pname:dstBuffer parameter.
* Fix ref page build to generate .3 targets in the right output
directory.

4
doc/specs/vulkan/Makefile
View File

@ -44,7 +44,7 @@ ECHO:=echo
# XHTMLDIR - 'xhtml' target
# PDFDIR - 'pdf' target
# CHECKDIR - 'allchecks' target
OUTDIR :=../../../out/core
OUTDIR :=../../../out/1.0
HTMLDIR := $(OUTDIR)/html
XHTMLDIR := $(OUTDIR)/xhtml
PDFDIR := $(OUTDIR)/pdf
@ -126,7 +126,7 @@ INCLUDES := $(wildcard protos/*.txt structs/*.txt flags/*.txt enums/*.txt funcpo
COMMONDOCS := $(CHAPTERS) $(INCLUDES)
# A generated included file with the spec version, date, and git commit
SPECVERSION = specversion.txt
SPECREVISION = 1.0.6
SPECREVISION = 1.0.7
SPECREMARK =
# Spec targets

4
doc/specs/vulkan/appendices/compressedtex.txt
View File

@ -24,7 +24,7 @@ Format Specification.
<<<
[[appendix-compressedtex-bc]]
== Block Compressed Image Formats
== Block-Compressed Image Formats
.Mapping of {apiname} BC formats to descriptions
[width="90%",options="header",cols="5,4"]
@ -86,7 +86,7 @@ chapter of the Khronos Data Format Specification.
.Mapping of {apiname} ASTC formats to descriptions
[width="75%",options="header",cols="63%,15%,22%"]
|==============================
| VkFormat ^| Block size ^| sRGB-encoded
| VkFormat ^| Compressed texel block dimensions ^| sRGB-encoded
| ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK ^|latexmath:[$4\times 4$] ^|No
| ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK ^|latexmath:[$4\times 4$] ^|Yes
| ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK ^|latexmath:[$5\times 4$] ^|No

8
doc/specs/vulkan/appendices/extensions.txt
View File

@ -415,14 +415,14 @@ The information needed to add new values to the XML are as follows:
positive, if not specified.
Implicit is the registered number of an extension, which is used to create a
block of unused values offset against a global extension base value.
Individual enumerant values are calculated as offsets in that block. Values
range of unused values offset against a global extension base value.
Individual enumerant values are calculated as offsets in that range. Values
are calculated as follows:
* base_value = 1000000000
* block_size = 1000
* range_size = 1000
* enum_offset(extension_number,offset) = base_value +
(extension_number - 1) × block_size + offset
(extension_number - 1) × range_size + offset
* Positive values: enum_offset(extension_number,offset)
* Negative values: -enum_offset(extension_number,offset)

24
doc/specs/vulkan/appendices/glossary.txt
View File

@ -139,6 +139,14 @@ Compatible Queues::
Queues within a queue family. Compatible queues have identical
properties.
Compressed Texel Block::
An element of an image having a block-compressed format, comprising a
rectangular block of texel values that are encoded as a single value in
memory. Compressed texel blocks of a particular block-compressed format
have a corresponding width, height, and depth that define the dimensions
of these elements in units of texels, and a size in bytes of the encoding
in memory.
Cull Distance::
A built-in output from vertex processing stages that defines a cull
half-space where the primitive is rejected if all vertices have a
@ -435,8 +443,8 @@ Memory Type::
Mip Tail Region::
The set of mipmap levels of a sparse residency texture that are too
small to fill a block, and that must all be bound to memory collectively
and opaquely.
small to fill a sparse block, and that must all be bound to memory
collectively and opaquely.
Non-Dispatchable Handle::
A handle of an integer handle type. Handle values may: not be unique,
@ -607,6 +615,18 @@ Shader Stage::
Side Effect::
A store to memory or atomic operation on memory from a shader invocation.
Sparse Block::
An element of a sparse resource that can be independently bound to memory.
Sparse blocks of a particular sparse resource have a corresponding size
in bytes that they use in the bound memory.
Sparse Image Block::
A sparse block in a sparse partially-resident image. In addition to the
sparse block size in bytes, sparse image blocks have a corresponding
width, height, and depth that define the dimensions of these elements
in units of texels or compressed texel blocks, the latter being used in
case of sparse images having a block-compressed format.
Sparse Unbound Texel::
A texel read from a region of a sparse texture that does not have
memory bound to it.

117
doc/specs/vulkan/chapters/copies.txt
View File

@ -28,7 +28,8 @@ Some rules for valid operation are common to all copy commands:
* Copy regions must: be non-empty.
* Regions must: not extend outside the bounds of the buffer or image
level, except that regions of compressed images can: extend as far as
the dimension of the image level rounded up to a complete block.
the dimension of the image level rounded up to a complete compressed
texel block.
* Source image subresources must: be in either the
ename:VK_IMAGE_LAYOUT_GENERAL or
ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL layout. Destination image
@ -154,51 +155,57 @@ destination. pname:layerCount layers are copied to the destination image.
The formats of pname:srcImage and pname:dstImage must: be compatible.
Formats are considered compatible if their texel size in bytes is the same
between both formats. For example, ename:VK_FORMAT_R8G8B8A8_UNORM is
compatible with ename:VK_FORMAT_R32_UINT because because both texels are 4
compatible with ename:VK_FORMAT_R32_UINT because both texels are 4
bytes in size. Depth/stencil formats must: match exactly.
fname:vkCmdCopyImage allows copying between size-compatible compressed
and uncompressed internal formats. Formats are size-compatible if the texel
size of the uncompressed format is equal to the block size in bytes of the
compressed format. Such a copy does not perform on-the-fly compression or
decompression. When copying from an uncompressed format to a compressed
format, each texel of uncompressed data becomes a single block of compressed
data. When copying from a compressed format to an uncompressed format, a
block of compressed data becomes a single texel of uncompressed data. Thus,
for example, it is legal to copy between a 128-bit uncompressed format and a
compressed format which uses 8-bit/texel 4x4 blocks, or between a 64-bit
uncompressed format and a compressed format which uses 4-bit/texel 4x4
blocks.
size of the uncompressed format is equal to the compressed texel block size in
bytes of the compressed format. Such a copy does not perform on-the-fly
compression or decompression. When copying from an uncompressed format to a
compressed format, each texel of uncompressed data of the source image is
copied as a raw value to the corresponding compressed texel block of the
destination image. When copying from a compressed format to an uncompressed
format, each compressed texel block of the source image is copied as a raw
value to the corresponding texel of uncompressed data in the destination
image. Thus, for example, it is legal to copy between a 128-bit uncompressed
format and a compressed format which has a 128-bit sized compressed texel
block representing 4x4 texels (using 8 bits per texel), or between a 64-bit
uncompressed format and a compressed format which has a 64-bit sized
compressed texel block representing 4x4 texels (using 4 bits per texel).
When copying between compressed and uncompressed formats the pname:extent
members represent the texel dimensions of the source image and not the
destination. When copying from a compressed image to an uncompressed image
the image texel dimensions written to the uncompressed image will be source
extent divided by the block size. When copying from an uncompressed image to
a compressed image the image texel dimensions written to the compressed
image will be the source extent multiplied by the block size. In both cases
the number of bytes read and the number of bytes written will be identical.
extent divided by the compressed texel block dimensions. When copying from an
uncompressed image to a compressed image the image texel dimensions written
to the compressed image will be the source extent multiplied by the
compressed texel block dimensions. In both cases the number of bytes read and
the number of bytes written will be identical.
Copying to or from block-compressed images is typically done in multiples of
the block. For this reason the pname:extent must: be a multiple of the
block dimension. There is one exception to this rule which is required: to
handle compressed images created with dimensions that are not a multiple
of the block dimensions. If the pname:srcImage is compressed and if
pname:extent.width is not a multiple of the block width then
(pname:extent.width + pname:srcOffset.x) must: equal the subresource width,
if pname:extent.height is not a multiple of the block height then
(pname:extent.height + pname:srcOffset.y) must: equal
the subresource height and if pname:extent.depth is not a multiple of the
block depth then (pname:extent.depth + pname:srcOffset.z) must: equal
the subresource depth. Similarily if the pname:dstImage is compressed and
if pname:extent.width is not a multiple of the block width then
(pname:extent.width + pname:dstOffset.x) must: equal the subresource width,
if pname:extent.height is not a multiple of the block height then
(pname:extent.height + pname:dstOffset.y) must: equal
the subresource height and if pname:extent.depth is not a multiple of the
block depth then (pname:extent.depth + pname:dstOffset.z) must: equal
the subresource depth. This allows the last block of the image in each
non-multiple dimension to be included as a source or target of the copy.
the compressed texel block. For this reason the pname:extent must: be a
multiple of the compressed texel block dimension. There is one exception to
this rule which is required: to handle compressed images created with
dimensions that are not a multiple of the compressed texel block dimensions.
If the pname:srcImage is compressed and if pname:extent.width is not a
multiple of the compressed texel block width then (pname:extent.width +
pname:srcOffset.x) must: equal the subresource width, if pname:extent.height
is not a multiple of the compressed texel block height then
(pname:extent.height + pname:srcOffset.y) must: equal the subresource height
and if pname:extent.depth is not a multiple of the compressed texel block
depth then (pname:extent.depth + pname:srcOffset.z) must: equal the
subresource depth. Similarily if the pname:dstImage is compressed and if
pname:extent.width is not a multiple of the compressed texel block width then
(pname:extent.width + pname:dstOffset.x) must: equal the subresource width, if
pname:extent.height is not a multiple of the compressed texel block height
then (pname:extent.height + pname:dstOffset.y) must: equal the subresource
height and if pname:extent.depth is not a multiple of the compressed texel
block depth then (pname:extent.depth + pname:dstOffset.z) must: equal the
subresource depth. This allows the last compressed texel block of the image
in each non-multiple dimension to be included as a source or destination of
the copy.
fname:vkCmdCopyImage can: be used to copy image data between multisample
images, but both images must: have the same number of samples.
@ -330,8 +337,8 @@ buffer memory. Instead, pname:bufferOffset can: be used to
select the starting address in buffer memory.
For block-compression formats, all parameters are still specified in texels
rather than blocks, but the addressing math operates on whole blocks.
Pseudocode for compressed copy addressing is:
rather than compressed texel blocks, but the addressing math operates on
whole compressed texel blocks. Pseudocode for compressed copy addressing is:
[source,c]
---------------------------------------------------
@ -343,28 +350,30 @@ imageHeight = region->bufferImageHeight;
if (imageHeight == 0)
imageHeight = region->imageExtent.height;
blockSizeInBytes = <block size taken from the src/dstImage>;
rowLength /= blockWidth;
imageHeight /= blockHeight;
compressedTexelBlockSizeInBytes = <compressed texel block size taken from the src/dstImage>;
rowLength /= compressedTexelBlockWidth;
imageHeight /= compressedTexelBlockHeight;
address of (x,y,z) = region->bufferOffset + (((z * imageHeight) + y) * rowLength + x) * blockSizeInBytes;
address of (x,y,z) = region->bufferOffset + (((z * imageHeight) + y) * rowLength + x) * compressedTexelBlockSizeInBytes;
where x,y,z range from (0,0,0) to region->imageExtent.{width/blockWidth,height/blockHeight,depth/blockDepth}.
where x,y,z range from (0,0,0) to region->imageExtent.{width/compressedTexelBlockWidth,height/compressedTexelBlockHeight,depth/compressedTexelBlockDepth}.
---------------------------------------------------
Copying to or from block-compressed images is typically done in multiples of
the block. For this reason the pname:imageExtent must: be a multiple of the
block dimension. There is one exception to this rule which is required: to
handle compressed images created with dimensions that are not a multiple of
the block dimensions. If pname:imageExtent.width is not a multiple of the
block width then (pname:imageExtent.width + pname:imageOffset.x) must: equal
the subresource width, if pname:imageExtent.height is not a multiple of the
block height then (pname:imageExtent.height + pname:imageOffset.y) must:
equal the subresource height and if pname:imageExtent.depth is not a
multiple of the block depth then (pname:imageExtent.depth +
pname:imageOffset.z) must: equal the subresource depth. This allows the last
block of the image in each non-multiple dimension to be included as a source
or target of the copy.
the compressed texel block. For this reason the pname:imageExtent must: be a
multiple of the compressed texel block dimension. There is one exception to
this rule which is required: to handle compressed images created with
dimensions that are not a multiple of the compressed texel block dimensions.
If pname:imageExtent.width is not a multiple of the compressed texel block
width then (pname:imageExtent.width + pname:imageOffset.x) must: equal the
subresource width, if pname:imageExtent.height is not a multiple of the
compressed texel block height then (pname:imageExtent.height +
pname:imageOffset.y) must: equal the subresource height and if
pname:imageExtent.depth is not a multiple of the compressed texel block depth
then (pname:imageExtent.depth + pname:imageOffset.z) must: equal the
subresource depth. This allows the last compressed texel block of the image
in each non-multiple dimension to be included as a source or destination of
the copy.
[[copies-imagescaling]]

10
doc/specs/vulkan/chapters/devsandqueues.txt
View File

@ -220,8 +220,9 @@ include::../validity/structs/VkQueueFamilyProperties.txt[]
For further details see <<devsandqueues-queues,Queues>>.
The value returned in pname:minImageTransferGranularity has a unit of blocks
for images having a block compressed format, and a unit of texels otherwise.
The value returned in pname:minImageTransferGranularity has a unit of
compressed texel blocks for images having a block-compressed format, and a
unit of texels otherwise.
Possible values of pname:minImageTransferGranularity are:
@ -257,8 +258,9 @@ Possible values of pname:minImageTransferGranularity are:
equal the depth of the image subresource corresponding to the
parameter.
** If the format of the image corresponding to the parameters is one of
the block compressed formats then for the purposes of the above
calculations the granularity must: be scaled up by the block size.
the block-compressed formats then for the purposes of the above
calculations the granularity must: be scaled up by the compressed
texel block dimensions.
Queues supporting graphics and/or compute operations must: report
latexmath:[$(1,1,1)$] in pname:minImageTransferGranularity, meaning that

403
doc/specs/vulkan/chapters/features.txt
View File

@ -463,9 +463,9 @@ check for the supported properties of individual formats.
code. This also indicates whether shader modules can: declare the
code:MinLod capability.
* [[features-features-sparseBinding]] pname:sparseBinding indicates
whether resource memory can: be managed at opaque block level instead of
at the object level. If this feature is not enabled, resource memory
must: be bound only on a per-object basis using the
whether resource memory can: be managed at opaque sparse block level
instead of at the object level. If this feature is not enabled, resource
memory must: be bound only on a per-object basis using the
fname:vkBindBufferMemory and fname:vkBindImageMemory commands. In this
case, buffers and images mustnot: be created with
ename:VK_BUFFER_CREATE_SPARSE_BINDING_BIT and
@ -624,9 +624,10 @@ properties of the physical device:
exist on a device.
* [[features-limits-bufferImageGranularity]] pname:bufferImageGranularity
is the granularity, in bytes, at which buffer or linear image resources,
and optimal image resources can: be bound to adjacent memory for
simultaneous usage. See <<resources-bufferimagegranularity,Buffer-Image
Granularity>> for more details.
and optimal image resources can: be bound to adjacent offsets in the same
sname:VkDeviceMemory object without aliasing. See
<<resources-bufferimagegranularity,Buffer-Image Granularity>> for more
details.
* [[features-limits-sparseAddressSpaceSize]] pname:sparseAddressSpaceSize
is the total amount of address space available, in bytes, for sparse
memory resources. This is an upper bound on the sum of the size of all
@ -726,7 +727,7 @@ properties of the physical device:
<<descriptorsets-combinedimagesampler>>.
* [[features-limits-maxDescriptorSetUniformBuffers]]
pname:maxDescriptorSetUniformBuffers is the maximum number of uniform
buffers that can: be be included in descriptor bindings in a pipeline
buffers that can: be included in descriptor bindings in a pipeline
layout across all pipeline shader stages and descriptor set numbers.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC count against this
@ -741,7 +742,7 @@ properties of the physical device:
limit. See <<descriptorsets-uniformbufferdynamic>>.
* [[features-limits-maxDescriptorSetStorageBuffers]]
pname:maxDescriptorSetStorageBuffers is the maximum number of storage
buffers that can: be be included in descriptor bindings in a pipeline
buffers that can: be included in descriptor bindings in a pipeline
layout across all pipeline shader stages and descriptor set numbers.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC count against this
@ -749,14 +750,14 @@ properties of the physical device:
<<descriptorsets-storagebufferdynamic>>.
* [[features-limits-maxDescriptorSetStorageBuffersDynamic]]
pname:maxDescriptorSetStorageBuffersDynamic is the maximum number of
dynamic storage buffers that can: be be included in descriptor bindings
dynamic storage buffers that can: be included in descriptor bindings
in a pipeline layout across all pipeline shader stages and descriptor
set numbers. Descriptors with a type of
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC count against this
limit. See <<descriptorsets-storagebufferdynamic>>.
* [[features-limits-maxDescriptorSetSampledImages]]
pname:maxDescriptorSetSampledImages is the maximum number of sampled
images that can: be be included in descriptor bindings in a pipeline
images that can: be included in descriptor bindings in a pipeline
layout across all pipeline shader stages and descriptor set numbers.
Descriptors with a type of
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
@ -767,7 +768,7 @@ properties of the physical device:
<<descriptorsets-uniformtexelbuffer>>.
* [[features-limits-maxDescriptorSetStorageImages]]
pname:maxDescriptorSetStorageImages is the maximum number of storage
images that can: be be included in descriptor bindings in a pipeline
images that can: be included in descriptor bindings in a pipeline
layout across all pipeline shader stages and descriptor set numbers.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER count against this limit.
@ -775,7 +776,7 @@ properties of the physical device:
<<descriptorsets-storagetexelbuffer>>.
* [[features-limits-maxDescriptorSetInputAttachments]]
pname:maxDescriptorSetInputAttachments is the maximum number of input
attachments that can: be be included in descriptor bindings in a
attachments that can: be included in descriptor bindings in a
pipeline layout across all pipeline shader stages and descriptor set
numbers. Descriptors with a type of
ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT count against this limit. See
@ -971,9 +972,28 @@ different equations in the spec).
which can: be created and used as a framebuffer attachment. See
<<vertexpostproc-viewport,Controlling the Viewport>>.
* [[features-limits-viewportboundsrange]] pname:viewportBoundsRange[2] is
the viewport bounds range
latexmath:[$[\mathit{minimum},\mathit{maximum}\]$]. See
<<vertexpostproc-viewport,Controlling the Viewport>>.
the latexmath:[$[\mathit{minimum},\mathit{maximum}\]$] range that the
corners of a viewport must: be contained in. This range must: be at
least latexmath:[$[- 2 \times \mathit{maxViewportDimensions},
2 \times \mathit{maxViewportDimensions} - 1\]$].
See <<vertexpostproc-viewport,Controlling the Viewport>>.
+
--
[NOTE]
.Note
====
The intent of the pname:viewportBoundsRange limit is to allow a maximum sized
viewport to be arbitrarily shifted relative to the output target as long
as at least some portion intersects. This would give a bounds limit of
latexmath:[$[- \mathit{maxViewportDimensions}+1,
2 \times \mathit{maxViewportDimensions} -1\]$] which would allow
all possible non-empty-set intersections of the output target and the viewport.
Since these numbers are typically powers of two, picking the signed number
range using the smalled possible number of bits, ends up with the specified
range.
====
--
* [[features-limits-viewportSubPixelBits]] pname:viewportSubPixelBits is
the number of bits of subpixel precision for viewport bounds. The
subpixel precision that floating-point viewport bounds are interpreted
@ -1453,10 +1473,12 @@ the same whether or not the feature is enabled.
It may: not be possible to reach this limit in every stage.
3::
Maximum image attachment size or maximum display size
See <<features-limits-maxViewportDimensions,pname:maxViewportDimensions>>
for the required relationship to other limits.
4::
Double the pname:maxViewportDimensions
See <<features-limits-viewportboundsrange,pname:viewportBoundsRange>>
for the required relationship to other limits.
5::
The values pname:minInterpolationOffset and pname:maxInterpolationOffset
@ -2260,283 +2282,274 @@ ename:VK_FORMAT_D32_SFLOAT_S8_UINT::
are optionally: 24-bits that are unused.
ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK::
A three-component, block compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data. This format
has no alpha and is considered opaque.
A three-component, block-compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data.
This format has no alpha and is considered opaque.
ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK::
A three-component, block compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data with sRGB
nonlinear encoding. This format has no alpha and is considered opaque.
A three-component, block-compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data
with sRGB nonlinear encoding. This format has no alpha and is considered
opaque.
ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data, and provides 1
bit of alpha.
A four-component, block-compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data,
and provides 1 bit of alpha.
ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data with sRGB
nonlinear encoding, and provides 1 bit of alpha.
A four-component, block-compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data
with sRGB nonlinear encoding, and provides 1 bit of alpha.
ename:VK_FORMAT_BC2_UNORM_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 64-bits of unsigned normalized alpha image data followed by 64-bits
of encoded unsigned normalized RGB image data.
A four-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits encoding
RGB values.
ename:VK_FORMAT_BC2_SRGB_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 64-bits of unsigned normalized alpha image data followed by 64-bits
of encoded unsigned normalized RGB image data with sRGB nonlinear
encoding.
A four-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits encoding
RGB values with sRGB nonlinear encoding.
ename:VK_FORMAT_BC3_UNORM_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 64-bits of encoded alpha image data followed by 64-bits of encoded
RGB image data. Both blocks are decoded as unsigned normalized values.
A four-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits encoding
RGB values.
ename:VK_FORMAT_BC3_SRGB_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 64-bits of encoded alpha image data followed by 64-bits of encoded
RGB image data with sRGB nonlinear encoding. Both blocks are decoded as
unsigned normalized values.
A four-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits encoding
RGB values with sRGB nonlinear encoding.
ename:VK_FORMAT_BC4_UNORM_BLOCK::
A one-component, block compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized red image data.
A one-component, block-compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized red texel data.
ename:VK_FORMAT_BC4_SNORM_BLOCK::
A one-component, block compressed format where each 4x4 block consists
of 64-bits of encoded signed normalized red image data.
A one-component, block-compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of signed normalized red texel data.
ename:VK_FORMAT_BC5_UNORM_BLOCK::
A two-component, block compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized red image data followed by
64-bits of encoded unsigned normalized green image data.
A two-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RG texel data
with the first 64 bits encoding red values followed by 64 bits encoding
green values.
ename:VK_FORMAT_BC5_SNORM_BLOCK::
A two-component, block compressed format where each 4x4 block consists
of 64-bits of encoded signed normalized red image data followed by
64-bits of encoded signed normalized green image data.
A two-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of signed normalized RG texel data
with the first 64 bits encoding red values followed by 64 bits encoding
green values.
ename:VK_FORMAT_BC6H_UFLOAT_BLOCK::
A three-component, block compressed format where each 4x4 block consists
of 128-bits of encoded unsigned floating-point RGB image data.
A three-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned floating-point RGB texel
data.
ename:VK_FORMAT_BC6H_SFLOAT_BLOCK::
A three-component, block compressed format where each 4x4 block consists
of 128-bits of encoded signed floating-point RGB image data.
A three-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of signed floating-point RGB texel
data.
ename:VK_FORMAT_BC7_UNORM_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 128-bits of encoded unsigned normalized RGBA image data.
A four-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_BC7_SRGB_BLOCK::
A four-component, block compressed format where each 4x4 block consists
of 128-bits of encoded unsigned normalized RGBA image data with sRGB
nonlinear encoding applied to the RGB components.
A four-component, block-compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel
data with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK::
A three-component, ETC2 compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data.
A three-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data.
This format has no alpha and is considered opaque.
ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK::
A three-component, ETC2 compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data with sRGB
nonlinear encoding.
A three-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data
with sRGB nonlinear encoding. This format has no alpha and is considered
opaque.
ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK::
A four-component, ETC2 compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data, and provides 1
bit of alpha.
A four-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data,
and provides 1 bit of alpha.
ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK::
A four-component, ETC2 compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data with sRGB
nonlinear encoding, and provides 1 bit of alpha.
A four-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGB texel data
with sRGB nonlinear encoding, and provides 1 bit of alpha.
ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK::
A four-component, ETC2 compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data, and 64-bits of
encoded unsigned normalized alpha image data.
A four-component, ETC2 compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits encoding
RGB values.
ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK::
A four-component, ETC2 compressed format where each 4x4 block consists
of 64-bits of encoded unsigned normalized RGB image data with sRGB
nonlinear encoding, and 64-bits of encoded unsigned normalized alpha
image data.
A four-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits encoding
RGB values with sRGB nonlinear encoding applied.
ename:VK_FORMAT_EAC_R11_UNORM_BLOCK::
A one-component, ETC2 compressed format where each 4x4 block consists of
64-bits of encoded unsigned normalized red image data.
A one-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized red texel data.
ename:VK_FORMAT_EAC_R11_SNORM_BLOCK::
A one-component, ETC2 compressed format where each 4x4 block consists of
64-bits of encoded signed normalized red image data.
A one-component, ETC2 compressed format where each 64-bit compressed
texel block encodes a 4x4 rectangle of signed normalized red texel data.
ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK::
A two-component, ETC2 compressed format where each 4x4 block consists of
64-bits of encoded unsigned normalized red image data followed by
64-bits of encoded unsigned normalized green image data.
A two-component, ETC2 compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RG texel data
with the first 64 bits encoding red values followed by 64 bits encoding
green values.
ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK::
A two-component, ETC2 compressed format where each 4x4 block consists of
64-bits of encoded signed normalized red image data followed by 64-bits
of encoded signed normalized green image data.
A two-component, ETC2 compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of signed normalized RG texel data
with the first 64 bits encoding red values followed by 64 bits encoding
green values.
ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK::
A four-component, ASTC compressed format where each 4x4 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK::
A four-component, ASTC compressed format where each 4x4 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 4x4 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK::
A four-component, ASTC compressed format where each 5x4 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 5x4 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK::
A four-component, ASTC compressed format where each 5x4 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 5x4 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK::
A four-component, ASTC compressed format where each 5x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 5x5 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK::
A four-component, ASTC compressed format where each 5x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 5x5 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK::
A four-component, ASTC compressed format where each 6x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 6x5 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK::
A four-component, ASTC compressed format where each 6x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 6x5 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK::
A four-component, ASTC compressed format where each 6x6 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 6x6 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK::
A four-component, ASTC compressed format where each 6x6 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 6x6 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK::
A four-component, ASTC compressed format where each 8x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 8x5 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK::
A four-component, ASTC compressed format where each 8x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 8x5 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK::
A four-component, ASTC compressed format where each 8x6 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 8x6 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK::
A four-component, ASTC compressed format where each 8x6 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 8x6 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK::
A four-component, ASTC compressed format where each 8x8 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 8x8 rectangle of unsigned normalized RGBA texel data.
ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK::
A four-component, ASTC compressed format where each 8x8 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 8x8 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK::
A four-component, ASTC compressed format where each 10x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x5 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK::
A four-component, ASTC compressed format where each 10x5 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x5 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK::
A four-component, ASTC compressed format where each 10x6 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x6 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK::
A four-component, ASTC compressed format where each 10x6 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x6 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK::
A four-component, ASTC compressed format where each 10x8 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x8 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK::
A four-component, ASTC compressed format where each 10x8 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x8 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK::
A four-component, ASTC compressed format where each 10x10 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x10 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK::
A four-component, ASTC compressed format where each 10x10 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 10x10 rectangle of unsigned normalized RGBA texel
data with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK::
A four-component, ASTC compressed format where each 12x10 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 12x10 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK::
A four-component, ASTC compressed format where each 12x10 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 12x10 rectangle of unsigned normalized RGBA texel
data with sRGB nonlinear encoding applied to the RGB components.
ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK::
A four-component, ASTC compressed format where each 12x12 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 12x12 rectangle of unsigned normalized RGBA texel
data.
ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK::
A four-component, ASTC compressed format where each 12x12 block consists
of 128-bits of encoded image data which is decoded as unsigned
normalized RGBA image data with sRGB nonlinear encoding applied to
the RGB components.
A four-component, ASTC compressed format where each 128-bit compressed
texel block encodes a 12x12 rectangle of unsigned normalized RGBA texel
data with sRGB nonlinear encoding applied to the RGB components.
[[features-formats-packed]]
@ -2616,7 +2629,7 @@ is unused, but may: be present for padding.
The suffix etext:_PACKnn indicates that the format is packed into an
underlying type with nn bits.
The suffix etext:_BLOCK indicates that the format is a block compressed
The suffix etext:_BLOCK indicates that the format is a block-compressed
format, with the representation of multiple pixels encoded interdependently
within a region.
@ -3702,10 +3715,10 @@ returns ename:VK_ERROR_FORMAT_NOT_SUPPORTED.
The limitations on an image format that are reported by
fname:vkGetPhysicalDeviceImageFormatProperties have the following property:
if code:usage1 and code:usage2 of type elink:VkImageUsageFlags and
if code:usage1 and code:usage2 of type elink:VkImageUsageFlags are such that
the bits set in code:usage1 are a subset of the bits set in code:usage2, and
code:flags1 and code:flags2 of type elink:VkImageCreateFlags are such that
code:usage1 contains a subset of the bits set in code:usage2 and code:flags1
contains a subset of the bits set in code:flags2, then the limitations for
code:usage1 and code:flags1 must: be no more strict than the limitations for
code:usage2 and code:flags2, for all values of pname:format, pname:type, and
pname:tiling.
the bits set in code:flags1 are a subset of the bits set in code:flags2,
then the limitations for code:usage1 and code:flags1 must: be no more strict
than the limitations for code:usage2 and code:flags2, for all values of
pname:format, pname:type, and pname:tiling.

59
doc/specs/vulkan/chapters/fundamentals.txt
View File

@ -5,10 +5,51 @@
= Fundamentals
This chapter introduces fundamental concepts including the {apiname}
execution model, API syntax, queues, pipeline configurations, numeric
representation, state and state queries, and the different types of objects
and shaders. It provides a framework for interpreting more specific
descriptions of commands and behavior in the remainder of the Specification.
architecture and execution model, API syntax, queues, pipeline
configurations, numeric representation, state and state queries, and the
different types of objects and shaders. It provides a framework for
interpreting more specific descriptions of commands and behavior in the
remainder of the Specification.
[[fundamentals-architecture-model]]
== Architecture Model
Vulkan is designed for, and the API is written for, CPU, GPU, and other
hardware accelerator architectures with the following properties:
* Runtime support for 8, 16, 32 and 64-bit signed and unsigned
twos-complement integers, all addressable at the granularity of their size
in bytes.
* Runtime support for 32- and 64-bit floating-point types satisfying the
range and precision constraints in the
<<fundamentals-floatingpoint,Floating Point Computation>> section.
* The representation and endianness of these types must: be identical for
the host and the physical devices.
[NOTE]
.Note
====
Since a variety of data types and structures in Vulkan may: be mapped back
and forth between host and physical device memory, host and device
architectures must: both be able to access such data efficiently in order to
write portable and performant applications.
====
Where the Specification leaves choices open that would affect Application
Binary Interface compatibility on a given platform supporting Vulkan, those
choices are usually made to be compliant to the preferred ABI defined by the
platform vendor. Some choices, such as function calling conventions, may: be
made in platform-specific portions of the +vk_platform.h+ header file.
[NOTE]
.Note
====
For example, the Android ABI is defined by Google, and the Linux ABI is
defined by a combination of gcc defaults, distribution vendor choices, and
external standards such as the Linux Standard Base.
====
[[fundamentals-execmodel]]
@ -266,7 +307,7 @@ descriptor set layout has been destroyed. Otherwise, descriptor set layouts
can be destroyed any time they are not in use by an API command.
The application mustnot: destroy any other type of {apiname} object until
any uses of that object by the device (such as via command buffer execution)
all uses of that object by the device (such as via command buffer execution)
have completed.
The following {apiname} objects can: be destroyed when no command buffers
@ -391,7 +432,7 @@ Information is retrieved from the implementation with commands of the form
ftext:vkGet*.
Commands are recorded into a command buffer by calling API commands of the
form ftext:vkCmd*. Each such command may have different restrictions on
form ftext:vkCmd*. Each such command may: have different restrictions on
where it can be used: in a primary and/or secondary command buffer, inside
and/or outside a render pass, and in one or more of the supported queue
types. These restrictions are documented together with the definition of
@ -975,8 +1016,8 @@ include::../validity/structs/VkOffset3D.txt[]
=== Extents
Extents are used to describe the size of a block of pixels within an image
or framebuffer, as (width,height) for two-dimensional images, or as
Extents are used to describe the size of a rectangular region of pixels within
an image or framebuffer, as (width,height) for two-dimensional images, or as
(width,height,depth) for three-dimensional images. Two- and
three-dimensional extents are respectively defined by the structures
@ -991,7 +1032,7 @@ include::../validity/structs/VkExtent3D.txt[]
=== Rectangles
Rectangles are used to describe a specified rectangular block of pixels
Rectangles are used to describe a specified rectangular region of pixels
within an image or framebuffer. Rectangles include both an offset and an
extent of the same dimensionality, as described above. Two-dimensional
rectangles are defined by the structure

2
doc/specs/vulkan/chapters/fxvertex.txt
View File

@ -247,7 +247,7 @@ as specified above are supported. _Location aliasing_ is
causing two variables to have the same location number. _Component aliasing_
is assigning the same (or overlapping) component number for
two location aliases. Location aliasing is allowed only if it does
not cause compenent aliasing. Further, when location aliasing, the
not cause component aliasing. Further, when location aliasing, the
aliases sharing the location must: have the same underlying numerical
type (floating-point or integer). Failure to meet these requirements
will result in an invalid pipeline.

48
doc/specs/vulkan/chapters/interfaces.txt
View File

@ -319,19 +319,21 @@ attachments specified in the pname:pInputAttachments array of the
slink:VkSubpassDescription structure that describes the subpass that
the fragment shader is executed in.
The fragment shader input variables listed by code:OpEntryPoint with the
code:Input storage class and a decoration of code:InputAttachmentIndex
form the _fragment input attachment interface_. These variables must:
be declared with a type of code:OpTypeImage and a code:Dim operand
of code:SubpassData.
The fragment shader subpass input variables with the code:UniformConstant
storage class and a decoration of code:InputAttachmentIndex that are
statically used by code:OpEntryPoint form the _fragment input
attachment interface_. These variables must: be declared with a type
of code:OpTypeImage, a code:Dim operand of code:SubpassData, and a
code:Sampled operand of 2.
A fragment shader input variable identified with an code:InputAttachmentIndex
A subpass input variable identified with an code:InputAttachmentIndex
decoration of _i_ reads from the input attachment indicated by
pname:pInputAttachments[_i_]. If the input variable is declared as
an array of size N, it consumes N consecutive input attachments, starting
with the index specified. There mustnot: be more than one input variable
with the same code:InputAttachmentIndex whether explicitly declared or
implied by an array declaration. The number of available input attachment
pname:pInputAttachments[_i_] member of sname:VkSubpassDescription.
If the subpass input variable is declared
as an array of size N, it consumes N consecutive input attachments,
starting with the index specified. There mustnot: be more than one input
variable with the same code:InputAttachmentIndex whether explicitly declared
or implied by an array declaration. The number of available input attachment
indices is given by the pname:maxPerStageDescriptorInputAttachments member
of the sname:VkPhysicalDeviceLimits structure.
@ -355,10 +357,9 @@ at pipeline creation time.
The set of shader resources that form the _shader resource interface_
for a stage are the variables statically used by code:OpEntryPoint
with the storage classes of code:Uniform, code:UniformConstant, and
code:PushConstant. For the fragment shader, the variables identified by
operands to code:OpEntryPoint with a storage class of code:Input and a
decoration of code:InputAttachmentIndex are also included in this interface.
with the storage class of code:Uniform, code:UniformConstant, or
code:PushConstant. For the fragment shader, this includes the
<<interfaces-inputattachment, fragment input attachment interface>>.
The shader resource interface can be further broken down into two
sub-interfaces: the push constant interface and the descriptor
@ -368,8 +369,8 @@ set interface.
[[interfaces-resources-pushconst]]
=== Push Constant Interface
The shader variables defined with a storage class of code:PushConstant that
are statically used by the shader entry points for the pipeline
The shader variables defined with a storage class of code:PushConstant
that are statically used by the shader entry points for the pipeline
define the _push constant interface_. They must: be:
* typed as code:OpTypeStruct,
@ -398,8 +399,8 @@ only be accessed with dynamically uniform indices.
=== Descriptor Set Interface
The _descriptor set interface_ is comprised of the shader variables with the
storage classes of code:Uniform, code:UniformConstant, and the variables in
the <<interfaces-inputattachment,fragment input attachment interface>>,
storage class of code:Uniform or code:UniformConstant (including the variables
in the <<interfaces-inputattachment,fragment input attachment interface>>)
that are statically used by the shader entry points for the pipeline.
These variables must: have code:DescriptorSet and code:Binding decorations
@ -473,9 +474,9 @@ decoration for any variable in a code:BufferBlock mustnot: cause the
space required for that variable to extend outside the range
latexmath:[$[0, \mathit{maxStorageBufferRange})$].
Variables identified with a storage class of code:Input and a decoration of
code:InputAttachmentIndex must be declared as described
<<interfaces-inputattachment,above>>.
Variables identified with a storage class of code:UniformConstant and a
decoration of code:InputAttachmentIndex must be declared as described in
<<interfaces-inputattachment,Fragment Input Attachment Interface>>.
Each shader variable declaration must: refer to the same type of resource as
is indicated by the pname:descriptorType. See
@ -524,7 +525,8 @@ descriptor types.
| code:Uniform | code:OpTypeStruct
| code:BufferBlock, code:Offset, (code:ArrayStride), (code:MatrixStride)
| input attachment
| code:Input | code:OpTypeImage (code:Dim=code:SubpassData) | code:InputAttachmentIndex
| code:UniformConstant | code:OpTypeImage (code:Dim=code:SubpassData, code:Sampled=2)
| code:InputAttachmentIndex
|=============================
1:: in addition to code:DescriptorSet and code:Binding

30
doc/specs/vulkan/chapters/pipelines.txt
View File

@ -221,7 +221,7 @@ include::../structs/VkGraphicsPipelineCreateInfo.txt[]
* pname:pViewportState is a pointer to an instance of the
slink:VkPipelineViewportStateCreateInfo structure, or `NULL` if the
pipeline has rasterization disabled.
* pname:pRasterState is a pointer to an instance of the
* pname:pRasterizationState is a pointer to an instance of the
slink:VkPipelineRasterizationStateCreateInfo structure.
* pname:pMultisampleState is a pointer to an instance of the
slink:VkPipelineMultisampleStateCreateInfo, or `NULL` if the pipeline
@ -791,31 +791,35 @@ Now to specialize the above via the specialization constants mechanism:
[source,{basebackend@docbook:c++:cpp}]
---------------------------------------------------
struct SpecializationData {
int32_t data0;
float data1;
};
const VkSpecializationMapEntry entries[] =
{
{
0, // constantID
0 * sizeof(int32_t), // offset
sizeof(int32_t) // size
0, // constantID
offsetof(SpecializationData, data0), // offset
sizeof(SpecializationData::data0) // size
},
{
12, // constantID
1 * sizeof(int32_t), // offset
sizeof(float) // size
12, // constantID
offsetof(SpecializationData, data1), // offset
sizeof(SpecializationData::data1) // size
}
};
int32_t data[2];
data[0] = -42; // set the data for the 32-bit integer
((float*)data)[1] = 42.0f; // set the data for the 32-bit floating-point
SpecializationData data;
data.data0 = -42; // set the data for the 32-bit integer
data.data1 = 42.0f; // set the data for the 32-bit floating-point
const VkSpecializationInfo info =
{
2, // mapEntryCount
entries, // pMapEntries
2 * sizeof(int32_t), // dataSize
data, // pData
sizeof(data), // dataSize
&data, // pData
};
---------------------------------------------------

68
doc/specs/vulkan/chapters/resources.txt
View File

@ -434,14 +434,15 @@ address(x,y,z,layer) = layer*arrayPitch + z*depthPitch + y*rowPitch + x*texelSiz
---------------------------------------------------
For compressed formats, the pname:rowPitch is the number of bytes between
compressed blocks in adjacent rows. pname:arrayPitch is the number of bytes
between blocks in adjacent array layers. pname:depthPitch is the number of
bytes between blocks in adjacent slices of a 3D image.
compressed texel blocks in adjacent rows. pname:arrayPitch is the number of
bytes between compressed texel blocks in adjacent array layers.
pname:depthPitch is the number of bytes between compressed texel blocks in
adjacent slices of a 3D image.
[source,c]
---------------------------------------------------
// (x,y,z,layer) are in block coordinates
address(x,y,z,layer) = layer*arrayPitch + z*depthPitch + y*rowPitch + x*blockSize + offset;
// (x,y,z,layer) are in compressed texel block coordinates
address(x,y,z,layer) = layer*arrayPitch + z*depthPitch + y*rowPitch + x*compressedTexelBlockByteSize + offset;
---------------------------------------------------
@ -950,15 +951,15 @@ flink:vkGetImageMemoryRequirements:
ename:VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT bit and the
ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT bit set. In other words,
mappable coherent memory can: always be attached to these objects.
* The pname:memoryTypeBits member is identical for all
sname:VkBuffer objects created with the same value for the pname:flags
and pname:usage members in the sname:VkBufferCreateInfo structure passed
to fname:vkCreateBuffer. Further, if code:usage1 and code:usage2 of type
elink:VkBufferUsageFlags are such that code:usage2 comprises a subset of
the bits set in code:usage1 and they have the same pname:flags, then the
bits set in pname:memoryTypeBits returned for code:usage1 must: be a
subset of the bits set in pname:memoryTypeBits returned for code:usage2,
for all values of pname:flags.
* The pname:memoryTypeBits member is identical for all sname:VkBuffer
objects created with the same value for the pname:flags and pname:usage
members in the sname:VkBufferCreateInfo structure passed to
fname:vkCreateBuffer. Further, if code:usage1 and code:usage2 of type
elink:VkBufferUsageFlags are such that the bits set in code:usage2 are a
subset of the bits set in code:usage1, and they have the same
pname:flags, then the bits set in pname:memoryTypeBits returned for
code:usage1 must: be a subset of the bits set in pname:memoryTypeBits
returned for code:usage2, for all values of pname:flags.
* The pname:alignment member is identical for all sname:VkBuffer objects
created with the same combination of values for the pname:usage and
pname:flags members in the sname:VkBufferCreateInfo structure passed to
@ -1011,8 +1012,8 @@ include::../validity/protos/vkBindImageMemory.txt[]
.Buffer-Image Granularity
There is an implementation-dependent limit, pname:bufferImageGranularity,
which specifies a page-like granularity at which buffer, linear image and
optimal image resources must be placed in adjacent memory locations for
simultaneous usage. Two resources which do not satisfy this granularity
optimal image resources must: be placed in adjacent memory locations to
avoid aliasing. Two resources which do not satisfy this granularity
requirement are said to <<resources-memory-aliasing,alias>>. Linear image
resource are images created with ename:VK_IMAGE_TILING_LINEAR and optimal
image resources are those created with ename:VK_IMAGE_TILING_OPTIMAL.
@ -1020,9 +1021,19 @@ pname:bufferImageGranularity is specified in bytes, and must: be a power of
two. Implementations which do not require such an additional granularity
may: report a value of one.
[NOTE]
.Note
====
pname:bufferImageGranularity is really a granularity between "linear"
resources, including buffers and images with linear tiling, vs. "optimal"
resources, i.e. images with optimal tiling. It would have been better named
"linearOptimalGranularity".
====
Given resourceA at the lower memory offset and resourceB at the higher
memory offset, where one of the resources is a buffer or a linear image
and the other is an optimal image, and the following:
memory offset in the same sname:VkDeviceMemory object, where one of the
resources is a buffer or a linear image and the other is an optimal image,
and the following:
resourceA.end = resourceA.memoryOffset + resourceA.size - 1
resourceA.endPage = resourceA.end & ~(bufferImageGranularity-1)
@ -1043,7 +1054,7 @@ Adjacent buffers' or adjacent images'
memory ranges can: be closer than pname:bufferImageGranularity, provided
they meet the pname:alignment requirement for the objects in question.
Sparse memory block sizes and sparse image and buffer memory alignments
Sparse block size in bytes and sparse image and buffer memory alignments
must: all be multiples of the pname:bufferImageGranularity. Therefore,
memory bound to sparse resources naturally satisfies the
pname:bufferImageGranularity.
@ -1142,10 +1153,10 @@ bound to an aliased range, all subresources of the image _overlap_ the
range. When a linear image is bound to an aliased range, the subresources
that (according to the image's advertised layout) include bytes from the
aliased range overlap the range. When a
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT image has blocks bound to an
aliased range, only subresources including those blocks overlap the range,
and when the memory bound to the image's miptail overlaps an aliased range
all subresources in the miptail overlap the range.
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT image has sparse image blocks bound
to an aliased range, only subresources including those sparse image blocks
overlap the range, and when the memory bound to the image's miptail overlaps
an aliased range all subresources in the miptail overlap the range.
Buffers, and linear image subresources in either the
ename:VK_IMAGE_LAYOUT_PREINITIALIZED or ename:VK_IMAGE_LAYOUT_GENERAL
@ -1167,16 +1178,17 @@ are those written by the memory operations according to its addressing
scheme. If the first alias is not host-accessible, then the bytes affected
are those overlapped by the image subresources that were written. If the
second alias is a host-accessible subresource, the affected bytes become
undefined. If the second alias is a not host-accessible, all sparse blocks
(for sparse residency images) or all subresources (for non-sparse residency
images) that overlap the affected bytes become undefined.
undefined. If the second alias is a not host-accessible, all sparse image
blocks (for sparse partially-resident images) or all subresources (for
non-sparse image and fully resident sparse images) that overlap the affected
bytes become undefined.
If any subresources are made undefined due to writes to an alias, then each
of those subresources must: have its layout transitioned from
ename:VK_IMAGE_LAYOUT_UNDEFINED to a valid layout before it is used, or from
ename:VK_IMAGE_LAYOUT_PREINITIALIZED if the memory has been written by the
host. If any blocks of a sparse image have been made undefined, then only
the subresources containing them must: be transitioned.
host. If any sparse blocks of a sparse image have been made undefined, then
only the subresources containing them must: be transitioned.
Use of an overlapping range by two aliases must: be separated by a memory
dependency using the appropriate access types if at least one of those uses

280
doc/specs/vulkan/chapters/sparsemem.txt
View File

@ -33,7 +33,7 @@ feature enables specified in slink:VkPhysicalDeviceFeatures.
* <<features-features-sparseBinding,Sparse binding>> is the base
feature, and provides the following capabilities:
** Resources can: be bound at some defined (block) granularity.
** Resources can: be bound at some defined (sparse block) granularity.
** The entire resource must: be bound to memory before use regardless of
regions actually accessed.
** No specific mapping of image region to memory offset is defined, i.e.
@ -55,8 +55,9 @@ feature enables specified in slink:VkPhysicalDeviceFeatures.
** Resources do not have to be completely bound to memory before use on
the device.
** Images have a prescribed block layout, allowing specific image blocks
to be bound to specific offsets in memory allocations.
** Images have a prescribed sparse image block layout, allowing specific
rectangular regions of the image to be bound to specific offsets in
memory allocations.
** Consistency of access to unbound regions of the resource is defined by
the absence or presence of
sname:VkPhysicalDeviceSparseProperties::pname:residencyNonResidentStrict.
@ -108,7 +109,7 @@ pname:sparseResidency16Samples.
* <<features-features-sparseResidencyAliased,Sparse aliasing>>
provides the following capability that can: be enabled per resource:
+
Allows physical memory blocks to be shared between multiple locations in
Allows physical memory ranges to be shared between multiple locations in
the same sparse resource or between multiple sparse resources, with each
binding of a memory location observing a consistent interpretation of the
memory contents.
@ -136,8 +137,8 @@ use.
=== Sparse Buffer and Fully-Resident Image Block Size
The block size for sparse buffers and fully-resident images is reported as
sname:VkMemoryRequirements::pname:alignment. pname:alignment
The sparse block size in bytes for sparse buffers and fully-resident images is
reported as sname:VkMemoryRequirements::pname:alignment. pname:alignment
represents both the memory alignment requirement and the binding granularity
(in bytes) for sparse resources.
@ -157,11 +158,13 @@ the ability for some regions of the buffer to be unbound during device use.
== Sparse Partially-Resident Images
sname:VkImage objects created with the
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT bit allow blocks of the image to
be bound to specific ranges of memory. This allows the application to manage
residency at either the subresource or pixel block granularity. Each
subresource (outside of the <<sparsememory-miptail,mip tail>>) starts on a
block boundary and has a size that is an integer number of blocks of memory.
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT bit allow specific rectangular
regions of the image called sparse image blocks to be bound to specific
ranges of memory. This allows the application to manage residency at either
subresource or sparse image block granularity. Each subresource (outside of
the <<sparsememory-miptail,mip tail>>) starts on a sparse block boundary and
has dimensions that are integer multiples of the corresponding dimensions of
the sparse image block.
[NOTE]
.Note
@ -230,25 +233,26 @@ Sparse images created using ename:VK_IMAGE_CREATE_SPARSE_BINDING_BIT have no
specific mapping of image region or subresource to memory offset defined, so
the entire image can: be thought of as a linear opaque address region.
However, images created with ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT do
have a prescribed block layout, and hence each subresource must: start on a
block boundary. Within each array layer, the set of mip-levels that are too
small to fill a block are grouped together into a _mip tail region_.
have a prescribed sparse image block layout, and hence each subresource must:
start on a sparse block boundary. Within each array layer, the set of
mip-levels that have a smaller size than the sparse block size in bytes are
grouped together into a _mip tail region_.
If the ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT flag is present in
the pname:flags member of sname:VkSparseImageFormatProperties, for the
image's pname:format, then any mip-level which is not a multiple of the
block size, and all subsequent mip-levels, are also included in the mip tail
region.
image's pname:format, then any mip-level which has dimensions that are not
integer multiples of the corresponding dimensions of the sparse image block,
and all subsequent mip-levels, are also included in the mip tail region.
The following member of sname:VkPhysicalDeviceSparseProperties may: affect
how the implementation places mip levels in the mip tail region:
* pname:residencyAlignedMipSize
Each mip tail region is bound to memory as an opaque block (i.e. must: be
Each mip tail region is bound to memory as an opaque region (i.e. must: be
bound using a slink:VkSparseImageOpaqueMemoryBindInfo structure) and may: be
of a size greater than or equal to the normal block size. It is guaranteed
to be an integer multiple of the normal image block size (in bytes).
of a size greater than or equal to the sparse block size in bytes. This size
is guaranteed to be an integer multiple of the sparse block size in bytes.
An implementation may: choose to allow each array-layer's mip tail region to
be bound to memory independently or require that all array-layer's mip tail
@ -266,12 +270,13 @@ image::images/sparseimage.{svgpdf}[align="center", title="Sparse Image"]
In the absence of ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT and
ename:VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT, each array layer contains a
mip tail region containing pixel data for all mip levels smaller than the
sparse block size in any dimension.
sparse image block in any dimension.
Mip levels that are as large or larger than a block in all dimensions can:
be bound individually. Right-edges and bottom-edges of each level are
allowed to have partially used blocks. Any bound partially-used-blocks must:
still have their full block size allocated in memory.
Mip levels that are as large or larger than a sparse image block in all
dimensions can: be bound individually. Right-edges and bottom-edges of each
level are allowed to have partially used sparse blocks. Any bound
partially-used-sparse-blocks must: still have their full sparse block
size in bytes allocated in memory.
image::images/sparseimage_singlemiptail.{svgpdf}[align="center", title="Sparse Image with Single Mip Tail"]
@ -284,15 +289,16 @@ image::images/sparseimage_alignedmipsize.{svgpdf}[align="center", title="Sparse
.Note
====
The mip tail regions are presented here in 2D arrays simply for figure size
reasons. Each mip tail is logically a single array of blocks with an
implementation-dependent mapping of pixels to blocks.
reasons. Each mip tail is logically a single array of sparse blocks with an
implementation-dependent mapping of pixels to sparse blocks.
====
When ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT is present the first
mip level that would contain partially used blocks begins the mip tail
mip level that would contain partially used sparse blocks begins the mip tail
region. This level and all subsequent levels are placed in the mip tail.
Only the first latexmath:[$N$] mip levels that are an exact multiple of the
sparse block size can: be bound and unbound on a block basis.
Only the first latexmath:[$N$] mip levels whose dimensions are an exact
multiple of the sparse image block dimensions can: be bound and unbound on a
sparse block basis.
image::images/sparseimage_alignedmipsize_singlemiptail.{svgpdf}[align="center", title="Sparse Image with Aligned Mip Size and Single Mip Tail"]
@ -300,8 +306,8 @@ image::images/sparseimage_alignedmipsize_singlemiptail.{svgpdf}[align="center",
.Note
====
The mip tail region is presented here in a 2D array simply for figure size
reasons. It is logically a single array of blocks with an
implementation-dependent mapping of pixels to blocks.
reasons. It is logically a single array of sparse blocks with an
implementation-dependent mapping of pixels to sparse blocks.
====
When both ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT and
@ -309,16 +315,25 @@ ename:VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT are present the constraints
from each of these flags are in effect.
[[sparsememory-standard-sizes]]
=== Standard Image Block Sizes
[[sparsememory-standard-shapes]]
=== Standard Sparse Image Block Shapes
Standard sparse image block sizes are defined by {apiname} and depend on
the format of the image. Layout of pixels within a block is
implementation dependent. All currently defined standard block shapes are 64
KB in size.
Standard sparse image block shapes define a standard set of dimensions for
sparse image blocks that depend on the format of the image. Layout of pixels
within a sparse image block is implementation dependent. All currently defined
standard sparse image block shapes are 64 KB in size.
For compressed pixel formats (e.g. ename:VK_FORMAT_BC5_UNORM_BLOCK), the
pixel size is the size of the compression block (128-bit for etext:BC5).
For block-compressed formats (e.g. ename:VK_FORMAT_BC5_UNORM_BLOCK), the
pixel size is the size of the compressed texel block (128-bit for etext:BC5)
thus the dimensions of the standard sparse image block shapes apply in terms
of compressed texel blocks.
.Note
====
For block-compressed formats, the dimensions of a sparse image block in terms
of texels can: be calculated by multiplying the sparse image block dimensions
by the compressed texel block dimensions.
====
<<<
@ -347,8 +362,9 @@ pixel size is the size of the compression block (128-bit for etext:BC5).
|====
Implementations that support the standard block shape for all applicable
formats may: advertise the following sname:VkPhysicalDeviceSparseProperties:
Implementations that support the standard sparse image block shape for all
applicable formats may: advertise the following
sname:VkPhysicalDeviceSparseProperties:
* pname:residencyStandard2DBlockShape
* pname:residencyStandard2DMultisampleBlockShape
@ -356,26 +372,29 @@ formats may: advertise the following sname:VkPhysicalDeviceSparseProperties:
Reporting each of these features does _not_ imply that all possible image
types are supported as sparse. Instead, this indicates that no supported
sparse image of the corresponding type will use a custom block size.
sparse image of the corresponding type will use custom sparse image block
dimensions for any formats that have a corresponding standard sparse image
block shape.
[[sparsememory-blocksizes]]
=== Custom Image Block Sizes
[[sparsememory-custom-shapes]]
=== Custom Sparse Image Block Shapes
An implementation that does not support the standard image block sizes may:
choose to support a custom block size instead. This custom block size will
have the pixel region size reported in
sname:VkSparseImageFormatProperties::pname:imageGranularity. As with
standard block sizes, the byte-size of the custom block size will be
reported in sname:VkMemoryRequirements::pname:alignment.
An implementation that does not support a standard image block shape for a
particular sparse partially-resident image may: choose to support a custom
sparse image block shape for it instead. The dimensions of such a custom
sparse image block shape are reported in
sname:VkSparseImageFormatProperties::pname:imageGranularity. As with standard
sparse image block shapes, the size in bytes of the custom sparse image
block shape will be reported in sname:VkMemoryRequirements::pname:alignment.
Custom block sizes are reported through
Custom sparse image block dimensions are reported through
fname:vkGetPhysicalDeviceSparseImageFormatProperties and
fname:vkGetImageSparseMemoryRequirements.
An implementation mustnot: support both the standard block size and a custom
block size for the same image. The standard size must: be used if it is
supported.
An implementation mustnot: support both the standard sparse image block shape
and a custom sparse image block shape for the same image. The standard sparse
image block shape must: be used if it is supported.
[[sparsememory-multiaspect]]
@ -394,15 +413,15 @@ image::images/sparseimage_multiaspect.{svgpdf}[align="center",title="Multiple As
.Note
====
The mip tail regions are presented here in 2D arrays simply for figure size
reasons. Each mip tail is logically a single array of blocks with an
implementation-dependent mapping of pixels to blocks.
reasons. Each mip tail is logically a single array of sparse blocks with an
implementation-dependent mapping of pixels to sparse blocks.
====
In the figure above the depth, stencil, and metadata aspects all have unique
sparse properties. The per-pixel stencil data is
latexmath:[${}^{1}\!/\!{}_4$] the size of the depth data, hence the stencil
sparse blocks include latexmath:[$4x$] the number of pixels. The block
byte-size for all of the aspects is identical and defined by
sparse blocks include latexmath:[$4x$] the number of pixels. The sparse block
size in bytes for all of the aspects is identical and defined by
sname:VkMemoryRequirements::pname:alignment.
@ -445,14 +464,14 @@ must: abide by the following guidelines:
* All resources that access aliased physical memory must interpret the
memory in the same way. This implies the following:
** Buffers and images cannot: alias the same physical memory in a data
consistent fashion. The physical memory blocks must be used exclusively
consistent fashion. The physical memory ranges must be used exclusively
by buffers or used exclusively by images for data consistency to be
guaranteed.
** Memory in sparse image mip tail regions cannot: access
aliased memory in a data consistent fashion.
** Sparse images that alias the same physical memory must: have compatible
formats and be using the same block shape in order to access aliased
memory in a data consistent fashion.
formats and be using the same sparse image block shape in order to access
aliased memory in a data consistent fashion.
Failure to follow any of the above guidelines will require the application
to abide by the normal, non-sparse resource <<resources-memory-aliasing,
@ -653,40 +672,42 @@ include::../structs/VkPhysicalDeviceSparseProperties.txt[]
* pname:residencyStandard2DBlockShape is ename:VK_TRUE if the physical
device will access all single-sample 2D sparse resources using the
standard block shapes (based on image format), as described in the
<<sparsememory-sparseblockshapessingle,Standard Sparse Image Block
standard sparse image block shapes (based on image format), as described
in the <<sparsememory-sparseblockshapessingle,Standard Sparse Image Block
Shapes (Single Sample)>> table. If this property is not supported the
value returned in the pname:imageGranularity member of the
sname:VkSparseImageFormatProperties structure for single-sample 2D
images is not required: to match the standard image block sizes listed
in the table.
images is not required: to match the standard sparse image block
dimensions listed in the table.
* pname:residencyStandard2DMultisampleBlockShape is ename:VK_TRUE if the
physical device will access all multisample 2D sparse resources using
the standard block shapes (based on image format), as described in the
<<sparsememory-sparseblockshapesmsaa,Standard Sparse Image Block Shapes
(MSAA)>> table. If this property is not supported, the value returned in
the pname:imageGranularity member of the
the standard sparse image block shapes (based on image format), as
described in the <<sparsememory-sparseblockshapesmsaa,Standard Sparse
Image Block Shapes (MSAA)>> table. If this property is not supported, the
value returned in the pname:imageGranularity member of the
sname:VkSparseImageFormatProperties structure for multisample 2D images
is not required: to match the standard image block sizes listed in the
table.
is not required: to match the standard sparse image block dimensions
listed in the table.
* pname:residencyStandard3DBlockShape is ename:VK_TRUE if the physical
device will access all 3D sparse resources using the standard block
shapes (based on image format), as described in the
device will access all 3D sparse resources using the standard sparse image
block shapes (based on image format), as described in the
<<sparsememory-sparseblockshapessingle,Standard Sparse Image Block
Shapes (Single Sample)>> table. If this property is not supported, the
value returned in the pname:imageGranularity member of the
sname:VkSparseImageFormatProperties structure for 3D images is not
required: to match the standard image block sizes listed in the table.
required: to match the standard sparse image block dimensions listed in
the table.
* pname:residencyAlignedMipSize is ename:VK_TRUE if images with mip level
dimensions that are not a multiple of a block size may: be placed in the
mip tail. If this property is not reported, only mip levels with
dimensions smaller than the pname:imageGranularity member
of the sname:VkSparseImageFormatProperties structure will be placed in
the mip tail. If this property is reported the implementation is allowed
to return ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT in the
pname:flags member of sname:VkSparseImageFormatProperties, indicating
that mip level dimensions that are not a multiple of a block size will
be placed in the mip tail.
dimensions that are not integer multiples of the corresponding dimensions
of the sparse image block may: be placed in the mip tail. If this property
is not reported, only mip levels with dimensions smaller than the
pname:imageGranularity member of the sname:VkSparseImageFormatProperties
structure will be placed in the mip tail. If this property is reported the
implementation is allowed to return
ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT in the pname:flags
member of sname:VkSparseImageFormatProperties, indicating that mip level
dimensions that are not integer multiples of the corresponding dimensions
of the sparse image block will be placed in the mip tail.
* pname:residencyNonResidentStrict specifies whether the physical device
can: consistently access non-resident regions of a resource. If this
property is ename:VK_TRUE, access to non-resident regions of resources
@ -700,11 +721,11 @@ include::../validity/structs/VkPhysicalDeviceSparseProperties.txt[]
=== Sparse Image Format Properties
Given that certain aspects of sparse image support, including the
sparse image block size, may: be implementation-dependent,
sparse image block dimensions, may: be implementation-dependent,
flink:vkGetPhysicalDeviceSparseImageFormatProperties can: be used to
query for sparse image format properties prior to resource creation. This
command is used to check whether a given set of sparse image parameters is
supported and what the sparse block shape will be.
supported and what the sparse image block shape will be.
==== Sparse Image Format Properties API
@ -714,7 +735,7 @@ include::../structs/VkSparseImageFormatProperties.txt[]
* pname:aspectMask is a elink:VkImageAspectFlags specifying which
aspects of the image the properties apply to.
* pname:imageGranularity is the width, height, and depth of the
block in pixels / compressed blocks.
sparse image block in texels or compressed texel blocks.
* pname:flags is a bitmask specifying additional information about
the sparse resource. Bits which can: be set include:
+
@ -724,12 +745,12 @@ include::../enums/VkSparseImageFormatFlagBits.txt[]
** If ename:VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT is set, the image
uses a single mip tail region for all array layers.
** If ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT is set, the first
mip level that is not an exact multiple of the sparse image block size
begins the mip tail region.
mip level whose dimensions are not integer multiples of the corresponding
dimensions of the sparse image block begins the mip tail region.
** If ename:VK_SPARSE_IMAGE_FORMAT_NONSTANDARD_BLOCK_SIZE_BIT is set, the
image uses a non-standard sparse block size, and the
pname:imageGranularity values do not match the standard block size for
the given pixel format.
image uses non-standard sparse image block dimensions, and the
pname:imageGranularity values do not match the standard sparse image
block dimensions for the given pixel format.
--
include::../validity/structs/VkSparseImageFormatProperties.txt[]
@ -818,8 +839,8 @@ sname:VkBuffer objects and sname:VkImage objects.
Buffers (both fully and partially resident) and fully-resident images can:
be bound to memory using only the data from sname:VkMemoryRequirements. For
all sparse resources the sname:VkMemoryRequirements::pname:alignment member
denotes both the bindable block byte-size and required: alignment of
sname:VkDeviceMemory.
denotes both the bindable sparse block size in bytes and required: alignment
of sname:VkDeviceMemory.
[[sparsememory-memory-partially-resident]]
@ -827,8 +848,8 @@ sname:VkDeviceMemory.
Partially resident images have a different method for binding memory. As
with buffers and fully resident images, the
sname:VkMemoryRequirements::pname:alignment field denotes the bindable block
byte-size for the image.
sname:VkMemoryRequirements::pname:alignment field denotes the bindable sparse
block size in bytes for the image.
Requesting sparse memory requirements for sname:VkImage objects using
fname:vkGetImageSparseMemoryRequirements will return an array of one or more
@ -847,32 +868,34 @@ include::../structs/VkSparseImageMemoryRequirements.txt[]
* pname:formatProperties.aspectMask is the set of aspects of the image
that this sparse memory requirement applies to. This will usually have a
single aspect specified. However, depth/stencil images may: have depth
and stencil data interleaved into the same memory blocks, in which case
and stencil data interleaved in the same sparse block, in which case
both ename:VK_IMAGE_ASPECT_DEPTH_BIT and
ename:VK_IMAGE_ASPECT_STENCIL_BIT would be present.
* pname:formatProperties.imageGranularity describes the size of a single
bindable block in pixel units. For aspect
ename:VK_IMAGE_ASPECT_METADATA_BIT, this region size will be zero
* pname:formatProperties.imageGranularity describes the dimensions of a
single bindable sparse image block in pixel units. For aspect
ename:VK_IMAGE_ASPECT_METADATA_BIT, all dimensions will be zero
pixels. All metadata is located in the mip tail region.
* pname:formatProperties.flags contains members of
elink:VkSparseImageFormatFlags:
** If ename:VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT is set the image
uses a single mip tail region for all array layers.
** If ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT is set the image
mip levels must: be an exact multiple of the sparse image block size
for levels not located in the mip tail.
** If ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT is set the
dimensions of mip levels must: be integer multiples of the corresponding
dimensions of the sparse image block for levels not located in the mip
tail.
** If ename:VK_SPARSE_IMAGE_FORMAT_NONSTANDARD_BLOCK_SIZE_BIT is set the
image uses a non-standard sparse block size. The
image uses non-standard sparse image block dimensions. The
pname:formatProperties.imageGranularity values do not match the
standard block size for image's given pixel format.
standard sparse image block dimension corresponding to the image's
pixel format.
* pname:imageMipTailFirstLod is the first mip level at which subresources
are included in the mip tail block.
are included in the mip tail region.
* pname:imageMipTailSize is the memory size (in bytes) of the mip tail
block. If pname:formatProperties.flags contains
region. If pname:formatProperties.flags contains
ename:VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT, this is the size of the
whole mip tail, otherwise this is the size of the mip tail of a single
array layer. This value is guaranteed to be a multiple of the block
byte-size.
array layer. This value is guaranteed to be a multiple of the sparse block
size in bytes.
* pname:imageMipTailOffset is the opaque memory offset used with
slink:VkSparseImageOpaqueMemoryBindInfo to bind the mip tail region(s).
* pname:imageMipTailStride is the offset stride between each array-layer's
@ -960,10 +983,10 @@ ranges of the same resource while a bind operation is executing.
[NOTE]
.Note
====
Implementations must: provide a guarantee that simultaneously binding blocks
while another queue accesses those same blocks via a sparse resource
mustnot: access memory owned by another process or otherwise corrupt the
system.
Implementations must: provide a guarantee that simultaneously binding sparse
blocks while another queue accesses those same sparse blocks via a sparse
resource mustnot: access memory owned by another process or otherwise corrupt
the system.
====
While some implementations may: include ename:VK_QUEUE_SPARSE_BINDING_BIT
@ -1140,13 +1163,14 @@ include::../structs/VkSparseImageMemoryBind.txt[]
* pname:offset are the coordinates of the first texel within the
subresource to bind.
* pname:extent is the size in texels of the region within the subresource
to bind. The extent must: be a multiple of the block size, except when
binding blocks along the edge of a subresource it can: instead be such
that any coordinate of latexmath:[$\mathit{offset} + \mathit{extent}$]
equals the subresource size in that dimension.
* pname:memory is the sname:VkDeviceMemory object that the blocks of the
image are bound to. If pname:memory is sname:VK_NULL_HANDLE, the blocks
are unbound.
to bind. The extent must: be a multiple of the sparse image block
dimensions, except when binding sparse image blocks along the edge of a
subresource it can: instead be such that any coordinate of
latexmath:[$\mathit{offset} + \mathit{extent}$] equals the corresponding
dimensions of the subresource.
* pname:memory is the sname:VkDeviceMemory object that the sparse image
blocks of the image are bound to. If pname:memory is sname:VK_NULL_HANDLE,
the sparse image blocks are unbound.
* pname:memoryOffset is an offset into sname:VkDeviceMemory object. If
pname:memory is sname:VK_NULL_HANDLE, this value is ignored.
* pname:flags are sparse memory binding flags.
@ -1232,7 +1256,7 @@ binding them to physical memory.
This basic example creates a normal sname:VkImage object but uses
fine-grained memory allocation to back the resource with multiple memory
blocks.
ranges.
[source,{basebackend@docbook:c++:cpp}]
---------------------------------------------------
@ -1262,7 +1286,7 @@ vkGetImageMemoryRequirements(
sparseImage,
&memoryRequirements);
// Bind memory in fine-grained fashion, find available memory blocks
// Bind memory in fine-grained fashion, find available memory ranges
// from potentially multiple VkDeviceMemory pools.
// (Illustration purposes only, can be optimized for perf)
while (memoryRequirements.size && bindCount < MAX_CHUNKS)
@ -1270,14 +1294,14 @@ while (memoryRequirements.size && bindCount < MAX_CHUNKS)
VkSparseMemoryBind* pBind = &binds[bindCount];
pBind->resourceOffset = offset;
AllocateOrGetMemoryBlock(
AllocateOrGetMemoryRange(
device,
&memoryRequirements,
&pBind->memory,
&pBind->memoryOffset,
&pBind->size);
// memory blocks must be sized as multiples of the alignment
// memory ranges must be sized as multiples of the alignment
assert(IsMultiple(pBind->size, memoryRequirements.alignment));
assert(IsMultiple(pBind->memoryOffset, memoryRequirements.alignment));
@ -1393,7 +1417,7 @@ for (uint32_t i = 0; i < sparseRequirementsCount; ++i)
pBind->memorySize = pSparseReqs[i].imageMipTailSize;
bindCount++;
// ... Allocate memory block
// ... Allocate memory range
pBind->resourceOffset = pSparseReqs[i].imageMipTailOffset;
pBind->memoryOffset = /* allocated memoryOffset */;
@ -1403,14 +1427,14 @@ for (uint32_t i = 0; i < sparseRequirementsCount; ++i)
}
else
{
// Need a mip tail block per array layer.
// Need a mip tail region per array layer.
for (uint32_t a = 0; a < sparseImageInfo.arrayLayers; ++a)
{
VkSparseMemoryBind* pBind = &binds[bindCount];
pBind->memorySize = pSparseReqs[i].imageMipTailSize;
bindCount++;
// ... Allocate memory block
// ... Allocate memory range
pBind->resourceOffset = pSparseReqs[i].imageMipTailOffset +
(a * pSparseReqs[i].imageMipTailStride);
@ -1446,7 +1470,7 @@ for (uint32_t i = 0; i < sparseRequirementsCount; ++i)
// Allocate memory for each array layer
for (uint32_t a = 0; a < sparseImageInfo.arrayLayers; ++a)
{
// ... Allocate memory block
// ... Allocate memory range
VkSparseImageMemoryBind* pBind = &imageBinds[a];
pBind->subresource.aspectMask = pSparseReqs[i].formatProperties.aspectMask;

2
doc/specs/vulkan/chapters/synchronization.txt
View File

@ -12,7 +12,7 @@ queue submissions, and between commands within a command buffer.
synchronization primitives for these purposes. Further, memory caches and
other optimizations mean that the normal flow of command execution does not
guarantee that all memory transactions from a command are immediately
visible to other agents with views into a given block of memory. {apiname}
visible to other agents with views into a given range of memory. {apiname}
also provides barrier operations to ensure this type of synchronization.
Four synchronization primitive types are exposed by {apiname}. These are:

12
doc/specs/vulkan/chapters/textures.txt
View File

@ -601,8 +601,8 @@ endif::editing-notes[]
If the sname:VkPhysicalDeviceSparseProperties property
pname:residencyNonResidentStrict is true, a sparse unbound texel is replaced
with zero values in the same fashion as described for reads from buffer
resources above.
with 0 or 0.0 values for integer and floating-point components of the image
format, respectively.
If pname:residencyNonResidentStrict is false, the read must: be safe, but
the value of the sparse unbound texel is undefined.
@ -1518,10 +1518,10 @@ pname:addressModeW parameters of the sampler, respectively.
=== Texel Gathering
SPIR-V instructions with code:Gather in the name return a vector derived
from a 2x2 block of texels in the base level of the image view. The rules
for the etext:LINEAR minification filter are applied to identify the four
selected texels. Each texel is then converted to an RGBA value according to
<<textures-conversion-to-rgba,conversion to RGBA>> and then
from a 2x2 rectangular region of texels in the base level of the image view.
The rules for the etext:LINEAR minification filter are applied to identify the
four selected texels. Each texel is then converted to an RGBA value according
to <<textures-conversion-to-rgba,conversion to RGBA>> and then
<<textures-component-swizzle,swizzled>>. A four-component vector is then
assembled by taking the component indicated by the code:Component value in
the instruction from the swizzled color value of the four texels:

20
doc/specs/vulkan/funcpointers/PFN_vkDebugReportCallbackEXT.txt Normal file
View File

@ -0,0 +1,20 @@
// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry
ifndef::doctype-manpage[]
[[PFN_vkDebugReportCallbackEXT,PFN_vkDebugReportCallbackEXT]]
["source","{basebackend@docbook:c++:cpp}",title=""]
endif::doctype-manpage[]
ifdef::doctype-manpage[]
["source","{basebackend@docbook:c++:cpp}"]
endif::doctype-manpage[]
------------------------------------------------------------------------------
typedef VkBool32 (VKAPI_PTR *PFN_vkDebugReportCallbackEXT)(
VkDebugReportFlagsEXT flags,
VkDebugReportObjectTypeEXT objectType,
uint64_t object,
size_t location,
int32_t messageCode,
const char* pLayerPrefix,
const char* pMessage,
void* pUserData);
------------------------------------------------------------------------------

26
doc/specs/vulkan/man/VkAccessFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkAccessFlagBits(3)
===================
Name
----
VkAccessFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkAccessFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkAccessFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkAccessFlags(3)
================
Name
----
VkAccessFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkAccessFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkAndroidSurfaceCreateFlagsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkAndroidSurfaceCreateFlagsKHR(3)
=================================
Name
----
VkAndroidSurfaceCreateFlagsKHR - Stub page (not yet written)
C Specification
---------------
include::../flags/VkAndroidSurfaceCreateFlagsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkAndroidSurfaceCreateInfoKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkAndroidSurfaceCreateInfoKHR(3)
================================
Name
----
VkAndroidSurfaceCreateInfoKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkAndroidSurfaceCreateInfoKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkAndroidSurfaceCreateInfoKHR.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkApplicationInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkApplicationInfo(3)
====================
Name
----
VkApplicationInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkApplicationInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkApplicationInfo.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkAttachmentDescription.txt Normal file
View File

@ -0,0 +1,27 @@
VkAttachmentDescription(3)
==========================
Name
----
VkAttachmentDescription - Stub page (not yet written)
C Specification
---------------
include::../structs/VkAttachmentDescription.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkAttachmentDescription.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkAttachmentDescriptionFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkAttachmentDescriptionFlagBits(3)
==================================
Name
----
VkAttachmentDescriptionFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkAttachmentDescriptionFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkAttachmentDescriptionFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkAttachmentDescriptionFlags(3)
===============================
Name
----
VkAttachmentDescriptionFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkAttachmentDescriptionFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkAttachmentLoadOp.txt Normal file
View File

@ -0,0 +1,26 @@
VkAttachmentLoadOp(3)
=====================
Name
----
VkAttachmentLoadOp - Stub page (not yet written)
C Specification
---------------
include::../enums/VkAttachmentLoadOp.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkAttachmentReference.txt Normal file
View File

@ -0,0 +1,27 @@
VkAttachmentReference(3)
========================
Name
----
VkAttachmentReference - Stub page (not yet written)
C Specification
---------------
include::../structs/VkAttachmentReference.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkAttachmentReference.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkAttachmentStoreOp.txt Normal file
View File

@ -0,0 +1,26 @@
VkAttachmentStoreOp(3)
======================
Name
----
VkAttachmentStoreOp - Stub page (not yet written)
C Specification
---------------
include::../enums/VkAttachmentStoreOp.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkBindSparseInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkBindSparseInfo(3)
===================
Name
----
VkBindSparseInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkBindSparseInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkBindSparseInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkBlendFactor.txt Normal file
View File

@ -0,0 +1,26 @@
VkBlendFactor(3)
================
Name
----
VkBlendFactor - Stub page (not yet written)
C Specification
---------------
include::../enums/VkBlendFactor.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkBlendOp.txt Normal file
View File

@ -0,0 +1,26 @@
VkBlendOp(3)
============
Name
----
VkBlendOp - Stub page (not yet written)
C Specification
---------------
include::../enums/VkBlendOp.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkBorderColor.txt Normal file
View File

@ -0,0 +1,26 @@
VkBorderColor(3)
================
Name
----
VkBorderColor - Stub page (not yet written)
C Specification
---------------
include::../enums/VkBorderColor.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkBufferCopy.txt Normal file
View File

@ -0,0 +1,27 @@
VkBufferCopy(3)
===============
Name
----
VkBufferCopy - Stub page (not yet written)
C Specification
---------------
include::../structs/VkBufferCopy.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkBufferCopy.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkBufferCreateFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkBufferCreateFlagBits(3)
=========================
Name
----
VkBufferCreateFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkBufferCreateFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkBufferImageCopy.txt Normal file
View File

@ -0,0 +1,27 @@
VkBufferImageCopy(3)
====================
Name
----
VkBufferImageCopy - Stub page (not yet written)
C Specification
---------------
include::../structs/VkBufferImageCopy.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkBufferImageCopy.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkBufferUsageFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkBufferUsageFlagBits(3)
========================
Name
----
VkBufferUsageFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkBufferUsageFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkBufferViewCreateFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkBufferViewCreateFlags(3)
==========================
Name
----
VkBufferViewCreateFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkBufferViewCreateFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkBufferViewCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkBufferViewCreateInfo(3)
=========================
Name
----
VkBufferViewCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkBufferViewCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkBufferViewCreateInfo.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkClearAttachment.txt Normal file
View File

@ -0,0 +1,27 @@
VkClearAttachment(3)
====================
Name
----
VkClearAttachment - Stub page (not yet written)
C Specification
---------------
include::../structs/VkClearAttachment.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkClearAttachment.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkClearColorValue.txt Normal file
View File

@ -0,0 +1,27 @@
VkClearColorValue(3)
====================
Name
----
VkClearColorValue - Stub page (not yet written)
C Specification
---------------
include::../structs/VkClearColorValue.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkClearColorValue.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkClearDepthStencilValue.txt Normal file
View File

@ -0,0 +1,27 @@
VkClearDepthStencilValue(3)
===========================
Name
----
VkClearDepthStencilValue - Stub page (not yet written)
C Specification
---------------
include::../structs/VkClearDepthStencilValue.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkClearDepthStencilValue.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkClearRect.txt Normal file
View File

@ -0,0 +1,27 @@
VkClearRect(3)
==============
Name
----
VkClearRect - Stub page (not yet written)
C Specification
---------------
include::../structs/VkClearRect.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkClearRect.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkClearValue.txt Normal file
View File

@ -0,0 +1,27 @@
VkClearValue(3)
===============
Name
----
VkClearValue - Stub page (not yet written)
C Specification
---------------
include::../structs/VkClearValue.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkClearValue.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkColorComponentFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkColorComponentFlagBits(3)
===========================
Name
----
VkColorComponentFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkColorComponentFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkColorComponentFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkColorComponentFlags(3)
========================
Name
----
VkColorComponentFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkColorComponentFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkColorSpaceKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkColorSpaceKHR(3)
==================
Name
----
VkColorSpaceKHR - Stub page (not yet written)
C Specification
---------------
include::../enums/VkColorSpaceKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkCommandBufferBeginInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkCommandBufferBeginInfo(3)
===========================
Name
----
VkCommandBufferBeginInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkCommandBufferBeginInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkCommandBufferBeginInfo.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkCommandBufferInheritanceInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkCommandBufferInheritanceInfo(3)
=================================
Name
----
VkCommandBufferInheritanceInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkCommandBufferInheritanceInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkCommandBufferInheritanceInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandBufferLevel.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandBufferLevel(3)
=======================
Name
----
VkCommandBufferLevel - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCommandBufferLevel.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandBufferResetFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandBufferResetFlagBits(3)
===============================
Name
----
VkCommandBufferResetFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCommandBufferResetFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandBufferResetFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandBufferResetFlags(3)
============================
Name
----
VkCommandBufferResetFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkCommandBufferResetFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandBufferUsageFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandBufferUsageFlagBits(3)
===============================
Name
----
VkCommandBufferUsageFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCommandBufferUsageFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandBufferUsageFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandBufferUsageFlags(3)
============================
Name
----
VkCommandBufferUsageFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkCommandBufferUsageFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandPoolCreateFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandPoolCreateFlagBits(3)
==============================
Name
----
VkCommandPoolCreateFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCommandPoolCreateFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandPoolCreateFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandPoolCreateFlags(3)
===========================
Name
----
VkCommandPoolCreateFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkCommandPoolCreateFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkCommandPoolCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkCommandPoolCreateInfo(3)
==========================
Name
----
VkCommandPoolCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkCommandPoolCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkCommandPoolCreateInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandPoolResetFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandPoolResetFlagBits(3)
=============================
Name
----
VkCommandPoolResetFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCommandPoolResetFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCommandPoolResetFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkCommandPoolResetFlags(3)
==========================
Name
----
VkCommandPoolResetFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkCommandPoolResetFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCompareOp.txt Normal file
View File

@ -0,0 +1,26 @@
VkCompareOp(3)
==============
Name
----
VkCompareOp - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCompareOp.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkComponentMapping.txt Normal file
View File

@ -0,0 +1,27 @@
VkComponentMapping(3)
=====================
Name
----
VkComponentMapping - Stub page (not yet written)
C Specification
---------------
include::../structs/VkComponentMapping.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkComponentMapping.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkComponentSwizzle.txt Normal file
View File

@ -0,0 +1,26 @@
VkComponentSwizzle(3)
=====================
Name
----
VkComponentSwizzle - Stub page (not yet written)
C Specification
---------------
include::../enums/VkComponentSwizzle.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCompositeAlphaFlagBitsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkCompositeAlphaFlagBitsKHR(3)
==============================
Name
----
VkCompositeAlphaFlagBitsKHR - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCompositeAlphaFlagBitsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCompositeAlphaFlagsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkCompositeAlphaFlagsKHR(3)
===========================
Name
----
VkCompositeAlphaFlagsKHR - Stub page (not yet written)
C Specification
---------------
include::../flags/VkCompositeAlphaFlagsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkComputePipelineCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkComputePipelineCreateInfo(3)
==============================
Name
----
VkComputePipelineCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkComputePipelineCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkComputePipelineCreateInfo.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkCopyDescriptorSet.txt Normal file
View File

@ -0,0 +1,27 @@
VkCopyDescriptorSet(3)
======================
Name
----
VkCopyDescriptorSet - Stub page (not yet written)
C Specification
---------------
include::../structs/VkCopyDescriptorSet.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkCopyDescriptorSet.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCullModeFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkCullModeFlagBits(3)
=====================
Name
----
VkCullModeFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkCullModeFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkCullModeFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkCullModeFlags(3)
==================
Name
----
VkCullModeFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkCullModeFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDebugReportCallbackCreateInfoEXT.txt Normal file
View File

@ -0,0 +1,27 @@
VkDebugReportCallbackCreateInfoEXT(3)
=====================================
Name
----
VkDebugReportCallbackCreateInfoEXT - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDebugReportCallbackCreateInfoEXT.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDebugReportCallbackCreateInfoEXT.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDebugReportErrorEXT.txt Normal file
View File

@ -0,0 +1,26 @@
VkDebugReportErrorEXT(3)
========================
Name
----
VkDebugReportErrorEXT - Stub page (not yet written)
C Specification
---------------
include::../enums/VkDebugReportErrorEXT.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDebugReportFlagBitsEXT.txt Normal file
View File

@ -0,0 +1,26 @@
VkDebugReportFlagBitsEXT(3)
===========================
Name
----
VkDebugReportFlagBitsEXT - Stub page (not yet written)
C Specification
---------------
include::../enums/VkDebugReportFlagBitsEXT.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDebugReportFlagsEXT.txt Normal file
View File

@ -0,0 +1,26 @@
VkDebugReportFlagsEXT(3)
========================
Name
----
VkDebugReportFlagsEXT - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDebugReportFlagsEXT.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDebugReportObjectTypeEXT.txt Normal file
View File

@ -0,0 +1,26 @@
VkDebugReportObjectTypeEXT(3)
=============================
Name
----
VkDebugReportObjectTypeEXT - Stub page (not yet written)
C Specification
---------------
include::../enums/VkDebugReportObjectTypeEXT.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDependencyFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkDependencyFlagBits(3)
=======================
Name
----
VkDependencyFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkDependencyFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDependencyFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkDependencyFlags(3)
====================
Name
----
VkDependencyFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDependencyFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDescriptorBufferInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkDescriptorBufferInfo(3)
=========================
Name
----
VkDescriptorBufferInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDescriptorBufferInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDescriptorBufferInfo.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDescriptorImageInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkDescriptorImageInfo(3)
========================
Name
----
VkDescriptorImageInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDescriptorImageInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDescriptorImageInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDescriptorPoolCreateFlagBits.txt Normal file
View File

@ -0,0 +1,26 @@
VkDescriptorPoolCreateFlagBits(3)
=================================
Name
----
VkDescriptorPoolCreateFlagBits - Stub page (not yet written)
C Specification
---------------
include::../enums/VkDescriptorPoolCreateFlagBits.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDescriptorPoolCreateFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkDescriptorPoolCreateFlags(3)
==============================
Name
----
VkDescriptorPoolCreateFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDescriptorPoolCreateFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDescriptorPoolCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkDescriptorPoolCreateInfo(3)
=============================
Name
----
VkDescriptorPoolCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDescriptorPoolCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDescriptorPoolCreateInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDescriptorPoolResetFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkDescriptorPoolResetFlags(3)
=============================
Name
----
VkDescriptorPoolResetFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDescriptorPoolResetFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDescriptorPoolSize.txt Normal file
View File

@ -0,0 +1,27 @@
VkDescriptorPoolSize(3)
=======================
Name
----
VkDescriptorPoolSize - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDescriptorPoolSize.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDescriptorPoolSize.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDescriptorSetLayoutBinding.txt Normal file
View File

@ -0,0 +1,27 @@
VkDescriptorSetLayoutBinding(3)
===============================
Name
----
VkDescriptorSetLayoutBinding - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDescriptorSetLayoutBinding.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDescriptorSetLayoutBinding.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDescriptorSetLayoutCreateFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkDescriptorSetLayoutCreateFlags(3)
===================================
Name
----
VkDescriptorSetLayoutCreateFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDescriptorSetLayoutCreateFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDescriptorSetLayoutCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkDescriptorSetLayoutCreateInfo(3)
==================================
Name
----
VkDescriptorSetLayoutCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDescriptorSetLayoutCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDescriptorSetLayoutCreateInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDeviceCreateFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkDeviceCreateFlags(3)
======================
Name
----
VkDeviceCreateFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDeviceCreateFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDeviceCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkDeviceCreateInfo(3)
=====================
Name
----
VkDeviceCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDeviceCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDeviceCreateInfo.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDeviceQueueCreateFlags.txt Normal file
View File

@ -0,0 +1,26 @@
VkDeviceQueueCreateFlags(3)
===========================
Name
----
VkDeviceQueueCreateFlags - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDeviceQueueCreateFlags.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDeviceQueueCreateInfo.txt Normal file
View File

@ -0,0 +1,27 @@
VkDeviceQueueCreateInfo(3)
==========================
Name
----
VkDeviceQueueCreateInfo - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDeviceQueueCreateInfo.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDeviceQueueCreateInfo.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDispatchIndirectCommand.txt Normal file
View File

@ -0,0 +1,27 @@
VkDispatchIndirectCommand(3)
============================
Name
----
VkDispatchIndirectCommand - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDispatchIndirectCommand.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDispatchIndirectCommand.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDisplayModeCreateFlagsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkDisplayModeCreateFlagsKHR(3)
==============================
Name
----
VkDisplayModeCreateFlagsKHR - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDisplayModeCreateFlagsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayModeCreateInfoKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayModeCreateInfoKHR(3)
=============================
Name
----
VkDisplayModeCreateInfoKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayModeCreateInfoKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayModeCreateInfoKHR.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayModeParametersKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayModeParametersKHR(3)
=============================
Name
----
VkDisplayModeParametersKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayModeParametersKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayModeParametersKHR.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayModePropertiesKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayModePropertiesKHR(3)
=============================
Name
----
VkDisplayModePropertiesKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayModePropertiesKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayModePropertiesKHR.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDisplayPlaneAlphaFlagBitsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkDisplayPlaneAlphaFlagBitsKHR(3)
=================================
Name
----
VkDisplayPlaneAlphaFlagBitsKHR - Stub page (not yet written)
C Specification
---------------
include::../enums/VkDisplayPlaneAlphaFlagBitsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDisplayPlaneAlphaFlagsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkDisplayPlaneAlphaFlagsKHR(3)
==============================
Name
----
VkDisplayPlaneAlphaFlagsKHR - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDisplayPlaneAlphaFlagsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayPlaneCapabilitiesKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayPlaneCapabilitiesKHR(3)
================================
Name
----
VkDisplayPlaneCapabilitiesKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayPlaneCapabilitiesKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayPlaneCapabilitiesKHR.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayPlanePropertiesKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayPlanePropertiesKHR(3)
==============================
Name
----
VkDisplayPlanePropertiesKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayPlanePropertiesKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayPlanePropertiesKHR.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayPresentInfoKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayPresentInfoKHR(3)
==========================
Name
----
VkDisplayPresentInfoKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayPresentInfoKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayPresentInfoKHR.txt[]
See Also
--------
include::footer.txt[]

27
doc/specs/vulkan/man/VkDisplayPropertiesKHR.txt Normal file
View File

@ -0,0 +1,27 @@
VkDisplayPropertiesKHR(3)
=========================
Name
----
VkDisplayPropertiesKHR - Stub page (not yet written)
C Specification
---------------
include::../structs/VkDisplayPropertiesKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Fields
------
Description
-----------
include::../validity/structs/VkDisplayPropertiesKHR.txt[]
See Also
--------
include::footer.txt[]

26
doc/specs/vulkan/man/VkDisplaySurfaceCreateFlagsKHR.txt Normal file
View File

@ -0,0 +1,26 @@
VkDisplaySurfaceCreateFlagsKHR(3)
=================================
Name
----
VkDisplaySurfaceCreateFlagsKHR - Stub page (not yet written)
C Specification
---------------
include::../flags/VkDisplaySurfaceCreateFlagsKHR.txt[]
This is a stub page. Content has not been filled in yet. Khronos is
aware of the problem and working on it as time allows; please do not
file Github issues bringing the missing content to our attention.
Constants
---------
Description
-----------
See Also
--------
include::footer.txt[]

Some files were not shown because too many files have changed in this diff Show More