Vulkan-Docs/doc/specs/vulkan/chapters/tessellation.txt

439 lines
23 KiB
Plaintext
Raw Normal View History

2016-02-16 09:53:44 +00:00
// Copyright (c) 2015-2016 The Khronos Group Inc.
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
[[tessellation]]
= Tessellation
Tessellation involves three pipeline stages. First, a
<<shaders-tessellation-control,tessellation control shader>> transforms
control points of a patch and can: produce per-patch data. Second, a
fixed-function tessellator generates multiple primitives corresponding to a
tessellation of the patch in (u,v) or (u,v,w) parameter space. Third, a
<<shaders-tessellation-evaluation,tessellation evaluation shader>>
transforms the vertices of the tessellated patch, for example to compute
their positions and attributes as part of the tessellated surface. The
tessellator is enabled when the pipeline contains both a tessellation
control shader and a tessellation evaluation shader.
== Tessellator
If a pipeline includes both tessellation shaders (control and evaluation),
the tessellator consumes each input patch (after vertex shading) and
produces a new set of independent primitives (points, lines, or triangles).
These primitives are logically produced by subdividing a geometric primitive
Change log for June 17, 2016 Vulkan 1.0.17 spec update: * Bump API patch number and header version number to 17 for this update. Github Issues: * Update description of vertex shader reuse in <<shaders-vertex-execution>> (public issue 106). * Simplify validity language around pname:ppEnabledExtensionNames and pname:ppEnabledLayerNames (in the <<initialization-instances>> and <<devsandqueues-device-creation>> sections) (public issue 214). * Add missing validity rule to flink:vkCmdBeginRenderPass requiring compatibility between slink:VkAttachmentDescription pname:initalLayout members and the corresponding attached framebuffer images (public issue 233). * Fix Unicode arrows appearing in output instead of relational operators (public issue 239). * Correctly describe the required number of elements for code:TessLevelInner and code:TessLevelOuter arrays in the <<interfaces-builtin-variables,Built-In Variables>> section as two and four, respectively, instead of the other way around, and refer to this section from the <<tessellation,Tessellation>> chapter (public issue 246). Internal Issues: * Document deprecation of ename:VK_COLORSPACE_SRGB_NONLINEAR_KHR in the VK_KHR_surface extension branch, and of ename:VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT in the VK_EXT_debug_report branch (internal issue 328). * Added language to define what a valid usage statement is and should be, with a note about some apparent weirdnesses this might entail (internal issue 357). Other Commits: * Added missing ename:VK_ERROR_DEVICE_LOST error to flink:vkQueueBindSparse.
2016-06-17 22:39:39 +00:00
(rectangle or triangle) according to the per-patch outer and inner
tessellation levels written by the tessellation control shader. These levels
are specified using the <<interfaces-builtin-variables,built-in variables>>
code:TessLevelOuter and code:TessLevelInner, respectively.
This subdivision is performed in
2016-02-16 09:53:44 +00:00
an implementation-dependent manner. If no tessellation shaders are present
in the pipeline, the tessellator is disabled and incoming primitives are
passed through without modification.
The type of subdivision performed by the tessellator is
specified by an code:OpExecutionMode instruction in the tessellation
evaluation or tessellation control shader using one of execution modes
code:Triangles, code:Quads, and code:IsoLines. Other
tessellation-related execution modes can: also be specified in either the
tessellation control or tessellation evaluation shaders, and if they are
specified in both then the modes must: be the same.
Tessellation execution modes include:
* code:Triangles, code:Quads, and code:IsoLines. These control the type of
subdivision and topology of the output primitives. One mode must: be set
in at least one of the tessellation shader stages.
* code:VertexOrderCw and code:VertexOrderCcw. These control the
orientation of triangles generated by the tessellator. One mode must: be
set in at least one of the tessellation shader stages.
* code:PointMode. Controls generation of points rather than triangles or
lines. This functionality defaults to disabled, and is enabled if either
shader stage includes the execution mode.
* code:SpacingEqual, code:SpacingFractionalEven, and
code:SpacingFractionalOdd. Controls the spacing of segments on the edges
of tessellated primitives. One mode must: be set in at least one of the
tessellation shader stages.
* code:OutputVertices. Controls the size of the output patch of the
tessellation control shader. One value must: be set in at least one of
the tessellation shader stages.
For triangles, the tessellator subdivides a triangle primitive into
smaller triangles. For quads, the tessellator subdivides a rectangle
primitive into smaller triangles. For isolines, the tessellator
subdivides a rectangle primitive into a collection of line segments arranged
in strips stretching across the rectangle in the latexmath:[$u$] dimension
(i.e. the coordinates in code:TessCoord are of the form (0,x) through (1,x)
for all tessellation evaluation shader invocations that share a line).
Each vertex produced by the tessellator has an associated (u,v,w) or (u,v)
2016-02-27 01:52:59 +00:00
position in a normalized parameter space, with parameter values in the range
2016-02-16 09:53:44 +00:00
latexmath:[$[0,1\]$], as illustrated in figure
<<img-tessellation-topology>>.
[[img-tessellation-topology]]
image::images/tessparam.{svgpdf}[align="center",title="Domain parameterization for tessellation primitive modes",{fullimagewidth}]
2016-02-16 09:53:44 +00:00
For triangles, the vertex's position is a barycentric coordinate (u,v,w),
where u + v + w = 1.0, and indicates the relative influence of the three
vertices of the triangle on the position of the vertex. For quads and
isolines, the position is a (u,v) coordinate indicating the relative
horizontal and vertical position of the vertex relative to the subdivided
rectangle. The subdivision process is explained in more detail in subsequent
sections.
== Tessellator Patch Discard
A patch is discarded by the tessellator if any
relevant outer tessellation level is less than or equal to zero.
Patches will also be discarded if any relevant outer tessellation level
corresponds to a floating-point NaN (not a number) in implementations
supporting NaN.
No new primitives are generated and the tessellation evaluation shader is
not executed for patches that are discarded. For code:Quads, all four outer
levels are relevant. For code:Triangles and code:IsoLines, only the first
three or two outer levels, respectively, are relevant. Negative inner levels
will not cause a patch to be discarded; they will be clamped as described
below.
[[tessellation-tessellator-spacing]]
== Tessellator Spacing
Each of the tessellation levels is used to determine the number and
spacing of segments used to subdivide a corresponding edge. The method
used to derive the number and spacing of segments is specified by an
code:OpExecutionMode in the tessellation control or tessellation evaluation
shader using one of the identifiers code:SpacingEqual,
code:SpacingFractionalEven, or code:SpacingFractionalOdd.
If code:SpacingEqual is used, the floating-point tessellation level is first
clamped to latexmath:[$[1,\mathit{maxLevel}\]$], where
latexmath:[$\mathit{maxLevel}$] is the implementation-dependent maximum
tessellation level
(sname:VkPhysicalDeviceLimits::pname:maxTessellationGenerationLevel). The
result is rounded up to the nearest integer latexmath:[$n$], and the
corresponding edge is divided into latexmath:[$n$] segments of equal length
in (u,v) space.
If code:SpacingFractionalEven is used, the tessellation level is first
clamped to latexmath:[$[2,\mathit{maxLevel}\]$] and then rounded up to the
nearest even integer latexmath:[$n$]. If code:SpacingFractionalOdd is used,
the tessellation level is clamped to latexmath:[$[1,\mathit{maxLevel}-1\]$]
and then rounded up to the nearest odd integer latexmath:[$n$]. If
latexmath:[$n$] is one, the edge will not be subdivided. Otherwise, the
corresponding edge will be divided into latexmath:[$n-2$] segments of equal
length, and two additional segments of equal length that are typically
shorter than the other segments. The length of the two additional segments
Change log for March 10, 2016 Vulkan 1.0.6 spec update: * Bump API patch number and header version number to 6 for this update. Github Issues: * Define 'invocation group' for compute and graphics shaders. Cleanup definition and use of 'workgroup', and add glossary entries (public issue 1). * Various minor editorial fixes (public issue 33). * Clarify locations for block members in the &lt;&lt;interfaces-iointerfaces-locations,Location Assignment>> section (public issue 45). * Editorial fixes for &lt;&lt;commandbuffer-allocation,Command Buffer Allocation>> section (public issues 54, 59). * Clarify behavior of depth test in the &lt;&lt;fragops-depth,Depth Test&gt;&gt; section (public issues 80, 81). * Remove discussion of return codes from flink:vkGetPhysicalDeviceSparseImageFormatProperties and flink:vkGetImageSparseMemoryRequirements, which don't return values (public issue 82). * Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect pname:drawCount of 0, as well as 1, when the multiDrawIndirect feature is not supported (public issue 88). * Remove confusing wording in the &lt;&lt;features-limits,Limits>> section describing the slink:VkPhysicalDeviceLimits pname:minTexelBufferOffsetAlignment, pname:minUniformBufferOffsetAlignment, and pname:minStorageBufferOffsetAlignment members as both minimums and maximums (public issue 91). * Clarified that only the RGB components should be affected in places where sRGB is referred to in the spec, such as ASTC formats. Minor re-wording to avoid "color space" when actively incorrect, now that we refer to the Data Format Spec which actually makes a distinction between color space and transfer function (public issue 94). * Treat pname:pPropertyCount == 0 consistently in flink:vkEnumerateInstanceLayerProperties and flink:vkEnumerateDeviceLayerProperties (public issue 99) * Cleanup minor editorial issues in chapters 14-17 (public issue 100). * Clarify definition of flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 101). * Define the flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties pname:pLayerName parameter to be a pointer to a null-terminated UTF-8 string (public issue 101). * Rearrange "Missing information" references in mandatory format tables (public issue 101). * Clarify that the enumerated extensions returned by flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties will only include extensions provided by the platform or extensions implemented in implicitly enabled layers (public issue 101). * Miscellaneous editorial fixes. Include the Vulkan spec patch number in the PDF title. Fix label on &lt;&lt;fig-non-strict-lines,Non strict lines>> diagram. Use more easily distinguished symbols in tables in the &lt;&lt;features-required-format-support,Required Format Support>> section. Don't require FQDNs used as layer names be encoded in lower case if not possible, in the &lt;&lt;extensions-naming-conventions, Extension and Layer Naming Conventions>> section (public issues 101, 119, 121). Internal Issues: * Fixed excessive spacing in tables in XHTML (internal issue 18). * Clarify that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT applies to secondary command buffers. Previously spec only referred to the members of pname:pCommandBuffers being affected by this bit. Added a separate slink:VkSubmitInfo Valid Usage restriction specifying that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT also applies to any secondary command buffers that are recorded into the primary command buffers in pname:pCommandBuffers (internal issue 106). * Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be NULL (internal issue 117). * Remove "the value of" where it is redundant (e.g. speaking of an API parameter, struct member, or SPIR-V variable, but not when speaking of color components) (internal issue 175). * Forced patch version to always be 0 in the header. Add a "VK_API_VERSION_<major>_<minor>" macro for people to use to do the right thing. Add a VK_HEADER_VERSION which captures the header release number independent of the spec patch number (internal issue 176). * Correct description of slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to a null-terminated UTF-8 string" (internal issue #197). Other Commits: * Updated DataFormat spec reference to the new date for revision 5 of that spec. * Fixed KEEP option (to retain LaTeX intermediate files) in the Makefile to be included when edited there, as well as set on the command line. * Reserve and add "VK_IMG_filter_cubic" to the registry, and implement script functionality to add and remove validity from existing functions. Includes schema and readme changes. * Update GL_KHR_vulkan_glsl so push_constants do not have descriptor sets.
2016-03-11 01:33:02 +00:00
relative to the others will decrease monotonically with
2016-02-16 09:53:44 +00:00
latexmath:[$n-f$], where latexmath:[$f$] is the clamped floating-point
tessellation level. When latexmath:[$n-f$] is zero, the additional segments
will have equal length to the other segments. As latexmath:[$n-f$]
approaches 2.0, the relative length of the additional segments approaches
zero. The two additional segments should: be placed symmetrically on
opposite sides of the subdivided edge. The relative location of these two
segments is implementation-dependent, but must: be identical for any pair of
Change log for March 10, 2016 Vulkan 1.0.6 spec update: * Bump API patch number and header version number to 6 for this update. Github Issues: * Define 'invocation group' for compute and graphics shaders. Cleanup definition and use of 'workgroup', and add glossary entries (public issue 1). * Various minor editorial fixes (public issue 33). * Clarify locations for block members in the &lt;&lt;interfaces-iointerfaces-locations,Location Assignment>> section (public issue 45). * Editorial fixes for &lt;&lt;commandbuffer-allocation,Command Buffer Allocation>> section (public issues 54, 59). * Clarify behavior of depth test in the &lt;&lt;fragops-depth,Depth Test&gt;&gt; section (public issues 80, 81). * Remove discussion of return codes from flink:vkGetPhysicalDeviceSparseImageFormatProperties and flink:vkGetImageSparseMemoryRequirements, which don't return values (public issue 82). * Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect pname:drawCount of 0, as well as 1, when the multiDrawIndirect feature is not supported (public issue 88). * Remove confusing wording in the &lt;&lt;features-limits,Limits>> section describing the slink:VkPhysicalDeviceLimits pname:minTexelBufferOffsetAlignment, pname:minUniformBufferOffsetAlignment, and pname:minStorageBufferOffsetAlignment members as both minimums and maximums (public issue 91). * Clarified that only the RGB components should be affected in places where sRGB is referred to in the spec, such as ASTC formats. Minor re-wording to avoid "color space" when actively incorrect, now that we refer to the Data Format Spec which actually makes a distinction between color space and transfer function (public issue 94). * Treat pname:pPropertyCount == 0 consistently in flink:vkEnumerateInstanceLayerProperties and flink:vkEnumerateDeviceLayerProperties (public issue 99) * Cleanup minor editorial issues in chapters 14-17 (public issue 100). * Clarify definition of flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 101). * Define the flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties pname:pLayerName parameter to be a pointer to a null-terminated UTF-8 string (public issue 101). * Rearrange "Missing information" references in mandatory format tables (public issue 101). * Clarify that the enumerated extensions returned by flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties will only include extensions provided by the platform or extensions implemented in implicitly enabled layers (public issue 101). * Miscellaneous editorial fixes. Include the Vulkan spec patch number in the PDF title. Fix label on &lt;&lt;fig-non-strict-lines,Non strict lines>> diagram. Use more easily distinguished symbols in tables in the &lt;&lt;features-required-format-support,Required Format Support>> section. Don't require FQDNs used as layer names be encoded in lower case if not possible, in the &lt;&lt;extensions-naming-conventions, Extension and Layer Naming Conventions>> section (public issues 101, 119, 121). Internal Issues: * Fixed excessive spacing in tables in XHTML (internal issue 18). * Clarify that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT applies to secondary command buffers. Previously spec only referred to the members of pname:pCommandBuffers being affected by this bit. Added a separate slink:VkSubmitInfo Valid Usage restriction specifying that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT also applies to any secondary command buffers that are recorded into the primary command buffers in pname:pCommandBuffers (internal issue 106). * Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be NULL (internal issue 117). * Remove "the value of" where it is redundant (e.g. speaking of an API parameter, struct member, or SPIR-V variable, but not when speaking of color components) (internal issue 175). * Forced patch version to always be 0 in the header. Add a "VK_API_VERSION_<major>_<minor>" macro for people to use to do the right thing. Add a VK_HEADER_VERSION which captures the header release number independent of the spec patch number (internal issue 176). * Correct description of slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to a null-terminated UTF-8 string" (internal issue #197). Other Commits: * Updated DataFormat spec reference to the new date for revision 5 of that spec. * Fixed KEEP option (to retain LaTeX intermediate files) in the Makefile to be included when edited there, as well as set on the command line. * Reserve and add "VK_IMG_filter_cubic" to the registry, and implement script functionality to add and remove validity from existing functions. Includes schema and readme changes. * Update GL_KHR_vulkan_glsl so push_constants do not have descriptor sets.
2016-03-11 01:33:02 +00:00
subdivided edges with identical values of latexmath:[$f$].
2016-02-16 09:53:44 +00:00
When the tessellator produces triangles (in the code:Triangles or
code:Quads modes), the orientation of all triangles is specified with
an code:OpExecutionMode of code:VertexOrderCw or code:VertexOrderCcw in the
tessellation control or tessellation evaluation shaders. If the order is
Change log for March 10, 2016 Vulkan 1.0.6 spec update: * Bump API patch number and header version number to 6 for this update. Github Issues: * Define 'invocation group' for compute and graphics shaders. Cleanup definition and use of 'workgroup', and add glossary entries (public issue 1). * Various minor editorial fixes (public issue 33). * Clarify locations for block members in the &lt;&lt;interfaces-iointerfaces-locations,Location Assignment>> section (public issue 45). * Editorial fixes for &lt;&lt;commandbuffer-allocation,Command Buffer Allocation>> section (public issues 54, 59). * Clarify behavior of depth test in the &lt;&lt;fragops-depth,Depth Test&gt;&gt; section (public issues 80, 81). * Remove discussion of return codes from flink:vkGetPhysicalDeviceSparseImageFormatProperties and flink:vkGetImageSparseMemoryRequirements, which don't return values (public issue 82). * Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect pname:drawCount of 0, as well as 1, when the multiDrawIndirect feature is not supported (public issue 88). * Remove confusing wording in the &lt;&lt;features-limits,Limits>> section describing the slink:VkPhysicalDeviceLimits pname:minTexelBufferOffsetAlignment, pname:minUniformBufferOffsetAlignment, and pname:minStorageBufferOffsetAlignment members as both minimums and maximums (public issue 91). * Clarified that only the RGB components should be affected in places where sRGB is referred to in the spec, such as ASTC formats. Minor re-wording to avoid "color space" when actively incorrect, now that we refer to the Data Format Spec which actually makes a distinction between color space and transfer function (public issue 94). * Treat pname:pPropertyCount == 0 consistently in flink:vkEnumerateInstanceLayerProperties and flink:vkEnumerateDeviceLayerProperties (public issue 99) * Cleanup minor editorial issues in chapters 14-17 (public issue 100). * Clarify definition of flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 101). * Define the flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties pname:pLayerName parameter to be a pointer to a null-terminated UTF-8 string (public issue 101). * Rearrange "Missing information" references in mandatory format tables (public issue 101). * Clarify that the enumerated extensions returned by flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties will only include extensions provided by the platform or extensions implemented in implicitly enabled layers (public issue 101). * Miscellaneous editorial fixes. Include the Vulkan spec patch number in the PDF title. Fix label on &lt;&lt;fig-non-strict-lines,Non strict lines>> diagram. Use more easily distinguished symbols in tables in the &lt;&lt;features-required-format-support,Required Format Support>> section. Don't require FQDNs used as layer names be encoded in lower case if not possible, in the &lt;&lt;extensions-naming-conventions, Extension and Layer Naming Conventions>> section (public issues 101, 119, 121). Internal Issues: * Fixed excessive spacing in tables in XHTML (internal issue 18). * Clarify that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT applies to secondary command buffers. Previously spec only referred to the members of pname:pCommandBuffers being affected by this bit. Added a separate slink:VkSubmitInfo Valid Usage restriction specifying that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT also applies to any secondary command buffers that are recorded into the primary command buffers in pname:pCommandBuffers (internal issue 106). * Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be NULL (internal issue 117). * Remove "the value of" where it is redundant (e.g. speaking of an API parameter, struct member, or SPIR-V variable, but not when speaking of color components) (internal issue 175). * Forced patch version to always be 0 in the header. Add a "VK_API_VERSION_<major>_<minor>" macro for people to use to do the right thing. Add a VK_HEADER_VERSION which captures the header release number independent of the spec patch number (internal issue 176). * Correct description of slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to a null-terminated UTF-8 string" (internal issue #197). Other Commits: * Updated DataFormat spec reference to the new date for revision 5 of that spec. * Fixed KEEP option (to retain LaTeX intermediate files) in the Makefile to be included when edited there, as well as set on the command line. * Reserve and add "VK_IMG_filter_cubic" to the registry, and implement script functionality to add and remove validity from existing functions. Includes schema and readme changes. * Update GL_KHR_vulkan_glsl so push_constants do not have descriptor sets.
2016-03-11 01:33:02 +00:00
code:VertexOrderCw, the vertices of all generated triangles will have
2016-02-16 09:53:44 +00:00
clockwise ordering in (u,v) or (u,v,w) space. If the order is
Change log for March 10, 2016 Vulkan 1.0.6 spec update: * Bump API patch number and header version number to 6 for this update. Github Issues: * Define 'invocation group' for compute and graphics shaders. Cleanup definition and use of 'workgroup', and add glossary entries (public issue 1). * Various minor editorial fixes (public issue 33). * Clarify locations for block members in the &lt;&lt;interfaces-iointerfaces-locations,Location Assignment>> section (public issue 45). * Editorial fixes for &lt;&lt;commandbuffer-allocation,Command Buffer Allocation>> section (public issues 54, 59). * Clarify behavior of depth test in the &lt;&lt;fragops-depth,Depth Test&gt;&gt; section (public issues 80, 81). * Remove discussion of return codes from flink:vkGetPhysicalDeviceSparseImageFormatProperties and flink:vkGetImageSparseMemoryRequirements, which don't return values (public issue 82). * Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect pname:drawCount of 0, as well as 1, when the multiDrawIndirect feature is not supported (public issue 88). * Remove confusing wording in the &lt;&lt;features-limits,Limits>> section describing the slink:VkPhysicalDeviceLimits pname:minTexelBufferOffsetAlignment, pname:minUniformBufferOffsetAlignment, and pname:minStorageBufferOffsetAlignment members as both minimums and maximums (public issue 91). * Clarified that only the RGB components should be affected in places where sRGB is referred to in the spec, such as ASTC formats. Minor re-wording to avoid "color space" when actively incorrect, now that we refer to the Data Format Spec which actually makes a distinction between color space and transfer function (public issue 94). * Treat pname:pPropertyCount == 0 consistently in flink:vkEnumerateInstanceLayerProperties and flink:vkEnumerateDeviceLayerProperties (public issue 99) * Cleanup minor editorial issues in chapters 14-17 (public issue 100). * Clarify definition of flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 101). * Define the flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties pname:pLayerName parameter to be a pointer to a null-terminated UTF-8 string (public issue 101). * Rearrange "Missing information" references in mandatory format tables (public issue 101). * Clarify that the enumerated extensions returned by flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties will only include extensions provided by the platform or extensions implemented in implicitly enabled layers (public issue 101). * Miscellaneous editorial fixes. Include the Vulkan spec patch number in the PDF title. Fix label on &lt;&lt;fig-non-strict-lines,Non strict lines>> diagram. Use more easily distinguished symbols in tables in the &lt;&lt;features-required-format-support,Required Format Support>> section. Don't require FQDNs used as layer names be encoded in lower case if not possible, in the &lt;&lt;extensions-naming-conventions, Extension and Layer Naming Conventions>> section (public issues 101, 119, 121). Internal Issues: * Fixed excessive spacing in tables in XHTML (internal issue 18). * Clarify that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT applies to secondary command buffers. Previously spec only referred to the members of pname:pCommandBuffers being affected by this bit. Added a separate slink:VkSubmitInfo Valid Usage restriction specifying that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT also applies to any secondary command buffers that are recorded into the primary command buffers in pname:pCommandBuffers (internal issue 106). * Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be NULL (internal issue 117). * Remove "the value of" where it is redundant (e.g. speaking of an API parameter, struct member, or SPIR-V variable, but not when speaking of color components) (internal issue 175). * Forced patch version to always be 0 in the header. Add a "VK_API_VERSION_<major>_<minor>" macro for people to use to do the right thing. Add a VK_HEADER_VERSION which captures the header release number independent of the spec patch number (internal issue 176). * Correct description of slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to a null-terminated UTF-8 string" (internal issue #197). Other Commits: * Updated DataFormat spec reference to the new date for revision 5 of that spec. * Fixed KEEP option (to retain LaTeX intermediate files) in the Makefile to be included when edited there, as well as set on the command line. * Reserve and add "VK_IMG_filter_cubic" to the registry, and implement script functionality to add and remove validity from existing functions. Includes schema and readme changes. * Update GL_KHR_vulkan_glsl so push_constants do not have descriptor sets.
2016-03-11 01:33:02 +00:00
code:VertexOrderCcw, the vertices will have counter-clockwise ordering.
The vertices of a triangle have counter-clockwise ordering if
2016-02-16 09:53:44 +00:00
[latexmath]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
\[
a = u_0 v_1 - u_1 v_0 + u_1 v_2 - u_2 v_1 + u_2 v_0 - u_0 v_2
\]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Change log for March 10, 2016 Vulkan 1.0.6 spec update: * Bump API patch number and header version number to 6 for this update. Github Issues: * Define 'invocation group' for compute and graphics shaders. Cleanup definition and use of 'workgroup', and add glossary entries (public issue 1). * Various minor editorial fixes (public issue 33). * Clarify locations for block members in the &lt;&lt;interfaces-iointerfaces-locations,Location Assignment>> section (public issue 45). * Editorial fixes for &lt;&lt;commandbuffer-allocation,Command Buffer Allocation>> section (public issues 54, 59). * Clarify behavior of depth test in the &lt;&lt;fragops-depth,Depth Test&gt;&gt; section (public issues 80, 81). * Remove discussion of return codes from flink:vkGetPhysicalDeviceSparseImageFormatProperties and flink:vkGetImageSparseMemoryRequirements, which don't return values (public issue 82). * Allow flink:vkCmdDrawIndirect and flink:vkCmdDrawIndexedIndirect pname:drawCount of 0, as well as 1, when the multiDrawIndirect feature is not supported (public issue 88). * Remove confusing wording in the &lt;&lt;features-limits,Limits>> section describing the slink:VkPhysicalDeviceLimits pname:minTexelBufferOffsetAlignment, pname:minUniformBufferOffsetAlignment, and pname:minStorageBufferOffsetAlignment members as both minimums and maximums (public issue 91). * Clarified that only the RGB components should be affected in places where sRGB is referred to in the spec, such as ASTC formats. Minor re-wording to avoid "color space" when actively incorrect, now that we refer to the Data Format Spec which actually makes a distinction between color space and transfer function (public issue 94). * Treat pname:pPropertyCount == 0 consistently in flink:vkEnumerateInstanceLayerProperties and flink:vkEnumerateDeviceLayerProperties (public issue 99) * Cleanup minor editorial issues in chapters 14-17 (public issue 100). * Clarify definition of flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties (public issue 101). * Define the flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties pname:pLayerName parameter to be a pointer to a null-terminated UTF-8 string (public issue 101). * Rearrange "Missing information" references in mandatory format tables (public issue 101). * Clarify that the enumerated extensions returned by flink:vkEnumerateInstanceExtensionProperties and flink:vkEnumerateDeviceExtensionProperties will only include extensions provided by the platform or extensions implemented in implicitly enabled layers (public issue 101). * Miscellaneous editorial fixes. Include the Vulkan spec patch number in the PDF title. Fix label on &lt;&lt;fig-non-strict-lines,Non strict lines>> diagram. Use more easily distinguished symbols in tables in the &lt;&lt;features-required-format-support,Required Format Support>> section. Don't require FQDNs used as layer names be encoded in lower case if not possible, in the &lt;&lt;extensions-naming-conventions, Extension and Layer Naming Conventions>> section (public issues 101, 119, 121). Internal Issues: * Fixed excessive spacing in tables in XHTML (internal issue 18). * Clarify that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT applies to secondary command buffers. Previously spec only referred to the members of pname:pCommandBuffers being affected by this bit. Added a separate slink:VkSubmitInfo Valid Usage restriction specifying that ename:VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT also applies to any secondary command buffers that are recorded into the primary command buffers in pname:pCommandBuffers (internal issue 106). * Clarify that slink:VkDeviceCreateInfo::pname:pEnabledFeatures can be NULL (internal issue 117). * Remove "the value of" where it is redundant (e.g. speaking of an API parameter, struct member, or SPIR-V variable, but not when speaking of color components) (internal issue 175). * Forced patch version to always be 0 in the header. Add a "VK_API_VERSION_<major>_<minor>" macro for people to use to do the right thing. Add a VK_HEADER_VERSION which captures the header release number independent of the spec patch number (internal issue 176). * Correct description of slink:VkPipelineShaderStageCreateInfo::pname:pName to "a pointer to a null-terminated UTF-8 string" (internal issue #197). Other Commits: * Updated DataFormat spec reference to the new date for revision 5 of that spec. * Fixed KEEP option (to retain LaTeX intermediate files) in the Makefile to be included when edited there, as well as set on the command line. * Reserve and add "VK_IMG_filter_cubic" to the registry, and implement script functionality to add and remove validity from existing functions. Includes schema and readme changes. * Update GL_KHR_vulkan_glsl so push_constants do not have descriptor sets.
2016-03-11 01:33:02 +00:00
is positive, and clockwise ordering if latexmath:[$a$] is negative.
latexmath:[$u_i$] and latexmath:[$v_i$] are the latexmath:[$u$] and
latexmath:[$v$] coordinates in normalized parameter space of the
latexmath:[$i$]th vertex of the triangle.
2016-02-16 09:53:44 +00:00
[NOTE]
.Note
====
The value latexmath:[$a$] is proportional (with a positive factor) to the
signed area of the triangle.
In code:Triangles mode, even though the vertex coordinates have a
latexmath:[$w$] value, it does not participate directly in the computation
of latexmath:[$a$], being an affine combination of latexmath:[$u$] and
latexmath:[$v$].
====
For all primitive modes, the tessellator is capable of generating points
instead of lines or triangles. If the tessellation control or tessellation
evaluation shader specifies the code:OpExecutionMode code:PointMode, the
primitive generator will generate one point for each distinct vertex
produced by tessellation. Otherwise, the tessellator will produce a
collection of line segments or triangles according to the primitive mode.
When tessellating triangles or quads in point mode with fractional odd
spacing, the tessellator may: produce _interior vertices_ that are
positioned on the edge of the patch if an inner tessellation level is less
than or equal to one. Such vertices are considered distinct from vertices
produced by subdividing the outer edge of the patch, even if there are pairs
of vertices with identical coordinates.
The points, lines, or triangles produced by the tessellator
are passed to subsequent pipeline stages in an
implementation-dependent order.
[[tessellation-triangle-tessellation]]
== Triangle Tessellation
If the tessellation primitive mode is code:Triangles, an equilateral
triangle is subdivided into a collection of triangles covering the area of
the original triangle. First, the original triangle is subdivided into a
collection of concentric equilateral triangles. The edges of each of these
triangles are subdivided, and the area between each triangle pair is filled
by triangles produced by joining the vertices on the subdivided edges. The
number of concentric triangles and the number of subdivisions along each
triangle except the outermost is derived from the first inner tessellation
level. The edges of the outermost triangle are subdivided independently,
using the first, second, and third outer tessellation levels to control the
number of subdivisions of the latexmath:[$u=0$] (left), latexmath:[$v=0$]
(bottom), and latexmath:[$w=0$] (right) edges, respectively. The second
inner tessellation level and the fourth outer tessellation level have no
effect in this mode.
If the first inner tessellation level and all three outer tessellation
levels are exactly one after clamping and rounding, only a single triangle
with (u,v,w) coordinates of (0,0,1), (1,0,0), and (0,1,0) is generated.
If the inner tessellation level is one and any of the outer tessellation
levels is greater than one, the inner tessellation level is treated as
though it were originally specified as latexmath:[$1+\epsilon$] and will
result in a two- or three-segment subdivision depending on the tessellation
spacing. When used with fractional odd spacing, the three-segment
subdivision may: produce _inner vertices_ positioned on the edge of the
triangle.
If any tessellation level is greater than one, tessellation begins by
producing a set of concentric inner triangles and subdividing their edges.
First, the three outer edges are temporarily subdivided using the clamped
and rounded first inner tessellation level and the specified tessellation
spacing, generating latexmath:[$n$] segments. For the outermost inner
triangle, the inner triangle is degenerate -- a single point at the center
of the triangle -- if latexmath:[$n$] is two. Otherwise, for each corner of
the outer triangle, an inner triangle corner is produced at the intersection
of two lines extended perpendicular to the corner's two adjacent edges
running through the vertex of the subdivided outer edge nearest that corner.
If latexmath:[$n$] is three, the edges of the inner triangle are not
subdivided and is the final triangle in the set of concentric triangles.
Otherwise, each edge of the inner triangle is divided into latexmath:[$n-2$]
segments, with the latexmath:[$n-1$] vertices of this subdivision produced
by intersecting the inner edge with lines perpendicular to the edge running
through the latexmath:[$n-1$] innermost vertices of the subdivision of the
outer edge. Once the outermost inner triangle is subdivided, the previous
subdivision process repeats itself, using the generated triangle as an outer
triangle. This subdivision process is illustrated in <<img-innertri,Inner
Triangle Tessellation>>.
[[img-innertri]]
image::images/innertri.{svgpdf}[align="center",title="Inner Triangle Tessellation",{fullimagewidth}]
2016-02-16 09:53:44 +00:00
// TODO: Add caption:
// Inner triangle tessellation with inner tessellation
// levels of (a) five and (b) four, respectively (not to scale). Solid
// black circles depict vertices along the edges of the concentric
// triangles. The edges of inner triangles are subdivided by intersecting
// the edge with segments perpendicular to the edge passing through each
// inner vertex of the subdivided outer edge. Dotted lines depict edges
// connecting corresponding vertices on the inner and outer triangle
// edges.
Once all the concentric triangles are produced and their edges are
subdivided, the area between each pair of adjacent inner triangles is
filled completely with a set of non-overlapping triangles. In this
subdivision, two of the three vertices of each triangle are taken from
adjacent vertices on a subdivided edge of one triangle; the third is one
of the vertices on the corresponding edge of the other triangle. If the
innermost triangle is degenerate (i.e., a point), the triangle containing
it is subdivided into six triangles by connecting each of the six vertices
on that triangle with the center point. If the innermost triangle is not
degenerate, that triangle is added to the set of generated triangles
as-is.
After the area corresponding to any inner triangles is filled, the
tessellator generates triangles to cover the area between the outermost
triangle and the outermost inner triangle. To do this, the temporary
subdivision of the outer triangle edge above is discarded. Instead, the
latexmath:[$u=0$], latexmath:[$v=0$], and latexmath:[$w=0$] edges are
subdivided according to the first, second, and third outer tessellation
levels, respectively, and the tessellation spacing. The original subdivision
of the first inner triangle is retained. The area between the outer and
first inner triangles is completely filled by non-overlapping triangles as
described above. If the first (and only) inner triangle is degenerate, a set
of triangles is produced by connecting each vertex on the outer triangle
edges with the center point.
After all triangles are generated, each vertex in the subdivided triangle
is assigned a barycentric (u,v,w) coordinate based on its location
relative to the three vertices of the outer triangle.
The algorithm used to subdivide the triangular domain in (u,v,w) space into
individual triangles is implementation-dependent. However, the set of
triangles produced will completely cover the domain, and no portion of the
domain will be covered by multiple triangles. The order in which the
generated triangles passed to subsequent pipeline stages and the order of
the vertices in those triangles are both implementation-dependent. However,
when depicted in a manner similar to <<img-innertri,Inner Triangle
Tessellation>>, the order of the vertices in the generated triangles will be
either all clockwise or all counter-clockwise, according to the vertex order
layout declaration.
[[tessellation-quad-tessellation]]
== Quad Tessellation
If the tessellation primitive mode is code:Quads, a rectangle is subdivided
into a collection of triangles covering the area of the original rectangle.
First, the original rectangle is subdivided into a regular mesh of
rectangles, where the number of rectangles along the latexmath:[$u=0$] and
latexmath:[$u=1$] (vertical) and latexmath:[$v=0$] and latexmath:[$v=1$]
(horizontal) edges are derived from the first and second inner tessellation
levels, respectively. All rectangles, except those adjacent to one of the
outer rectangle edges, are decomposed into triangle pairs. The outermost
rectangle edges are subdivided independently, using the first, second,
third, and fourth outer tessellation levels to control the number of
subdivisions of the latexmath:[$u=0$] (left), latexmath:[$v=0$] (bottom),
latexmath:[$u=1$] (right), and latexmath:[$v=1$] (top) edges, respectively.
The area between the inner rectangles of the mesh and the outer rectangle
edges are filled by triangles produced by joining the vertices on the
subdivided outer edges to the vertices on the edge of the inner rectangle
mesh.
If both clamped inner tessellation levels and all four clamped outer
tessellation levels are exactly one, only a single triangle pair covering
the outer rectangle is generated. Otherwise, if either clamped inner
tessellation level is one, that tessellation level is treated as though it
were originally specified as latexmath:[$1+\epsilon$] and will result in a
two- or three-segment subdivision depending on the tessellation spacing.
When used with fractional odd spacing, the three-segment subdivision may:
produce _inner vertices_ positioned on the edge of the rectangle.
If any tessellation level is greater than one, tessellation begins by
subdividing the latexmath:[$u=0$] and latexmath:[$u=1$] edges of the outer
rectangle into latexmath:[$m$] segments using the clamped and rounded first
inner tessellation level and the tessellation spacing. The latexmath:[$v=0$]
and latexmath:[$v=1$] edges are subdivided into latexmath:[$n$] segments
using the second inner tessellation level. Each vertex on the
latexmath:[$u=0$] and latexmath:[$v=0$] edges are joined with the
corresponding vertex on the latexmath:[$u=1$] and latexmath:[$v=1$] edges to
produce a set of vertical and horizontal lines that divide the rectangle
into a grid of smaller rectangles. The primitive generator emits a pair of
non-overlapping triangles covering each such rectangle not adjacent to an
edge of the outer rectangle. The boundary of the region covered by these
triangles forms an inner rectangle, the edges of which are subdivided by the
grid vertices that lie on the edge. If either latexmath:[$m$] or
latexmath:[$n$] is two, the inner rectangle is degenerate, and one or both
of the rectangle's _edges_ consist of a single point. This subdivision is
illustrated in Figure <<img-innerquad,Inner Quad Tessellation>>.
[[img-innerquad]]
image::images/innerquad.{svgpdf}[align="center",title="Inner Quad Tessellation",{fullimagewidth}]
2016-02-16 09:53:44 +00:00
// TODO: Add caption:
// Inner quad tessellation with inner tessellation
// levels of
// (a) $(4,2)$ and (b) $(7,4)$, respectively. Gray regions on the
// bottom figure
// depict the 10 inner rectangles, each of which will be subdivided
// into two triangles.
// Solid black circles depict vertices on the boundary of the outer and
// inner rectangles,
// where the inner rectangle on the top figure
// is degenerate (a single line segment). Dotted lines depict the
// horizontal and vertical edges connecting corresponding
// vertices on the inner and outer rectangle edges.
After the area corresponding to the inner rectangle is filled, the
tessellator must: produce triangles to cover the area between the inner and
outer rectangles. To do this, the subdivision of the outer rectangle edge
above is discarded. Instead, the latexmath:[$u=0$], latexmath:[$v=0$],
latexmath:[$u=1$], and latexmath:[$v=1$] edges are subdivided according to
the first, second, third, and fourth outer tessellation levels,
respectively, and the tessellation spacing. The original subdivision of the
inner rectangle is retained. The area between the outer and inner rectangles
is completely filled by non-overlapping triangles. Two of the three vertices
of each triangle are adjacent vertices on a subdivided edge of one
rectangle; the third is one of the vertices on the corresponding edge of the
other triangle. If either edge of the innermost rectangle is degenerate, the
area near the corresponding outer edges is filled by connecting each vertex
on the outer edge with the single vertex making up the _inner edge_.
The algorithm used to subdivide the rectangular domain in (u,v) space into
individual triangles is implementation-dependent. However, the set of
triangles produced will completely cover the domain, and no portion of the
domain will be covered by multiple triangles. The order in which the
generated triangles passed to subsequent pipeline stages and the order of
the vertices in those triangles are both implementation-dependent.
However, when depicted in a manner similar to <<img-innerquad,Inner Quad
Tessellation>>, the order of the vertices in the generated triangles will be
either all clockwise or all counter-clockwise, according to the vertex order
layout declaration.
[[tessellation-isoline-tessellation]]
== Isoline Tessellation
If the tessellation primitive mode is code:IsoLines, a set of independent
horizontal line segments is drawn. The segments are arranged into
connected strips called _isolines_, where the vertices of each isoline
have a constant v coordinate and u coordinates covering the full range
[0,1]. The number of isolines generated is derived from the first outer
tessellation level; the number of segments in each isoline is derived from
the second outer tessellation level. Both inner tessellation levels and
the third and fourth outer tessellation levels have no effect in this
mode.
As with quad tessellation above, isoline tessellation begins with a
rectangle. The latexmath:[$u=0$] and latexmath:[$u=1$] edges of the
rectangle are subdivided according to the first outer tessellation level.
For the purposes of this subdivision, the tessellation spacing mode is
ignored and treated as equal_spacing. An isoline is drawn connecting each
vertex on the latexmath:[$u=0$] rectangle edge to the corresponding vertex
on the latexmath:[$u=1$] rectangle edge, except that no line is drawn
between (0,1) and (1,1). If the number of isolines on the subdivided
latexmath:[$u=0$] and latexmath:[$u=1$] edges is latexmath:[$n$], this
process will result in latexmath:[$n$] equally spaced lines with constant v
coordinates of 0, latexmath:[$\frac{1}{n}, \frac{2}{n}, \ldots,
\frac{n-1}{n}$].
Each of the latexmath:[$n$] isolines is then subdivided according to the
second outer tessellation level and the tessellation spacing, resulting in
latexmath:[$m$] line segments. Each segment of each line is emitted by the
tessellator.
The order in which the generated line segments are passed to subsequent
pipeline stages and the order of the vertices in each generated line
segment are both implementation-dependent.
== Tessellation Pipeline State
Change log for April 22, 2016 Vulkan 1.0.11 spec update: * Bump API patch number and header version number to 11 for this update. Github Issues: * Clarify the WSI extension language by switching from the fuzzier "ownership" language to more-consistent "acquire" language (public issue 117). * Clarify that memory barriers apply to all commands in the dependency chains in the flink:vkGetRenderAreaGranularity command and the <<synchronization-execution-and-memory-dependencies,Execution And Memory Dependencies>> section (public issue 132). * Clarify that a queue family is a set of queues in the <<fundamentals-execmodel,Execution Model>> section (public issue 166). * Removed requirement from valid usage language that VkPresentInfoKHR::waitSemaphoreCount must be greater than 0 (public issue 171). * Fix broken internal links, describe structures consistently, use consistent style for SPIR-V codewords, and tag normative terms that were missing asciidoc tags (public issue 183 and ancillary markup/normative language fixes). * Fix typos for slink:VkPhysicalDeviceLimits member names in slink:VkImageCreateInfo validity language (public issue 184). Internal Issues: * Document that the requested patch version number specified as part of slink:VkApplicationInfo::pname:apiVersion is ignored when creating an instance (internal issue 176). * Clarify handling of extension structs in the <<fundamentals-validusageValid Usage>> section (internal issue 254). * Update required slink:VkImageFormatProperties::pname:maxMipLevels to be limited to the maximum allowed mipmap pyramid size corresponding to the actual maximum supported size for the format (internal issue 256). * Modify the <<features-extentperimagetype,Allowed Extent Values Based On Image Type>> section so the allowed maximum extent is the maximum image dimension supported for each dimension of the type of texture being queried (internal issue 257). * Clarify in the <<spirvenv-module-validation,Validation Rules within a Module>> section that at least one of the code:LocalSize execution mode or code:WorkgroupSize decoration is required for each compute shader entry point in a shader module (internal issue 279). * Add validity rules for formats in flink:vkCmdClearColorImage and flink:vkCmdClearDepthStencilImage (internal issue 283). * Clarify that slink:VkImageFormatProperties::pname:maxResourceSize is an upper bound, and that it may not be possible to create an image anywhere near that size (internal issue 284). Other Commits: * Fix various minor markup errors reported by validation scripts. * Change copyright from Khronos Free Use License to Apache 2.0 license on relevant script/XML/header files. This does not affect the specification source copyright.
2016-04-21 08:08:38 +00:00
The pname:pTessellationState member of slink:VkGraphicsPipelineCreateInfo
points to a structure of type sname:VkPipelineTessellationStateCreateInfo.
2016-02-16 09:53:44 +00:00
Change log for April 22, 2016 Vulkan 1.0.11 spec update: * Bump API patch number and header version number to 11 for this update. Github Issues: * Clarify the WSI extension language by switching from the fuzzier "ownership" language to more-consistent "acquire" language (public issue 117). * Clarify that memory barriers apply to all commands in the dependency chains in the flink:vkGetRenderAreaGranularity command and the <<synchronization-execution-and-memory-dependencies,Execution And Memory Dependencies>> section (public issue 132). * Clarify that a queue family is a set of queues in the <<fundamentals-execmodel,Execution Model>> section (public issue 166). * Removed requirement from valid usage language that VkPresentInfoKHR::waitSemaphoreCount must be greater than 0 (public issue 171). * Fix broken internal links, describe structures consistently, use consistent style for SPIR-V codewords, and tag normative terms that were missing asciidoc tags (public issue 183 and ancillary markup/normative language fixes). * Fix typos for slink:VkPhysicalDeviceLimits member names in slink:VkImageCreateInfo validity language (public issue 184). Internal Issues: * Document that the requested patch version number specified as part of slink:VkApplicationInfo::pname:apiVersion is ignored when creating an instance (internal issue 176). * Clarify handling of extension structs in the <<fundamentals-validusageValid Usage>> section (internal issue 254). * Update required slink:VkImageFormatProperties::pname:maxMipLevels to be limited to the maximum allowed mipmap pyramid size corresponding to the actual maximum supported size for the format (internal issue 256). * Modify the <<features-extentperimagetype,Allowed Extent Values Based On Image Type>> section so the allowed maximum extent is the maximum image dimension supported for each dimension of the type of texture being queried (internal issue 257). * Clarify in the <<spirvenv-module-validation,Validation Rules within a Module>> section that at least one of the code:LocalSize execution mode or code:WorkgroupSize decoration is required for each compute shader entry point in a shader module (internal issue 279). * Add validity rules for formats in flink:vkCmdClearColorImage and flink:vkCmdClearDepthStencilImage (internal issue 283). * Clarify that slink:VkImageFormatProperties::pname:maxResourceSize is an upper bound, and that it may not be possible to create an image anywhere near that size (internal issue 284). Other Commits: * Fix various minor markup errors reported by validation scripts. * Change copyright from Khronos Free Use License to Apache 2.0 license on relevant script/XML/header files. This does not affect the specification source copyright.
2016-04-21 08:08:38 +00:00
The sname:VkPipelineTessellationStateCreateInfo structure is defined as:
2016-02-16 09:53:44 +00:00
Change log for April 22, 2016 Vulkan 1.0.11 spec update: * Bump API patch number and header version number to 11 for this update. Github Issues: * Clarify the WSI extension language by switching from the fuzzier "ownership" language to more-consistent "acquire" language (public issue 117). * Clarify that memory barriers apply to all commands in the dependency chains in the flink:vkGetRenderAreaGranularity command and the <<synchronization-execution-and-memory-dependencies,Execution And Memory Dependencies>> section (public issue 132). * Clarify that a queue family is a set of queues in the <<fundamentals-execmodel,Execution Model>> section (public issue 166). * Removed requirement from valid usage language that VkPresentInfoKHR::waitSemaphoreCount must be greater than 0 (public issue 171). * Fix broken internal links, describe structures consistently, use consistent style for SPIR-V codewords, and tag normative terms that were missing asciidoc tags (public issue 183 and ancillary markup/normative language fixes). * Fix typos for slink:VkPhysicalDeviceLimits member names in slink:VkImageCreateInfo validity language (public issue 184). Internal Issues: * Document that the requested patch version number specified as part of slink:VkApplicationInfo::pname:apiVersion is ignored when creating an instance (internal issue 176). * Clarify handling of extension structs in the <<fundamentals-validusageValid Usage>> section (internal issue 254). * Update required slink:VkImageFormatProperties::pname:maxMipLevels to be limited to the maximum allowed mipmap pyramid size corresponding to the actual maximum supported size for the format (internal issue 256). * Modify the <<features-extentperimagetype,Allowed Extent Values Based On Image Type>> section so the allowed maximum extent is the maximum image dimension supported for each dimension of the type of texture being queried (internal issue 257). * Clarify in the <<spirvenv-module-validation,Validation Rules within a Module>> section that at least one of the code:LocalSize execution mode or code:WorkgroupSize decoration is required for each compute shader entry point in a shader module (internal issue 279). * Add validity rules for formats in flink:vkCmdClearColorImage and flink:vkCmdClearDepthStencilImage (internal issue 283). * Clarify that slink:VkImageFormatProperties::pname:maxResourceSize is an upper bound, and that it may not be possible to create an image anywhere near that size (internal issue 284). Other Commits: * Fix various minor markup errors reported by validation scripts. * Change copyright from Khronos Free Use License to Apache 2.0 license on relevant script/XML/header files. This does not affect the specification source copyright.
2016-04-21 08:08:38 +00:00
include::../structs/VkPipelineTessellationStateCreateInfo.txt[]
2016-02-16 09:53:44 +00:00
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:flags is reserved for future use.
* pname:patchControlPoints number of control points per patch.
include::../validity/structs/VkPipelineTessellationStateCreateInfo.txt[]