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

534 lines
29 KiB
Plaintext
Raw Normal View History

// Copyright (c) 2014-2016 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
2016-02-16 09:53:44 +00:00
VkPhysicalDeviceFeatures(3)
===========================
Name
----
VkPhysicalDeviceFeatures - Structure describing the fine-grained features that can be supported by an implementation.
C Specification
---------------
// refBegin VkPhysicalDeviceFeatures Structure describing the fine-grained features that can be supported by an implementation.
2016-02-16 09:53:44 +00:00
The sname:VkPhysicalDeviceFeatures structure is defined as:
2016-02-16 09:53:44 +00:00
Change log for July 22, 2016 Vulkan 1.0.22 spec update: * Bump API patch number and header version number to 22 for this update. Github Issues: * Translate the subpass self-dependency language into concrete validity statements, and added a validity statement about the restrictions on layout parameters (public issue 267). * Add validity requirement that slink:VkAttachmentDescription::pname:finalLayout and slink:VkAttachmentReference::pname:layout must not be ename:VK_IMAGE_LAYOUT_UNDEFINED or ename:VK_IMAGE_LAYOUT_PREINITIALIZED (public issue 268). * Clarify that slink:VkSubpassDescription::pname:pResolveAttachments layouts are used. Make language consistent with other attachment arrays (public issue 270). * Changed 64-bit definition for dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE to work for x32 platform in +vk.xml+ and the resulting +vulkan.h+ (public issue 282). * Add missing error return code for flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 285) * Fix several cases of stext::VkStructName.memberName markup to stext::VkStructName::pname:memberName, to match other usage in the spec, and describe this markup in the style guide (public issue 286). * Modified validity language generation script to avoid redundant common ancestor language if covered by generic parent language, and used `Both' instead of `Each' when appropriate (public issue 288). Internal Issues: * Add language about behavior of flink:vkAllocateDescriptorSets when allocation fails due to fragmentation, a new error ename:VK_ERROR_FRAGMENTED_POOL, and a Note explaining the situation (internal issue 309). * For the features of code:PointSize, code:ClipDistance, and code:CullDistance, the SPIR-V capability is required to be declared on use (read or write) rather than on decoration (internal issue 359). * Have desktop versions of GLSL respect precision qualification (code:mediump and code:lowp) when compiling for Vulkan. These will get translated to SPIR-V's code:RelaxedPrecision decoration as they do with OpenGL ES versions of GLSL (ESSL). The default precision of all types is code:highp when using a desktop version (internal issue 360). * Add validity statement for slink:VkImageCreateInfo specifying that multisampled images must be two-dimensional, optimally tiled, and with a single mipmap level (internal issue 369). * Add validity statements to slink:VkImageViewCreateInfo disallowing creation of images or image views with no supported features. Made some slink:VkImageViewCreateInfo validity statements more precise and consistent. Added a Note to the <<features,features>> chapter about formats with no features (internal issue 371). * Remove +manpages+ from default build targets. Nroff outputs containing imbedded latexmath will not render properly. Fixing this is a lot of work for limited use cases (internal issue 401). Other Commits: * Fix flink:vkRenderPassBeginInfo::pname:clearValueCount validity statement to be based on attachment indices rather than the number of cleared attachments (Vulkan-LoaderAndValidationLayers/issues/601). * Convert registry documentation from LaTeX to asciidoc source and rename from +src/spec/readme.tex+ to +src/spec/registry.txt+. * Fix lack of Oxford commas in validity language. * Lots of cleanup of generator scripts and Makefiles to move extension list for generator into the script arguments instead of the body of genvk.py, and express better dependencies between XML, scripts, and generated files.
2016-07-23 10:15:48 +00:00
include::../api/structs/VkPhysicalDeviceFeatures.txt[]
2016-02-16 09:53:44 +00:00
Members
-------
2016-02-16 09:53:44 +00:00
The members of the sname:VkPhysicalDeviceFeatures structure describe the
following features:
2016-02-16 09:53:44 +00:00
Description
-----------
2016-02-16 09:53:44 +00:00
* [[features-features-robustBufferAccess]] pname:robustBufferAccess
indicates that out of bounds accesses to buffers via shader operations
are well-defined.
** When enabled, out-of-bounds buffer reads will return any of the
following values:
*** Values from anywhere within the buffer object.
*** Zero values, or (0,0,0,x) vectors for vector reads where x is a valid
value represented in the type of the vector components and may: be any
of:
**** 0, 1, or the maximum representable positive integer value, for signed
or unsigned integer components
**** 0.0 or 1.0, for floating-point components
** When enabled, out-of-bounds writes may: modify values within the buffer
object or be ignored.
** If not enabled, out of bounds accesses may: cause undefined behaviour
up-to and including process termination.
* [[features-features-fullDrawIndexUint32]] pname:fullDrawIndexUint32
indicates the full 32-bit range of indices is supported for indexed draw
calls when using a elink:VkIndexType of ename:VK_INDEX_TYPE_UINT32.
pname:maxDrawIndexedIndexValue is the maximum index value that may: be
used (aside from the primitive restart index, which is always 2^32^-1
when the elink:VkIndexType is ename:VK_INDEX_TYPE_UINT32). If this
feature is supported, pname:maxDrawIndexedIndexValue must: be 2^32^-1;
otherwise it must: be no smaller than 2^24^-1. See
<<features-limits-maxDrawIndexedIndexValue,maxDrawIndexedIndexValue>>.
* [[features-features-imageCubeArray]] pname:imageCubeArray indicates
whether image views with a elink:VkImageViewType of
ename:VK_IMAGE_VIEW_TYPE_CUBE_ARRAY can: be created, and that the
corresponding code:SampledCubeArray and code:ImageCubeArray SPIR-V
capabilities can: be used in shader code.
* [[features-features-independentBlend]] pname:independentBlend indicates
whether the sname:VkPipelineColorBlendAttachmentState settings are
controlled independently per-attachment. If this feature is not enabled,
the sname:VkPipelineColorBlendAttachmentState settings for all color
attachments must: be identical. Otherwise, a different
sname:VkPipelineColorBlendAttachmentState can: be provided for each
bound color attachment.
* [[features-features-geometryShader]] pname:geometryShader indicates
whether geometry shaders are supported. If this feature is not enabled,
the ename:VK_SHADER_STAGE_GEOMETRY_BIT and
ename:VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT enum values mustnot: be
used. This also indicates whether shader modules can: declare the
code:Geometry capability.
* [[features-features-tessellationShader]] pname:tessellationShader
indicates whether tessellation control and evaluation shaders are
supported. If this feature is not enabled, the
ename:VK_SHADER_STAGE_TESSELLATION_CONTROL_BIT,
ename:VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT,
ename:VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT,
ename:VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT, and
ename:VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_STATE_CREATE_INFO enum
values mustnot: be used. This also indicates whether shader modules can:
declare the code:Tessellation capability.
* [[features-features-sampleRateShading]] pname:sampleRateShading
indicates whether per-sample shading and multisample interpolation are
supported. If this feature is not enabled, the pname:sampleShadingEnable
member of the sname:VkPipelineMultisampleStateCreateInfo structure must:
be set to ename:VK_FALSE and the pname:minSampleShading member is
ignored. This also indicates whether shader modules can: declare the
code:SampleRateShading capability.
* [[features-features-dualSrcBlend]] pname:dualSrcBlend indicates whether
blend operations which take two sources are supported. If this feature
is not enabled, the ename:VK_BLEND_FACTOR_SRC1_COLOR,
ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR,
ename:VK_BLEND_FACTOR_SRC1_ALPHA, and
ename:VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA enum values mustnot: be used
as source or destination blending factors. See <<framebuffer-dsb>>.
* [[features-features-logicOp]] pname:logicOp indicates whether logic
operations are supported. If this feature is not enabled, the
pname:logicOpEnable member of the
sname:VkPipelineColorBlendStateCreateInfo structure must: be set to
ename:VK_FALSE, and the pname:logicOp member is ignored.
* [[features-features-multiDrawIndirect]] pname:multiDrawIndirect
indicates whether multiple draw indirect is supported. If this feature
is not enabled, the pname:drawCount parameter to the
fname:vkCmdDrawIndirect and fname:vkCmdDrawIndexedIndirect commands
must: be 0 or 1. The pname:maxDrawIndirectCount member of the
sname:VkPhysicalDeviceLimits structure must: also be 1 if this feature
is not supported. See
<<features-limits-maxDrawIndirectCount,maxDrawIndirectCount>>.
* [[features-features-drawIndirectFirstInstance]]
pname:drawIndirectFirstInstance indicates whether indirect draw calls
support the pname:firstInstance parameter. If this feature is not
enabled, the pname:firstInstance member of all
sname:VkDrawIndirectCommand and sname:VkDrawIndexedIndirectCommand
structures that are provided to the fname:vkCmdDrawIndirect and
fname:vkCmdDrawIndexedIndirect commands must: be 0.
* [[features-features-depthClamp]] pname:depthClamp indicates whether
depth clamping is supported. If this feature is not enabled, the
pname:depthClampEnable member of the
sname:VkPipelineRasterizationStateCreateInfo structure must: be set to
ename:VK_FALSE. Otherwise, setting pname:depthClampEnable to
ename:VK_TRUE will enable depth clamping.
* [[features-features-depthBiasClamp]] pname:depthBiasClamp indicates
whether depth bias clamping is supported. If this feature is not
enabled, the pname:depthBiasClamp member of the
sname:VkPipelineRasterizationStateCreateInfo structure must: be set
to 0.0 unless the VK_DYNAMIC_STATE_DEPTH_BIAS dynamic state is enabled,
and the pname:depthBiasClamp parameter to fname:vkCmdSetDepthBias must:
be set to 0.0.
* [[features-features-fillModeNonSolid]] pname:fillModeNonSolid indicates
whether point and wireframe fill modes are supported. If this feature is
not enabled, the ename:VK_POLYGON_MODE_POINT and
ename:VK_POLYGON_MODE_LINE enum values mustnot: be used.
* [[features-features-depthBounds]] pname:depthBounds indicates whether
depth bounds tests are supported. If this feature is not enabled, the
pname:depthBoundsTestEnable member of the
sname:VkPipelineDepthStencilStateCreateInfo structure must: be set to
ename:VK_FALSE. When pname:depthBoundsTestEnable is set to
ename:VK_FALSE, the pname:minDepthBounds and
pname:maxDepthBounds members of the
sname:VkPipelineDepthStencilStateCreateInfo structure are ignored.
* [[features-features-wideLines]] pname:wideLines indicates whether lines
with width other than 1.0 are supported. If this feature is not enabled,
the pname:lineWidth member of the
sname:VkPipelineRasterizationStateCreateInfo structure must: be set
to 1.0 unless the VK_DYNAMIC_STATE_LINE_WIDTH dynamic state is enabled,
and the pname:lineWidth parameter to fname:vkCmdSetLineWidth must: be set
to 1.0. When this feature is supported, the range and granularity of
supported line widths are indicated by the pname:lineWidthRange and
pname:lineWidthGranularity members of the sname:VkPhysicalDeviceLimits
structure, respectively.
* [[features-features-largePoints]] pname:largePoints indicates whether
points with size greater than 1.0 are supported. If this feature is not
enabled, only a point size of 1.0 written by a shader is supported. The
range and granularity of supported point sizes are indicated by the
pname:pointSizeRange and pname:pointSizeGranularity members of the
sname:VkPhysicalDeviceLimits structure, respectively.
* [[features-features-alphaToOne]] pname:alphaToOne indicates whether the
implementation is able to replace the alpha value of the color fragment
output from the fragment shader with the maximum representable alpha
value for fixed-point colors or 1.0 for floating-point colors. If this
feature is not enabled, then the pname:alphaToOneEnable member of the
sname:VkPipelineMultisampleStateCreateInfo structure must: be set to
ename:VK_FALSE. Otherwise setting pname:alphaToOneEnable to
ename:VK_TRUE will enable alpha-to-one behaviour.
* [[features-features-multiViewport]] pname:multiViewport indicates
whether more than one viewport is supported. If this feature is not
enabled, the pname:viewportCount and pname:scissorCount members of the
sname:VkPipelineViewportStateCreateInfo structure must: be set to 1.
Similarly, the pname:viewportCount parameter to the
fname:vkCmdSetViewport command and the pname:scissorCount parameter to
the fname:vkCmdSetScissor command must: be 1, and the
pname:firstViewport parameter to the fname:vkCmdSetViewport command and
the pname:firstScissor parameter to the fname:vkCmdSetScissor command
must: be 0.
* [[features-features-samplerAnisotropy]] pname:samplerAnisotropy
indicates whether anisotropic filtering is supported. If this feature is
not enabled, the pname:maxAnisotropy member of the
sname:VkSamplerCreateInfo structure must: be 1.0.
* [[features-features-textureCompressionETC2]]
pname:textureCompressionETC2 indicates whether the ETC2 and EAC
compressed texture formats are supported. If this feature is not
enabled, the following formats mustnot: be used to create images:
+
--
* ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK
* ename:VK_FORMAT_EAC_R11_UNORM_BLOCK
* ename:VK_FORMAT_EAC_R11_SNORM_BLOCK
* ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK
* ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK
--
+
flink:vkGetPhysicalDeviceFormatProperties is used to
check for the supported properties of individual formats.
+
* [[features-features-textureCompressionASTC_LDR]]
pname:textureCompressionASTC_LDR indicates whether the ASTC LDR
compressed texture formats are supported. If this feature is not
enabled, the following formats mustnot: be used to create images:
+
--
* ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK
* ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK
* ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK
--
+
flink:vkGetPhysicalDeviceFormatProperties is used to
check for the supported properties of individual formats.
+
* [[features-features-textureCompressionBC]] pname:textureCompressionBC
indicates whether the BC compressed texture formats are supported. If
this feature is not enabled, the following formats mustnot: be used to
create images:
+
--
* ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK
* ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK
* ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK
* ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK
* ename:VK_FORMAT_BC2_UNORM_BLOCK
* ename:VK_FORMAT_BC2_SRGB_BLOCK
* ename:VK_FORMAT_BC3_UNORM_BLOCK
* ename:VK_FORMAT_BC3_SRGB_BLOCK
* ename:VK_FORMAT_BC4_UNORM_BLOCK
* ename:VK_FORMAT_BC4_SNORM_BLOCK
* ename:VK_FORMAT_BC5_UNORM_BLOCK
* ename:VK_FORMAT_BC5_SNORM_BLOCK
* ename:VK_FORMAT_BC6H_UFLOAT_BLOCK
* ename:VK_FORMAT_BC6H_SFLOAT_BLOCK
* ename:VK_FORMAT_BC7_UNORM_BLOCK
* ename:VK_FORMAT_BC7_SRGB_BLOCK
--
+
flink:vkGetPhysicalDeviceFormatProperties is used to
check for the supported properties of individual formats.
+
* [[features-features-occlusionQueryPrecise]] pname:occlusionQueryPrecise
indicates whether occlusion queries returning actual sample counts are
supported. Occlusion queries are created in a sname:VkQueryPool by
specifying the pname:queryType of ename:VK_QUERY_TYPE_OCCLUSION in the
sname:VkQueryPoolCreateInfo structure which is passed to
fname:vkCreateQueryPool. If this feature is enabled, queries of this
type can: enable ename:VK_QUERY_CONTROL_PRECISE_BIT in the pname:flags
parameter to fname:vkCmdBeginQuery. If this feature is not supported,
the implementation supports only boolean occlusion queries. When any
samples are passed, boolean queries will return a non-zero result value,
otherwise a result value of zero is returned. When this feature is
enabled and ename:VK_QUERY_CONTROL_PRECISE_BIT is set, occlusion queries
will report the actual number of samples passed.
* [[features-features-pipelineStatisticsQuery]]
pname:pipelineStatisticsQuery indicates whether the pipeline statistics
queries are supported. If this feature is not enabled, queries of type
ename:VK_QUERY_TYPE_PIPELINE_STATISTICS cannot: be created, and none of
the elink:VkQueryPipelineStatisticFlagBits bits can: be set in the
pname:pipelineStatistics member of the sname:VkQueryPoolCreateInfo
structure.
* [[features-features-vertexPipelineStoresAndAtomics]]
pname:vertexPipelineStoresAndAtomics indicates whether storage buffers
and images support stores and atomic operations in the vertex,
tessellation, and geometry shader stages. If this feature is not
enabled, all storage image, storage texel buffers, and storage buffer
variables used by these stages in shader modules must: be decorated with
the code:NonWriteable decoration (or the code:readonly memory qualifier
in GLSL).
* [[features-features-fragmentStoresAndAtomics]]
pname:fragmentStoresAndAtomics indicates whether storage buffers and
images support stores and atomic operations in the fragment shader
stage. If this feature is not enabled, all storage image, storage texel
buffers, and storage buffer variables used by the fragment stage in
shader modules must: be decorated with the code:NonWriteable decoration
(or the code:readonly memory qualifier in GLSL).
* [[features-features-shaderTessellationAndGeometryPointSize]]
pname:shaderTessellationAndGeometryPointSize indicates whether the
code:PointSize built-in decoration is available in the tessellation
control, tessellation evaluation, and geometry shader stages. If this
Change log for July 22, 2016 Vulkan 1.0.22 spec update: * Bump API patch number and header version number to 22 for this update. Github Issues: * Translate the subpass self-dependency language into concrete validity statements, and added a validity statement about the restrictions on layout parameters (public issue 267). * Add validity requirement that slink:VkAttachmentDescription::pname:finalLayout and slink:VkAttachmentReference::pname:layout must not be ename:VK_IMAGE_LAYOUT_UNDEFINED or ename:VK_IMAGE_LAYOUT_PREINITIALIZED (public issue 268). * Clarify that slink:VkSubpassDescription::pname:pResolveAttachments layouts are used. Make language consistent with other attachment arrays (public issue 270). * Changed 64-bit definition for dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE to work for x32 platform in +vk.xml+ and the resulting +vulkan.h+ (public issue 282). * Add missing error return code for flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 285) * Fix several cases of stext::VkStructName.memberName markup to stext::VkStructName::pname:memberName, to match other usage in the spec, and describe this markup in the style guide (public issue 286). * Modified validity language generation script to avoid redundant common ancestor language if covered by generic parent language, and used `Both' instead of `Each' when appropriate (public issue 288). Internal Issues: * Add language about behavior of flink:vkAllocateDescriptorSets when allocation fails due to fragmentation, a new error ename:VK_ERROR_FRAGMENTED_POOL, and a Note explaining the situation (internal issue 309). * For the features of code:PointSize, code:ClipDistance, and code:CullDistance, the SPIR-V capability is required to be declared on use (read or write) rather than on decoration (internal issue 359). * Have desktop versions of GLSL respect precision qualification (code:mediump and code:lowp) when compiling for Vulkan. These will get translated to SPIR-V's code:RelaxedPrecision decoration as they do with OpenGL ES versions of GLSL (ESSL). The default precision of all types is code:highp when using a desktop version (internal issue 360). * Add validity statement for slink:VkImageCreateInfo specifying that multisampled images must be two-dimensional, optimally tiled, and with a single mipmap level (internal issue 369). * Add validity statements to slink:VkImageViewCreateInfo disallowing creation of images or image views with no supported features. Made some slink:VkImageViewCreateInfo validity statements more precise and consistent. Added a Note to the <<features,features>> chapter about formats with no features (internal issue 371). * Remove +manpages+ from default build targets. Nroff outputs containing imbedded latexmath will not render properly. Fixing this is a lot of work for limited use cases (internal issue 401). Other Commits: * Fix flink:vkRenderPassBeginInfo::pname:clearValueCount validity statement to be based on attachment indices rather than the number of cleared attachments (Vulkan-LoaderAndValidationLayers/issues/601). * Convert registry documentation from LaTeX to asciidoc source and rename from +src/spec/readme.tex+ to +src/spec/registry.txt+. * Fix lack of Oxford commas in validity language. * Lots of cleanup of generator scripts and Makefiles to move extension list for generator into the script arguments instead of the body of genvk.py, and express better dependencies between XML, scripts, and generated files.
2016-07-23 10:15:48 +00:00
feature is not enabled, members decorated with the code:PointSize
built-in decoration mustnot: be read from or written to
and all points written from a
tessellation or geometry shader will have a size of 1.0. This also
indicates whether shader modules can: declare the
code:TessellationPointSize capability for tessellation control and
evaluation shaders, or if the shader modules can: declare the
code:GeometryPointSize capability for geometry shaders. An
implementation supporting this feature must: also support one or both of
the <<features-features-tessellationShader,pname:tessellationShader>> or
<<features-features-geometryShader,pname:geometryShader>> features.
* [[features-features-shaderImageGatherExtended]]
pname:shaderImageGatherExtended indicates whether the extended set of
image gather instructions are available in shader code. If this feature
is not enabled, the code:OpImage*code:Gather instructions do not support
the code:Offset and code:ConstOffsets operands. This also indicates
whether shader modules can: declare the code:ImageGatherExtended
capability.
* [[features-features-shaderStorageImageExtendedFormats]]
pname:shaderStorageImageExtendedFormats indicates whether the extended
storage image formats are available in shader code. If this feature is
not enabled, the formats requiring the code:StorageImageExtendedFormats
capability are not supported for storage images. This also indicates
whether shader modules can: declare the code:StorageImageExtendedFormats
capability.
* [[features-features-shaderStorageImageMultisample]]
pname:shaderStorageImageMultisample indicates whether multisampled
storage images are supported. If this feature is not enabled, images
that are created with a pname:usage that includes
ename:VK_IMAGE_USAGE_STORAGE_BIT must: be created with pname:samples
equal to ename:VK_SAMPLE_COUNT_1_BIT. This also indicates whether shader
modules can: declare the code:StorageImageMultisample capability.
* [[features-features-shaderStorageImageReadWithoutFormat]]
pname:shaderStorageImageReadWithoutFormat indicates whether storage
images require a format qualifier to be specified when reading from
storage images. If this feature is not enabled, the code:OpImageRead
instruction mustnot: have an code:OpTypeImage of code:Unknown. This also
indicates whether shader modules can: declare the
code:StorageImageReadWithoutFormat capability.
* [[features-features-shaderStorageImageWriteWithoutFormat]]
pname:shaderStorageImageWriteWithoutFormat indicates whether storage
images require a format qualifier to be specified when writing to
storage images. If this feature is not enabled, the code:OpImageWrite
instruction mustnot: have an code:OpTypeImage of code:Unknown. This also
indicates whether shader modules can: declare the
code:StorageImageWriteWithoutFormat capability.
* [[features-features-shaderUniformBufferArrayDynamicIndexing]]
pname:shaderUniformBufferArrayDynamicIndexing indicates whether arrays
of uniform buffers can: be indexed by dynamically uniform integer
expressions in shader code. If this feature is not enabled, resources
with a descriptor type of ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or
ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC must: be indexed only by
constant integral expressions when aggregated into arrays in shader
code. This also indicates whether shader modules can: declare the
code:UniformBufferArrayDynamicIndexing capability.
* [[features-features-shaderSampledImageArrayDynamicIndexing]]
pname:shaderSampledImageArrayDynamicIndexing indicates whether arrays of
samplers or sampled images can: be indexed by dynamically uniform
integer expressions in shader code. If this feature is not enabled,
resources with a descriptor type of ename:VK_DESCRIPTOR_TYPE_SAMPLER,
ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, or
ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE must: be indexed only by constant
integral expressions when aggregated into arrays in shader code. This
also indicates whether shader modules can: declare the
code:SampledImageArrayDynamicIndexing capability.
* [[features-features-shaderStorageBufferArrayDynamicIndexing]]
pname:shaderStorageBufferArrayDynamicIndexing indicates whether arrays
of storage buffers can: be indexed by dynamically uniform integer
expressions in shader code. If this feature is not enabled, resources
with a descriptor type of ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC must: be indexed only by
constant integral expressions when aggregated into arrays in shader
code. This also indicates whether shader modules can: declare the
code:StorageBufferArrayDynamicIndexing capability.
* [[features-features-shaderStorageImageArrayDynamicIndexing]]
pname:shaderStorageImageArrayDynamicIndexing indicates whether arrays of
storage images can: be indexed by dynamically uniform integer
expressions in shader code. If this feature is not enabled, resources
with a descriptor type of ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE must:
be indexed only by constant integral expressions when aggregated into
arrays in shader code. This also indicates whether shader modules can:
declare the code:StorageImageArrayDynamicIndexing capability.
* [[features-features-shaderClipDistance]] pname:shaderClipDistance
indicates whether clip distances are supported in shader code. If this
Change log for July 22, 2016 Vulkan 1.0.22 spec update: * Bump API patch number and header version number to 22 for this update. Github Issues: * Translate the subpass self-dependency language into concrete validity statements, and added a validity statement about the restrictions on layout parameters (public issue 267). * Add validity requirement that slink:VkAttachmentDescription::pname:finalLayout and slink:VkAttachmentReference::pname:layout must not be ename:VK_IMAGE_LAYOUT_UNDEFINED or ename:VK_IMAGE_LAYOUT_PREINITIALIZED (public issue 268). * Clarify that slink:VkSubpassDescription::pname:pResolveAttachments layouts are used. Make language consistent with other attachment arrays (public issue 270). * Changed 64-bit definition for dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE to work for x32 platform in +vk.xml+ and the resulting +vulkan.h+ (public issue 282). * Add missing error return code for flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 285) * Fix several cases of stext::VkStructName.memberName markup to stext::VkStructName::pname:memberName, to match other usage in the spec, and describe this markup in the style guide (public issue 286). * Modified validity language generation script to avoid redundant common ancestor language if covered by generic parent language, and used `Both' instead of `Each' when appropriate (public issue 288). Internal Issues: * Add language about behavior of flink:vkAllocateDescriptorSets when allocation fails due to fragmentation, a new error ename:VK_ERROR_FRAGMENTED_POOL, and a Note explaining the situation (internal issue 309). * For the features of code:PointSize, code:ClipDistance, and code:CullDistance, the SPIR-V capability is required to be declared on use (read or write) rather than on decoration (internal issue 359). * Have desktop versions of GLSL respect precision qualification (code:mediump and code:lowp) when compiling for Vulkan. These will get translated to SPIR-V's code:RelaxedPrecision decoration as they do with OpenGL ES versions of GLSL (ESSL). The default precision of all types is code:highp when using a desktop version (internal issue 360). * Add validity statement for slink:VkImageCreateInfo specifying that multisampled images must be two-dimensional, optimally tiled, and with a single mipmap level (internal issue 369). * Add validity statements to slink:VkImageViewCreateInfo disallowing creation of images or image views with no supported features. Made some slink:VkImageViewCreateInfo validity statements more precise and consistent. Added a Note to the <<features,features>> chapter about formats with no features (internal issue 371). * Remove +manpages+ from default build targets. Nroff outputs containing imbedded latexmath will not render properly. Fixing this is a lot of work for limited use cases (internal issue 401). Other Commits: * Fix flink:vkRenderPassBeginInfo::pname:clearValueCount validity statement to be based on attachment indices rather than the number of cleared attachments (Vulkan-LoaderAndValidationLayers/issues/601). * Convert registry documentation from LaTeX to asciidoc source and rename from +src/spec/readme.tex+ to +src/spec/registry.txt+. * Fix lack of Oxford commas in validity language. * Lots of cleanup of generator scripts and Makefiles to move extension list for generator into the script arguments instead of the body of genvk.py, and express better dependencies between XML, scripts, and generated files.
2016-07-23 10:15:48 +00:00
feature is not enabled, any members decorated with the code:ClipDistance
built-in decoration mustnot: be read from or written to in shader modules.
This also indicates whether shader
modules can: declare the code:ClipDistance capability.
* [[features-features-shaderCullDistance]] pname:shaderCullDistance
indicates whether cull distances are supported in shader code. If this
Change log for July 22, 2016 Vulkan 1.0.22 spec update: * Bump API patch number and header version number to 22 for this update. Github Issues: * Translate the subpass self-dependency language into concrete validity statements, and added a validity statement about the restrictions on layout parameters (public issue 267). * Add validity requirement that slink:VkAttachmentDescription::pname:finalLayout and slink:VkAttachmentReference::pname:layout must not be ename:VK_IMAGE_LAYOUT_UNDEFINED or ename:VK_IMAGE_LAYOUT_PREINITIALIZED (public issue 268). * Clarify that slink:VkSubpassDescription::pname:pResolveAttachments layouts are used. Make language consistent with other attachment arrays (public issue 270). * Changed 64-bit definition for dname:VK_DEFINE_NON_DISPATCHABLE_HANDLE to work for x32 platform in +vk.xml+ and the resulting +vulkan.h+ (public issue 282). * Add missing error return code for flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 285) * Fix several cases of stext::VkStructName.memberName markup to stext::VkStructName::pname:memberName, to match other usage in the spec, and describe this markup in the style guide (public issue 286). * Modified validity language generation script to avoid redundant common ancestor language if covered by generic parent language, and used `Both' instead of `Each' when appropriate (public issue 288). Internal Issues: * Add language about behavior of flink:vkAllocateDescriptorSets when allocation fails due to fragmentation, a new error ename:VK_ERROR_FRAGMENTED_POOL, and a Note explaining the situation (internal issue 309). * For the features of code:PointSize, code:ClipDistance, and code:CullDistance, the SPIR-V capability is required to be declared on use (read or write) rather than on decoration (internal issue 359). * Have desktop versions of GLSL respect precision qualification (code:mediump and code:lowp) when compiling for Vulkan. These will get translated to SPIR-V's code:RelaxedPrecision decoration as they do with OpenGL ES versions of GLSL (ESSL). The default precision of all types is code:highp when using a desktop version (internal issue 360). * Add validity statement for slink:VkImageCreateInfo specifying that multisampled images must be two-dimensional, optimally tiled, and with a single mipmap level (internal issue 369). * Add validity statements to slink:VkImageViewCreateInfo disallowing creation of images or image views with no supported features. Made some slink:VkImageViewCreateInfo validity statements more precise and consistent. Added a Note to the <<features,features>> chapter about formats with no features (internal issue 371). * Remove +manpages+ from default build targets. Nroff outputs containing imbedded latexmath will not render properly. Fixing this is a lot of work for limited use cases (internal issue 401). Other Commits: * Fix flink:vkRenderPassBeginInfo::pname:clearValueCount validity statement to be based on attachment indices rather than the number of cleared attachments (Vulkan-LoaderAndValidationLayers/issues/601). * Convert registry documentation from LaTeX to asciidoc source and rename from +src/spec/readme.tex+ to +src/spec/registry.txt+. * Fix lack of Oxford commas in validity language. * Lots of cleanup of generator scripts and Makefiles to move extension list for generator into the script arguments instead of the body of genvk.py, and express better dependencies between XML, scripts, and generated files.
2016-07-23 10:15:48 +00:00
feature is not enabled, any members decorated with the code:CullDistance
built-in decoration mustnot: be read from or written to in shader modules.
This also indicates whether shader
modules can: declare the code:CullDistance capability.
* [[features-features-shaderFloat64]] pname:shaderFloat64 indicates
whether 64-bit floats (doubles) are supported in shader code. If this
feature is not enabled, 64-bit floating-point types mustnot: be used in
shader code. This also indicates whether shader modules can: declare the
code:Float64 capability.
* [[features-features-shaderInt64]] pname:shaderInt64 indicates whether
64-bit integers (signed and unsigned) are supported in shader code. If
this feature is not enabled, 64-bit integer types mustnot: be used in
shader code. This also indicates whether shader modules can: declare the
code:Int64 capability.
* [[features-features-shaderInt16]] pname:shaderInt16 indicates whether
16-bit integers (signed and unsigned) are supported in shader code. If
this feature is not enabled, 16-bit integer types mustnot: be used in
shader code. This also indicates whether shader modules can: declare the
code:Int16 capability.
* [[features-features-shaderResourceResidency]]
pname:shaderResourceResidency indicates whether image operations that
return resource residency information are supported in shader code. If
this feature is not enabled, the code:OpImageSparse* instructions
mustnot: be used in shader code. This also indicates whether shader
modules can: declare the code:SparseResidency capability. The feature
requires at least one of the ptext:sparseResidency* features to be
supported.
* [[features-features-shaderResourceMinLod]] pname:shaderResourceMinLod
indicates whether image operations that specify the minimum resource
level-of-detail (LOD) are supported in shader code. If this feature is
not enabled, the code:MinLod image operand mustnot: be used in shader
code. This also indicates whether shader modules can: declare the
code:MinLod capability.
* [[features-features-sparseBinding]] pname:sparseBinding indicates
whether resource memory can: be managed at opaque sparse block level
instead of at the object level. If this feature is not enabled, resource
memory must: be bound only on a per-object basis using the
fname:vkBindBufferMemory and fname:vkBindImageMemory commands. In this
case, buffers and images mustnot: be created with
ename:VK_BUFFER_CREATE_SPARSE_BINDING_BIT and
ename:VK_IMAGE_CREATE_SPARSE_BINDING_BIT set in the pname:flags member
of the sname:VkBufferCreateInfo and sname:VkImageCreateInfo structures,
respectively. Otherwise resource memory can: be managed as described in
<<sparsememory-sparseresourcefeatures,Sparse Resource Features>>.
* [[features-features-sparseResidencyBuffer]] pname:sparseResidencyBuffer
indicates whether the device can: access partially resident buffers. If
this feature is not enabled, buffers mustnot: be created with
ename:VK_BUFFER_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags
member of the sname:VkBufferCreateInfo structure.
* [[features-features-sparseResidencyImage2D]]
pname:sparseResidencyImage2D indicates whether the device can: access
partially resident 2D images with 1 sample per pixel. If this feature is
not enabled, images with an pname:imageType of ename:VK_IMAGE_TYPE_2D
and pname:samples set to ename:VK_SAMPLE_COUNT_1_BIT mustnot: be created
with ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags
member of the sname:VkImageCreateInfo structure.
* [[features-features-sparseResidencyImage3D]]
pname:sparseResidencyImage3D indicates whether the device can: access
partially resident 3D images. If this feature is not enabled, images
with an pname:imageType of ename:VK_IMAGE_TYPE_3D mustnot: be created
with ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags
member of the sname:VkImageCreateInfo structure.
* [[features-features-sparseResidency2Samples]]
pname:sparseResidency2Samples indicates whether the physical device can:
access partially resident 2D images with 2 samples per pixel. If this
feature is not enabled, images with an pname:imageType of
ename:VK_IMAGE_TYPE_2D and pname:samples set to
ename:VK_SAMPLE_COUNT_2_BIT mustnot: be created with
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags member
of the sname:VkImageCreateInfo structure.
* [[features-features-sparseResidency4Samples]]
pname:sparseResidency4Samples indicates whether the physical device can:
access partially resident 2D images with 4 samples per pixel. If this
feature is not enabled, images with an pname:imageType of
ename:VK_IMAGE_TYPE_2D and pname:samples set to
ename:VK_SAMPLE_COUNT_4_BIT mustnot: be created with
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags member
of the sname:VkImageCreateInfo structure.
* [[features-features-sparseResidency8Samples]]
pname:sparseResidency8Samples indicates whether the physical device can:
access partially resident 2D images with 8 samples per pixel. If this
feature is not enabled, images with an pname:imageType of
ename:VK_IMAGE_TYPE_2D and pname:samples set to
ename:VK_SAMPLE_COUNT_8_BIT mustnot: be created with
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags member
of the sname:VkImageCreateInfo structure.
* [[features-features-sparseResidency16Samples]]
pname:sparseResidency16Samples indicates whether the physical device
can: access partially resident 2D images with 16 samples per pixel. If
this feature is not enabled, images with an pname:imageType of
ename:VK_IMAGE_TYPE_2D and pname:samples set to
ename:VK_SAMPLE_COUNT_16_BIT mustnot: be created with
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT set in the pname:flags member
of the sname:VkImageCreateInfo structure.
* [[features-features-sparseResidencyAliased]]
pname:sparseResidencyAliased indicates whether the physical device can:
correctly access data aliased into multiple locations. If this feature
is not enabled, the ename:VK_BUFFER_CREATE_SPARSE_ALIASED_BIT and
ename:VK_IMAGE_CREATE_SPARSE_ALIASED_BIT enum values mustnot: be used in
pname:flags members of the sname:VkBufferCreateInfo and
sname:VkImageCreateInfo structures, respectively.
* [[features-features-variableMultisampleRate]]
pname:variableMultisampleRate indicates whether all pipelines that will
be bound to a command buffer during a subpass with no attachments must:
have the same value for
sname:VkPipelineMultisampleStateCreateInfo::pname:rasterizationSamples.
If set to ename:VK_TRUE, the implementation supports variable
multisample rates in a subpass with no attachments. If set to
ename:VK_FALSE, then all pipelines bound in such a subpass must: have
the same multisample rate. This has no effect in situations where a
subpass uses any attachments.
* [[features-features-inheritedQueries]] pname:inheritedQueries indicates
whether a secondary command buffer may: be executed while a query is
active.
include::../validity/structs/VkPhysicalDeviceFeatures.txt[]
2016-02-16 09:53:44 +00:00
See Also
--------
2016-02-16 09:53:44 +00:00
Change log for July 15, 2016 Vulkan 1.0.21 spec update: * Bump API patch number and header version number to 21 for this update. Github Issues: * Clarify how <<features-supported-sample-counts,sample count queries>> relate to the limits in slink:VkPhysicalDeviceLimits. (public issue 185). * Clarify in the <<interfaces-iointerfaces,Shader Input and Output Interfaces>> section that shader output variables have undefined values until the shader writes to them (public issue 240). * Specify the implicit value of image parameters that cannot be set in slink:VkSwapchainCreateInfo::pname:flags, pname:imageType, pname:mipLevels, pname:samples, pname:tiling, and pname:initialLayout (public issue 243). * Make use of code:NULL and code:VK_NULL_HANDLE consistent in the VK_KHR_swapchain extension (public issue 276). Internal Issues: * Clarify that presenting an image to a display surface swapchain applies the display surface's mode, and that destroying a display surface swapchain may reset the display's mode, in the VK_KHR_display_swapchain extension (internal issue 247). * Better describe what a slink:VkSurfaceKHR is, and that creating one does not set a mode, in the VK_KHR_display extension. This is a round-about way of pointing out that mode setting is not covered by the extension, but rather is performed as a side effect of presentation (internal issue 247). * Add more valid usage statements to flink:vkQueuePresentKHR command when the VK_KHR_display_swapchain extension is present (internal issue 247). * Add more includes to the VK_KHR_swapchain extension to better document interactions with VK_KHR_display_swapchain (internal issue 247). * Clarify restrictions on location aliasing in the <<fxvertex,Fixed-Function Vertex Processing>> section (internal issue 370). * Add mathematical description of blitting to flink:vkCmdBlitImage, and link it to the <<textures,Image Operations>> chapter. Use mathematical notation for ranges of texel coordinates in the <<textures,Image Operations>> chapter. Fixed miscellaneous validity statements for flink:vkCmdBlit and slink:VkImageBlit (internal issue 382). Other Commits: * Added a valid usage rule to flink:VkGraphicsPipelineCreateInfo that the ename:VK_PRIMITIVE_TOPOLOGY_PATCH_LIST topology must only be used when tessellation shaders are used. * Expand the style guide into a formal "Procedures and Conventions" document. Add a API Naming Conventions section, move most of the API Specification Appendix C (Layers and Extensions) content into the new document, and define the resulting procedures as mandatory (where relevant). This more clearly separates use vs. specification of Vulkan APIs. * Update vk_platform.h to handle 32-bit ARMv8 binaries. * Various minor cleanups to the Makefile and build process.
2016-07-16 02:05:43 +00:00
basetype:VkBool32, slink:VkDeviceCreateInfo, flink:vkGetPhysicalDeviceFeatures
2016-02-16 09:53:44 +00:00
Document Notes
--------------
2016-02-16 09:53:44 +00:00
For more information, see the Vulkan Specification at URL
2016-02-16 09:53:44 +00:00
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#VkPhysicalDeviceFeatures
2016-02-16 09:53:44 +00:00
This page is extracted from the Vulkan Specification.
Fixes and changes should be made to the Specification,not directly.
2016-02-16 09:53:44 +00:00
include::footer.txt[]