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

Merge branch '1.0' into 1.0-wsi_extensions

This commit is contained in:
Jon Leech 2016-03-03 01:57:29 -08:00
parent 39c5187999 741ae579ab
commit afbb7c0320
27 changed files with 152 additions and 139 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -2,6 +2,8 @@
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
[appendix]
[[extensions]]
= Layers & Extensions
Extensions to the {apiname} API can: be defined by authors, groups of
@ -118,25 +120,28 @@ only for layers.
an author prefix can: instead use a fully-qualified domain name (FQDN)
in reverse-order as an author prefix, using all lower-case characters,
and replacing +.+ (period) with `_` (underscore) characters. For
example, a layer written by the owner of www.3dxcl.com would use the
prefix `VK_LAYER_com_3dxcl_www_`. FQDNs must: be encoded in UTF-8.
example, a layer written by the owner of www.3dxcl.invalid would use
the prefix `VK_LAYER_invalid_3dxcl_www_`. FQDNs must: be encoded in
UTF-8.
[NOTE]
.Note
====
To avoid linking to a nonexistent domain, the reserved TLD +.invalid+ is
used.
====
== Extension Command, Token, and Type Naming Conventions
[[extensions-naming]]
== Extension Command, Type, and Token Naming Conventions
Extensions may: add new commands, tokens, and types, or collectively
``objects'' to the {apiname} API. These objects also require globally unique
names. These names shall conform to the following template:
Extensions may: add new commands, types, and tokens, or collectively
``objects'', to the {apiname} API. These objects are given globally unique
names by appending the author prefix defined above for the extension name
according to the following templates.
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
vk<CommandName><ExtensionAuthorPrefix>
------------------------------------------------------------------------------
Where +ExtensionAuthorPrefix+ is equal to that of the prefixes defined above
for extension names with the exception that a leading `_` (underscore) is
added for non-Khronos extensions. For example, a Khronos-blessed extension
could expose the following command:
A command or type name simply appends the author prefix. For example, a
Khronos-blessed extension could expose the following command:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
@ -150,14 +155,16 @@ A Google extension could expose the following command:
void vkDoSomethingGOOGLE(void);
------------------------------------------------------------------------------
A multi-author extension could expose the following type:
And a multi-author extension could expose the following type:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
typedef struct VkSomeDataEXT;
------------------------------------------------------------------------------
And a non-Khronos extension could expose this enumerant:
Enumeration or constant token names are constructed by following the token
name with `_` and the author prefix, so a non-Khronos extension could expose
this enumeration:
["source","{basebackend@docbook:c++:cpp}",title=""]
------------------------------------------------------------------------------
@ -359,7 +366,7 @@ extensions. This includes the following:
Extensions can: define their own enumeration types and assign any values to
their enumerants that they like. Each enumeration has a private namespace,
so collisions are not a problem. However, when extending existing
enumeration object with new values, care must: be taken to preserve global
enumeration objects with new values, care must: be taken to preserve global
uniqueness of values. Enumerations which define new bitfields are treated
specially as described in <<extensions-reserving-bitfield-values,Reserving
Bitfield Values>> below.
@ -450,9 +457,9 @@ the following definitions were in effect:
== Extension Objects, Enums, and Typedefs
Expanding on previous discussion, extensions can: add values to existing
enums; and can: add their own objects, enums, typedefs, etc. This is done by
adding to <<extensions-api-registry,+vk.xml+>>. All such additions will be
included in the +vulkan.h+ header supplied by Khronos.
enums; and can: add their own commands, enums, typedefs, etc. This is done
by adding to <<extensions-api-registry,+vk.xml+>>. All such additions will
be included in the +vulkan.h+ header supplied by Khronos.
[NOTE]
.Note
@ -468,22 +475,23 @@ values to existing enums. The use of a +default:+ statement, within a
== Extension Function Prototypes
Function pointer declarations and function prototypes for all core {apiname}
API functions are included in the +vulkan.h+ file. These come from the
API commands are included in the +vulkan.h+ file. These come from the
official XML specification of the {apiname} API hosted by Khronos.
Function pointer declarations are also included in the +vulkan.h+ file for
all extension functions. Function prototypes for extensions may: be included
in +vulkan.h+. Extension functions that are part of the {apiname} ABI must:
be flagged in the XML. Prototypes will be included in +vulkan.h+ for all
extension functions that are part of the {apiname} ABI.
all commands defined by registered extensions. Function prototypes for
extensions may: be included in +vulkan.h+. Extension commands that are part
of the {apiname} ABI must: be flagged in the XML. Function prototypes will
be included in +vulkan.h+ for all extension commands that are part of the
{apiname} ABI.
An extension can: be considered platform specific, in which case, its
objects, functions, etc. are protected by #ifdefs. This is orthogonal to
whether a function is considered to be part of the {apiname} ABI.
An extension can: be considered platform specific, in which case its
interfaces in +vulkan.h+ are protected by #ifdefs. This is orthogonal to
whether an extension command is considered to be part of the {apiname} ABI.
The initial set of WSI extension functions are considered to be part of the
{apiname} ABI. Prototypes for these WSI functions are included in the
+vulkan.h+ provided by Khronos, though the platform-specific portions of
The initial set of WSI extension commands are considered to be part of the
{apiname} ABI. Function prototypes for these WSI commands are included in
the +vulkan.h+ provided by Khronos, though the platform-specific portions of
+vulkan.h+ are protected by #ifdefs.
[NOTE]
@ -498,27 +506,27 @@ these implementations.
====
== Accessing Extension Function from Programs
== Accessing Extension Functions from Programs
The {apiname} API flink:vkGetInstanceProcAddr and flink:vkGetDeviceProcAddr
functions (i.e. GPA functions) can: be used in order to obtain addresses for
core and extension functions (per the description in
<<initialization-functionpointers,Command Function Pointers>>). Various
{apiname} API loaders can: be created on different platforms, which can:
statically export some or all of the core {apiname} API functions, and which
can: statically export some or all extension functions. If a loader
statically exports a function, an application can: link against that
function without needing to call a GPA function.
flink:vkGetInstanceProcAddr and flink:vkGetDeviceProcAddr can: be used in
order to obtain function pointer addresses for core and extension commands
(per the description in <<initialization-functionpointers,Command Function
Pointers>>). Different {apiname} API loaders can: choose to statically
export functions for some or all of the core {apiname} API commands, and
can: statically export functions for some or all extension commands. If a
loader statically exports a function, an application can: link against that
function without needing to call one of the ftext:vkGet*ProcAddr commands.
[NOTE]
.Note
====
As mentioned above, the {apiname} API loader on Android, Linux, and Windows
will export all core {apiname} API and WSI extension functions. The WSI
functions are considered special, because they are required for many
The Khronos-provided {apiname} API loader for Android, Linux, and Windows
exports functions for all core {apiname} API and WSI extension commands. The
WSI functions are considered special, because they are required for many
applications.
====
[[extensions-reserving-bitfield-values]]
=== Reserving Bitfield Values
@ -544,7 +552,7 @@ defined and locked down, it's safest to refer to the listed contact.
== Extension Interactions
Extensions modifying the behavior of existing commands should: provide
additional parameters by using the param:pNext field of an existing
additional parameters by using the pname:pNext field of an existing
structure, pointing to a new structure defined by the extension, as
described in the <<fundamentals-validusage,Valid Usage>> section. Extension
structures defined by multiple extensions affecting the same structure can

