Vulkan-Docs/appendices/VK_NN_vi_surface.txt
Jon Leech 22a5a1459f Change log for October 6, 2019 Vulkan 1.1.124 spec update:
* Update release number to 124.

Github Issues:

  * Fix Makefile SPECREMARK macro to work when not building in a git tree
    (public issue 992).
  * Ignore pname:aspectMask for unused attachments in
    slink:VkSubpassDescription2KHR valid usage statements (public pull
    request 1028).
  * Minor markup / spelling fixes (public pull requests 1035, 1045).

Internal Issues:

  * Fix markup in Valid Usage statement for slink:VkCreateFramebuffer
    (internal issue 1823).
  * Add a new <<synchronization-signal-operation-order, _signal operation
    order_>> section to the synchronization chapter which describes in
    detail the ordering guarantees provided by the API between fence and
    semaphore signal operations (internal merge request 3368).
  * Move generated `appendix/meta/` files into the Makefile GENERATED
    directory (internal merge request 3381).

New Extensions

  * `<<VK_KHR_shader_clock>>`
  * `<<VK_KHR_timeline_semaphore>>`
2019-10-06 12:42:12 -07:00

64 lines
1.6 KiB
Plaintext

include::{generated}/meta/VK_NN_vi_surface.txt[]
*Last Modified Date*::
2016-12-02
*IP Status*::
No known IP claims.
*Contributors*::
- Mathias Heyer, NVIDIA
- Michael Chock, NVIDIA
- Yasuhiro Yoshioka, Nintendo
- Daniel Koch, NVIDIA
The `VK_NN_vi_surface` extension is an instance extension.
It provides a mechanism to create a slink:VkSurfaceKHR object (defined by
the `<<VK_KHR_surface>>` extension) associated with an
code:nn::code:vi::code:Layer.
=== New Object Types
None
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN
=== New Enums
None
=== New Structures
* slink:VkViSurfaceCreateInfoNN
=== New Functions
* flink:vkCreateViSurfaceNN
=== Issues
1) Does VI need a way to query for compatibility between a particular
physical device (and queue family?) and a specific VI display?
*RESOLVED*: No.
It is currently always assumed that the device and display will always be
compatible.
2) slink:VkViSurfaceCreateInfoNN::pname:pWindow is intended to store an
code:nn::code:vi::code:NativeWindowHandle, but its declared type is a bare
code:void* to store the window handle.
Why the discrepancy?
*RESOLVED*: It is for C compatibility.
The definition for the VI native window handle type is defined inside the
code:nn::code:vi C++ namespace.
This prevents its use in C source files.
code:nn::code:vi::code:NativeWindowHandle is always defined to be
code:void*, so this extension uses code:void* to match.
=== Version History
* Revision 1, 2016-12-2 (Michael Chock)
- Initial draft.