status-im
/
Vulkan-Docs
mirror of https://github.com/status-im/Vulkan-Docs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
Vulkan-Docs/doc/specs/vulkan/appendices/VK_NN_vi_surface.txt

64 lines
1.5 KiB
Plaintext
Raw Normal View History

Change log for September 5, 2017 Vulkan 1.0.60 spec update: * Bump API patch number and header version number to 60 for this update. Github Issues: * Document that <<queries-timestamps, Timestamp Queries>> can only be meaningfully compared when they are written from the same queue (public issue 216). * Document that the `<extension>` tag `type` attribute is required for non-disabled extensions (derived from, but does not close public issue 354). * Clean up registry schema length attribute descriptions to be consistent and correct (public issue 555). Internal Issues: * Replace as much of the hand-written extension appendix metadata as possible with asciidoc includes generated from corresponding attributes of +vk.xml+, and enhance the style guide to match. This avoids inconsistencies between +vk.xml+ and the appendices, and produces a more uniform style (internal issue 137). * Remove the generated extDependency.{py,sh} files from the tree and create them dynamically on demand instead, reducing merge conflicts (internal issue 713). * Add a prototype tool for generating in-place difference markup for sections guarded by asciidoc conditionals, and new syntax for open blocks to support it (internal issue 833). * Remove unnecessary restriction of etext:*SYNC_FD_BIT_KHR external handle types to the same physical device in the slink:VkPhysicalDeviceIDPropertiesKHR, flink:VkImportMemoryWin32HandleInfoKHR, slink:VkImportFenceWin32HandleInfoKHR, slink:VkImportFenceFdInfoKHR, slink:VkImportSemaphoreWin32HandleInfoKHR, slink:VkImportSemaphoreFdInfoKHR <<external-memory-handle-types-compatibility, External memory handle types compatibility>>, <<external-semaphore-handle-types-compatibility, External semaphore handle types compatibility>>, and <<external-fence-handle-types-compatibility, External fence handle types compatibility>> sections (internal issue 956). Other Issues: * Remove dependency of +VK_KHX_device_group+ on +VK_KHR_swapchain+ (there is an interaction, but not a strict dependency), and add a new `extension` attribute to the `<require` XML tag to allow classifying a subset of interfaces of an extension as requiring another extension. Update the registry schema and documentation accordingly. New Extensions: * `VK_AMD_shader_fragment_mask` (and related `GL_AMD_shader_fragment_mask` GLSL extension) * `VK_EXT_sample_locations` * `VK_EXT_validation_cache`
2017-09-04 10:06:55 +00:00
include::meta/VK_NN_vi_surface.txt[]
Change log for January 23, 2017 Vulkan 1.0.39 spec update: * Bump API patch number and header version number to 39 for this update. Github Issues: * Clarified that only accesses via the specified buffer/image subresource ranges are included in the access scopes (public issue 306). * Add missing valid usage statements for flink:vkCreateComputePipelines and flink:vkCreateGraphicsPipelines (public issue 427). Internal Issues: * Add a Note to the <<invariance,Invariance>> appendix about a difference between OpenGL and Vulkan with regards to how primitives derived from offsets are handled (internal issue 355). * Add the +<<VK_KHR_get_physical_device_properties2>>+, +<<VK_KHR_maintenance1>>+, and +<<VK_KHR_shader_draw_parameters>>+ extensions (internal issue 448). * Add the +<<VK_EXT_shader_subgroup_vote>>+ and +<<VK_EXT_shader_subgroup_ballot>>+ extensions (internal issue 449). * Update the texture level-of-detail equation in the <<textures-scale-factor,Scale Factor Operation>> section to better approximate the ellipse major and minor axes (internal issue 547). * Forbid non-explicitly allowed uses of interface decorations in the introduction to the <<interfaces,Shader Interfaces>> chapter (internal issue 607). * Replace use of MathJax with KaTeX, for improved load-time performance as well as avoiding the scrolling-and-scrolling behavior due to MathJax asynchronous rendering when loading at an anchor inside the spec. This change also requires moving to HTML5 output for the spec instead of XHTML, and there is a visible difference in that the chapter navigation index is now in a scrollable sidebar instead of at the top of the document. We may or may not retain the nav sidebar based on feedback (internal issue 613). * Improve consistency of markup and formatting in extension appendices (internal issue 631). Other Issues: * Add explicit valid usage statements to slink:VkImageCopy requiring that the source and destination layer ranges be contained in their respective source and destination images. * Add valid usage language for swapchain of flink:vkAcquireNextImage. If the swapchain has been replaced, then it should not be passed to flink:vkAcquireNextImage. * Add a valid usage statement to flink:vkCreateImageView, that the image must have been created with an appropriate usage bit set. * Noted that slink:VkDisplayPresentInfoKHR is a valid extension of slink:VkPresentInfoKHR in the <<wsi_swapchain,WSI Swapchain>> section. * Update valid usage for flink:vkCmdSetViewport and flink:vkCmdSetScissor to account for the multiple viewport feature. If the feature is not enabled, the parameters for these functions have required values that are defined in the <<features-features-multiViewport,multiple viewports>> section of the spec but were not reflected in the valid usage text for these functions. * Add the +<<VK_EXT_swapchain_colorspace>>+ extension defining common color spaces.
2017-01-18 04:11:25 +00:00
*Last Modified Date*::
Update some old date formats
2017-10-26 17:45:00 +00:00
2016-12-02
Change log for January 23, 2017 Vulkan 1.0.39 spec update: * Bump API patch number and header version number to 39 for this update. Github Issues: * Clarified that only accesses via the specified buffer/image subresource ranges are included in the access scopes (public issue 306). * Add missing valid usage statements for flink:vkCreateComputePipelines and flink:vkCreateGraphicsPipelines (public issue 427). Internal Issues: * Add a Note to the <<invariance,Invariance>> appendix about a difference between OpenGL and Vulkan with regards to how primitives derived from offsets are handled (internal issue 355). * Add the +<<VK_KHR_get_physical_device_properties2>>+, +<<VK_KHR_maintenance1>>+, and +<<VK_KHR_shader_draw_parameters>>+ extensions (internal issue 448). * Add the +<<VK_EXT_shader_subgroup_vote>>+ and +<<VK_EXT_shader_subgroup_ballot>>+ extensions (internal issue 449). * Update the texture level-of-detail equation in the <<textures-scale-factor,Scale Factor Operation>> section to better approximate the ellipse major and minor axes (internal issue 547). * Forbid non-explicitly allowed uses of interface decorations in the introduction to the <<interfaces,Shader Interfaces>> chapter (internal issue 607). * Replace use of MathJax with KaTeX, for improved load-time performance as well as avoiding the scrolling-and-scrolling behavior due to MathJax asynchronous rendering when loading at an anchor inside the spec. This change also requires moving to HTML5 output for the spec instead of XHTML, and there is a visible difference in that the chapter navigation index is now in a scrollable sidebar instead of at the top of the document. We may or may not retain the nav sidebar based on feedback (internal issue 613). * Improve consistency of markup and formatting in extension appendices (internal issue 631). Other Issues: * Add explicit valid usage statements to slink:VkImageCopy requiring that the source and destination layer ranges be contained in their respective source and destination images. * Add valid usage language for swapchain of flink:vkAcquireNextImage. If the swapchain has been replaced, then it should not be passed to flink:vkAcquireNextImage. * Add a valid usage statement to flink:vkCreateImageView, that the image must have been created with an appropriate usage bit set. * Noted that slink:VkDisplayPresentInfoKHR is a valid extension of slink:VkPresentInfoKHR in the <<wsi_swapchain,WSI Swapchain>> section. * Update valid usage for flink:vkCmdSetViewport and flink:vkCmdSetScissor to account for the multiple viewport feature. If the feature is not enabled, the parameters for these functions have required values that are defined in the <<features-features-multiViewport,multiple viewports>> section of the spec but were not reflected in the valid usage text for these functions. * Add the +<<VK_EXT_swapchain_colorspace>>+ extension defining common color spaces.
2017-01-18 04:11:25 +00:00
*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
Change log for June 4, 2017 Vulkan 1.0.51 spec update: * Bump API patch number and header version number to 51 for this update. Github Issues: * Add Valid Usage statement to flink:vkCmdResolveImage to require that source and destination image formats match (public issue 492). * Specify that a code:char* parameter must: be a valid null-terminated string in the <<fundamentals-implicit-validity, implicit valid usage>> section (public issue 494). * Removed unnecessary VU for slink:VkPhysicalDeviceFeatures which is covered by ename:VK_ERROR_FEATURE_NOT_PRESENT already (public issue 496). * Clarify valid usage of pname:pQueueFamilyIndices in slink:VkBufferCreateInfo, slink:VkImageCreateInfo, and slink:VkSwapchainCreateInfoKHR (public issue 501). * Document that dependencies of enabled extensions must also be enabled in the <<extended-functionality-extensions-dependencies, Extension Dependencies>> section (public issue 507). Internal Issues: * Change slink:VkMappedMemoryRange valid usage to allow pname:offset + pname:size == size of the allocation. Also, if ename:VK_WHOLE_SIZE is used, require the end of the mapping to be aligned to a multiple of pname:nonCoherentAtomSize (internal issue 611). * Add issue to `VK_KHR_win32_surface` about reusing window objects from a different graphics API or Vulkan ICD (internal issue 639). * Require locations on user in/out in `GL_KHR_vulkan_glsl` (internal issue 783). * Added version info to the json validation output, and updated the schema to match (internal issue 838). * Restructure enumerated type descriptions separately from the command or structure they are used in, allowing better reference page generation (internal issue 841). * Re-sort extension appendices to be in alphabetical order within each author ID section. * Fix enum naming and clarify behavior for `VK_NVX_device_generated_commands` extension. New Extensions:
2017-06-05 03:48:43 +00:00
* Extending elink:VkStructureType:
Change log for January 23, 2017 Vulkan 1.0.39 spec update: * Bump API patch number and header version number to 39 for this update. Github Issues: * Clarified that only accesses via the specified buffer/image subresource ranges are included in the access scopes (public issue 306). * Add missing valid usage statements for flink:vkCreateComputePipelines and flink:vkCreateGraphicsPipelines (public issue 427). Internal Issues: * Add a Note to the <<invariance,Invariance>> appendix about a difference between OpenGL and Vulkan with regards to how primitives derived from offsets are handled (internal issue 355). * Add the +<<VK_KHR_get_physical_device_properties2>>+, +<<VK_KHR_maintenance1>>+, and +<<VK_KHR_shader_draw_parameters>>+ extensions (internal issue 448). * Add the +<<VK_EXT_shader_subgroup_vote>>+ and +<<VK_EXT_shader_subgroup_ballot>>+ extensions (internal issue 449). * Update the texture level-of-detail equation in the <<textures-scale-factor,Scale Factor Operation>> section to better approximate the ellipse major and minor axes (internal issue 547). * Forbid non-explicitly allowed uses of interface decorations in the introduction to the <<interfaces,Shader Interfaces>> chapter (internal issue 607). * Replace use of MathJax with KaTeX, for improved load-time performance as well as avoiding the scrolling-and-scrolling behavior due to MathJax asynchronous rendering when loading at an anchor inside the spec. This change also requires moving to HTML5 output for the spec instead of XHTML, and there is a visible difference in that the chapter navigation index is now in a scrollable sidebar instead of at the top of the document. We may or may not retain the nav sidebar based on feedback (internal issue 613). * Improve consistency of markup and formatting in extension appendices (internal issue 631). Other Issues: * Add explicit valid usage statements to slink:VkImageCopy requiring that the source and destination layer ranges be contained in their respective source and destination images. * Add valid usage language for swapchain of flink:vkAcquireNextImage. If the swapchain has been replaced, then it should not be passed to flink:vkAcquireNextImage. * Add a valid usage statement to flink:vkCreateImageView, that the image must have been created with an appropriate usage bit set. * Noted that slink:VkDisplayPresentInfoKHR is a valid extension of slink:VkPresentInfoKHR in the <<wsi_swapchain,WSI Swapchain>> section. * Update valid usage for flink:vkCmdSetViewport and flink:vkCmdSetScissor to account for the multiple viewport feature. If the feature is not enabled, the parameters for these functions have required values that are defined in the <<features-features-multiViewport,multiple viewports>> section of the spec but were not reflected in the valid usage text for these functions. * Add the +<<VK_EXT_swapchain_colorspace>>+ extension defining common color spaces.
2017-01-18 04:11:25 +00:00
** 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
nn::vi C++ namespace.
This prevents its use in C source files.
nn::vi::NativeWindowHandle is always defined to be void*, so this
extension uses void* to match.
=== Version History
* Revision 1, 2016-12-2 (Michael Chock)
- Initial draft.