2
doc/specs/vulkan/appendices/spirvenv.txt
View File

@ -153,7 +153,7 @@ The precision of double-precision instructions is at least that of single
precision. For single precision (32 bit) instructions, precisions are
required: to be at least as follows, unless decorated with RelaxedPrecision:
.Precision of core SPIRV Instructions
.Precision of core SPIR-V Instructions
[options="header"]
|====
|Instruction | Precision

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

@ -241,7 +241,7 @@ include::../protos/vkCmdCopyImageToBuffer.txt[]
structures specifying the regions to copy.
Each region in pname:pRegions is copied from the specified region of the
source buffer to the specified region of the destination image.
source image to the specified region of the destination buffer.
include::../validity/protos/vkCmdCopyImageToBuffer.txt[]
@ -456,7 +456,7 @@ following conversion rules apply:
converted to sRGB color space before writing the pixel to the image.
Signed and unsigned integers are converted by first clamping to the
representable range of destination format, then casting the value.
representable range of the destination format, then casting the value.
[[copies-resolve]]
@ -470,11 +470,11 @@ include::../protos/vkCmdResolveImage.txt[]
recorded.
* pname:srcImage is the source image.
* pname:srcImageLayout is the layout of the source image subresources for
the blit.
the resolve.
* pname:dstImage is the destination image.
* pname:dstImageLayout is the layout of the destination image subresources
for the blit.
* pname:regionCount is the number of regions to blit.
for the resolve.
* pname:regionCount is the number of regions to resolve.
* pname:pRegions is a pointer to an array of slink:VkImageResolve
structures specifying the regions to resolve.
@ -516,4 +516,4 @@ pname:height and pname:depth.
Resolves are done layer by layer starting with pname:baseArrayLayer member
of pname:srcSubresource for the source and pname:dstSubresource for the
destination. pname:layerCount layers are blitted to the destination image.
destination. pname:layerCount layers are resolved to the destination image.

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

@ -324,8 +324,7 @@ The members of sname:VkDeviceCreateInfo have the following meanings:
* pname:ppEnabledLayerNames is a pointer to an array of
pname:enabledLayerCount null-terminated UTF-8 strings containing the
names of layers to enable for the created device. See the
<<querying-layers-and-extensions,Querying Layers and Extensions>>
chapter for further details.
<<extended-functionality-layers,Layers>> section for further details.
* pname:enabledExtensionCount is the number of device extensions to
enable.
* pname:ppEnabledExtensionNames is a pointer to an array of

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

@ -4,7 +4,7 @@
[[drawing]]
= Drawing Commands
_Drawing commands_ (command with ftext:Draw in the name) provoke work in a
_Drawing commands_ (commands with ftext:Draw in the name) provoke work in a
graphics pipeline. Drawing commands are recorded into a command buffer and
when executed by a queue, will produce work which executes according to the
currently bound graphics pipeline. A graphics pipeline must: be bound to a

11
doc/specs/vulkan/chapters/extensions.txt
View File

@ -80,16 +80,17 @@ The definition of sname:VkLayerProperties is:
include::../structs/VkLayerProperties.txt[]
* pname:layerName is a null-terminated string specifying the name of the
layer. Use this name in the pname:ppEnabledLayerNames array in the
sname:VkInstanceCreateInfo given to fname:vkCreateInstance to enable
this layer in the instance.
* pname:layerName is a null-terminated UTF-8 string specifying the name of
the layer. Use this name in the pname:ppEnabledLayerNames array passed
in the slink:VkInstanceCreateInfo and slink:VkDeviceCreateInfo
structures passed to flink:vkCreateInstance and flink:vkCreateDevice,
respectively, to enable this layer for an instance or device.
* pname:apiVersion is the {apiname} version the layer was written to,
encoded as described in the <<fundamentals-versionnum,API Version
Numbers and Semantics>> section.
* pname:implementationVersion is the version of this layer. It is an
integer, increasing with backward compatible changes.
* pname:description is a null-terminated string providing additional
* pname:description is a null-terminated UTF-8 string providing additional
details that can: be used by the application to identify the layer.
include::../validity/structs/VkLayerProperties.txt[]

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

