1include::meta/VK_NN_vi_surface.txt[] 2 3*Last Modified Date*:: 4 2016-12-02 5*IP Status*:: 6 No known IP claims. 7*Contributors*:: 8 - Mathias Heyer, NVIDIA 9 - Michael Chock, NVIDIA 10 - Yasuhiro Yoshioka, Nintendo 11 - Daniel Koch, NVIDIA 12 13The `VK_NN_vi_surface` extension is an instance extension. 14It provides a mechanism to create a slink:VkSurfaceKHR object (defined by 15the `<<VK_KHR_surface>>` extension) associated with an 16code:nn::code:vi::code:Layer. 17 18=== New Object Types 19 20None 21 22=== New Enum Constants 23 24 * Extending elink:VkStructureType: 25 ** ename:VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN 26 27=== New Enums 28 29None 30 31=== New Structures 32 33 * slink:VkViSurfaceCreateInfoNN 34 35=== New Functions 36 37 * flink:vkCreateViSurfaceNN 38 39=== Issues 40 411) Does VI need a way to query for compatibility between a particular 42physical device (and queue family?) and a specific VI display? 43 44*RESOLVED*: No. 45It is currently always assumed that the device and display will always be 46compatible. 47 482) slink:VkViSurfaceCreateInfoNN::pname:pWindow is intended to store an 49code:nn::code:vi::code:NativeWindowHandle, but its declared type is a bare 50code:void* to store the window handle. 51Why the discrepancy? 52 53*RESOLVED*: It is for C compatibility. 54The definition for the VI native window handle type is defined inside the 55code:nn::code:vi C++ namespace. 56This prevents its use in C source files. 57code:nn::code:vi::code:NativeWindowHandle is always defined to be 58code:void*, so this extension uses code:void* to match. 59 60=== Version History 61 62 * Revision 1, 2016-12-2 (Michael Chock) 63 - Initial draft. 64