2016-07-11 01:13:41 +00:00
|
|
|
// 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
|
|
|
|
---------------
|
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
// refBegin VkPhysicalDeviceFeatures Structure describing the fine-grained features that can be supported by an implementation.
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-07-11 01:13:41 +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
|
|
|
|
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
Members
|
|
|
|
-------
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
The members of the sname:VkPhysicalDeviceFeatures structure describe the
|
|
|
|
following features:
|
2016-02-16 09:53:44 +00:00
|
|
|
|
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
Description
|
|
|
|
-----------
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-07-11 01:13:41 +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
|
2016-07-11 01:13:41 +00:00
|
|
|
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
|
2016-07-11 01:13:41 +00:00
|
|
|
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
|
2016-07-11 01:13:41 +00:00
|
|
|
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
|
|
|
|
|
|
|
|
2016-07-11 01:13:41 +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
|
|
|
|
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
Document Notes
|
|
|
|
--------------
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
For more information, see the Vulkan Specification at URL
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-07-11 01:13:41 +00:00
|
|
|
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#VkPhysicalDeviceFeatures
|
2016-02-16 09:53:44 +00:00
|
|
|
|
2016-07-11 01:13:41 +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[]
|
2016-07-11 01:13:41 +00:00
|
|
|
|