@ -377,14 +377,14 @@ check for the supported properties of individual formats.
pname:shaderStorageImageReadWithoutFormat indicates whether storage
images require a format qualifier to be specified when reading from
storage images. If this feature is not enabled, the code:OpImageRead
instruction mustnot: have an code:OpImageType of code:Unknown. This also
instruction mustnot: have an code:OpTypeImage of code:Unknown. This also
indicates whether shader modules can: declare the
code:StorageImageReadWithoutFormat capability.
* [[features-features-shaderStorageImageWriteWithoutFormat]]
pname:shaderStorageImageWriteWithoutFormat indicates whether storage
images require a format qualifier to be specified when writing to
storage images. If this feature is not enabled, the code:OpImageWrite
instruction mustnot: have an code:OpImageType of code:Unknown. This also
instruction mustnot: have an code:OpTypeImage of code:Unknown. This also
indicates whether shader modules can: declare the
code:StorageImageWriteWithoutFormat capability.
* [[features-features-shaderUniformBufferArrayDynamicIndexing]]
@ -429,7 +429,7 @@ check for the supported properties of individual formats.
mustnot: be used in shader modules. This also indicates whether shader
modules can: declare the code:ClipDistance capability.
* [[features-features-shaderCullDistance]] pname:shaderCullDistance
indicates whether cull distances are suppored in shader code. If this
indicates whether cull distances are supported in shader code. If this
feature is not enabled, the code:CullDistance built-in decoration
mustnot: be used in shader modules. This also indicates whether shader
modules can: declare the code:CullDistance capability.
@ -453,7 +453,7 @@ check for the supported properties of individual formats.
return resource residency information are supported in shader code. If
this feature is not enabled, the code:OpImageSparse* instructions
mustnot: be used in shader code. This also indicates whether shader
modules can: declare the op:SparseResidency capability. The feature
modules can: declare the code:SparseResidency capability. The feature
requires at least one of the ptext:sparseResidency* features to be
supported.
* [[features-features-shaderResourceMinLod]] pname:shaderResourceMinLod
@ -713,7 +713,7 @@ properties of the physical device:
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC,
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC, or
enume:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT count against this limit. For
ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT count against this limit. For
the fragment shader stage the framebuffer color attachments also count
against this limit.
* [[features-limits-maxDescriptorSetSamplers]]
@ -917,14 +917,14 @@ properties of the physical device:
* [[features-limits-subTexelPrecisionBits]] pname:subTexelPrecisionBits is
the number of bits of precision in the division along an axis of an
image used for minification and magnification filters.
latexmath[$2^\mathit{subTexelPrecisionBits}$] is the actual number of
latexmath:[$2^\mathit{subTexelPrecisionBits}$] is the actual number of
divisions along each axis of the image represented. The filtering
hardware will snap to these locations when computing the filtered
results.
* [[features-limits-mipmapPrecisionBits]] pname:mipmapPrecisionBits is the
number of bits of division that the LOD calculation for mipmap fetching
get snapped to when determining the contribution from each miplevel to
the mip filtered results. latexmath[$2^\mathit{mipmapPrecisionBits}$] is
the mip filtered results. latexmath:[$2^\mathit{mipmapPrecisionBits}$] is
the actual number of divisions.
+
--
@ -952,7 +952,7 @@ different equations in the spec).
the code:Bias operand of image sampling operations in shader modules (or
0 if no code:Bias operand is provided to an image sampling operation)
are clamped to the range
latexmath[$[-\mathit{maxSamplerLodBias},+\mathit{maxSamplerLodBias}]$].
latexmath:[$[-\mathit{maxSamplerLodBias},+\mathit{maxSamplerLodBias}\]$].
See <<samplers-mipLodBias>>.
* [[features-limits-maxSamplerAnisotropy]] pname:maxSamplerAnisotropy is
the maximum degree of sampler anisotropy. The maximum degree of
@ -972,7 +972,7 @@ different equations in the spec).
<<vertexpostproc-viewport,Controlling the Viewport>>.
* [[features-limits-viewportboundsrange]] pname:viewportBoundsRange[2] is
the viewport bounds range
latexmath[$[\mathit{minimum},\mathit{maximum}]$]. See
latexmath:[$[\mathit{minimum},\mathit{maximum}\]$]. See
<<vertexpostproc-viewport,Controlling the Viewport>>.
* [[features-limits-viewportSubPixelBits]] pname:viewportSubPixelBits is
the number of bits of subpixel precision for viewport bounds. The
@ -1126,12 +1126,12 @@ different equations in the spec).
least 2, and levels must: be spread evenly over the range, with at least
one level at 1.0, and another at 0.0. See <<devsandqueues-priority>>.
* [[features-limits-pointSizeRange]] pname:pointSizeRange[2] is the range
latexmath[$[\mathit{minimum},\mathit{maximum}]$] of supported sizes for
points. Values written to variables decorated with the code:PointSize
built-in decoration are clamped to this range.
latexmath:[$[\mathit{minimum},\mathit{maximum}\]$] of supported sizes
for points. Values written to variables decorated with the
code:PointSize built-in decoration are clamped to this range.
* [[features-limits-lineWidthRange]] pname:lineWidthRange[2] is the range
latexmath[$[\mathit{minimum},\mathit{maximum}]$] of supported widths for
lines. Values specified by the pname:lineWidth member of the
latexmath:[$[\mathit{minimum},\mathit{maximum}\]$] of supported widths
for lines. Values specified by the pname:lineWidth member of the
sname:VkPipelineRasterizationStateCreateInfo or the pname:lineWidth
parameter to fname:vkCmdSetLineWidth are clamped to this range.
* [[features-limits-pointSizeGranularity]] pname:pointSizeGranularity is
@ -1181,8 +1181,9 @@ different equations in the spec).
For all bitmasks of type elink:VkSampleCountFlags above, the bits which
can: be set include:
+
--
include::../enums/VkSampleCountFlagBits.txt[]
+
The sample count limits defined above represent the minimum
supported sample counts for each image type. Individual images may: support
additional sample counts, which are queried using
@ -1190,6 +1191,7 @@ flink:vkGetPhysicalDeviceImageFormatProperties. The sample
count limits for images only apply to images created with the pname:tiling
set to ename:VK_IMAGE_TILING_OPTIMAL. For ename:VK_IMAGE_TILING_LINEAR
images the only supported sample count is ename:VK_SAMPLE_COUNT_1_BIT.
--
include::../validity/structs/VkPhysicalDeviceLimits.txt[]
@ -1334,7 +1336,7 @@ the same whether or not the feature is enabled.
|maxMemoryAllocationCount |- |4096 | min
|maxSamplerAllocationCount |- |4000 | min
|bufferImageGranularity |- |131072 | max
|sparseAddressSpaceSize | 0 | 2 GB | min
|sparseAddressSpaceSize | 0 | 2^31^ | min
|maxBoundDescriptorSets |- |4 | min
|maxPerStageDescriptorSamplers |- |16 | min
|maxPerStageDescriptorUniformBuffers|- |12 | min

