Change log for September 15, 2017 Vulkan 1.0.61 spec update:
* Bump API patch number and header version number to 61 for this update.
Github Issues:
* Provide alternate length attributes (altlen=) in the XML schema, for
those using length attributes to generate code instead of documentation
(public issue 555).
* Fix erroneous references to `latex:` being used for asciidoc math
markup, rather than `latexmath:` (public pull request 556).
* Add author ID to XML for Kazan software renderer (public pull request
557).
Internal Issues:
* Add the <<fundamentals-abi,Application Binary Interface>> section
describing platform ABI requirements and recommendations, add examples
of function and function pointer declarations to the
<<boilerplate-platform-specific-calling-conventions, Platform-Specific
Calling Conventions>> section, and remove related language that existed
elsewhere in the specification (internal issue 64).
* Describe where to document valid usage interactions of chained
structures in the style guide, and fix one case now appearing in
slink:VkBufferCreateInfo instead of the child
slink:VkDedicatedAllocationBufferCreateInfoNV structure (internal issue
715).
* Add example to the style guide of describing enumerated types which are
empty when the spec is built without relevant extensions enabled, and
apply it to existing examples for
elink:VkDescriptorSetLayoutCreateFlagBits and
elink:VkSubpassDescriptionFlagBits (internal issue 864).
* Add a note to the <<fundamentals-validusage-enums, Valid Usage for
Enumerated Types>> section that the special values suffixed with
etext:_BEGIN_RANGE, etext:_END_RANGE, etext:_RANGE_SIZE and
etext:_MAX_ENUM are not part of the API and should: not be used by
applications (internal issue 872).
* Added note to flink:vkCmdUpdateBuffers explaining the performance
penalty for copies done in this way, and why the upper copy limit is
what it is (internal issue 952).
* Update `VK_KHX_device_group` to split some functionality into the new
`VK_KHR_bind_memory2` extension, and rename that functionality (internal
issue 969).
* Remove *Status* fields from extension appendices, since they are by
definition published and complete by the time they reach the public
github repository (internal issue 973).
Other Issues:
* Update Data Format specification dependency to version 1.2 and change
references to DF sections accordingly.
* Update XML to make the pname:pAllocator parameter of
flink:vkRegisterDeviceEventEXT and flink:vkRegisterDisplayEventEXT in
the `VK_EXT_display_control` extension as optional.
New Extensions:
* `VK_KHR_bind_memory2`
* `VK_KHR_image_format_list`
* `VK_KHR_maintenance2`
* `VK_KHR_sampler_ycbcr_conversion`
2017-09-15 05:41:33 +00:00
|
|
|
// Copyright (c) 2016-2017 Khronos Group. This work is licensed under a
|
|
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
|
|
|
|
include::meta/VK_KHR_maintenance2.txt[]
|
|
|
|
|
|
|
|
*Last Modified Date*::
|
2017-10-26 17:45:00 +00:00
|
|
|
2017-04-28
|
Change log for September 15, 2017 Vulkan 1.0.61 spec update:
* Bump API patch number and header version number to 61 for this update.
Github Issues:
* Provide alternate length attributes (altlen=) in the XML schema, for
those using length attributes to generate code instead of documentation
(public issue 555).
* Fix erroneous references to `latex:` being used for asciidoc math
markup, rather than `latexmath:` (public pull request 556).
* Add author ID to XML for Kazan software renderer (public pull request
557).
Internal Issues:
* Add the <<fundamentals-abi,Application Binary Interface>> section
describing platform ABI requirements and recommendations, add examples
of function and function pointer declarations to the
<<boilerplate-platform-specific-calling-conventions, Platform-Specific
Calling Conventions>> section, and remove related language that existed
elsewhere in the specification (internal issue 64).
* Describe where to document valid usage interactions of chained
structures in the style guide, and fix one case now appearing in
slink:VkBufferCreateInfo instead of the child
slink:VkDedicatedAllocationBufferCreateInfoNV structure (internal issue
715).
* Add example to the style guide of describing enumerated types which are
empty when the spec is built without relevant extensions enabled, and
apply it to existing examples for
elink:VkDescriptorSetLayoutCreateFlagBits and
elink:VkSubpassDescriptionFlagBits (internal issue 864).
* Add a note to the <<fundamentals-validusage-enums, Valid Usage for
Enumerated Types>> section that the special values suffixed with
etext:_BEGIN_RANGE, etext:_END_RANGE, etext:_RANGE_SIZE and
etext:_MAX_ENUM are not part of the API and should: not be used by
applications (internal issue 872).
* Added note to flink:vkCmdUpdateBuffers explaining the performance
penalty for copies done in this way, and why the upper copy limit is
what it is (internal issue 952).
* Update `VK_KHX_device_group` to split some functionality into the new
`VK_KHR_bind_memory2` extension, and rename that functionality (internal
issue 969).
* Remove *Status* fields from extension appendices, since they are by
definition published and complete by the time they reach the public
github repository (internal issue 973).
Other Issues:
* Update Data Format specification dependency to version 1.2 and change
references to DF sections accordingly.
* Update XML to make the pname:pAllocator parameter of
flink:vkRegisterDeviceEventEXT and flink:vkRegisterDisplayEventEXT in
the `VK_EXT_display_control` extension as optional.
New Extensions:
* `VK_KHR_bind_memory2`
* `VK_KHR_image_format_list`
* `VK_KHR_maintenance2`
* `VK_KHR_sampler_ycbcr_conversion`
2017-09-15 05:41:33 +00:00
|
|
|
*Contributors*::
|
|
|
|
- Michael Worcester, Imagination Technologies
|
|
|
|
- Stuart Smith, Imagination Technologies
|
|
|
|
- Jeff Bolz, NVIDIA
|
|
|
|
- Daniel Koch, NVIDIA
|
|
|
|
- Jan-Harald Fredriksen, ARM
|
|
|
|
- Daniel Rakos, AMD
|
|
|
|
- Neil Henning, Codeplay
|
|
|
|
- Piers Daniell, NVIDIA
|
|
|
|
|
|
|
|
+VK_KHR_maintenance2+ adds a collection of minor features that were
|
|
|
|
intentionally left out or overlooked from the original Vulkan 1.0 release.
|
|
|
|
|
|
|
|
The new features are as follows:
|
|
|
|
|
|
|
|
* Allow the application to specify which aspect of an input attachment
|
|
|
|
might be read for a given subpass.
|
|
|
|
* Allow implementations to express the clipping behavior of points.
|
|
|
|
* Allow creating images with usage flags that may not be supported for the
|
|
|
|
base image's format, but are supported for image views of the image that
|
|
|
|
have a different but compatible format.
|
|
|
|
* Allow creating uncompressed image views of compressed images.
|
|
|
|
* Allow the application to select between an upper-left and lower-left
|
|
|
|
origin for the tessellation domain space.
|
|
|
|
* Adds two new image layouts for depth stencil images to allow either the
|
|
|
|
depth or stencil aspect to be read-only while the other aspect is
|
|
|
|
writable.
|
|
|
|
|
|
|
|
=== Input Attachment Specification
|
|
|
|
|
|
|
|
Input attachment specification allows an application to specify which aspect
|
|
|
|
of a multi-aspect image (e.g. a combined depth stencil format) will be
|
|
|
|
accessed via a subpassLoad operation.
|
|
|
|
|
|
|
|
On some implementations there may: be a performance penalty if the
|
|
|
|
implementation does not know (at flink:vkCreateRenderPass time) which
|
|
|
|
aspect(s) of multi-aspect images can: be be accessed as input attachments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=== New Object Types
|
|
|
|
|
|
|
|
None.
|
|
|
|
|
|
|
|
=== New Enum Constants
|
|
|
|
|
|
|
|
* Extending elink:VkStructureType:
|
|
|
|
** ename:VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR
|
|
|
|
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_POINT_CLIPPING_PROPERTIES_KHR
|
|
|
|
** ename:VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO_KHR
|
|
|
|
** ename:VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_DOMAIN_ORIGIN_STATE_CREATE_INFO_KHR
|
|
|
|
|
|
|
|
* Extending elink:VkImageCreateFlagBits:
|
|
|
|
** ename:VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR
|
|
|
|
** ename:VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR
|
|
|
|
|
|
|
|
* Extending elink:VkImageLayout
|
|
|
|
** ename:VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR
|
|
|
|
** ename:VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR
|
|
|
|
|
|
|
|
* ename:VK_POINT_CLIPPING_BEHAVIOR_ALL_CLIP_PLANES_KHR
|
|
|
|
* ename:VK_POINT_CLIPPING_BEHAVIOR_USER_CLIP_PLANES_ONLY_KHR
|
|
|
|
|
|
|
|
=== New Enums
|
|
|
|
|
|
|
|
* slink:VkPointClippingBehaviorKHR
|
|
|
|
* slink:VkTessellationDomainOriginKHR
|
|
|
|
|
|
|
|
=== New Structures
|
|
|
|
|
|
|
|
* slink:VkPhysicalDevicePointClippingPropertiesKHR
|
|
|
|
* slink:VkRenderPassInputAttachmentAspectCreateInfoKHR
|
|
|
|
* slink:VkInputAttachmentAspectReferenceKHR
|
|
|
|
* slink:VkImageViewUsageCreateInfoKHR
|
|
|
|
* slink:VkPipelineTessellationDomainOriginStateCreateInfoKHR
|
|
|
|
|
|
|
|
=== New Functions
|
|
|
|
|
|
|
|
None.
|
|
|
|
|
|
|
|
=== Input Attachment Specification Example
|
|
|
|
|
|
|
|
Consider the case where a render pass has two subpasses and two attachments.
|
|
|
|
|
|
|
|
Attachment 0 has the format VK_FORMAT_D24_UNORM_S8_UINT, attachment 1 has
|
|
|
|
some color format.
|
|
|
|
|
|
|
|
Subpass 0 writes to attachment 0, subpass 1 reads only the depth information
|
|
|
|
from attachment 0 (using inputAttachmentRead) and writes to attachment 1.
|
|
|
|
|
|
|
|
[source,c++]
|
|
|
|
----------------------------------------
|
|
|
|
VkInputAttachmentAspectReferenceKHR references[] = {
|
|
|
|
{
|
|
|
|
.subpass = 1,
|
|
|
|
.inputAttachment = 0,
|
|
|
|
.aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
VkRenderPassInputAttachmentAspectCreateInfoKHR specifyAspects = {
|
|
|
|
.sType = VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR,
|
|
|
|
.pNext = NULL,
|
|
|
|
.aspectReferenceCount = 1,
|
|
|
|
.pAspectReferences = references
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
VkRenderPassCreateInfo createInfo = {
|
|
|
|
...
|
|
|
|
.pNext = &specifyAspects,
|
|
|
|
...
|
|
|
|
}
|
|
|
|
|
|
|
|
vkCreateRenderPass(...);
|
|
|
|
----------------------------------------
|
|
|
|
|
|
|
|
=== Issues
|
|
|
|
|
|
|
|
1) What is the default tessellation domain origin?
|
|
|
|
|
|
|
|
*RESOLVED*: Vulkan 1.0 originally inadvertently documented a lower-left
|
|
|
|
origin, but the conformance tests and all implementations implemented an
|
|
|
|
upper-left origin.
|
|
|
|
This extension adds a control to select between lower-left (for
|
|
|
|
compatibility with OpenGL) and upper-left, and we retroactively fix
|
|
|
|
unextended Vulkan to have a default of an upper-left origin.
|
|
|
|
|
|
|
|
=== Version History
|
|
|
|
|
2017-10-26 17:45:00 +00:00
|
|
|
* Revision 1, 2017-04-28
|