Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
// Copyright (c) 2015-2019 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[limits]]
= Limits
_Limits_ are implementation-dependent minimums, maximums, and other device
characteristics that an application may: need to be aware of.
[NOTE]
.Note
====
Limits are reported via the basic slink:VkPhysicalDeviceLimits structure, as
well as the extensible structure sname:VkPhysicalDeviceProperties2, which
was added in `<<VK_KHR_get_physical_device_properties2>>` and included in
Vulkan 1.1.
When limits are added in future Vulkan versions or extensions, each
extension should: introduce one new limit structure, if needed.
This structures can: be added to the pname:pNext chain of the
sname:VkPhysicalDeviceProperties2 structure.
====
[open,refpage='VkPhysicalDeviceLimits',desc='Structure reporting implementation-dependent physical device limits',type='structs']
--
The sname:VkPhysicalDeviceLimits structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceLimits.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The sname:VkPhysicalDeviceLimits are properties of the physical device.
These are available in the pname:limits member of the
slink:VkPhysicalDeviceProperties structure which is returned from
flink:vkGetPhysicalDeviceProperties.
* [[limits-maxImageDimension1D]] pname:maxImageDimension1D is the maximum
dimension (pname:width) supported for all images created with an
pname:imageType of ename:VK_IMAGE_TYPE_1D.
* [[limits-maxImageDimension2D]] pname:maxImageDimension2D is the maximum
dimension (pname:width or pname:height) supported for all images created
with an pname:imageType of ename:VK_IMAGE_TYPE_2D and without
ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT set in pname:flags.
* [[limits-maxImageDimension3D]] pname:maxImageDimension3D is the maximum
dimension (pname:width, pname:height, or pname:depth) supported for all
images created with an pname:imageType of ename:VK_IMAGE_TYPE_3D.
* [[limits-maxImageDimensionCube]] pname:maxImageDimensionCube is the
maximum dimension (pname:width or pname:height) supported for all images
created with an pname:imageType of ename:VK_IMAGE_TYPE_2D and with
ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT set in pname:flags.
* [[limits-maxImageArrayLayers]] pname:maxImageArrayLayers is the maximum
number of layers (pname:arrayLayers) for an image.
* [[limits-maxTexelBufferElements]] pname:maxTexelBufferElements is the
maximum number of addressable texels for a buffer view created on a
buffer which was created with the
ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT or
ename:VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT set in the pname:usage
member of the sname:VkBufferCreateInfo structure.
* [[limits-maxUniformBufferRange]] pname:maxUniformBufferRange is the
maximum value that can: be specified in the pname:range member of any
slink:VkDescriptorBufferInfo structures passed to a call to
flink:vkUpdateDescriptorSets for descriptors of type
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC.
* [[limits-maxStorageBufferRange]] pname:maxStorageBufferRange is the
maximum value that can: be specified in the pname:range member of any
slink:VkDescriptorBufferInfo structures passed to a call to
flink:vkUpdateDescriptorSets for descriptors of type
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC.
* [[limits-maxPushConstantsSize]] pname:maxPushConstantsSize is the
maximum size, in bytes, of the pool of push constant memory.
For each of the push constant ranges indicated by the
pname:pPushConstantRanges member of the sname:VkPipelineLayoutCreateInfo
structure, [eq]#(pname:offset {plus} pname:size)# must: be less than or
equal to this limit.
* [[limits-maxMemoryAllocationCount]] pname:maxMemoryAllocationCount is
the maximum number of device memory allocations, as created by
flink:vkAllocateMemory, which can: simultaneously exist.
* [[limits-maxSamplerAllocationCount]] pname:maxSamplerAllocationCount is
the maximum number of sampler objects, as created by
flink:vkCreateSampler, which can: simultaneously exist on a device.
* [[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 offsets in the same
sname:VkDeviceMemory object without aliasing.
See <<resources-bufferimagegranularity,Buffer-Image Granularity>> for
more details.
* [[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 sparse resources,
regardless of whether any memory is bound to them.
* [[limits-maxBoundDescriptorSets]] pname:maxBoundDescriptorSets is the
maximum number of descriptor sets that can: be simultaneously used by a
pipeline.
All code:DescriptorSet decorations in shader modules must: have a value
less than pname:maxBoundDescriptorSets.
See <<descriptorsets-sets>>.
* [[limits-maxPerStageDescriptorSamplers]]
pname:maxPerStageDescriptorSamplers is the maximum number of samplers
that can: be accessible to a single shader stage in a pipeline layout.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_SAMPLER or
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
A descriptor is accessible to a shader stage when the pname:stageFlags
member of the sname:VkDescriptorSetLayoutBinding structure has the bit
for that shader stage set.
See <<descriptorsets-sampler>> and
<<descriptorsets-combinedimagesampler>>.
* [[limits-maxPerStageDescriptorUniformBuffers]]
pname:maxPerStageDescriptorUniformBuffers is the maximum number of
uniform buffers that can: be accessible to a single shader stage in a
pipeline layout.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
A descriptor is accessible to a shader stage when the pname:stageFlags
member of the sname:VkDescriptorSetLayoutBinding structure has the bit
for that shader stage set.
See <<descriptorsets-uniformbuffer>> and
<<descriptorsets-uniformbufferdynamic>>.
* [[limits-maxPerStageDescriptorStorageBuffers]]
pname:maxPerStageDescriptorStorageBuffers is the maximum number of
storage buffers that can: be accessible to a single shader stage in a
pipeline layout.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
A descriptor is accessible to a pipeline shader stage when the
pname:stageFlags member of the sname:VkDescriptorSetLayoutBinding
structure has the bit for that shader stage set.
See <<descriptorsets-storagebuffer>> and
<<descriptorsets-storagebufferdynamic>>.
* [[limits-maxPerStageDescriptorSampledImages]]
pname:maxPerStageDescriptorSampledImages is the maximum number of
sampled images that can: be accessible to a single shader stage in a
pipeline layout.
Descriptors with a type of
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER count against this limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
A descriptor is accessible to a pipeline shader stage when the
pname:stageFlags member of the sname:VkDescriptorSetLayoutBinding
structure has the bit for that shader stage set.
See <<descriptorsets-combinedimagesampler>>,
<<descriptorsets-sampledimage>>, and
<<descriptorsets-uniformtexelbuffer>>.
* [[limits-maxPerStageDescriptorStorageImages]]
pname:maxPerStageDescriptorStorageImages is the maximum number of
storage images that can: be accessible to a single shader stage in a
pipeline layout.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER count against this limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
A descriptor is accessible to a pipeline shader stage when the
pname:stageFlags member of the sname:VkDescriptorSetLayoutBinding
structure has the bit for that shader stage set.
See <<descriptorsets-storageimage>>, and
<<descriptorsets-storagetexelbuffer>>.
* [[limits-maxPerStageDescriptorInputAttachments]]
pname:maxPerStageDescriptorInputAttachments is the maximum number of
input attachments that can: be accessible to a single shader stage in a
pipeline layout.
Descriptors with a type of ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT
count against this limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
A descriptor is accessible to a pipeline shader stage when the
pname:stageFlags member of the sname:VkDescriptorSetLayoutBinding
structure has the bit for that shader stage set.
These are only supported for the fragment stage.
See <<descriptorsets-inputattachment>>.
* [[limits-maxPerStageResources]] pname:maxPerStageResources is the
maximum number of resources that can: be accessible to a single shader
stage in a pipeline layout.
Descriptors with a type of
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE,
ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE,
ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER,
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER,
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER,
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC,
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC, or
ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT count against this limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
For the fragment shader stage the framebuffer color attachments also
count against this limit.
* [[limits-maxDescriptorSetSamplers]] pname:maxDescriptorSetSamplers is
the maximum number of samplers 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_SAMPLER or
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-sampler>> and
<<descriptorsets-combinedimagesampler>>.
* [[limits-maxDescriptorSetUniformBuffers]]
pname:maxDescriptorSetUniformBuffers is the maximum number of uniform
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
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-uniformbuffer>> and
<<descriptorsets-uniformbufferdynamic>>.
* [[limits-maxDescriptorSetUniformBuffersDynamic]]
pname:maxDescriptorSetUniformBuffersDynamic is the maximum number of
dynamic uniform 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_DYNAMIC count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-uniformbufferdynamic>>.
* [[limits-maxDescriptorSetStorageBuffers]]
pname:maxDescriptorSetStorageBuffers is the maximum number of 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 or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-storagebuffer>> and
<<descriptorsets-storagebufferdynamic>>.
* [[limits-maxDescriptorSetStorageBuffersDynamic]]
pname:maxDescriptorSetStorageBuffersDynamic is the maximum number of
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.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-storagebufferdynamic>>.
* [[limits-maxDescriptorSetSampledImages]]
pname:maxDescriptorSetSampledImages is the maximum number of sampled
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,
ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER count against this limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-combinedimagesampler>>,
<<descriptorsets-sampledimage>>, and
<<descriptorsets-uniformtexelbuffer>>.
* [[limits-maxDescriptorSetStorageImages]]
pname:maxDescriptorSetStorageImages is the maximum number of storage
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.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-storageimage>>, and
<<descriptorsets-storagetexelbuffer>>.
* [[limits-maxDescriptorSetInputAttachments]]
pname:maxDescriptorSetInputAttachments is the maximum number of input
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.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptors in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
See <<descriptorsets-inputattachment>>.
* [[limits-maxVertexInputAttributes]] pname:maxVertexInputAttributes is
the maximum number of vertex input attributes that can: be specified for
a graphics pipeline.
These are described in the array of
sname:VkVertexInputAttributeDescription structures that are provided at
graphics pipeline creation time via the
pname:pVertexAttributeDescriptions member of the
sname:VkPipelineVertexInputStateCreateInfo structure.
See <<fxvertex-attrib>> and <<fxvertex-input>>.
* [[limits-maxVertexInputBindings]] pname:maxVertexInputBindings is the
maximum number of vertex buffers that can: be specified for providing
vertex attributes to a graphics pipeline.
These are described in the array of
sname:VkVertexInputBindingDescription structures that are provided at
graphics pipeline creation time via the pname:pVertexBindingDescriptions
member of the sname:VkPipelineVertexInputStateCreateInfo structure.
The pname:binding member of sname:VkVertexInputBindingDescription must:
be less than this limit.
See <<fxvertex-input>>.
* [[limits-maxVertexInputAttributeOffset]]
pname:maxVertexInputAttributeOffset is the maximum vertex input
attribute offset that can: be added to the vertex input binding stride.
The pname:offset member of the sname:VkVertexInputAttributeDescription
structure must: be less than or equal to this limit.
See <<fxvertex-input>>.
* [[limits-maxVertexInputBindingStride]] pname:maxVertexInputBindingStride
is the maximum vertex input binding stride that can: be specified in a
vertex input binding.
The pname:stride member of the sname:VkVertexInputBindingDescription
structure must: be less than or equal to this limit.
See <<fxvertex-input>>.
* [[limits-maxVertexOutputComponents]] pname:maxVertexOutputComponents is
the maximum number of components of output variables which can: be
output by a vertex shader.
See <<shaders-vertex>>.
* [[limits-maxTessellationGenerationLevel]]
pname:maxTessellationGenerationLevel is the maximum tessellation
generation level supported by the fixed-function tessellation primitive
generator.
See <<tessellation>>.
* [[limits-maxTessellationPatchSize]] pname:maxTessellationPatchSize is
the maximum patch size, in vertices, of patches that can: be processed
by the tessellation control shader and tessellation primitive generator.
The pname:patchControlPoints member of the
sname:VkPipelineTessellationStateCreateInfo structure specified at
pipeline creation time and the value provided in the code:OutputVertices
execution mode of shader modules must: be less than or equal to this
limit.
See <<tessellation>>.
* [[limits-maxTessellationControlPerVertexInputComponents]]
pname:maxTessellationControlPerVertexInputComponents is the maximum
number of components of input variables which can: be provided as
per-vertex inputs to the tessellation control shader stage.
* [[limits-maxTessellationControlPerVertexOutputComponents]]
pname:maxTessellationControlPerVertexOutputComponents is the maximum
number of components of per-vertex output variables which can: be output
from the tessellation control shader stage.
* [[limits-maxTessellationControlPerPatchOutputComponents]]
pname:maxTessellationControlPerPatchOutputComponents is the maximum
number of components of per-patch output variables which can: be output
from the tessellation control shader stage.
* [[limits-maxTessellationControlTotalOutputComponents]]
pname:maxTessellationControlTotalOutputComponents is the maximum total
number of components of per-vertex and per-patch output variables which
can: be output from the tessellation control shader stage.
* [[limits-maxTessellationEvaluationInputComponents]]
pname:maxTessellationEvaluationInputComponents is the maximum number of
components of input variables which can: be provided as per-vertex
inputs to the tessellation evaluation shader stage.
* [[limits-maxTessellationEvaluationOutputComponents]]
pname:maxTessellationEvaluationOutputComponents is the maximum number of
components of per-vertex output variables which can: be output from the
tessellation evaluation shader stage.
* [[limits-maxGeometryShaderInvocations]]
pname:maxGeometryShaderInvocations is the maximum invocation count
supported for instanced geometry shaders.
The value provided in the code:Invocations execution mode of shader
modules must: be less than or equal to this limit.
See <<geometry>>.
* [[limits-maxGeometryInputComponents]] pname:maxGeometryInputComponents
is the maximum number of components of input variables which can: be
provided as inputs to the geometry shader stage.
* [[limits-maxGeometryOutputComponents]] pname:maxGeometryOutputComponents
is the maximum number of components of output variables which can: be
output from the geometry shader stage.
* [[limits-maxGeometryOutputVertices]] pname:maxGeometryOutputVertices is
the maximum number of vertices which can: be emitted by any geometry
shader.
* [[limits-maxGeometryTotalOutputComponents]]
pname:maxGeometryTotalOutputComponents is the maximum total number of
components of output, across all emitted vertices, which can: be output
from the geometry shader stage.
* [[limits-maxFragmentInputComponents]] pname:maxFragmentInputComponents
is the maximum number of components of input variables which can: be
provided as inputs to the fragment shader stage.
* [[limits-maxFragmentOutputAttachments]]
pname:maxFragmentOutputAttachments is the maximum number of output
attachments which can: be written to by the fragment shader stage.
* [[limits-maxFragmentDualSrcAttachments]]
pname:maxFragmentDualSrcAttachments is the maximum number of output
attachments which can: be written to by the fragment shader stage when
blending is enabled and one of the dual source blend modes is in use.
See <<framebuffer-dsb>> and <<features-dualSrcBlend,dualSrcBlend>>.
* [[limits-maxFragmentCombinedOutputResources]]
pname:maxFragmentCombinedOutputResources is the total number of storage
buffers, storage images, and output buffers which can: be used in the
fragment shader stage.
* [[limits-maxComputeSharedMemorySize]] pname:maxComputeSharedMemorySize
is the maximum total storage size, in bytes, available for variables
declared with the code:Workgroup storage class in shader modules (or
with the code:shared storage qualifier in GLSL) in the compute shader
stage.
The amount of storage consumed by the variables declared with the
code:Workgroup storage class is implementation-dependent.
However, the amount of storage consumed may not exceed the largest block
size that would be obtained if all active variables declared with
code:Workgroup storage class were assigned offsets in an arbitrary order
by successively taking the smallest valid offset according to the
<<interfaces-resources-layout-std430,Standard Storage Buffer Layout>>
rules.
(This is equivalent to using the GLSL std430 layout rules.)
* [[limits-maxComputeWorkGroupCount]] pname:maxComputeWorkGroupCount[3] is
the maximum number of local workgroups that can: be dispatched by a
single dispatch command.
These three values represent the maximum number of local workgroups for
the X, Y, and Z dimensions, respectively.
The workgroup count parameters to the dispatch commands must: be less
than or equal to the corresponding limit.
See <<dispatch>>.
* [[limits-maxComputeWorkGroupInvocations]]
pname:maxComputeWorkGroupInvocations is the maximum total number of
compute shader invocations in a single local workgroup.
The product of the X, Y, and Z sizes as specified by the code:LocalSize
execution mode in shader modules and by the object decorated by the
code:WorkgroupSize decoration must: be less than or equal to this limit.
* [[limits-maxComputeWorkGroupSize]] pname:maxComputeWorkGroupSize[3] is
the maximum size of a local compute workgroup, per dimension.
These three values represent the maximum local workgroup size in the X,
Y, and Z dimensions, respectively.
The pname:x, pname:y, and pname:z sizes specified by the code:LocalSize
execution mode and by the object decorated by the code:WorkgroupSize
decoration in shader modules must: be less than or equal to the
corresponding limit.
* [[limits-subPixelPrecisionBits]] pname:subPixelPrecisionBits is the
number of bits of subpixel precision in framebuffer coordinates
[eq]#x~f~# and [eq]#y~f~#.
See <<primsrast>>.
* [[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.
[eq]#2^pname:subTexelPrecisionBits^# is the actual number of divisions
along each axis of the image represented.
Sub-texel values calculated during image sampling will snap to these
locations when generating the filtered results.
* [[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 mip level to the
mip filtered results.
[eq]#2^pname:mipmapPrecisionBits^# is the actual number of divisions.
* [[limits-maxDrawIndexedIndexValue]] pname:maxDrawIndexedIndexValue is
the maximum index value that can: be used for indexed draw calls when
using 32-bit indices.
This excludes the primitive restart index value of 0xFFFFFFFF.
See <<features-fullDrawIndexUint32,fullDrawIndexUint32>>.
* [[limits-maxDrawIndirectCount]] pname:maxDrawIndirectCount is the
maximum draw count that is supported for indirect draw calls.
See <<features-multiDrawIndirect,multiDrawIndirect>>.
* [[limits-maxSamplerLodBias]] pname:maxSamplerLodBias is the maximum
absolute sampler LOD bias.
The sum of the pname:mipLodBias member of the sname:VkSamplerCreateInfo
structure and 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
[eq]#[-pname:maxSamplerLodBias,+pname:maxSamplerLodBias]#.
See <<samplers-mipLodBias>>.
* [[limits-maxSamplerAnisotropy]] pname:maxSamplerAnisotropy is the
maximum degree of sampler anisotropy.
The maximum degree of anisotropic filtering used for an image sampling
operation is the minimum of the pname:maxAnisotropy member of the
sname:VkSamplerCreateInfo structure and this limit.
See <<samplers-maxAnisotropy>>.
* [[limits-maxViewports]] pname:maxViewports is the maximum number of
active viewports.
The pname:viewportCount member of the
sname:VkPipelineViewportStateCreateInfo structure that is provided at
pipeline creation must: be less than or equal to this limit.
* [[limits-maxViewportDimensions]] pname:maxViewportDimensions[2] are the
maximum viewport dimensions in the X (width) and Y (height) dimensions,
respectively.
The maximum viewport dimensions must: be greater than or equal to the
largest image which can: be created and used as a framebuffer
attachment.
See <<vertexpostproc-viewport,Controlling the Viewport>>.
* [[limits-viewportboundsrange]] pname:viewportBoundsRange[2] is the
[eq]#[minimum, maximum]# range that the corners of a viewport must: be
contained in.
This range must: be at least [eq]#[-2 {times} pname:size, 2 {times}
pname:size - 1]#, where [eq]#pname:size =
max(pname:maxViewportDimensions[0], pname: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 [eq]#[-pname:size {plus} 1, 2 {times}
pname:size - 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 smallest possible number of bits ends up with the specified
range.
====
* [[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 at is given by this limit.
* [[limits-minMemoryMapAlignment]] pname:minMemoryMapAlignment is the
minimum required: alignment, in bytes, of host visible memory
allocations within the host address space.
When mapping a memory allocation with flink:vkMapMemory, subtracting
pname:offset bytes from the returned pointer will always produce an
integer multiple of this limit.
See <<memory-device-hostaccess>>.
* [[limits-minTexelBufferOffsetAlignment]]
pname:minTexelBufferOffsetAlignment is the minimum required: alignment,
in bytes, for the pname:offset member of the
sname:VkBufferViewCreateInfo structure for texel buffers.
When a buffer view is created for a buffer which was created with
ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT or
ename:VK_BUFFER_USAGE_STORAGE_TEXEL_BUFFER_BIT set in the pname:usage
member of the sname:VkBufferCreateInfo structure, the pname:offset must:
be an integer multiple of this limit.
* [[limits-minUniformBufferOffsetAlignment]]
pname:minUniformBufferOffsetAlignment is the minimum required:
alignment, in bytes, for the pname:offset member of the
sname:VkDescriptorBufferInfo structure for uniform buffers.
When a descriptor of type ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC is updated, the
pname:offset must: be an integer multiple of this limit.
Similarly, dynamic offsets for uniform buffers must: be multiples of
this limit.
* [[limits-minStorageBufferOffsetAlignment]]
pname:minStorageBufferOffsetAlignment is the minimum required:
alignment, in bytes, for the pname:offset member of the
sname:VkDescriptorBufferInfo structure for storage buffers.
When a descriptor of type ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC is updated, the
pname:offset must: be an integer multiple of this limit.
Similarly, dynamic offsets for storage buffers must: be multiples of
this limit.
* [[limits-minTexelOffset]] pname:minTexelOffset is the minimum offset
value for the code:ConstOffset image operand of any of the
code:OpImageSample* or code:OpImageFetch* image instructions.
* [[limits-maxTexelOffset]] pname:maxTexelOffset is the maximum offset
value for the code:ConstOffset image operand of any of the
code:OpImageSample* or code:OpImageFetch* image instructions.
* [[limits-minTexelGatherOffset]] pname:minTexelGatherOffset is the
minimum offset value for the code:Offset or code:ConstOffsets image
operands of any of the code:OpImage*code:Gather image instructions.
* [[limits-maxTexelGatherOffset]] pname:maxTexelGatherOffset is the
maximum offset value for the code:Offset or code:ConstOffsets image
operands of any of the code:OpImage*code:Gather image instructions.
* [[limits-minInterpolationOffset]] pname:minInterpolationOffset is the
minimum negative offset value for the code:offset operand of the
code:InterpolateAtOffset extended instruction.
* [[limits-maxInterpolationOffset]] pname:maxInterpolationOffset is the
maximum positive offset value for the code:offset operand of the
code:InterpolateAtOffset extended instruction.
* [[limits-subPixelInterpolationOffsetBits]]
pname:subPixelInterpolationOffsetBits is the number of subpixel
fractional bits that the code:x and code:y offsets to the
code:InterpolateAtOffset extended instruction may: be rounded to as
fixed-point values.
* [[limits-maxFramebufferWidth]] pname:maxFramebufferWidth is the maximum
width for a framebuffer.
The pname:width member of the sname:VkFramebufferCreateInfo structure
must: be less than or equal to this limit.
* [[limits-maxFramebufferHeight]] pname:maxFramebufferHeight is the
maximum height for a framebuffer.
The pname:height member of the sname:VkFramebufferCreateInfo structure
must: be less than or equal to this limit.
* [[limits-maxFramebufferLayers]] pname:maxFramebufferLayers is the
maximum layer count for a layered framebuffer.
The pname:layers member of the sname:VkFramebufferCreateInfo structure
must: be less than or equal to this limit.
* [[limits-framebufferColorSampleCounts]]
pname:framebufferColorSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the color sample counts that are
supported for all framebuffer color attachments with floating- or
fixed-point formats.
There is no limit that specifies the color sample counts that are
supported for all color attachments with integer formats.
* [[limits-framebufferDepthSampleCounts]]
pname:framebufferDepthSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the supported depth sample counts
for all framebuffer depth/stencil attachments, when the format includes
a depth component.
* pname:framebufferStencilSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the supported stencil sample
counts for all framebuffer depth/stencil attachments, when the format
includes a stencil component.
* pname:framebufferNoAttachmentsSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the supported sample counts for a
framebuffer with no attachments.
* [[limits-maxColorAttachments]] pname:maxColorAttachments is the maximum
number of color attachments that can: be used by a subpass in a render
pass.
The pname:colorAttachmentCount member of the sname:VkSubpassDescription
structure must: be less than or equal to this limit.
* [[limits-sampledImageColorSampleCounts]]
pname:sampledImageColorSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the sample counts supported for
all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a non-integer color
format.
* [[limits-sampledImageIntegerSampleCounts]]
pname:sampledImageIntegerSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the sample counts supported for
all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and an integer color
format.
* [[limits-sampledImageDepthSampleCounts]]
pname:sampledImageDepthSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the sample counts supported for
all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a depth format.
* [[limits-sampledImageStencilSampleCounts]]
pname:sampledImageStencilSampleCounts is a bitmask^1^ of
elink:VkSampleCountFlagBits indicating the sample supported for all 2D
images created with ename:VK_IMAGE_TILING_OPTIMAL, pname:usage
containing ename:VK_IMAGE_USAGE_SAMPLED_BIT, and a stencil format.
* [[limits-storageImageSampleCounts]] pname:storageImageSampleCounts is a
bitmask^1^ of elink:VkSampleCountFlagBits indicating the sample counts
supported for all 2D images created with ename:VK_IMAGE_TILING_OPTIMAL,
and pname:usage containing ename:VK_IMAGE_USAGE_STORAGE_BIT.
* [[limits-maxSampleMaskWords]] pname:maxSampleMaskWords is the maximum
number of array elements of a variable decorated with the
code:SampleMask built-in decoration.
* [[limits-timestampComputeAndGraphics]] pname:timestampComputeAndGraphics
specifies support for timestamps on all graphics and compute queues.
If this limit is set to ename:VK_TRUE, all queues that advertise the
ename:VK_QUEUE_GRAPHICS_BIT or ename:VK_QUEUE_COMPUTE_BIT in the
sname:VkQueueFamilyProperties::pname:queueFlags support
sname:VkQueueFamilyProperties::pname:timestampValidBits of at least 36.
See <<queries-timestamps, Timestamp Queries>>.
* [[limits-timestampPeriod]] pname:timestampPeriod is the number of
nanoseconds required: for a timestamp query to be incremented by 1.
See <<queries-timestamps, Timestamp Queries>>.
* [[limits-maxClipDistances]] pname:maxClipDistances is the maximum number
of clip distances that can: be used in a single shader stage.
The size of any array declared with the code:ClipDistance built-in
decoration in a shader module must: be less than or equal to this limit.
* [[limits-maxCullDistances]] pname:maxCullDistances is the maximum number
of cull distances that can: be used in a single shader stage.
The size of any array declared with the code:CullDistance built-in
decoration in a shader module must: be less than or equal to this limit.
* [[limits-maxCombinedClipAndCullDistances]]
pname:maxCombinedClipAndCullDistances is the maximum combined number of
clip and cull distances that can: be used in a single shader stage.
The sum of the sizes of any pair of arrays declared with the
code:ClipDistance and code:CullDistance built-in decoration used by a
single shader stage in a shader module must: be less than or equal to
this limit.
* [[limits-discreteQueuePriorities]] pname:discreteQueuePriorities is the
number of discrete priorities that can: be assigned to a queue based on
the value of each member of
sname:VkDeviceQueueCreateInfo::pname:pQueuePriorities.
This must: be at 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>>.
* [[limits-pointSizeRange]] pname:pointSizeRange[2] is the range
[eq]#[pname:minimum,pname:maximum]# of supported sizes for points.
Values written to variables decorated with the code:PointSize built-in
decoration are clamped to this range.
* [[limits-lineWidthRange]] pname:lineWidthRange[2] is the range
[eq]#[pname:minimum,pname: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.
* [[limits-pointSizeGranularity]] pname:pointSizeGranularity is the
granularity of supported point sizes.
Not all point sizes in the range defined by pname:pointSizeRange are
supported.
This limit specifies the granularity (or increment) between successive
supported point sizes.
* [[limits-lineWidthGranularity]] pname:lineWidthGranularity is the
granularity of supported line widths.
Not all line widths in the range defined by pname:lineWidthRange are
supported.
This limit specifies the granularity (or increment) between successive
supported line widths.
* [[limits-strictLines]] pname:strictLines specifies whether lines are
rasterized according to the preferred method of rasterization.
If set to ename:VK_FALSE, lines may: be rasterized under a relaxed set
of rules.
If set to ename:VK_TRUE, lines are rasterized as per the strict
definition.
See <<primsrast-lines-basic,Basic Line Segment Rasterization>>.
* [[limits-standardSampleLocations]] pname:standardSampleLocations
specifies whether rasterization uses the standard sample locations as
documented in <<primsrast-multisampling,Multisampling>>.
If set to ename:VK_TRUE, the implementation uses the documented sample
locations.
If set to ename:VK_FALSE, the implementation may: use different sample
locations.
* [[limits-optimalBufferCopyOffsetAlignment]]
pname:optimalBufferCopyOffsetAlignment is the optimal buffer offset
alignment in bytes for fname:vkCmdCopyBufferToImage and
fname:vkCmdCopyImageToBuffer.
The per texel alignment requirements are enforced, but applications
should: use the optimal alignment for optimal performance and power use.
* [[limits-optimalBufferCopyRowPitchAlignment]]
pname:optimalBufferCopyRowPitchAlignment is the optimal buffer row pitch
alignment in bytes for fname:vkCmdCopyBufferToImage and
fname:vkCmdCopyImageToBuffer.
Row pitch is the number of bytes between texels with the same X
coordinate in adjacent rows (Y coordinates differ by one).
The per texel alignment requirements are enforced, but applications
should: use the optimal alignment for optimal performance and power use.
* [[limits-nonCoherentAtomSize]] pname:nonCoherentAtomSize is the size and
alignment in bytes that bounds concurrent access to
<<memory-device-hostaccess, host-mapped device memory>>.
// refBody VkPhysicalDeviceLimits
1::
For all bitmasks of elink:VkSampleCountFlagBits, 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 flink:vkGetPhysicalDeviceImageFormatProperties as
described in <<features-supported-sample-counts, Supported Sample
Counts>>.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceLimits.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkSampleCountFlagBits',desc='Bitmask specifying sample counts supported for an image used for storage operations',type='enums']
--
Bits which may: be set in the sample count limits returned by
slink:VkPhysicalDeviceLimits, as well as in other queries and structures
representing image sample counts, are:
2019-04-16 12:19:43 +00:00
include::{generated}/api/enums/VkSampleCountFlagBits.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* ename:VK_SAMPLE_COUNT_1_BIT specifies an image with one sample per
pixel.
* ename:VK_SAMPLE_COUNT_2_BIT specifies an image with 2 samples per pixel.
* ename:VK_SAMPLE_COUNT_4_BIT specifies an image with 4 samples per pixel.
* ename:VK_SAMPLE_COUNT_8_BIT specifies an image with 8 samples per pixel.
* ename:VK_SAMPLE_COUNT_16_BIT specifies an image with 16 samples per
pixel.
* ename:VK_SAMPLE_COUNT_32_BIT specifies an image with 32 samples per
pixel.
* ename:VK_SAMPLE_COUNT_64_BIT specifies an image with 64 samples per
pixel.
--
[open,refpage='VkSampleCountFlags',desc='Bitmask of VkSampleCountFlagBits',type='flags']
--
2019-04-16 12:19:43 +00:00
include::{generated}/api/flags/VkSampleCountFlags.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
tname:VkSampleCountFlags is a bitmask type for setting a mask of zero or
more elink:VkSampleCountFlagBits.
--
ifdef::VK_KHR_push_descriptor[]
[open,refpage='VkPhysicalDevicePushDescriptorPropertiesKHR',desc='Structure describing push descriptor limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDevicePushDescriptorPropertiesKHR structure is defined
as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDevicePushDescriptorPropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDevicePushDescriptorPropertiesKHR
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxPushDescriptors]] pname:maxPushDescriptors is the maximum
number of descriptors that can: be used in a descriptor set created with
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR set.
If the sname:VkPhysicalDevicePushDescriptorPropertiesKHR structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDevicePushDescriptorPropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_KHR_push_descriptor[]
ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
[open,refpage='VkPhysicalDeviceMultiviewProperties',desc='Structure describing multiview limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceMultiviewProperties structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceMultiviewProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
ifdef::VK_KHR_multiview[]
or the equivalent
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceMultiviewPropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
endif::VK_KHR_multiview[]
The members of the sname:VkPhysicalDeviceMultiviewProperties structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxMultiviewViewCount]] pname:maxMultiviewViewCount is one
greater than the maximum view index that can: be used in a subpass.
* [[limits-maxMultiviewInstanceIndex]] pname:maxMultiviewInstanceIndex is
the maximum valid value of instance index allowed to be generated by a
drawing command recorded within a subpass of a multiview render pass
instance.
If the sname:VkPhysicalDeviceMultiviewProperties structure is included in
the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceMultiviewProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_KHR_shader_float_controls[]
[open,refpage='VkPhysicalDeviceFloatControlsPropertiesKHR',desc='Structure describing properties supported by VK_KHR_shader_float_controls',type='structs']
--
The members of the sname:VkPhysicalDeviceFloatControlsPropertiesKHR
structure describe the following implementation-dependent limits:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceFloatControlsPropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* [[features-separateDenormSettings]] pname:separateDenormSettings is a
boolean value indicating whether the implementation supports separate
settings for 16-bit and 64-bit denormals.
* [[features-separateRoundingModeSettings]]
pname:separateRoundingModeSettings is a boolean value indicating whether
the implementation supports separate rounding modes for 16-bit and
64-bit floating point instructions.
* [[features-shaderSignedZeroInfNanPreserveFloat16]]
pname:shaderSignedZeroInfNanPreserveFloat16 is a boolean value
indicating whether sign of a zero, [eq]##Nan##s and
latexmath:[\pm\infty] can: be preserved in 16-bit floating-point
computations.
It also indicates whether the code:SignedZeroInfNanPreserve execution
mode can: be used for 16-bit floating-point types.
* [[features-shaderSignedZeroInfNanPreserveFloat32]]
pname:shaderSignedZeroInfNanPreserveFloat32 is a boolean value
indicating whether sign of a zero, [eq]##Nan##s and
latexmath:[\pm\infty] can: be preserved in 32-bit floating-point
computations.
It also indicates whether the code:SignedZeroInfNanPreserve execution
mode can: be used for 32-bit floating-point types.
* [[features-shaderSignedZeroInfNanPreserveFloat64]]
pname:shaderSignedZeroInfNanPreserveFloat64 is a boolean value
indicating whether sign of a zero, [eq]##Nan##s and
latexmath:[\pm\infty] can: be preserved in 64-bit floating-point
computations.
It also indicates whether the code:SignedZeroInfNanPreserve execution
mode can: be used for 64-bit floating-point types.
* [[features-shaderDenormPreserveFloat16]]
pname:shaderDenormPreserveFloat16 is a boolean value indicating whether
denormals can: be preserved in 16-bit floating-point computations.
It also indicates whether the code:DenormPreserve execution mode can: be
used for 16-bit floating-point types.
* [[features-shaderDenormPreserveFloat32]]
pname:shaderDenormPreserveFloat32 is a boolean value indicating whether
denormals can: be preserved in 32-bit floating-point computations.
It also indicates whether the code:DenormPreserve execution mode can: be
used for 32-bit floating-point types.
* [[features-shaderDenormPreserveFloat64]]
pname:shaderDenormPreserveFloat64 is a boolean value indicating whether
denormals can: be preserved in 64-bit floating-point computations.
It also indicates whether the code:DenormPreserve execution mode can: be
used for 64-bit floating-point types.
* [[features-shaderDenormFlushToZeroFloat16]]
pname:shaderDenormFlushToZeroFloat16 is a boolean value indicating
whether denormals can: be flushed to zero in 16-bit floating-point
computations.
It also indicates whether the code:DenormFlushToZero execution mode can:
be used for 16-bit floating-point types.
* [[features-shaderDenormFlushToZeroFloat32]]
pname:shaderDenormFlushToZeroFloat32 is a boolean value indicating
whether denormals can: be flushed to zero in 32-bit floating-point
computations.
It also indicates whether the code:DenormFlushToZero execution mode can:
be used for 32-bit floating-point types.
* [[features-shaderDenormFlushToZeroFloat64]]
pname:shaderDenormFlushToZeroFloat64 is a boolean value indicating
whether denormals can: be flushed to zero in 64-bit floating-point
computations.
It also indicates whether the code:DenormFlushToZero execution mode can:
be used for 64-bit floating-point types.
* [[features-shaderRoundingModeRTEFloat16]]
pname:shaderRoundingModeRTEFloat16 is a boolean value indicating whether
an implementation supports the round-to-nearest-even rounding mode for
16-bit floating-point arithmetic and conversion instructions.
It also indicates whether the code:RoundingModeRTE execution mode can:
be used for 16-bit floating-point types.
* [[features-shaderRoundingModeRTEFloat32]]
pname:shaderRoundingModeRTEFloat32 is a boolean value indicating whether
an implementation supports the round-to-nearest-even rounding mode for
32-bit floating-point arithmetic and conversion instructions.
It also indicates whether the code:RoundingModeRTE execution mode can:
be used for 32-bit floating-point types.
* [[features-shaderRoundingModeRTEFloat64]]
pname:shaderRoundingModeRTEFloat64 is a boolean value indicating whether
an implementation supports the round-to-nearest-even rounding mode for
64-bit floating-point arithmetic and conversion instructions.
It also indicates whether the code:RoundingModeRTE execution mode can:
be used for 64-bit floating-point types.
* [[features-shaderRoundingModeRTZFloat16]]
pname:shaderRoundingModeRTZFloat16 is a boolean value indicating whether
an implementation supports the round-towards-zero rounding mode for
16-bit floating-point arithmetic and conversion instructions.
It also indicates whether the code:RoundingModeRTZ execution mode can:
be used for 16-bit floating-point types.
* [[features-shaderRoundingModeRTZFloat32]]
pname:shaderRoundingModeRTZFloat32 is a boolean value indicating whether
an implementation supports the round-towards-zero rounding mode for
32-bit floating-point arithmetic and conversion instructions.
It also indicates whether the code:RoundingModeRTZ execution mode can:
be used for 32-bit floating-point types.
* [[features-shaderRoundingModeRTZFloat64]]
pname:shaderRoundingModeRTZFloat64 is a boolean value indicating whether
an implementation supports the round-towards-zero rounding mode for
64-bit floating-point arithmetic and conversion instructions.
It also indicates whether the code:RoundingModeRTZ execution mode can:
be used for 64-bit floating-point types.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
Implementations may not be able to control behavior of denorms for
floating-point atomics.
This needs to be taken into account when such atomics will be added to
Vulkan.
====
endif::editing-notes[]
If the sname:VkPhysicalDeviceFloatControlsPropertiesKHR structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceFloatControlsPropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_KHR_shader_float_controls[]
ifdef::VK_EXT_discard_rectangles[]
[open,refpage='VkPhysicalDeviceDiscardRectanglePropertiesEXT',desc='Structure describing discard rectangle limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceDiscardRectanglePropertiesEXT structure is defined
as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceDiscardRectanglePropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceDiscardRectanglePropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxDiscardRectangles]] pname:maxDiscardRectangles is the
maximum number of active discard rectangles that can: be specified.
If the sname:VkPhysicalDeviceDiscardRectanglePropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceDiscardRectanglePropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_discard_rectangles[]
ifdef::VK_EXT_sample_locations[]
[open,refpage='VkPhysicalDeviceSampleLocationsPropertiesEXT',desc='Structure describing sample location limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceSampleLocationsPropertiesEXT structure is defined
as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceSampleLocationsPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceSampleLocationsPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-sampleLocationSampleCounts]] pname:sampleLocationSampleCounts
is a bitmask of elink:VkSampleCountFlagBits indicating the sample counts
supporting custom sample locations.
* [[limits-maxSampleLocationGridSize]] pname:maxSampleLocationGridSize is
the maximum size of the pixel grid in which sample locations can: vary
that is supported for all sample counts in
pname:sampleLocationSampleCounts.
* [[limits-sampleLocationCoordinateRange]]
pname:sampleLocationCoordinateRange[2] is the range of supported sample
location coordinates.
* [[limits-sampleLocationSubPixelBits]] pname:sampleLocationSubPixelBits
is the number of bits of subpixel precision for sample locations.
* [[limits-variableSampleLocations]] pname:variableSampleLocations
specifies whether the sample locations used by all pipelines that will
be bound to a command buffer during a subpass must: match.
If set to ename:VK_TRUE, the implementation supports variable sample
locations in a subpass.
If set to ename:VK_FALSE, then the sample locations must: stay constant
in each subpass.
If the sname:VkPhysicalDeviceSampleLocationsPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceSampleLocationsPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_sample_locations[]
ifdef::VK_EXT_external_memory_host[]
[open,refpage='VkPhysicalDeviceExternalMemoryHostPropertiesEXT',desc='Structure describing external memory host pointer limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceExternalMemoryHostPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceExternalMemoryHostPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceExternalMemoryHostPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-minImportedHostPointerAlignment]]
pname:minImportedHostPointerAlignment is the minimum required:
alignment, in bytes, for the base address and size of host pointers that
can: be imported to a Vulkan memory object.
If the sname:VkPhysicalDeviceExternalMemoryHostPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceExternalMemoryHostPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_external_memory_host[]
ifdef::VK_NVX_multiview_per_view_attributes[]
[open,refpage='VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX',desc='Structure describing multiview limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX structure
is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the
sname:VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-perViewPositionAllComponents]]
pname:perViewPositionAllComponents is ename:VK_TRUE if the
implementation supports per-view position values that differ in
components other than the X component.
If the sname:VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX
structure is included in the pname:pNext chain of
slink:VkPhysicalDeviceProperties2, it is filled with the
implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_NVX_multiview_per_view_attributes[]
ifdef::VK_VERSION_1_1,VK_KHR_maintenance2[]
[open,refpage='VkPhysicalDevicePointClippingProperties',desc='Structure describing the point clipping behavior supported by an implementation',type='structs']
--
The sname:VkPhysicalDevicePointClippingProperties structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDevicePointClippingProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
ifdef::VK_KHR_maintenance2[]
or the equivalent
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDevicePointClippingPropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
endif::VK_KHR_maintenance2[]
The members of the sname:VkPhysicalDevicePointClippingProperties structure
describe the following implementation-dependent limit:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-pointClipping]] pname:pointClippingBehavior is the point
clipping behavior supported by the implementation, and is of type
elink:VkPointClippingBehavior.
If the sname:VkPhysicalDevicePointClippingProperties structure is included
in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDevicePointClippingProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_VERSION_1_1,VK_KHR_maintenance2[]
ifdef::VK_VERSION_1_1[]
[open,refpage='VkPhysicalDeviceSubgroupProperties',desc='Structure describing subgroup support for an implementation',type='structs']
--
The sname:VkPhysicalDeviceSubgroupProperties structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceSubgroupProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceSubgroupProperties structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:subgroupSize is the number of invocations in each subgroup.
This will match any <<interfaces-builtin-variables-sgs,
code:SubgroupSize>> decorated variable used in any shader module created
on this device.
pname:subgroupSize is at least 1 if any of the physical device's queues
support ename:VK_QUEUE_GRAPHICS_BIT or ename:VK_QUEUE_COMPUTE_BIT.
* pname:supportedStages is a bitfield of elink:VkShaderStageFlagBits
describing the shader stages that subgroup operations are supported in.
pname:supportedStages will have the ename:VK_SHADER_STAGE_COMPUTE_BIT
bit set if any of the physical device's queues support
ename:VK_QUEUE_COMPUTE_BIT.
* pname:supportedOperations is a bitmask of
elink:VkSubgroupFeatureFlagBits specifying the sets of subgroup
operations supported on this device.
pname:supportedOperations will have the
ename:VK_SUBGROUP_FEATURE_BASIC_BIT bit set if any of the physical
device's queues support ename:VK_QUEUE_GRAPHICS_BIT or
ename:VK_QUEUE_COMPUTE_BIT.
* pname:quadOperationsInAllStages is a boolean that specifies whether
<<features-subgroup-quad,quad subgroup operations>> are available in all
stages, or are restricted to fragment and compute stages.
If the sname:VkPhysicalDeviceSubgroupProperties structure is included in the
pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled with
the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceSubgroupProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkSubgroupFeatureFlagBits',desc='Enum describing what subgroup operations are supported',type='enums']
--
Bits which can: be set in
slink:VkPhysicalDeviceSubgroupProperties::pname:supportedOperations to
specify supported subgroup operations are:
2019-04-16 12:19:43 +00:00
include::{generated}/api/enums/VkSubgroupFeatureFlagBits.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* [[features-subgroup-basic]] ename:VK_SUBGROUP_FEATURE_BASIC_BIT
specifies the device will accept SPIR-V shader modules that contain the
code:GroupNonUniform capability.
* [[features-subgroup-vote]] ename:VK_SUBGROUP_FEATURE_VOTE_BIT specifies
the device will accept SPIR-V shader modules that contain the
code:GroupNonUniformVote capability.
* [[features-subgroup-arithmetic]]
ename:VK_SUBGROUP_FEATURE_ARITHMETIC_BIT specifies the device will
accept SPIR-V shader modules that contain the
code:GroupNonUniformArithmetic capability.
* [[features-subgroup-ballot]] ename:VK_SUBGROUP_FEATURE_BALLOT_BIT
specifies the device will accept SPIR-V shader modules that contain the
code:GroupNonUniformBallot capability.
* [[features-subgroup-shuffle]] ename:VK_SUBGROUP_FEATURE_SHUFFLE_BIT
specifies the device will accept SPIR-V shader modules that contain the
code:GroupNonUniformShuffle capability.
* [[features-subgroup-shuffle-relative]]
ename:VK_SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT specifies the device will
accept SPIR-V shader modules that contain the
code:GroupNonUniformShuffleRelative capability.
* [[features-subgroup-clustered]] ename:VK_SUBGROUP_FEATURE_CLUSTERED_BIT
specifies the device will accept SPIR-V shader modules that contain the
code:GroupNonUniformClustered capability.
* [[features-subgroup-quad]] ename:VK_SUBGROUP_FEATURE_QUAD_BIT specifies
the device will accept SPIR-V shader modules that contain the
code:GroupNonUniformQuad capability.
ifdef::VK_NV_shader_subgroup_partitioned[]
* [[features-subgroup-partitioned]]
ename:VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV specifies the device will
accept SPIR-V shader modules that contain the
code:GroupNonUniformPartitionedNV capability.
endif::VK_NV_shader_subgroup_partitioned[]
--
[open,refpage='VkSubgroupFeatureFlags',desc='Bitmask of VkSubgroupFeatureFlagBits',type='flags']
--
2019-04-16 12:19:43 +00:00
include::{generated}/api/flags/VkSubgroupFeatureFlags.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
tname:VkSubgroupFeatureFlags is a bitmask type for setting a mask of zero or
more elink:VkSubgroupFeatureFlagBits.
--
endif::VK_VERSION_1_1[]
ifdef::VK_EXT_blend_operation_advanced[]
[open,refpage='VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT',desc='Structure describing advanced blending limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-advancedBlendMaxColorAttachments]]
pname:advancedBlendMaxColorAttachments is one greater than the highest
color attachment index that can: be used in a subpass, for a pipeline
that uses an <<framebuffer-blend-advanced,advanced blend operation>>.
* [[limits-advancedBlendIndependentBlend]]
pname:advancedBlendIndependentBlend specifies whether advanced blend
operations can: vary per-attachment.
* [[limits-advancedBlendNonPremultipliedSrcColor]]
pname:advancedBlendNonPremultipliedSrcColor specifies whether the source
color can: be treated as non-premultiplied.
If this is ename:VK_FALSE, then
slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT::pname:srcPremultiplied
must: be ename:VK_TRUE.
* [[limits-advancedBlendNonPremultipliedDstColor]]
pname:advancedBlendNonPremultipliedDstColor specifies whether the
destination color can: be treated as non-premultiplied.
If this is ename:VK_FALSE, then
slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT::pname:dstPremultiplied
must: be ename:VK_TRUE.
* [[limits-advancedBlendCorrelatedOverlap]]
pname:advancedBlendCorrelatedOverlap specifies whether the overlap mode
can: be treated as correlated.
If this is ename:VK_FALSE, then
slink:VkPipelineColorBlendAdvancedStateCreateInfoEXT::pname:blendOverlap
must: be ename:VK_BLEND_OVERLAP_UNCORRELATED_EXT.
* [[limits-advancedBlendAllOperations]] pname:advancedBlendAllOperations
specifies whether all advanced blend operation enums are supported.
See the valid usage of slink:VkPipelineColorBlendAttachmentState.
If the sname:VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT structure
is included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2,
it is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_blend_operation_advanced[]
ifdef::VK_EXT_vertex_attribute_divisor[]
[open,refpage='VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT',desc='Structure describing max value of vertex attribute divisor that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxVertexAttribDivisor]] pname:maxVertexAttribDivisor is the
maximum value of the number of instances that will repeat the value of
vertex attribute data when instanced rendering is enabled.
If the sname:VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT structure
is included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2,
it is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_vertex_attribute_divisor[]
ifdef::VK_EXT_sampler_filter_minmax[]
[open,refpage='VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT',desc='Structure describing sampler filter minmax limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-filterMinmaxSingleComponentFormats]]
pname:filterMinmaxSingleComponentFormats is a boolean value indicating
whether a minimum set of required formats support min/max filtering.
* [[limits-filterMinmaxImageComponentMapping]]
pname:filterMinmaxImageComponentMapping is a boolean value indicating
whether the implementation supports non-identity component mapping of
the image when doing min/max filtering.
If the sname:VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
If pname:filterMinmaxSingleComponentFormats is ename:VK_TRUE, the following
formats must: support the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT feature with
ename:VK_IMAGE_TILING_OPTIMAL, if they support
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT.
* ename:VK_FORMAT_R8_UNORM
* ename:VK_FORMAT_R8_SNORM
* ename:VK_FORMAT_R16_UNORM
* ename:VK_FORMAT_R16_SNORM
* ename:VK_FORMAT_R16_SFLOAT
* ename:VK_FORMAT_R32_SFLOAT
* ename:VK_FORMAT_D16_UNORM
* ename:VK_FORMAT_X8_D24_UNORM_PACK32
* ename:VK_FORMAT_D32_SFLOAT
* ename:VK_FORMAT_D16_UNORM_S8_UINT
* ename:VK_FORMAT_D24_UNORM_S8_UINT
* ename:VK_FORMAT_D32_SFLOAT_S8_UINT
If the format is a depth/stencil format, this bit only specifies that the
depth aspect (not the stencil aspect) of an image of this format supports
min/max filtering, and that min/max filtering of the depth aspect is
supported when depth compare is disabled in the sampler.
If pname:filterMinmaxImageComponentMapping is ename:VK_FALSE the component
mapping of the image view used with min/max filtering must: have been
created with the pname:r component set to
ename:VK_COMPONENT_SWIZZLE_IDENTITY.
Only the pname:r component of the sampled image value is defined and the
other component values are undefined:.
If pname:filterMinmaxImageComponentMapping is ename:VK_TRUE this restriction
does not apply and image component mapping works as normal.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_sampler_filter_minmax[]
ifdef::VK_VERSION_1_1[]
[open,refpage='VkPhysicalDeviceProtectedMemoryProperties',desc='Structure describing protected memory properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceProtectedMemoryProperties structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceProtectedMemoryProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
2019-03-17 13:05:46 +00:00
* pname:protectedNoFault specifies the behavior of the implementation when
<<memory-protected-access-rules, protected memory access rules>> are
broken.
If pname:protectedNoFault is ename:VK_TRUE, breaking those rules will
not result in process termination or device loss.
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
If the sname:VkPhysicalDeviceProtectedMemoryProperties structure is included
in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with a value indicating the implementation-dependent behavior.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceProtectedMemoryProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_VERSION_1_1[]
ifdef::VK_VERSION_1_1,VK_KHR_maintenance3[]
[open,refpage='VkPhysicalDeviceMaintenance3Properties',desc='Structure describing descriptor set properties',type='structs']
--
The sname:VkPhysicalDeviceMaintenance3Properties structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceMaintenance3Properties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
ifdef::VK_KHR_maintenance3[]
or the equivalent
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceMaintenance3PropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
endif::VK_KHR_maintenance3[]
The members of the sname:VkPhysicalDeviceMaintenance3Properties structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxPerSetDescriptors]] pname:maxPerSetDescriptors is a maximum
number of descriptors (summed over all descriptor types) in a single
descriptor set that is guaranteed to satisfy any
implementation-dependent constraints on the size of a descriptor set
itself.
Applications can: query whether a descriptor set that goes beyond this
limit is supported using flink:vkGetDescriptorSetLayoutSupport.
* [[limits-maxMemoryAllocationSize]] pname:maxMemoryAllocationSize is the
maximum size of a memory allocation that can: be created, even if there
is more space available in the heap.
If the sname:VkPhysicalDeviceMaintenance3Properties structure is included in
the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceMaintenance3Properties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_VERSION_1_1,VK_KHR_maintenance3[]
ifdef::VK_NV_mesh_shader[]
[open,refpage='VkPhysicalDeviceMeshShaderPropertiesNV',desc='Structure describing mesh shading properties',type='structs']
--
The sname:VkPhysicalDeviceMeshShaderPropertiesNV structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceMeshShaderPropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceMeshShaderPropertiesNV structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:maxDrawMeshTasksCount is the maximum number of local workgroups
that can: be launched by a single draw mesh tasks command.
See <<drawing-mesh-shading>>.
* pname:maxTaskWorkGroupInvocations is the maximum total number of task
shader invocations in a single local workgroup.
The product of the X, Y, and Z sizes as specified by the code:LocalSize
execution mode in shader modules and by the object decorated by the
code:WorkgroupSize decoration must: be less than or equal to this limit.
* pname:maxTaskWorkGroupSize[3] is the maximum size of a local task
workgroup.
These three values represent the maximum local workgroup size in the X,
Y, and Z dimensions, respectively.
The pname:x, pname:y, and pname:z sizes specified by the code:LocalSize
execution mode and by the object decorated by the code:WorkgroupSize
decoration in shader modules must: be less than or equal to the
corresponding limit.
* pname:maxTaskTotalMemorySize is the maximum number of bytes that the
task shader can use in total for shared and output memory combined.
* pname:maxTaskOutputCount is the maximum number of output tasks a single
task shader workgroup can emit.
* pname:maxMeshWorkGroupInvocations is the maximum total number of mesh
shader invocations in a single local workgroup.
The product of the X, Y, and Z sizes as specified by the code:LocalSize
execution mode in shader modules and by the object decorated by the
code:WorkgroupSize decoration must: be less than or equal to this limit.
* pname:maxMeshWorkGroupSize[3] is the maximum size of a local mesh
workgroup.
These three values represent the maximum local workgroup size in the X,
Y, and Z dimensions, respectively.
The pname:x, pname:y, and pname:z sizes specified by the code:LocalSize
execution mode and by the object decorated by the code:WorkgroupSize
decoration in shader modules must: be less than or equal to the
corresponding limit.
* pname:maxMeshTotalMemorySize is the maximum number of bytes that the
mesh shader can use in total for shared and output memory combined.
* pname:maxMeshOutputVertices is the maximum number of vertices a mesh
shader output can store.
* pname:maxMeshOutputPrimitives is the maximum number of primitives a mesh
shader output can store.
* pname:maxMeshMultiviewViewCount is the maximum number of multi-view
views a mesh shader can use.
* pname:meshOutputPerVertexGranularity is the granularity with which mesh
vertex outputs are allocated.
The value can be used to compute the memory size used by the mesh
shader, which must be less than or equal to
pname:maxMeshTotalMemorySize.
* pname:meshOutputPerPrimitiveGranularity is the granularity with which
mesh outputs qualified as per-primitive are allocated.
The value can be used to compute the memory size used by the mesh
shader, which must be less than or equal to
pname:maxMeshTotalMemorySize.
If the sname:VkPhysicalDeviceMeshShaderPropertiesNV structure is included in
the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceMeshShaderPropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_NV_mesh_shader[]
ifdef::VK_EXT_descriptor_indexing[]
[open,refpage='VkPhysicalDeviceDescriptorIndexingPropertiesEXT',desc='Structure describing descriptor indexing properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceDescriptorIndexingPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceDescriptorIndexingPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceDescriptorIndexingPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxUpdateAfterBindDescriptorsInAllPools]]
pname:maxUpdateAfterBindDescriptorsInAllPools is the maximum number of
descriptors (summed over all descriptor types) that can: be created
across all pools that are created with the
ename:VK_DESCRIPTOR_POOL_CREATE_UPDATE_AFTER_BIND_BIT_EXT bit set.
Pool creation may: fail when this limit is exceeded, or when the space
this limit represents is unable to satisfy a pool creation due to
fragmentation.
* [[limits-shaderUniformBufferArrayNonUniformIndexingNative]]
pname:shaderUniformBufferArrayNonUniformIndexingNative is a boolean
value indicating whether uniform buffer descriptors natively support
nonuniform indexing.
If this is ename:VK_FALSE, then a single dynamic instance of an
instruction that nonuniformly indexes an array of uniform buffers may:
execute multiple times in order to access all the descriptors.
* [[limits-shaderSampledImageArrayNonUniformIndexingNative]]
pname:shaderSampledImageArrayNonUniformIndexingNative is a boolean value
indicating whether sampler and image descriptors natively support
nonuniform indexing.
If this is ename:VK_FALSE, then a single dynamic instance of an
instruction that nonuniformly indexes an array of samplers or images
may: execute multiple times in order to access all the descriptors.
* [[limits-shaderStorageBufferArrayNonUniformIndexingNative]]
pname:shaderStorageBufferArrayNonUniformIndexingNative is a boolean
value indicating whether storage buffer descriptors natively support
nonuniform indexing.
If this is ename:VK_FALSE, then a single dynamic instance of an
instruction that nonuniformly indexes an array of storage buffers may:
execute multiple times in order to access all the descriptors.
* [[limits-shaderStorageImageArrayNonUniformIndexingNative]]
pname:shaderStorageImageArrayNonUniformIndexingNative is a boolean value
indicating whether storage image descriptors natively support nonuniform
indexing.
If this is ename:VK_FALSE, then a single dynamic instance of an
instruction that nonuniformly indexes an array of storage images may:
execute multiple times in order to access all the descriptors.
* [[limits-shaderInputAttachmentArrayNonUniformIndexingNative]]
pname:shaderInputAttachmentArrayNonUniformIndexingNative is a boolean
value indicating whether input attachment descriptors natively support
nonuniform indexing.
If this is ename:VK_FALSE, then a single dynamic instance of an
instruction that nonuniformly indexes an array of input attachments may:
execute multiple times in order to access all the descriptors.
* [[limits-robustBufferAccessUpdateAfterBind]]
pname:robustBufferAccessUpdateAfterBind is a boolean value indicating
whether <<features-robustBufferAccess, pname:robustBufferAccess>> can:
be enabled in a device simultaneously with
pname:descriptorBindingUniformBufferUpdateAfterBind,
pname:descriptorBindingStorageBufferUpdateAfterBind,
pname:descriptorBindingUniformTexelBufferUpdateAfterBind, and/or
pname:descriptorBindingStorageTexelBufferUpdateAfterBind.
If this is ename:VK_FALSE, then either pname:robustBufferAccess must: be
disabled or all of these update-after-bind features must: be disabled.
* [[limits-quadDivergentImplicitLod]] pname:quadDivergentImplicitLod is a
boolean value indicating whether implicit level of detail calculations
for image operations have well-defined results when the image and/or
sampler objects used for the instruction are not uniform within a quad.
See <<textures-derivative-image-operations,Derivative Image
Operations>>.
* [[limits-maxPerStageDescriptorUpdateAfterBindSamplers]]
pname:maxPerStageDescriptorUpdateAfterBindSamplers is similar to
pname:maxPerStageDescriptorSamplers but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxPerStageDescriptorUpdateAfterBindUniformBuffers]]
pname:maxPerStageDescriptorUpdateAfterBindUniformBuffers is similar to
pname:maxPerStageDescriptorUniformBuffers but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxPerStageDescriptorUpdateAfterBindStorageBuffers]]
pname:maxPerStageDescriptorUpdateAfterBindStorageBuffers is similar to
pname:maxPerStageDescriptorStorageBuffers but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxPerStageDescriptorUpdateAfterBindSampledImages]]
pname:maxPerStageDescriptorUpdateAfterBindSampledImages is similar to
pname:maxPerStageDescriptorSampledImages but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxPerStageDescriptorUpdateAfterBindStorageImages]]
pname:maxPerStageDescriptorUpdateAfterBindStorageImages is similar to
pname:maxPerStageDescriptorStorageImages but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxPerStageDescriptorUpdateAfterBindInputAttachments]]
pname:maxPerStageDescriptorUpdateAfterBindInputAttachments is similar to
pname:maxPerStageDescriptorInputAttachments but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxPerStageUpdateAfterBindResources]]
pname:maxPerStageUpdateAfterBindResources is similar to
pname:maxPerStageResources but counts descriptors from descriptor sets
created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindSamplers]]
pname:maxDescriptorSetUpdateAfterBindSamplers is similar to
pname:maxDescriptorSetSamplers but counts descriptors from descriptor
sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindUniformBuffers]]
pname:maxDescriptorSetUpdateAfterBindUniformBuffers is similar to
pname:maxDescriptorSetUniformBuffers but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindUniformBuffersDynamic]]
pname:maxDescriptorSetUpdateAfterBindUniformBuffersDynamic is similar to
pname:maxDescriptorSetUniformBuffersDynamic but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindStorageBuffers]]
pname:maxDescriptorSetUpdateAfterBindStorageBuffers is similar to
pname:maxDescriptorSetStorageBuffers but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindStorageBuffersDynamic]]
pname:maxDescriptorSetUpdateAfterBindStorageBuffersDynamic is similar to
pname:maxDescriptorSetStorageBuffersDynamic but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindSampledImages]]
pname:maxDescriptorSetUpdateAfterBindSampledImages is similar to
pname:maxDescriptorSetSampledImages but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindStorageImages]]
pname:maxDescriptorSetUpdateAfterBindStorageImages is similar to
pname:maxDescriptorSetStorageImages but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
* [[limits-maxDescriptorSetUpdateAfterBindInputAttachments]]
pname:maxDescriptorSetUpdateAfterBindInputAttachments is similar to
pname:maxDescriptorSetInputAttachments but counts descriptors from
descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
If the sname:VkPhysicalDeviceDescriptorIndexingPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceDescriptorIndexingPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_inline_uniform_block[]
[open,refpage='VkPhysicalDeviceInlineUniformBlockPropertiesEXT',desc='Structure describing inline uniform block properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceInlineUniformBlockPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxInlineUniformBlockSize]] pname:maxInlineUniformBlockSize is
the maximum size in bytes of an <<descriptorsets-inlineuniformblock,
inline uniform block>> binding.
* [[limits-maxPerStageDescriptorInlineUniformBlocks]]
pname:maxPerStageDescriptorInlineUniformBlock is the maximum number of
inline uniform block bindings that can: be accessible to a single shader
stage in a pipeline layout.
Descriptor bindings with a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptor bindings in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
* [[limits-maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks]]
pname:maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks
ifndef::VK_EXT_descriptor_indexing[]
equals pname:maxPerStageDescriptorInlineUniformBlocks and is reserved
for future use.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_descriptor_indexing[]
is similar to pname:maxPerStageDescriptorInlineUniformBlocks but counts
descriptor bindings from descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
endif::VK_EXT_descriptor_indexing[]
* [[limits-maxDescriptorSetInlineUniformBlocks]]
pname:maxDescriptorSetInlineUniformBlocks is the maximum number of
inline uniform block bindings that can: be included in descriptor
bindings in a pipeline layout across all pipeline shader stages and
descriptor set numbers.
Descriptor bindings with a descriptor type of
ename:VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT count against this
limit.
ifdef::VK_EXT_descriptor_indexing[]
Only descriptor bindings in descriptor set layouts created without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set count against this limit.
endif::VK_EXT_descriptor_indexing[]
* [[limits-maxDescriptorSetUpdateAfterBindInlineUniformBlocks]]
pname:maxDescriptorSetUpdateAfterBindInlineUniformBlocks
ifndef::VK_EXT_descriptor_indexing[]
equals pname:maxDescriptorSetInlineUniformBlocks and is reserved for
future use.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_descriptor_indexing[]
is similar to pname:maxDescriptorSetInlineUniformBlocks but counts
descriptor bindings from descriptor sets created with or without the
ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
set.
endif::VK_EXT_descriptor_indexing[]
If the sname:VkPhysicalDeviceInlineUniformBlockPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceInlineUniformBlockPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_inline_uniform_block[]
ifdef::VK_EXT_conservative_rasterization[]
[open,refpage='VkPhysicalDeviceConservativeRasterizationPropertiesEXT',desc='Structure describing conservative raster properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceConservativeRasterizationPropertiesEXT structure
is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceConservativeRasterizationPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the
sname:VkPhysicalDeviceConservativeRasterizationPropertiesEXT structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-primitiveOverestimationSize]] pname:primitiveOverestimationSize
is the size in pixels the generating primitive is increased at each of
its edges during conservative rasterization overestimation mode.
Even with a size of 0.0, conservative rasterization overestimation rules
still apply and if any part of the pixel rectangle is covered by the
generating primitive, fragments are generated for the entire pixel.
However implementations may: make the pixel coverage area even more
conservative by increasing the size of the generating primitive.
* [[limits-maxExtraPrimitiveOverestimationSize]]
pname:maxExtraPrimitiveOverestimationSize is the maximum size in pixels
of extra overestimation the implementation supports in the pipeline
state.
A value of 0.0 means the implementation does not support any additional
overestimation of the generating primitive during conservative
rasterization.
A value above 0.0 allows the application to further increase the size of
the generating primitive during conservative rasterization
overestimation.
* [[limits-extraPrimitiveOverestimationSizeGranularity]]
pname:extraPrimitiveOverestimationSizeGranularity is the granularity of
extra overestimation that can be specified in the pipeline state between
0.0 and pname:maxExtraPrimitiveOverestimationSize inclusive.
A value of 0.0 means the implementation can use the smallest
representable non-zero value in the screen space pixel fixed-point grid.
* [[limits-primitiveUnderestimation]] pname:primitiveUnderestimation is
true if the implementation supports the
ename:VK_CONSERVATIVE_RASTERIZATION_MODE_UNDERESTIMATE_EXT conservative
rasterization mode in addition to
ename:VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT.
Otherwise the implementation only supports
ename:VK_CONSERVATIVE_RASTERIZATION_MODE_OVERESTIMATE_EXT.
* [[limits-conservativePointAndLineRasterization]]
pname:conservativePointAndLineRasterization is true if the
implementation supports conservative rasterization of point and line
primitives as well as triangle primitives.
Otherwise the implementation only supports triangle primitives.
* [[limits-degenerateTrianglesRasterized]]
pname:degenerateTrianglesRasterized is false if the implementation culls
primitives generated from triangles that become zero area after they are
quantized to the fixed-point rasterization pixel grid.
pname:degenerateTrianglesRasterized is true if these primitives are not
culled and the provoking vertex attributes and depth value are used for
the fragments.
The primitive area calculation is done on the primitive generated from
the clipped triangle if applicable.
Zero area primitives are backfacing and the application can: enable
backface culling if desired.
* [[limits-degenerateLinesRasterized]] pname:degenerateLinesRasterized is
false if the implementation culls lines that become zero length after
they are quantized to the fixed-point rasterization pixel grid.
pname:degenerateLinesRasterized is true if zero length lines are not
culled and the provoking vertex attributes and depth value are used for
the fragments.
* [[limits-fullyCoveredFragmentShaderInputVariable]]
pname:fullyCoveredFragmentShaderInputVariable is true if the
implementation supports the SPIR-V builtin fragment shader input
variable FullyCoveredEXT which specifies that conservative rasterization
is enabled and the fragment area is fully covered by the generating
primitive.
* [[limits-conservativeRasterizationPostDepthCoverage]]
ifdef::VK_EXT_post_depth_coverage[]
pname:conservativeRasterizationPostDepthCoverage is true if the
implementation supports conservative rasterization with the
<<shaders-fragment-earlytest-postdepthcoverage,code:PostDepthCoverage>>
execution mode enabled.
When supported the code:SampleMask built-in input variable will reflect
the coverage after the early per-fragment depth and stencil tests are
applied even when conservative rasterization is enabled.
Otherwise
<<shaders-fragment-earlytest-postdepthcoverage,code:PostDepthCoverage>>
execution mode must: not be used when conservative rasterization is
enabled.
endif::VK_EXT_post_depth_coverage[]
ifndef::VK_EXT_post_depth_coverage[]
pname:conservativeRasterizationPostDepthCoverage must: be false.
endif::VK_EXT_post_depth_coverage[]
If the sname:VkPhysicalDeviceConservativeRasterizationPropertiesEXT
structure is included in the pname:pNext chain of
slink:VkPhysicalDeviceProperties2, it is filled with the
implementation-dependent limits and properties.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceConservativeRasterizationPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_conservative_rasterization[]
ifdef::VK_EXT_fragment_density_map[]
[open,refpage='VkPhysicalDeviceFragmentDensityMapPropertiesEXT',desc='Structure describing fragment density map properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceFragmentDensityMapPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceFragmentDensityMapPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceFragmentDensityMapPropertiesEXT
structure describe the following implementation-dependent limits:
* [[limits-minfragmentdensitytexelsize]] pname:minFragmentDensityTexelSize
is the minimum <<glossary-fragment-density-texel-size,fragment density
texel size>>.
* [[limits-maxfragmentdensitytexelsize]] pname:maxFragmentDensityTexelSize
is the maximum fragment density texel size.
* [[limits-fragmentdensityinvocations]] pname:fragmentDensityInvocations
specifies whether the implementation may: invoke additional fragment
shader invocations for each covered sample.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceFragmentDensityMapPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
If the sname:VkPhysicalDeviceFragmentDensityMapPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2KHR,
it is filled with the implementation-dependent limits and properties.
--
endif::VK_EXT_fragment_density_map[]
ifdef::VK_AMD_shader_core_properties[]
[open,refpage='VkPhysicalDeviceShaderCorePropertiesAMD',desc='Structure describing shader core properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceShaderCorePropertiesAMD structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceShaderCorePropertiesAMD.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceShaderCorePropertiesAMD structure
describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-shaderEngineCount]] pname:shaderEngineCount is an unsigned
integer value indicating the number of shader engines found inside the
shader core of the physical device.
* [[limits-shaderArraysPerEngineCount]] pname:shaderArraysPerEngineCount
is an unsigned integer value indicating the number of shader arrays
inside a shader engine.
Each shader array has its own scan converter, set of compute units, and
a render back end (color and depth buffers).
Shader arrays within a shader engine share shader processor input (wave
launcher) and shader export (export buffer) units.
Currently, a shader engine can have one or two shader arrays.
* [[limits-computeUnitsPerShaderArray]] pname:computeUnitsPerShaderArray
is an unsigned integer value indicating the number of compute units
within a shader array.
A compute unit houses a set of SIMDs along with a sequencer module and a
local data store.
* [[limits-simdPerComputeUnit]] pname:simdPerComputeUnit is an unsigned
integer value indicating the number of SIMDs inside a compute unit.
Each SIMD processes a single instruction at a time.
* [[limits-wavefrontSize]] pname:wavefrontSize is an unsigned integer
value indicating the number of channels (or threads) in a wavefront.
* [[limits-sgprsPerSimd]] pname:sgprsPerSimd is an unsigned integer value
indicating the number of physical Scalar General Purpose Registers
(SGPRs) per SIMD.
* [[limits-minSgprAllocation]] pname:minSgprAllocation is an unsigned
integer value indicating the minimum number of SGPRs allocated for a
wave.
* [[limits-maxSgprAllocation]] pname:maxSgprAllocation is an unsigned
integer value indicating the maximum number of SGPRs allocated for a
wave.
* [[limits-sgprAllocationGranularity]] pname:sgprAllocationGranularity is
an unsigned integer value indicating the granularity of SGPR allocation
for a wave.
* [[limits-vgprsPerSimd]] pname:vgprsPerSimd is an unsigned integer value
indicating the number of physical Vector General Purpose Registers
(VGPRs) per SIMD.
* [[limits-minVgprAllocation]] pname:minVgprAllocation is an unsigned
integer value indicating the minimum number of VGPRs allocated for a
wave.
* [[limits-maxVgprAllocation]] pname:maxVgprAllocation is an unsigned
integer value indicating the maximum number of VGPRs allocated for a
wave.
* [[limits-vgprAllocationGranularity]] pname:vgprAllocationGranularity is
an unsigned integer value indicating the granularity of VGPR allocation
for a wave.
If the sname:VkPhysicalDeviceShaderCorePropertiesAMD structure is included
in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceShaderCorePropertiesAMD.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_AMD_shader_core_properties[]
ifdef::VK_KHR_depth_stencil_resolve[]
[open,refpage='VkPhysicalDeviceDepthStencilResolvePropertiesKHR',desc='Structure describing depth/stencil resolve properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceDepthStencilResolvePropertiesKHR structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceDepthStencilResolvePropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceDepthStencilResolvePropertiesKHR
structure describe the following implementation-dependent limits:
* [[features-depthResolveModes]] pname:supportedDepthResolveModes is a
bitmask of elink:VkResolveModeFlagBitsKHR indicating the set of
supported depth resolve modes.
ename:VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR must: be included in the set
but implementations may: support additional modes.
* [[features-stencilResolveModes]] pname:supportedStencilResolveModes is a
bitmask of elink:VkResolveModeFlagBitsKHR indicating the set of
supported stencil resolve modes.
ename:VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR must: be included in the set
but implementations may: support additional modes.
ename:VK_RESOLVE_MODE_AVERAGE_BIT_KHR must: not be included in the set.
* [[features-independentResolveNone]] pname:independentResolveNone is
ename:VK_TRUE if the implementation supports setting the depth and
stencil resolve modes to different values when one of those modes is
ename:VK_RESOLVE_MODE_NONE_KHR.
Otherwise the implementation only supports setting both modes to the
same value.
* [[features-independentResolve]] pname:independentResolve is
ename:VK_TRUE if the implementation supports all combinations of the
supported depth and stencil resolve modes.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceDepthStencilResolvePropertiesKHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_KHR_depth_stencil_resolve[]
ifdef::VK_NV_shading_rate_image[]
[open,refpage='VkPhysicalDeviceShadingRateImagePropertiesNV',desc='Structure describing shading rate image limits that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceShadingRateImagePropertiesNV structure is defined
as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceShadingRateImagePropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceShadingRateImagePropertiesNV
structure describe the following implementation-dependent properties related
to the <<primsrast-shading-rate-image, shading rate image>> feature:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-shading-rate-texel-size]] pname:shadingRateTexelSize indicates
the width and height of the portion of the framebuffer corresponding to
each texel in the shading rate image.
* [[limits-shading-rate-palette-size]] pname:shadingRatePaletteSize
indicates the maximum number of palette entries supported for the
shading rate image.
* [[limits-shading-rate-max-coarse-samples]]
pname:shadingRateMaxCoarseSamples specifies the maximum number of
coverage samples supported in a single fragment.
If the product of the fragment size derived from the base shading rate
and the number of coverage samples per pixel exceeds this limit, the
final shading rate will be adjusted so that its product does not exceed
the limit.
If the sname:VkPhysicalDeviceShadingRateImagePropertiesNV structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceShadingRateImagePropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_NV_shading_rate_image[]
ifdef::VK_EXT_transform_feedback[]
[open,refpage='VkPhysicalDeviceTransformFeedbackPropertiesEXT',desc='Structure describing transform feedback properties that can be supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceTransformFeedbackPropertiesEXT structure is
defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceTransformFeedbackPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceTransformFeedbackPropertiesEXT
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-maxTransformFeedbackStreams]] pname:maxTransformFeedbackStreams
is the maximum number of vertex streams that can be output from geometry
shaders declared with the code:GeometryStreams capability.
If the implementation does not support
sname:VkPhysicalDeviceTransformFeedbackFeaturesEXT::pname:geometryStreams
then pname:maxTransformFeedbackStreams must: be set to `1`.
* [[limits-maxTransformFeedbackBuffers]] pname:maxTransformFeedbackBuffers
is the maximum number of transform feedback buffers that can be bound
for capturing shader outputs from the last vertex processing stage.
* [[limits-maxTransformFeedbackBufferSize]]
pname:maxTransformFeedbackBufferSize is the maximum size that can be
specified when binding a buffer for transform feedback in
flink:vkCmdBindTransformFeedbackBuffersEXT.
* [[limits-maxTransformFeedbackStreamDataSize]]
pname:maxTransformFeedbackStreamDataSize is the maximum amount of data
in bytes for each vertex that captured to one or more transform feedback
buffers associated with a specific vertex stream.
* [[limits-maxTransformFeedbackBufferDataSize]]
pname:maxTransformFeedbackBufferDataSize is the maximum amount of data
in bytes for each vertex that can be captured to a specific transform
feedback buffer.
* [[limits-maxTransformFeedbackBufferDataStride]]
pname:maxTransformFeedbackBufferDataStride is the maximum stride between
each capture of vertex data to the buffer.
* [[limits-transformFeedbackQueries]] pname:transformFeedbackQueries is
true if the implementation supports the
ename:VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT query type.
pname:transformFeedbackQueries is false if queries of this type cannot:
be created.
* [[limits-transformFeedbackStreamsLinesTriangles]]
pname:transformFeedbackStreamsLinesTriangles is true if the
implementation supports the geometry shader code:OpExecutionMode of
code:OutputLineStrip and code:OutputTriangleStrip in addition to
code:OutputPoints when more than one vertex stream is output.
If pname:transformFeedbackStreamsLinesTriangles is false the
implementation only supports an code:OpExecutionMode of
code:OutputPoints when more than one vertex stream is output from the
geometry shader.
* [[limits-transformFeedbackRasterizationStreamSelect]]
pname:transformFeedbackRasterizationStreamSelect is true if the
implementation supports the code:GeometryStreams SPIR-V capability and
the application can use
slink:VkPipelineRasterizationStateStreamCreateInfoEXT to modify which
vertex stream output is used for rasterization.
Otherwise vertex stream `0` must: always be used for rasterization.
* [[limits-transformFeedbackDraw]] pname:transformFeedbackDraw is true if
the implementation supports the flink:vkCmdDrawIndirectByteCountEXT
function otherwise the function must: not be called.
If the sname:VkPhysicalDeviceTransformFeedbackPropertiesEXT structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits and properties.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceTransformFeedbackPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_transform_feedback[]
ifdef::VK_NV_ray_tracing[]
[open,refpage='VkPhysicalDeviceRayTracingPropertiesNV',desc='Properties of the physical device for ray tracing',type='structs']
--
The sname:VkPhysicalDeviceRayTracingPropertiesNV structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceRayTracingPropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:shaderGroupHandleSize size in bytes of the shader header.
* pname:maxRecursionDepth is the maximum number of levels of recursion
allowed in a trace command.
* pname:maxShaderGroupStride is the maximum stride in bytes allowed
between shader groups in the SBT.
* pname:shaderGroupBaseAlignment is the required alignment in bytes for
the base of the SBTs.
* pname:maxGeometryCount is the maximum number of geometries in the bottom
level acceleration structure.
* pname:maxInstanceCount is the maximum number of instances in the top
level acceleration structure.
* pname:maxTriangleCount is the maximum number of triangles in all
geometries in the bottom level acceleration structure.
* pname:maxDescriptorSetAccelerationStructures is the maximum number of
acceleration structure descriptors that are allowed in a descriptor set.
If the sname:VkPhysicalDeviceRayTracingPropertiesNV structure is included in
the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it is filled
with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceRayTracingPropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_NV_ray_tracing[]
ifdef::VK_NV_cooperative_matrix[]
[open,refpage='VkPhysicalDeviceCooperativeMatrixPropertiesNV',desc='Structure describing cooperative matrix properties supported by an implementation',type='structs']
--
The sname:VkPhysicalDeviceCooperativeMatrixPropertiesNV structure is defined
as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkPhysicalDeviceCooperativeMatrixPropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The members of the sname:VkPhysicalDeviceCooperativeMatrixPropertiesNV
structure describe the following implementation-dependent limits:
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* [[limits-cooperativeMatrixSupportedStages]]
pname:cooperativeMatrixSupportedStages is a bitfield of
elink:VkShaderStageFlagBits describing the shader stages that
cooperative matrix instructions are supported in.
pname:cooperativeMatrixSupportedStages will have the
ename:VK_SHADER_STAGE_COMPUTE_BIT bit set if any of the physical
device's queues support ename:VK_QUEUE_COMPUTE_BIT.
If the sname:VkPhysicalDeviceCooperativeMatrixPropertiesNV structure is
included in the pname:pNext chain of slink:VkPhysicalDeviceProperties2, it
is filled with the implementation-dependent limits.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkPhysicalDeviceCooperativeMatrixPropertiesNV.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_NV_cooperative_matrix[]
[[limits-minmax]]
== Limit Requirements
The following table specifies the required: minimum/maximum for all Vulkan
graphics implementations.
Where a limit corresponds to a fine-grained device feature which is
optional:, the feature name is listed with two required: limits, one when
the feature is supported and one when it is not supported.
If an implementation supports a feature, the limits reported are the same
whether or not the feature is enabled.
[[limits-types]]
.Required Limit Types
[width="100%",cols="<20%,<50%,<30%",options="header"]
|====
| Type | Limit | Feature
| code:uint32_t | pname:maxImageDimension1D | -
| code:uint32_t | pname:maxImageDimension2D | -
| code:uint32_t | pname:maxImageDimension3D | -
| code:uint32_t | pname:maxImageDimensionCube | -
| code:uint32_t | pname:maxImageArrayLayers | -
| code:uint32_t | pname:maxTexelBufferElements | -
| code:uint32_t | pname:maxUniformBufferRange | -
| code:uint32_t | pname:maxStorageBufferRange | -
| code:uint32_t | pname:maxPushConstantsSize | -
| code:uint32_t | pname:maxMemoryAllocationCount | -
| code:uint32_t | pname:maxSamplerAllocationCount | -
| basetype:VkDeviceSize | pname:bufferImageGranularity | -
| basetype:VkDeviceSize | pname:sparseAddressSpaceSize | pname:sparseBinding
| code:uint32_t | pname:maxBoundDescriptorSets | -
| code:uint32_t | pname:maxPerStageDescriptorSamplers | -
| code:uint32_t | pname:maxPerStageDescriptorUniformBuffers | -
| code:uint32_t | pname:maxPerStageDescriptorStorageBuffers | -
| code:uint32_t | pname:maxPerStageDescriptorSampledImages | -
| code:uint32_t | pname:maxPerStageDescriptorStorageImages | -
| code:uint32_t | pname:maxPerStageDescriptorInputAttachments| -
| code:uint32_t | pname:maxPerStageResources | -
| code:uint32_t | pname:maxDescriptorSetSamplers | -
| code:uint32_t | pname:maxDescriptorSetUniformBuffers | -
| code:uint32_t | pname:maxDescriptorSetUniformBuffersDynamic| -
| code:uint32_t | pname:maxDescriptorSetStorageBuffers | -
| code:uint32_t | pname:maxDescriptorSetStorageBuffersDynamic| -
| code:uint32_t | pname:maxDescriptorSetSampledImages | -
| code:uint32_t | pname:maxDescriptorSetStorageImages | -
| code:uint32_t | pname:maxDescriptorSetInputAttachments | -
| code:uint32_t | pname:maxVertexInputAttributes | -
| code:uint32_t | pname:maxVertexInputBindings | -
| code:uint32_t | pname:maxVertexInputAttributeOffset | -
| code:uint32_t | pname:maxVertexInputBindingStride | -
| code:uint32_t | pname:maxVertexOutputComponents | -
| code:uint32_t | pname:maxTessellationGenerationLevel | pname:tessellationShader
| code:uint32_t | pname:maxTessellationPatchSize | pname:tessellationShader
| code:uint32_t | pname:maxTessellationControlPerVertexInputComponents | pname:tessellationShader
| code:uint32_t | pname:maxTessellationControlPerVertexOutputComponents | pname:tessellationShader
| code:uint32_t | pname:maxTessellationControlPerPatchOutputComponents | pname:tessellationShader
| code:uint32_t | pname:maxTessellationControlTotalOutputComponents | pname:tessellationShader
| code:uint32_t | pname:maxTessellationEvaluationInputComponents | pname:tessellationShader
| code:uint32_t | pname:maxTessellationEvaluationOutputComponents | pname:tessellationShader
| code:uint32_t | pname:maxGeometryShaderInvocations | pname:geometryShader
| code:uint32_t | pname:maxGeometryInputComponents | pname:geometryShader
| code:uint32_t | pname:maxGeometryOutputComponents | pname:geometryShader
| code:uint32_t | pname:maxGeometryOutputVertices | pname:geometryShader
| code:uint32_t | pname:maxGeometryTotalOutputComponents | pname:geometryShader
| code:uint32_t | pname:maxFragmentInputComponents | -
| code:uint32_t | pname:maxFragmentOutputAttachments | -
| code:uint32_t | pname:maxFragmentDualSrcAttachments | pname:dualSrcBlend
| code:uint32_t | pname:maxFragmentCombinedOutputResources | -
| code:uint32_t | pname:maxComputeSharedMemorySize | -
| 3 {times} code:uint32_t | pname:maxComputeWorkGroupCount | -
| code:uint32_t | pname:maxComputeWorkGroupInvocations | -
| 3 {times} code:uint32_t | pname:maxComputeWorkGroupSize | -
| code:uint32_t | pname:subPixelPrecisionBits | -
| code:uint32_t | pname:subTexelPrecisionBits | -
| code:uint32_t | pname:mipmapPrecisionBits | -
| code:uint32_t | pname:maxDrawIndexedIndexValue | pname:fullDrawIndexUint32
| code:uint32_t | pname:maxDrawIndirectCount | pname:multiDrawIndirect
| code:float | pname:maxSamplerLodBias | -
| code:float | pname:maxSamplerAnisotropy | pname:samplerAnisotropy
| code:uint32_t | pname:maxViewports | pname:multiViewport
| 2 {times} code:uint32_t | pname:maxViewportDimensions | -
| 2 {times} code:float | pname:viewportBoundsRange | -
| code:uint32_t | pname:viewportSubPixelBits | -
| code:size_t | pname:minMemoryMapAlignment | -
| basetype:VkDeviceSize | pname:minTexelBufferOffsetAlignment | -
| basetype:VkDeviceSize | pname:minUniformBufferOffsetAlignment | -
| basetype:VkDeviceSize | pname:minStorageBufferOffsetAlignment | -
| code:int32_t | pname:minTexelOffset | -
| code:uint32_t | pname:maxTexelOffset | -
| code:int32_t | pname:minTexelGatherOffset | pname:shaderImageGatherExtended
| code:uint32_t | pname:maxTexelGatherOffset | pname:shaderImageGatherExtended
| code:float | pname:minInterpolationOffset | pname:sampleRateShading
| code:float | pname:maxInterpolationOffset | pname:sampleRateShading
| code:uint32_t | pname:subPixelInterpolationOffsetBits | pname:sampleRateShading
| code:uint32_t | pname:maxFramebufferWidth | -
| code:uint32_t | pname:maxFramebufferHeight | -
| code:uint32_t | pname:maxFramebufferLayers | -
| tlink:VkSampleCountFlags | pname:framebufferColorSampleCounts | -
| tlink:VkSampleCountFlags | pname:framebufferDepthSampleCounts | -
| tlink:VkSampleCountFlags | pname:framebufferStencilSampleCounts | -
| tlink:VkSampleCountFlags | pname:framebufferNoAttachmentsSampleCounts | -
| code:uint32_t | pname:maxColorAttachments | -
| tlink:VkSampleCountFlags | pname:sampledImageColorSampleCounts | -
| tlink:VkSampleCountFlags | pname:sampledImageIntegerSampleCounts | -
| tlink:VkSampleCountFlags | pname:sampledImageDepthSampleCounts | -
| tlink:VkSampleCountFlags | pname:sampledImageStencilSampleCounts | -
| tlink:VkSampleCountFlags | pname:storageImageSampleCounts | pname:shaderStorageImageMultisample
| code:uint32_t | pname:maxSampleMaskWords | -
| basetype:VkBool32 | pname:timestampComputeAndGraphics | -
| code:float | pname:timestampPeriod | -
| code:uint32_t | pname:maxClipDistances | pname:shaderClipDistance
| code:uint32_t | pname:maxCullDistances | pname:shaderCullDistance
| code:uint32_t | pname:maxCombinedClipAndCullDistances | pname:shaderCullDistance
| code:uint32_t | pname:discreteQueuePriorities | -
| 2 {times} code:float | pname:pointSizeRange | pname:largePoints
| 2 {times} code:float | pname:lineWidthRange | pname:wideLines
| code:float | pname:pointSizeGranularity | pname:largePoints
| code:float | pname:lineWidthGranularity | pname:wideLines
| basetype:VkBool32 | pname:strictLines | -
| basetype:VkBool32 | pname:standardSampleLocations | -
| basetype:VkDeviceSize | pname:optimalBufferCopyOffsetAlignment | -
| basetype:VkDeviceSize | pname:optimalBufferCopyRowPitchAlignment | -
| basetype:VkDeviceSize | pname:nonCoherentAtomSize | -
ifdef::VK_EXT_discard_rectangles[]
| code:uint32_t | pname:maxDiscardRectangles | `<<VK_EXT_discard_rectangles>>`
endif::VK_EXT_discard_rectangles[]
ifdef::VK_EXT_sampler_filter_minmax[]
| basetype:VkBool32 | pname:filterMinmaxSingleComponentFormats | `<<VK_EXT_sampler_filter_minmax>>`
| basetype:VkBool32 | pname:filterMinmaxImageComponentMapping | `<<VK_EXT_sampler_filter_minmax>>`
endif::VK_EXT_sampler_filter_minmax[]
ifdef::VK_EXT_conservative_rasterization[]
| code:float | pname:primitiveOverestimationSize | `<<VK_EXT_conservative_rasterization>>`
| basetype:VkBool32 | pname:maxExtraPrimitiveOverestimationSize | `<<VK_EXT_conservative_rasterization>>`
| code:float | pname:extraPrimitiveOverestimationSizeGranularity | `<<VK_EXT_conservative_rasterization>>`
| basetype:VkBool32 | pname:degenerateTriangleRasterized | `<<VK_EXT_conservative_rasterization>>`
| code:float | pname:degenerateLinesRasterized | `<<VK_EXT_conservative_rasterization>>`
| basetype:VkBool32 | pname:fullyCoveredFragmentShaderInputVariable | `<<VK_EXT_conservative_rasterization>>`
| basetype:VkBool32 | pname:conservativeRasterizationPostDepthCoverage | `<<VK_EXT_conservative_rasterization>>`
endif::VK_EXT_conservative_rasterization[]
ifdef::VK_EXT_vertex_attribute_divisor[]
| code:uint32_t | pname:maxVertexAttribDivisor | `<<VK_EXT_vertex_attribute_divisor>>`
endif::VK_EXT_vertex_attribute_divisor[]
ifdef::VK_NV_mesh_shader[]
| code:uint32_t | pname:maxDrawMeshTasksCount | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxTaskWorkGroupInvocations | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxTaskWorkGroupSize | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxTaskTotalMemorySize | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxTaskOutputCount | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxMeshWorkGroupInvocations | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxMeshWorkGroupSize | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxMeshTotalMemorySize | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxMeshOutputVertices | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxMeshOutputPrimitives | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:maxMeshMultiviewViewCount | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:meshOutputPerVertexGranularity | `<<VK_NV_mesh_shader>>`
| code:uint32_t | pname:meshOutputPerPrimitiveGranularity | `<<VK_NV_mesh_shader>>`
endif::VK_NV_mesh_shader[]
ifdef::VK_EXT_transform_feedback[]
| code:uint32_t | pname:maxTransformFeedbackStreams | `<<VK_EXT_transform_feedback>>`
| code:uint32_t | pname:maxTransformFeedbackBuffers | `<<VK_EXT_transform_feedback>>`
| basetype:VkDeviceSize | pname:maxTransformFeedbackBufferSize | `<<VK_EXT_transform_feedback>>`
| code:uint32_t | pname:maxTransformFeedbackStreamDataSize | `<<VK_EXT_transform_feedback>>`
| code:uint32_t | pname:maxTransformFeedbackBufferDataSize | `<<VK_EXT_transform_feedback>>`
| code:uint32_t | pname:maxTransformFeedbackBufferDataStride | `<<VK_EXT_transform_feedback>>`
| basetype:VkBool32 | pname:transformFeedbackQueries | `<<VK_EXT_transform_feedback>>`
| basetype:VkBool32 | pname:transformFeedbackStreamsLinesTriangles | `<<VK_EXT_transform_feedback>>`
| basetype:VkBool32 | pname:transformFeedbackRasterizationStreamSelect | `<<VK_EXT_transform_feedback>>`
| basetype:VkBool32 | pname:transformFeedbackDraw | `<<VK_EXT_transform_feedback>>`
endif::VK_EXT_transform_feedback[]
ifdef::VK_EXT_fragment_density_map[]
| slink:VkExtent2D | pname:minFragmentDensityTexelSize | pname:fragmentDensityMap
| slink:VkExtent2D | pname:maxFragmentDensityTexelSize | pname:fragmentDensityMap
| basetype:VkBool32 | pname:fragmentDensityInvocations | pname:fragmentDensityMap
endif::VK_EXT_fragment_density_map[]
ifdef::VK_NV_ray_tracing[]
| code:uint32_t | pname:shaderGroupHandleSize | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxRecursionDepth | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:shaderGroupBaseAlignment | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxGeometryCount | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxInstanceCount | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxTriangleCount | `<<VK_NV_ray_tracing>>`
| code:uint32_t | pname:maxDescriptorSetAccelerationStructures | `<<VK_NV_ray_tracing>>`
endif::VK_NV_ray_tracing[]
|====
[[limits-required]]
.Required Limits
[width="100%",cols="<35,<9,<14,<11",options="header"]
|====
| Limit | Unsupported Limit | Supported Limit | Limit Type^1^
| pname:maxImageDimension1D | - | 4096 | min
| pname:maxImageDimension2D | - | 4096 | min
| pname:maxImageDimension3D | - | 256 | min
| pname:maxImageDimensionCube | - | 4096 | min
| pname:maxImageArrayLayers | - | 256 | min
| pname:maxTexelBufferElements | - | 65536 | min
| pname:maxUniformBufferRange | - | 16384 | min
| pname:maxStorageBufferRange | - | 2^27^ | min
| pname:maxPushConstantsSize | - | 128 | min
| pname:maxMemoryAllocationCount | - | 4096 | min
| pname:maxSamplerAllocationCount | - | 4000 | min
| pname:bufferImageGranularity | - | 131072 | max
| pname:sparseAddressSpaceSize | 0 | 2^31^ | min
| pname:maxBoundDescriptorSets | - | 4 | min
| pname:maxPerStageDescriptorSamplers | - | 16 | min
| pname:maxPerStageDescriptorUniformBuffers | - | 12 | min
| pname:maxPerStageDescriptorStorageBuffers | - | 4 | min
| pname:maxPerStageDescriptorSampledImages | - | 16 | min
| pname:maxPerStageDescriptorStorageImages | - | 4 | min
| pname:maxPerStageDescriptorInputAttachments| - | 4 | min
| pname:maxPerStageResources | - | 128 ^2^ | min
| pname:maxDescriptorSetSamplers | - | 96 ^8^ | min, _n_ {times} PerStage
| pname:maxDescriptorSetUniformBuffers | - | 72 ^8^ | min, _n_ {times} PerStage
| pname:maxDescriptorSetUniformBuffersDynamic| - | 8 | min
| pname:maxDescriptorSetStorageBuffers | - | 24 ^8^ | min, _n_ {times} PerStage
| pname:maxDescriptorSetStorageBuffersDynamic| - | 4 | min
| pname:maxDescriptorSetSampledImages | - | 96 ^8^ | min, _n_ {times} PerStage
| pname:maxDescriptorSetStorageImages | - | 24 ^8^ | min, _n_ {times} PerStage
| pname:maxDescriptorSetInputAttachments | - | 4 | min
| pname:maxVertexInputAttributes | - | 16 | min
| pname:maxVertexInputBindings | - | 16 | min
| pname:maxVertexInputAttributeOffset | - | 2047 | min
| pname:maxVertexInputBindingStride | - | 2048 | min
| pname:maxVertexOutputComponents | - | 64 | min
| pname:maxTessellationGenerationLevel | 0 | 64 | min
| pname:maxTessellationPatchSize | 0 | 32 | min
| pname:maxTessellationControlPerVertexInputComponents | 0 |64 | min
| pname:maxTessellationControlPerVertexOutputComponents | 0 |64 | min
| pname:maxTessellationControlPerPatchOutputComponents | 0 |120 | min
| pname:maxTessellationControlTotalOutputComponents | 0 |2048 | min
| pname:maxTessellationEvaluationInputComponents | 0 |64 | min
| pname:maxTessellationEvaluationOutputComponents | 0 |64 | min
| pname:maxGeometryShaderInvocations | 0 | 32 | min
| pname:maxGeometryInputComponents | 0 | 64 | min
| pname:maxGeometryOutputComponents | 0 | 64 | min
| pname:maxGeometryOutputVertices | 0 | 256 | min
| pname:maxGeometryTotalOutputComponents | 0 | 1024 | min
| pname:maxFragmentInputComponents | - | 64 | min
| pname:maxFragmentOutputAttachments | - | 4 | min
| pname:maxFragmentDualSrcAttachments | 0 | 1 | min
| pname:maxFragmentCombinedOutputResources | - | 4 | min
| pname:maxComputeSharedMemorySize | - | 16384 | min
| pname:maxComputeWorkGroupCount | - | (65535,65535,65535) | min
| pname:maxComputeWorkGroupInvocations | - | 128 | min
| pname:maxComputeWorkGroupSize | - | (128,128,64) | min
| pname:subPixelPrecisionBits | - | 4 | min
| pname:subTexelPrecisionBits | - | 4 | min
| pname:mipmapPrecisionBits | - | 4 | min
| pname:maxDrawIndexedIndexValue | 2^24^-1 | 2^32^-1 | min
| pname:maxDrawIndirectCount | 1 | 2^16^-1 | min
| pname:maxSamplerLodBias | - | 2 | min
| pname:maxSamplerAnisotropy | 1 | 16 | min
| pname:maxViewports | 1 | 16 | min
| pname:maxViewportDimensions | - | (4096,4096) ^3^ | min
| pname:viewportBoundsRange | - | (-8192,8191) ^4^ | (max,min)
| pname:viewportSubPixelBits | - | 0 | min
| pname:minMemoryMapAlignment | - | 64 | min
| pname:minTexelBufferOffsetAlignment | - | 256 | max
| pname:minUniformBufferOffsetAlignment | - | 256 | max
| pname:minStorageBufferOffsetAlignment | - | 256 | max
| pname:minTexelOffset | - | -8 | max
| pname:maxTexelOffset | - | 7 | min
| pname:minTexelGatherOffset | 0 | -8 | max
| pname:maxTexelGatherOffset | 0 | 7 | min
| pname:minInterpolationOffset |0.0| -0.5 ^5^ | max
| pname:maxInterpolationOffset |0.0| 0.5 - (1 ULP) ^5^ | min
| pname:subPixelInterpolationOffsetBits | 0 | 4 ^5^ | min
| pname:maxFramebufferWidth | - | 4096 | min
| pname:maxFramebufferHeight | - | 4096 | min
| pname:maxFramebufferLayers | - | 256 | min
| pname:framebufferColorSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:framebufferDepthSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:framebufferStencilSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:framebufferNoAttachmentsSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:maxColorAttachments | - | 4 | min
| pname:sampledImageColorSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:sampledImageIntegerSampleCounts | - | ename:VK_SAMPLE_COUNT_1_BIT | min
| pname:sampledImageDepthSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:sampledImageStencilSampleCounts | - | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:storageImageSampleCounts | ename:VK_SAMPLE_COUNT_1_BIT | (ename:VK_SAMPLE_COUNT_1_BIT \| ename:VK_SAMPLE_COUNT_4_BIT) | min
| pname:maxSampleMaskWords | - | 1 | min
| pname:timestampComputeAndGraphics | - | - |implementation dependent
| pname:timestampPeriod | - | - |duration
| pname:maxClipDistances | 0 | 8 | min
| pname:maxCullDistances | 0 | 8 | min
| pname:maxCombinedClipAndCullDistances | 0 | 8 | min
| pname:discreteQueuePriorities | - | 2 | min
| pname:pointSizeRange | (1.0,1.0) | (1.0,64.0 - ULP)^6^| (max,min)
| pname:lineWidthRange | (1.0,1.0) | (1.0,8.0 - ULP)^7^ | (max,min)
| pname:pointSizeGranularity | 0.0 | 1.0 ^6^ | max, fixed point increment
| pname:lineWidthGranularity | 0.0 | 1.0 ^7^ | max, fixed point increment
| pname:strictLines | - | - | implementation dependent
| pname:standardSampleLocations | - | - | implementation dependent
| pname:optimalBufferCopyOffsetAlignment | - | - | recommendation
| pname:optimalBufferCopyRowPitchAlignment | - | - | recommendation
| pname:nonCoherentAtomSize | - | 256 | max
ifdef::VK_KHR_push_descriptor[]
| pname:maxPushDescriptors | - | 32 | min
endif::VK_KHR_push_descriptor[]
ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
| pname:maxMultiviewViewCount | - | 6 | min
| pname:maxMultiviewInstanceIndex | - | 2^27^-1 | min
endif::VK_VERSION_1_1,VK_KHR_multiview[]
ifdef::VK_EXT_discard_rectangles[]
| pname:maxDiscardRectangles | 0 | 4 | min
endif::VK_EXT_discard_rectangles[]
ifdef::VK_EXT_sample_locations[]
| pname:sampleLocationSampleCounts | - | ename:VK_SAMPLE_COUNT_4_BIT | min
| pname:maxSampleLocationGridSize | - | (1,1) | min
| pname:sampleLocationCoordinateRange | - | (0.0, 0.9375) | (max,min)
| pname:sampleLocationSubPixelBits | - | 4 | min
| pname:variableSampleLocations | - |false| implementation dependent
endif::VK_EXT_sample_locations[]
ifdef::VK_EXT_external_memory_host[]
| pname:minImportedHostPointerAlignment | - | 65536 | max
endif::VK_EXT_external_memory_host[]
ifdef::VK_NVX_multiview_per_view_attributes[]
| pname:perViewPositionAllComponents | - | - | implementation dependent
endif::VK_NVX_multiview_per_view_attributes[]
ifdef::VK_EXT_sampler_filter_minmax[]
| pname:filterMinmaxSingleComponentFormats | - | - | implementation dependent
| pname:filterMinmaxImageComponentMapping | - | - | implementation dependent
endif::VK_EXT_sampler_filter_minmax[]
ifdef::VK_EXT_blend_operation_advanced[]
| pname:advancedBlendMaxColorAttachments | - | 1 | min
| pname:advancedBlendIndependentBlend | - |false| implementation dependent
| pname:advancedBlendNonPremultipliedSrcColor | - |false| implementation dependent
| pname:advancedBlendNonPremultipliedDstColor | - |false| implementation dependent
| pname:advancedBlendCorrelatedOverlap | - |false| implementation dependent
| pname:advancedBlendAllOperations | - |false| implementation dependent
endif::VK_EXT_blend_operation_advanced[]
ifdef::VK_VERSION_1_1,VK_KHR_maintenance3[]
| pname:maxPerSetDescriptors | - |1024 | min
| pname:maxMemoryAllocationSize | - | 2^30^ | min
endif::VK_VERSION_1_1,VK_KHR_maintenance3[]
ifdef::VK_EXT_conservative_rasterization[]
| pname:primitiveOverestimationSize | - |0.0 | min
| pname:maxExtraPrimitiveOverestimationSize | - |0.0 | min
| pname:extraPrimitiveOverestimationSizeGranularity | - |0.0 | min
| pname:primitiveUnderestimation | - |false | implementation dependent
| pname:conservativePointAndLineRasterization | - |false | implementation dependent
| pname:degenerateTrianglesRasterized | - |false | implementation dependent
| pname:degenerateLinesRasterized | - |false | implementation dependent
| pname:fullyCoveredFragmentShaderInputVariable | - |false | implementation dependent
| pname:conservativeRasterizationPostDepthCoverage | - |false | implementation dependent
endif::VK_EXT_conservative_rasterization[]
ifdef::VK_EXT_descriptor_indexing[]
| pname:maxUpdateAfterBindDescriptorsInAllPools | - |500000| min
| pname:shaderUniformBufferArrayNonUniformIndexingNative | - |false| implementation dependent
| pname:shaderSampledImageArrayNonUniformIndexingNative | - |false| implementation dependent
| pname:shaderStorageBufferArrayNonUniformIndexingNative | - |false| implementation dependent
| pname:shaderStorageImageArrayNonUniformIndexingNative | - |false| implementation dependent
| pname:shaderInputAttachmentArrayNonUniformIndexingNative | - |false| implementation dependent
| pname:maxPerStageDescriptorUpdateAfterBindSamplers | - |500000 ^9^ | min
| pname:maxPerStageDescriptorUpdateAfterBindUniformBuffers | - |12 ^9^ | min
| pname:maxPerStageDescriptorUpdateAfterBindStorageBuffers | - |500000 ^9^ | min
| pname:maxPerStageDescriptorUpdateAfterBindSampledImages | - |500000 ^9^ | min
| pname:maxPerStageDescriptorUpdateAfterBindStorageImages | - |500000 ^9^ | min
| pname:maxPerStageDescriptorUpdateAfterBindInputAttachments| - |500000 ^9^ | min
| pname:maxPerStageUpdateAfterBindResources | - |500000 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindSamplers | - |500000 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindUniformBuffers | - |72 ^8^ ^9^ | min, _n_ {times} PerStage
| pname:maxDescriptorSetUpdateAfterBindUniformBuffersDynamic| - |8 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindStorageBuffers | - |500000 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindStorageBuffersDynamic| - |4 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindSampledImages | - |500000 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindStorageImages | - |500000 ^9^ | min
| pname:maxDescriptorSetUpdateAfterBindInputAttachments | - |500000 ^9^ | min
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_inline_uniform_block[]
| pname:maxInlineUniformBlockSize | - | 256 | min
| pname:maxPerStageDescriptorInlineUniformBlocks | - | 4 | min
| pname:maxPerStageDescriptorUpdateAfterBindInlineUniformBlocks | - | 4 | min
| pname:maxDescriptorSetInlineUniformBlocks | - | 4 | min
| pname:maxDescriptorSetUpdateAfterBindInlineUniformBlocks | - | 4 | min
endif::VK_EXT_inline_uniform_block[]
ifdef::VK_EXT_vertex_attribute_divisor[]
| pname:maxVertexAttribDivisor | - | 2^16^-1 | min
endif::VK_EXT_vertex_attribute_divisor[]
ifdef::VK_NV_mesh_shader[]
| pname:maxDrawMeshTasksCount | - | 2^32^-1 | min
| pname:maxTaskWorkGroupInvocations | - | 32 | min
| pname:maxTaskWorkGroupSize | - | (32,1,1) | min
| pname:maxTaskTotalMemorySize | - | 16384 | min
| pname:maxTaskOutputCount | - | 2^16^-1 | min
| pname:maxMeshWorkGroupInvocations | - | 32 | min
| pname:maxMeshWorkGroupSize | - | (32,1,1) | min
| pname:maxMeshTotalMemorySize | - | 16384 | min
| pname:maxMeshOutputVertices | - | 256 | min
| pname:maxMeshOutputPrimitives | - | 256 | min
| pname:maxMeshMultiviewViewCount | - | 1 | min
| pname:meshOutputPerVertexGranularity | - | - | implementation dependent
| pname:meshOutputPerPrimitiveGranularity | - | - | implementation dependent
endif::VK_NV_mesh_shader[]
ifdef::VK_EXT_transform_feedback[]
| pname:maxTransformFeedbackStreams | - | 1 | min
| pname:maxTransformFeedbackBuffers | - | 1 | min
| pname:maxTransformFeedbackBufferSize | - | 2^27^ | min
| pname:maxTransformFeedbackStreamDataSize | - | 512 | min
| pname:maxTransformFeedbackBufferDataSize | - | 512 | min
| pname:maxTransformFeedbackBufferDataStride | - | 512 | min
| pname:transformFeedbackQueries | - | false | implementation dependent
| pname:transformFeedbackStreamsLinesTriangles | - | false | implementation dependent
| pname:transformFeedbackRasterizationStreamSelect | - | false | implementation dependent
| pname:transformFeedbackDraw | - | false | implementation dependent
endif::VK_EXT_transform_feedback[]
ifdef::VK_EXT_fragment_density_map[]
| pname:minFragmentDensityTexelSize | - | (1,1) | min
| pname:maxFragmentDensityTexelSize | - | (1,1) | min
| pname:fragmentDensityInvocations | - | - | implementation dependent
endif::VK_EXT_fragment_density_map[]
ifdef::VK_NV_ray_tracing[]
| pname:shaderGroupHandleSize | - | 16 | min
| pname:maxRecursionDepth | - | 31 | min
| pname:shaderGroupBaseAlignment | - | 64 | max
| pname:maxGeometryCount | - | 2^24 | min
| pname:maxInstanceCount | - | 2^24 | min
| pname:maxTriangleCount | - | 2^29 | min
| pname:maxDescriptorSetAccelerationStructures | - | 16 | min
endif::VK_NV_ray_tracing[]
|====
1::
The *Limit Type* column specifies the limit is either the minimum limit
all implementations must: support or the maximum limit all
implementations must: support.
For bitmasks a minimum limit is the least bits all implementations must:
set, but they may: have additional bits set beyond this minimum.
2::
The pname:maxPerStageResources must: be at least the smallest of the
following:
+
* the sum of the pname:maxPerStageDescriptorUniformBuffers,
pname:maxPerStageDescriptorStorageBuffers,
pname:maxPerStageDescriptorSampledImages,
pname:maxPerStageDescriptorStorageImages,
pname:maxPerStageDescriptorInputAttachments, pname:maxColorAttachments
limits, or
* 128.
+
It may: not be possible to reach this limit in every stage.
3::
See <<limits-maxViewportDimensions,pname:maxViewportDimensions>> for the
required: relationship to other limits.
4::
See <<limits-viewportboundsrange,pname:viewportBoundsRange>> for the
required: relationship to other limits.
5::
The values pname:minInterpolationOffset and pname:maxInterpolationOffset
describe the closed interval of supported interpolation offsets:
[pname:minInterpolationOffset, pname:maxInterpolationOffset].
The ULP is determined by pname:subPixelInterpolationOffsetBits.
If pname:subPixelInterpolationOffsetBits is 4, this provides increments
of (1/2^4^) = 0.0625, and thus the range of supported interpolation
offsets would be [eq]#[-0.5, 0.4375]#.
6::
The point size ULP is determined by pname:pointSizeGranularity.
If the pname:pointSizeGranularity is 0.125, the range of supported point
sizes must: be at least [1.0, 63.875].
7::
The line width ULP is determined by pname:lineWidthGranularity.
If the pname:lineWidthGranularity is 0.0625, the range of supported line
widths must: be at least [1.0, 7.9375].
8:: The minimum ptext:maxDescriptorSet* limit is _n_ times the corresponding
_specification_ minimum ptext:maxPerStageDescriptor* limit, where _n_ is
the number of shader stages supported by the slink:VkPhysicalDevice.
If all shader stages are supported, _n_ = 6 (vertex, tessellation
control, tessellation evaluation, geometry, fragment, compute).
ifdef::VK_EXT_descriptor_indexing[]
9:: The ptext:UpdateAfterBind descriptor limits must: each be greater than
or equal to the corresponding ptext:non-UpdateAfterBind limit.
endif::VK_EXT_descriptor_indexing[]
ifdef::VK_EXT_sample_locations[]
[[limits-multisample]]
== Additional Multisampling Capabilities
[open,refpage='vkGetPhysicalDeviceMultisamplePropertiesEXT',desc='Report sample count specific multisampling capabilities of a physical device',type='protos']
--
In addition to the minimum capabilities described for (<<limits, Limits>>)
above, implementations may: support additional multisampling capabilities
specific to a particular sample count.
To query additional sample count specific multisampling capabilities, call:
2019-04-16 12:19:43 +00:00
include::{generated}/api/protos/vkGetPhysicalDeviceMultisamplePropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:physicalDevice is the physical device from which to query the
additional multisampling capabilities.
* pname:samples is the sample count to query the capabilities for.
* pname:pMultisampleProperties is a pointer to a structure of type
slink:VkMultisamplePropertiesEXT, in which information about the
additional multisampling capabilities specific to the sample count is
returned.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/protos/vkGetPhysicalDeviceMultisamplePropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkMultisamplePropertiesEXT',desc='Structure returning information about sample count specific additional multisampling capabilities',type='structs']
--
The sname:VkMultisamplePropertiesEXT structure is defined as
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkMultisamplePropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:maxSampleLocationGridSize is the maximum size of the pixel grid in
which sample locations can: vary.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkMultisamplePropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
If the sample count for which additional multisampling capabilities are
requested using fname:vkGetPhysicalDeviceMultisamplePropertiesEXT is set
in sname:VkPhysicalDeviceSampleLocationsPropertiesEXT::
<<limits-sampleLocationSampleCounts, pname:sampleLocationSampleCounts>> the
pname:width and pname:height members of
sname:VkMultisamplePropertiesEXT::pname:maxSampleLocationGridSize must: be
greater than or equal to the corresponding members of
sname:VkPhysicalDeviceSampleLocationsPropertiesEXT::
<<limits-maxSampleLocationGridSize,pname:maxSampleLocationGridSize>>,
respectively, otherwise both members must: be `0`.
endif::VK_EXT_sample_locations[]