4
doc/specs/vulkan/chapters/fragops.txt
View File

@ -376,7 +376,7 @@ include::../protos/vkCmdSetStencilWriteMask.txt[]
* pname:commandBuffer is the command buffer into which the command will be
recorded.
* pname:faceMask is a bitmask of elink:VkStencilFaceFlagBits specifying
the set of stencil state for which to update the compare mask, as
the set of stencil state for which to update the write mask, as
described above for flink:vkCmdSetStencilCompareMask.
* pname:writeMask is the new value to use as the stencil write mask.
@ -391,7 +391,7 @@ include::../protos/vkCmdSetStencilReference.txt[]
* pname:commandBuffer is the command buffer into which the command will be
recorded.
* pname:faceMask is a bitmask of elink:VkStencilFaceFlagBits specifying
the set of stencil state for which to update the compare mask, as
the set of stencil state for which to update the reference value, as
described above for flink:vkCmdSetStencilCompareMask.
* pname:reference is the new value to use as the stencil reference value.

3
doc/specs/vulkan/chapters/initialization.txt
View File

@ -126,7 +126,8 @@ include::../structs/VkInstanceCreateInfo.txt[]
* pname:enabledLayerCount is the number of global layers to enable.
* pname:ppEnabledLayerNames is a pointer to an array of
pname:enabledLayerCount null-terminated UTF-8 strings containing the
names of layers to enable.
names of layers to enable for the created instance. See the
<<extended-functionality-layers,Layers>> section for further details.
* pname:enabledExtensionCount is the number of global extensions to
enable.
* pname:ppEnabledExtensionNames is a pointer to an array of

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

@ -96,7 +96,7 @@ interface block must: match exactly, as described above. At an interface
involving the fragment shader inputs, the presence or absence of any
built-in output does not affect the interface matching.
Any input value to a shader stage is well-defined as long as the preceeding
Any input value to a shader stage is well-defined as long as the preceding
stages writes to a matching output, as described above.
Additionally, scalar and vector inputs are well-defined if there
@ -165,7 +165,7 @@ order.
The locations consumed by block and structure members are determined
by applying the rules above in a depth-first traversal of the instantiated
members as though the structure or block member were declared as in input or
members as though the structure or block member were declared as an input or
output variable of the same type.
Any two inputs listed as operands on the same code:OpEntryPoint mustnot: be
@ -217,7 +217,7 @@ and components 0 and 1 of the second location. This leaves components
A scalar or two-component 64-bit data type mustnot: specify a
code:Component decoration of 1 or 3.
A code:Component decoration mustnot: be specified any type that is
A code:Component decoration mustnot: be specified for any type that is
not a scalar or vector.
@ -322,10 +322,10 @@ 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:OpImageType and a code:Dim operand
be declared with a type of code:OpTypeImage and a code:Dim operand
of code:SubpassData.
A fragment shader input variable identified with a code:InputAttachmentIndex
A fragment shader 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
@ -539,7 +539,7 @@ that has a pname:binding equal to latexmath:[$b$] in pname:pSetLayouts[_s_]
that was specified in slink:VkPipelineLayoutCreateInfo.
The range of descriptor sets is between zero and
pname:maxBoundDescriptorSets minus one, inclusive. If a descriptor set value
pname:maxBoundDescriptorSets minus one. If a descriptor set value
is statically used by an entry point there must: be an associated
pname:pSetLayout in the corresponding pipeline layout as described in
<<descriptorsets-pipelinelayout-consistency,Pipeline Layouts consistency>>.
@ -613,7 +613,7 @@ depending on the specific resources.
[[interfaces-resources-layout-std140]]
*Standard Uniform Buffer Layout*
Member variables of an code:OpTypeStructure with storage class of
Member variables of an code:OpTypeStruct with storage class of
code:Uniform and a decoration of code:Block (uniform buffers) must: be laid
out according to the following rules.
@ -648,7 +648,7 @@ The *std140 layout* in GLSL satisfies these rules.
[[interfaces-resources-layout-std430]]
*Standard Storage Buffer Layout*
Member variables of an code:OpTypeStructure with a storage class of
Member variables of an code:OpTypeStruct with a storage class of
code:PushConstant (push constants), or a storage class of code:Uniform
with a decoration of code:BufferBlock (storage buffers) must: be laid
out as <<interfaces-resources-layout-std140,above>>, except
@ -735,7 +735,7 @@ location of the sample corresponding to the shader invocation when using
sample shading.
+
The z component of code:FragCoord is the interpolated depth value of the
primitive, and the w components is the interpolated
primitive, and the w component is the interpolated
latexmath:[$\frac{1}{w}$].
+
The code:FragCoord decoration is only supported in fragment shaders. The
@ -976,7 +976,7 @@ vertex processing stage, the output position is used in subsequent primitive
assembly, clipping and rasterization operations.
+
Variables decorated as code:Position mustnot: be used as inputs in vertex
shaders and are mustnot: be used in fragment or compute shaders.
shaders and mustnot: be used in fragment or compute shaders.
+
code:Position must: be declared as a four-component vector of 32-bit
floating-point values.

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

