Vulkan-Docs/appendices/VK_KHR_get_surface_capabilities2.txt
Jon Leech 56e0289318 Change log for January 05, 2019 Vulkan 1.1.97 spec update:
* Update release number to 97.

Public Issues:

  * Add a special case to the <<renderpass-compatibility, Render Pass
    Compatibility>> rules allowing single-subpass renderpasses to be
    compatible even if they have different resolve attachment references
    (public issue 835).
  * Fix the miss shader binding table record address rule in the
    <<shader-binding-table-indexing-rules, Miss Shaders>> section to index
    by code:missIndex, not code:sbtOffset (public issue 875).

Internal Issues:

  * Add a missing anchor to the elink:VkSamplerCreateFlagBits language
    (internal issue 1483).
  * Add missing implicit valid usage include for slink:VkHdrMetadataEXT and
    corresponding `noautovalidity` attributes in `vk.xml` for the
    externally-defined metadata properties (internal issue 1514).
  * Remove restrictions on the `mask` parameter of SPIR-V's
    code:OpGroupNonUniformXor in the <<spirvenv-module-validation,
    Validation Rules within a Module>> appendix (internal merge request
    2971).
  * Restore `noautovalidity` attribute for
    slink:VkPipelineViewportWScalingStateCreateInfoNV::pname:pViewportWScalings
    in `vk.xml` (internal merge request 2975).
  * Update copyright dates on Khronos-copyrighted files to 2019 (internal
    merge request 2980).

New Extensions:

  * `VK_KHR_depth_stencil_resolve`
  * `VK_EXT_buffer_device_address`
  * `VK_EXT_memory_budget`
  * `VK_EXT_memory_priority`
  * `VK_EXT_validation_features`
2019-01-05 19:40:12 -08:00

87 lines
2.5 KiB
Plaintext

// Copyright (c) 2017-2019 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_get_surface_capabilities2.txt[]
*Last Modified Date*::
2017-02-27
*IP Status*::
No known IP claims.
*Contributors*::
- Ian Elliott, Google
- James Jones, NVIDIA
- Alon Or-bach, Samsung
This extension provides new entry points to query device surface
capabilities in a way that can be easily extended by other extensions,
without introducing any further entry points.
This extension can be considered the `<<VK_KHR_surface>>` equivalent of the
`<<VK_KHR_get_physical_device_properties2>>` extension.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SURFACE_INFO_2_KHR
** ename:VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_KHR
** ename:VK_STRUCTURE_TYPE_SURFACE_FORMAT_2_KHR
=== New Enums
None.
=== New Structures
* slink:VkPhysicalDeviceSurfaceInfo2KHR
* slink:VkSurfaceCapabilities2KHR
* slink:VkSurfaceFormat2KHR
=== New Functions
* flink:vkGetPhysicalDeviceSurfaceCapabilities2KHR
* flink:vkGetPhysicalDeviceSurfaceFormats2KHR
=== Issues
1) What should this extension be named?
*RESOLVED*: `VK_KHR_get_surface_capabilities2`.
Other alternatives:
* `VK_KHR_surface2`
* One extension, combining a separate display-specific query extension.
2) Should additional WSI query functions be extended?
*RESOLVED*:
* flink:vkGetPhysicalDeviceSurfaceCapabilitiesKHR: Yes.
The need for this motivated the extension.
* flink:vkGetPhysicalDeviceSurfaceSupportKHR: No.
Currently only has boolean output.
Extensions should instead extend
flink:vkGetPhysicalDeviceSurfaceCapabilities2KHR.
* flink:vkGetPhysicalDeviceSurfaceFormatsKHR: Yes.
* flink:vkGetPhysicalDeviceSurfacePresentModesKHR: No.
Recent discussion concluded this introduced too much variability for
applications to deal with.
Extensions should instead extend
flink:vkGetPhysicalDeviceSurfaceCapabilities2KHR.
* flink:vkGetPhysicalDeviceXlibPresentationSupportKHR: Not in this
extension.
* flink:vkGetPhysicalDeviceXcbPresentationSupportKHR: Not in this
extension.
* flink:vkGetPhysicalDeviceWaylandPresentationSupportKHR: Not in this
extension.
* flink:vkGetPhysicalDeviceWin32PresentationSupportKHR: Not in this
extension.
=== Version History
* Revision 1, 2017-02-27 (James Jones)
- Initial draft.