Vulkan-Docs/appendices/VK_KHR_maintenance2.txt
Jon Leech 279452463a Change log for November 12, 2018 Vulkan 1.1.92 spec update:
* Update release number to 92.

Public Issues:

  * Move and modify valid usage statements dealing with pname:aspectMask in
    flink:vkCmdClearColorImage, flink:vkCmdClearDepthStencilImage, and
    slink:VkClearAttachment, so they are in places where all necessary
    information is available (public issue 529).
  * Fix math markup in <<textures-texel-anisotropic-filtering, Texel
    Anisotropic Filtering>> (public pull request 840).
  * Fix misspellings (public pull request 845).

Internal Issues:

  * Add installation instructions and a Makefile "`chunked`" target for
    chunked HTML generation (internal issue 1352).
  * Fix pipeline mesh diagram style; also fix a minor bug in the classic
    pipeline diagram where vertex/index buffers wrongly fed into the vertex
    shader (internal issue 1436).
  * Make asciidoctor ERROR output raise an error, and don't suppress
    executed command output from CI make invocation (internal issue 1454).
  * Minor typo fixes and clarifications for `VK_NV_raytracing`.
  * Cleanup extension-specific properties
  ** Remove duplicated documentation for pname:maxDiscardRectangles,
     pname:pointClippingBehavior, and pname:maxVertexAttribDivisor (they
     shouldn't be documented with the other members of
     slink:VkPhysicalDeviceLimits at all).
  ** Remove duplicate anchor for pname:maxVertexAttribDivisor
  ** Consistently document stext:VkPhysicalDevice<Extension>PropertiesKHR
  *** Always document pname:sType/pname:pNext (was inconsistent before)
  *** Always mention chaining to slink:VkPhysicalDeviceProperties2 (and not
      as slink:VkPhysicalDeviceProperties2KHR)
  *** Always include Valid Usage statements last
  * Update Makefile 'checklinks' target and associated scripts, and fix
    markup problems identified by checkLinks.py, so that we can rely on the
    checklinks script as part of Gitlab CI.
2018-11-12 04:40:40 -08:00

149 lines
4.9 KiB
Plaintext

// Copyright (c) 2016-2018 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-09-05
*Interactions and External Dependencies*::
- Promoted to Vulkan 1.1 Core
*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 code: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 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
* elink:VkPointClippingBehaviorKHR
* elink:VkTessellationDomainOriginKHR
=== New Structures
* slink:VkPhysicalDevicePointClippingPropertiesKHR
* slink:VkRenderPassInputAttachmentAspectCreateInfoKHR
* slink:VkInputAttachmentAspectReferenceKHR
* slink:VkImageViewUsageCreateInfoKHR
* slink:VkPipelineTessellationDomainOriginStateCreateInfoKHR
=== New Functions
None.
=== Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the
KHR suffix omitted.
The original type, enum and command names are still available as aliases of
the core functionality.
=== Input Attachment Specification Example
Consider the case where a render pass has two subpasses and two attachments.
Attachment 0 has the format ename: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,
.inputAttachmentIndex = 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
* Revision 1, 2017-04-28