@ -102,7 +102,7 @@ If pname:pOriginal is `NULL`, then pname:pfnReallocation must: behave
similarly to tlink:PFN_vkAllocationFunction. If pname:size is zero, then
pname:pfnReallocation must: behave similarly to tlink:PFN_vkFreeFunction.
The contents of the original allocation from bytes zero to
latexmath:[$\min(\textrm{original size, new size})-1$], inclusive, must: be
latexmath:[$\min(\textrm{original size, new size})-1$] must: be
preserved in the new allocation. If the new allocation is larger than the
old allocation, then the contents of the additional space are undefined.
If pname:pOriginal is non-`NULL`, pname:alignment must: be equal to the

15
doc/specs/vulkan/chapters/primsrast.txt
View File

@ -73,13 +73,13 @@ as follows:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is reserved for future use.
* pname:rasterizationSamples is an elink:VkSampleCountFlagBits specifying
* pname:rasterizationSamples is a elink:VkSampleCountFlagBits specifying
the number of samples per pixel used in rasterization.
* pname:sampleShadingEnable specifies that fragment shading executes
per-sample if ename:VK_TRUE, or per-fragment if ename:VK_FALSE, as
described in <<primsrast-sampleshading,Sample Shading>>.
* pname:minSampleShading is the minimum number of unique samples to shade
for each fragment.
* pname:minSampleShading is the minimum fraction of sample shading, as
described in <<primsrast-sampleshading,Sample Shading>>.
* pname:pSampleMask is a bitmask of static coverage information that is
ANDed with the coverage information generated during rasterization, as
described in <<fragops-samplemask,Sample Mask>>.
@ -235,10 +235,9 @@ latexmath:[$\max(\lceil{minSampleShading \times rasterizationSamples}\rceil,
is the minimum fraction of sample shading and pname:rasterizationSamples is
the number of samples requested in
slink:VkPipelineMultisampleStateCreateInfo. These are associated with the
samples in an implementation-dependent manner. pname:minSampleShading must:
be in the range latexmath:[$[0,1\]$]. When the sample shading fraction is
1.0, a separate set of associated data are evaluated for each sample, and
each set of values is evaluated at the sample location.
samples in an implementation-dependent manner. When the sample shading
fraction is 1.0, a separate set of associated data are evaluated for each
sample, and each set of values is evaluated at the sample location.
[[primsrast-points]]
@ -447,7 +446,7 @@ image:images/non_strict_lines.{svgpdf}["Non strict lines",{fullimagewidth}]
A polygon results from the decomposition of a triangle strip, triangle fan
or a series of independent triangles. Like points and line segments,
polygon rasterization is controled by several variables in the
polygon rasterization is controlled by several variables in the
slink:VkPipelineRasterizationStateCreateInfo structure.

6
doc/specs/vulkan/chapters/queries.txt
View File

@ -362,7 +362,7 @@ uses of fname:vkCmdResetQueryPool in the same queue, without any additional
synchronization. Thus, the results will always reflect the most
recent use of the query.
pname:flags has the same possible values described above for the param:flags
pname:flags has the same possible values described above for the pname:flags
parameter of flink:vkGetQueryPoolResults, but the different style of
execution causes some subtle behavioral differences. Because
fname:vkCmdCopyQueryPoolResults executes in order with respect to other
@ -438,7 +438,7 @@ non-zero.
Not setting ename:VK_QUERY_CONTROL_PRECISE_BIT mode may: be more efficient
on some implementations, and should: be used where it is sufficient to know
a boolean result on whether any samples passed the per-fragment tests. In
this case, some implementations may: only return zero or one, indifferent of
this case, some implementations may: only return zero or one, indifferent to
the actual number of samples passing the per-fragment tests.
====
@ -505,7 +505,7 @@ These bits have the following meanings:
* If ename:VK_QUERY_PIPELINE_STATISTIC_GEOMETRY_SHADER_INVOCATIONS_BIT is
set, queries managed by the pool will count the number of geometry
shader invocations. This counter's value is incremented each time a
geometry shader is <<shaders-geometry-execution,invoked>>. In case of
geometry shader is <<shaders-geometry-execution,invoked>>. In the case
of <<geometry-invocations,instanced geometry shaders>>, the geometry
shader invocations count is incremented for each separate instanced
invocation.

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

@ -263,7 +263,7 @@ requirements.
image::images/sparseimage.{svgpdf}[align="center", title="Sparse Image"]
In the absense of ename:VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT and
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.
@ -479,7 +479,7 @@ understanding of sparse resources.
.Device Virtual Address
The basic pname:sparseBinding feature allows the resource to reserve its own
device virtual address range at resource creation time rather relying on a
device virtual address range at resource creation time rather than relying on a
bind operation to set this. Without any other creation flags, no other
constraints are relaxed compared to normal resources. All pages must: be
bound to physical memory before the device accesses the resource.
@ -563,7 +563,7 @@ virtual address holes with this operation.
.Binding Metadata Memory
All metadata for sparse images have their own sparse properties and is
All metadata for sparse images have their own sparse properties and are
embedded in the mip tail region for said properties. See the
<<sparsememory-multiaspect,Multiaspect>> section for details.

4
doc/specs/vulkan/chapters/tessellation.txt
View File

@ -64,7 +64,7 @@ in strips stretching across the rectangle in the latexmath:[$u$] dimension
for all tessellation evaluation shader invocations that share a line).
Each vertex produced by the tessellator has an associated (u,v,w) or (u,v)
position in a normalized parameter space, with parameter values in the
position in a normalized parameter space, with parameter values in the range
latexmath:[$[0,1\]$], as illustrated in figure
<<img-tessellation-topology>>.
@ -146,7 +146,7 @@ code:VertexOrderCcw, the vertices will be generated with counter-clockwise
order.
The vertices of a triangle are defined to be in counter-clockwise ordering
of the value
if the value
[latexmath]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
\[

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

@ -8,7 +8,7 @@
Image Operations are steps performed by SPIR-V image instructions, where
those instructions which take an code:OpTypeImage (representing a
sname:VkImageView) or code:OpTypeImageSampler (representing a
sname:VkImageView) or code:OpTypeSampledImage (representing a
(sname:VkImageView, sname:VkSampler) pair) and texel coordinates as
operands, and return a value based on one or more neighboring texture
elements (_texels_) in the image.
@ -37,10 +37,10 @@ SPIR-V Image Instructions include the following functionality:
used in the sampling operation based on additional coordinates.
** Instructions with code:Proj in the name apply homogeneous
<<textures-projection,projection>> to the coordinates.
* code:OpImageFetch and code:OpImageSparseFetch returns a single texel of
* code:OpImageFetch and code:OpImageSparseFetch return a single texel of
the image. No sampler is used.
* code:OpImage*code:Gather and code:OpImageSparse*code:Gather read
neighboring texels and <<textures-gather,returns a single component>> of
neighboring texels and <<textures-gather,return a single component>> of
each.
* code:OpImageRead (and code:OpImageSparseRead) and code:OpImageWrite read
and write, respectively, a texel in the image. No sampler is used.
@ -406,7 +406,7 @@ unnormalized texel coordinates, this is performed on the coordinates that
result after <<textures-unnormalized-to-integer,conversion>> to integer
texel coordinates.
If the integer texel coordinates satifies any of the conditions
If the integer texel coordinates satisfy any of the conditions
[latexmath]
+++++++++++++++++++
\begin{align*}
@ -523,7 +523,7 @@ elink:VkFormat), using the appropriate equations in
<<fundamentals-fp16,16-Bit Floating-Point Numbers>>,
<<fundamentals-fp11,Unsigned 11-Bit Floating-Point Numbers>>,
<<fundamentals-fp10,Unsigned 10-Bit Floating-Point Numbers>>,
<<fundamentals-fixedconf,Fixed-Point Data Conversion>>, and
<<fundamentals-fixedconv,Fixed-Point Data Conversion>>, and
<<textures-sexp-RGB,Shared Exponent to RGB>>.
If the image format is sRGB, the color components are first converted as if
@ -734,7 +734,7 @@ code to a boolean value.
_Texel output instructions_ are SPIR-V image instructions that write to an
image. _Texel output operations_ are a set of steps that are performed on
state, coordinates, and texel values while processing a texel output
instruction, and which are common to some or all texel ouitput instructions.
instruction, and which are common to some or all texel output instructions.
They include the following steps, which are performed in the listed order:
* <<textures-output-validation,Validation operations>>
@ -845,7 +845,7 @@ dPdy & =
\end{align*}
+++++++++++++++++++
code:OpDPdx and code:OpDPdy must return: the same result as either
code:OpDPdx and code:OpDPdy must: return the same result as either
code:OpDPdxFine or code:OpDPdxCoarse and either code:OpDPdyFine or
code:OpDPdyCoarse, respectively. Implementations must: make the same choice
of either coarse or fine for both code:OpDPdx and code:OpDPdy, and
@ -929,7 +929,7 @@ transform the derivatives to per-face derivatives.
=== Cube Map Face Selection
The direction vector selects one of the cube maps face's layers based on the
The direction vector selects one of the cube map's faces based on the
largest magnitude coordinate direction (the major axis direction). Since two
or more coordinates can: have identical magnitude, the implementation must:
have rules to disambiguate this situation.
@ -1571,7 +1571,7 @@ latexmath:[$(i,j,k)$] texel coordinates, with all texels taken from layer l.
++++++++++++++++++++++++
Within a miplevel, etext:LINEAR filtering computes a weighted average of 8
(for 3D), 4 (for 2D or ube), or 2 (for 1D) texel values, using the weights
(for 3D), 4 (for 2D or Cube), or 2 (for 1D) texel values, using the weights
computed earlier:
[latexmath]

9
doc/specs/vulkan/chapters/vertexpostproc.txt
View File

@ -284,10 +284,11 @@ latexmath:[$
\end{array}\right).
$]
Multiple viewports are available and are numbered zero up to the value of
sname:VkPhysicalDeviceLimits::pname:maxViewports. The number of viewports
used by a pipeline is controlled by the pname:viewportCount member of the
sname:VkPipelineViewportStateCreateInfo structure used in pipeline creation:
Multiple viewports are available, numbered zero up to
sname:VkPhysicalDeviceLimits::pname:maxViewports minus one. The number of
viewports used by a pipeline is controlled by the pname:viewportCount member
of the sname:VkPipelineViewportStateCreateInfo structure used in pipeline
creation:
include::../structs/VkPipelineViewportStateCreateInfo.txt[]

2
doc/specs/vulkan/enums/VkCullModeFlagBits.txt
View File

@ -11,6 +11,6 @@ typedef enum VkCullModeFlagBits {
VK_CULL_MODE_NONE = 0,
VK_CULL_MODE_FRONT_BIT = 0x00000001,
VK_CULL_MODE_BACK_BIT = 0x00000002,
VK_CULL_MODE_FRONT_AND_BACK = 0x3,
VK_CULL_MODE_FRONT_AND_BACK = 0x00000003,
} VkCullModeFlagBits;
------------------------------------------------------------------------------

2
doc/specs/vulkan/enums/VkStencilFaceFlagBits.txt
View File

@ -10,6 +10,6 @@ endif::doctype-manpage[]
typedef enum VkStencilFaceFlagBits {
VK_STENCIL_FACE_FRONT_BIT = 0x00000001,
VK_STENCIL_FACE_BACK_BIT = 0x00000002,
VK_STENCIL_FRONT_AND_BACK = 0x3,
VK_STENCIL_FRONT_AND_BACK = 0x00000003,
} VkStencilFaceFlagBits;
------------------------------------------------------------------------------

2
doc/specs/vulkan/style/styleguide.txt
View File

@ -282,7 +282,7 @@ following table:
something that should be rendered like a structure name,
but is not actually one (e.g. is a wildcard or subset of
an actual structure name).
| elink{cl} | Formats the macro argument as a Vulkan enumerantion
| elink{cl} | Formats the macro argument as a Vulkan enumeration
name and links to the definition of that enumeration type.
Example: ename{cl}VkResult -> ename:VkResult.
| ename{cl} | Formats the macro argument as a Vulkan enumerant name.

2
doc/specs/vulkan/validity/protos/vkEnumerateDeviceExtensionProperties.txt
View File

@ -11,7 +11,7 @@ endif::doctype-manpage[]
* If pname:pLayerName is not `NULL`, pname:pLayerName must: be a null-terminated string
* pname:pPropertyCount must: be a pointer to a basetype:uint32_t value
* If the value referenced by pname:pPropertyCount is not `0`, and pname:pProperties is not `NULL`, pname:pProperties must: be a pointer to an array of pname:pPropertyCount sname:VkExtensionProperties structures
* If pname:pLayerName is not `NULL`, it must: be the name of a layer available on the system
* If pname:pLayerName is not `NULL`, it must: be the name of a device layer returned by flink:vkEnumerateDeviceLayerProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/protos/vkEnumerateInstanceExtensionProperties.txt
View File

@ -10,7 +10,7 @@ endif::doctype-manpage[]
* If pname:pLayerName is not `NULL`, pname:pLayerName must: be a null-terminated string
* pname:pPropertyCount must: be a pointer to a basetype:uint32_t value
* If the value referenced by pname:pPropertyCount is not `0`, and pname:pProperties is not `NULL`, pname:pProperties must: be a pointer to an array of pname:pPropertyCount sname:VkExtensionProperties structures
* If pname:pLayerName is not `NULL`, it must: be the name of a layer available on the system
* If pname:pLayerName is not `NULL`, it must: be the name of an instance layer returned by flink:vkEnumerateInstanceLayerProperties
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

6
doc/specs/vulkan/validity/structs/VkBufferImageCopy.txt
View File

@ -22,9 +22,9 @@ endif::doctype-manpage[]
* pname:imageExtent.height must: be a multiple of the block height or (pname:imageExtent.height + pname:imageOffset.y) must: equal the image subresource height
* pname:imageExtent.depth must: be a multiple of the block depth or (pname:imageExtent.depth + pname:imageOffset.z) must: equal the image subresource depth
* pname:bufferOffset, pname:bufferRowLength, pname:bufferImageHeight and all members of pname:imageOffset and pname:imageExtent must: respect the image transfer granularity requirements of the queue family that it will be submitted against, as described in <<execution-physical-device-enumeration,Physical Device Enumeration>>
* The pname:aspectMask member of pname:srcSubresource must: specify aspects present in the calling command's sname:VkImage parameter
* The pname:aspectMask member of pname:pSubresource must: only have a single bit set
* If the calling command's sname:VkImage parameter is of elink:VkImageType ename:VK_IMAGE_TYPE_3D, the pname:baseArrayLayer and pname:layerCount members of both pname:srcSubresource and pname:dstSubresource must: be `0` and `1`, respectively
* The pname:aspectMask member of pname:imageSubresource must: specify aspects present in the calling command's sname:VkImage parameter
* The pname:aspectMask member of pname:imageSubresource must: only have a single bit set
* If the calling command's sname:VkImage parameter is of elink:VkImageType ename:VK_IMAGE_TYPE_3D, the pname:baseArrayLayer and pname:layerCount members of pname:imageSubresource must: be `0` and `1`, respectively
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

1
doc/specs/vulkan/validity/structs/VkPipelineMultisampleStateCreateInfo.txt
View File

@ -14,6 +14,7 @@ endif::doctype-manpage[]
* If pname:pSampleMask is not `NULL`, pname:pSampleMask must: be a pointer to an array of latexmath:[$\lceil{\mathit{rasterizationSamples} \over 32}\rceil$] basetype:VkSampleMask values
* If the <<features-features-sampleRateShading,sample rate shading>> feature is not enabled, pname:sampleShadingEnable must: be ename:VK_FALSE
* If the <<features-features-alphaToOne,alpha to one>> feature is not enabled, pname:alphaToOneEnable must: be ename:VK_FALSE
* pname:minSampleShading must: be in the range latexmath:[$[0,1\]$]
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

2
doc/specs/vulkan/validity/structs/VkPipelineRasterizationStateCreateInfo.txt
View File

@ -14,7 +14,7 @@ endif::doctype-manpage[]
* pname:cullMode must: be a valid combination of elink:VkCullModeFlagBits values
* pname:frontFace must: be a valid elink:VkFrontFace value
* If the <<features-features-depthClamp,depth clamping>> feature is not enabled, the value of pname:depthClampEnable must: be ename:VK_FALSE
* If the <<features-features-fillModeNonSolid,non-solid fill modes>> feature is not enabled, the value of pname:fillMode must: be ename:VK_POLYGON_MODE_FILL
* If the <<features-features-fillModeNonSolid,non-solid fill modes>> feature is not enabled, the value of pname:polygonMode must: be ename:VK_POLYGON_MODE_FILL
ifndef::doctype-manpage[]
********************************************************************************
endif::doctype-manpage[]

17
src/spec/vk.xml
View File

@ -1018,9 +1018,9 @@ maintained in the master branch of the Khronos Vulkan Github project.
<usage> pname:imageExtent.height must: be a multiple of the block height or (pname:imageExtent.height + pname:imageOffset.y) must: equal the image subresource height</usage>
<usage> pname:imageExtent.depth must: be a multiple of the block depth or (pname:imageExtent.depth + pname:imageOffset.z) must: equal the image subresource depth</usage>
<usage>pname:bufferOffset, pname:bufferRowLength, pname:bufferImageHeight and all members of pname:imageOffset and pname:imageExtent must: respect the image transfer granularity requirements of the queue family that it will be submitted against, as described in &lt;&lt;execution-physical-device-enumeration,Physical Device Enumeration&gt;&gt;</usage>
<usage>The pname:aspectMask member of pname:srcSubresource must: specify aspects present in the calling command's sname:VkImage parameter</usage>
<usage>The pname:aspectMask member of pname:pSubresource must: only have a single bit set</usage>
<usage>If the calling command's sname:VkImage parameter is of elink:VkImageType ename:VK_IMAGE_TYPE_3D, the pname:baseArrayLayer and pname:layerCount members of both pname:srcSubresource and pname:dstSubresource must: be `0` and `1`, respectively</usage>
<usage>The pname:aspectMask member of pname:imageSubresource must: specify aspects present in the calling command's sname:VkImage parameter</usage>
<usage>The pname:aspectMask member of pname:imageSubresource must: only have a single bit set</usage>
<usage>If the calling command's sname:VkImage parameter is of elink:VkImageType ename:VK_IMAGE_TYPE_3D, the pname:baseArrayLayer and pname:layerCount members of pname:imageSubresource must: be `0` and `1`, respectively</usage>
</validity>
</type>
<type category="struct" name="VkImageResolve">
@ -1248,7 +1248,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<member><type>float</type> <name>lineWidth</name></member>
<validity>
<usage>If the &lt;&lt;features-features-depthClamp,depth clamping&gt;&gt; feature is not enabled, the value of pname:depthClampEnable must: be ename:VK_FALSE</usage>
<usage>If the &lt;&lt;features-features-fillModeNonSolid,non-solid fill modes&gt;&gt; feature is not enabled, the value of pname:fillMode must: be ename:VK_POLYGON_MODE_FILL</usage>
<usage>If the &lt;&lt;features-features-fillModeNonSolid,non-solid fill modes&gt;&gt; feature is not enabled, the value of pname:polygonMode must: be ename:VK_POLYGON_MODE_FILL</usage>
</validity>
</type>
<type category="struct" name="VkPipelineMultisampleStateCreateInfo">
@ -1264,6 +1264,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<validity>
<usage>If the &lt;&lt;features-features-sampleRateShading,sample rate shading&gt;&gt; feature is not enabled, pname:sampleShadingEnable must: be ename:VK_FALSE</usage>
<usage>If the &lt;&lt;features-features-alphaToOne,alpha to one&gt;&gt; feature is not enabled, pname:alphaToOneEnable must: be ename:VK_FALSE</usage>
<usage>pname:minSampleShading must: be in the range latexmath:[$[0,1\]$]</usage>
</validity>
</type>
<type category="struct" name="VkPipelineColorBlendAttachmentState">
@ -2279,7 +2280,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enum value="0" name="VK_CULL_MODE_NONE"/>
<enum bitpos="0" name="VK_CULL_MODE_FRONT_BIT"/>
<enum bitpos="1" name="VK_CULL_MODE_BACK_BIT"/>
<enum value="0x3" name="VK_CULL_MODE_FRONT_AND_BACK"/>
<enum value="0x00000003" name="VK_CULL_MODE_FRONT_AND_BACK"/>
</enums>
<enums name="VkFrontFace" type="enum" expand="VK_FRONT_FACE">
<enum value="0" name="VK_FRONT_FACE_COUNTER_CLOCKWISE"/>
@ -2831,7 +2832,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<enums name="VkStencilFaceFlagBits" type="bitmask">
<enum bitpos="0" name="VK_STENCIL_FACE_FRONT_BIT" comment="Front face"/>
<enum bitpos="1" name="VK_STENCIL_FACE_BACK_BIT" comment="Back face"/>
<enum value="0x3" name="VK_STENCIL_FRONT_AND_BACK" comment="Front and back faces"/>
<enum value="0x00000003" name="VK_STENCIL_FRONT_AND_BACK" comment="Front and back faces"/>
</enums>
<enums name="VkDescriptorPoolCreateFlagBits" type="bitmask">
<enum bitpos="0" name="VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT" comment="Descriptor sets may be freed individually"/>
@ -3021,7 +3022,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<param optional="false,true"><type>uint32_t</type>* <name>pPropertyCount</name></param>
<param optional="true" len="pPropertyCount"><type>VkExtensionProperties</type>* <name>pProperties</name></param>
<validity>
<usage>If pname:pLayerName is not `NULL`, it must: be the name of a layer available on the system</usage>
<usage>If pname:pLayerName is not `NULL`, it must: be the name of an instance layer returned by flink:vkEnumerateInstanceLayerProperties</usage>
</validity>
</command>
<command successcodes="VK_SUCCESS,VK_INCOMPLETE" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
@ -3037,7 +3038,7 @@ maintained in the master branch of the Khronos Vulkan Github project.
<param optional="false,true"><type>uint32_t</type>* <name>pPropertyCount</name></param>
<param optional="true" len="pPropertyCount"><type>VkExtensionProperties</type>* <name>pProperties</name></param>
<validity>
<usage>If pname:pLayerName is not `NULL`, it must: be the name of a layer available on the system</usage>
<usage>If pname:pLayerName is not `NULL`, it must: be the name of a device layer returned by flink:vkEnumerateDeviceLayerProperties</usage>
</validity>
</command>
<command>

4
src/vulkan/vulkan.h
View File

@ -992,7 +992,7 @@ typedef enum VkCullModeFlagBits {
VK_CULL_MODE_NONE = 0,
VK_CULL_MODE_FRONT_BIT = 0x00000001,
VK_CULL_MODE_BACK_BIT = 0x00000002,
VK_CULL_MODE_FRONT_AND_BACK = 0x3,
VK_CULL_MODE_FRONT_AND_BACK = 0x00000003,
} VkCullModeFlagBits;
typedef VkFlags VkCullModeFlags;
typedef VkFlags VkPipelineMultisampleStateCreateFlags;
@ -1083,7 +1083,7 @@ typedef VkFlags VkCommandBufferResetFlags;
typedef enum VkStencilFaceFlagBits {
VK_STENCIL_FACE_FRONT_BIT = 0x00000001,
VK_STENCIL_FACE_BACK_BIT = 0x00000002,
VK_STENCIL_FRONT_AND_BACK = 0x3,
VK_STENCIL_FRONT_AND_BACK = 0x00000003,
} VkStencilFaceFlagBits;
typedef VkFlags VkStencilFaceFlags;