mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-24 20:18:06 +00:00
* Bump API patch number and header version number to 67 for this update. * Update copyright dates to 2018 Github Issues: * Fix texture lookup functions in `GL_KHR_vulkan_glsl` specification (public pull request 363). * Clarify the state waited semaphores are left in when a call to flink:vkQueuePresentKHR fails (public issue 572). * Cleanup descriptions of slink:VkObjectTablePushConstantEntryNVX and slink:VkObjectTableDescriptorSetEntryNVX (public issue 583) * Remove redundant flink:vkCmdSetDiscardRectangleEXT valid usage statements (public pull 586). * Make dynamic state array length valid usage statements implicit for flink:vkCmdSetViewportWScalingNV, flink:vkCmdSetDiscardRectangleEXT, and flink:vkCmdSetViewport (public pull 589). * Clarify meaning of window extent (0,0) in slink:VkSwapchainKHR for the Windows and X11 platforms, in their respective extensions (public issue 590). * Allow flink:vkGetPastPresentationTimingGOOGLE to return ename:VK_INCOMPLETE (public issue 604). * Add synchronization valid usage statements to flink:vkAcquireNextImage (public pull 611). * Fix some broken external links and internal xrefs (public pull 613). * Clean up slink:VkViewport valid usage statements in the presence or absence of relevant extensions (public pull 623). * Remove ename:VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR token from VK_KHR_maintenance2 from the non-extension VU path for slink:VkGraphicsPipelineCreateInfo (public issue 628). * Miscellaneous minor markup fixes - extension name strings (public pull 631), Notes (pull 633), queue names emitted by generator scripts (pull 634), block formatting in slink:VkDescriptorUpdateTemplateEntryKHR (pull 635), ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_IMG (pull 641), quotes and apostrophes (pull 643), * Miscellaneous minor grammar fixes (public pull 644). * Fix markup macros so usage like ptext:*Src* works (public pull 647). Internal Issues: * Clarify in the `VK_KHR_surface` and `VK_KHR_swapchain` extensions that parameter combinations which aren't supported for normal images are also unsupported for presentable images, even if the parameter values are individually supported as reported by the surface capability queries (internal issue 1029). * Fixed XML typo in the valid value field of the pname:sType member of slink:VkPhysicalDeviceExternalMemoryHostPropertiesEXT (internal issue 1100). Other Issues: * Add memory semantics validity rules to the <<spirvenv-module-validation, Validation Rules within a Module>> section of the SPIR-V environment appendix, and specify that sequentiality consistency is not supported. This forbids certain cases like "`Load+Release`" that we don't expect to ever be meaningful. * Document mapping of OpenGL Shading Language barriers to SPIR-V scope and semantics in the `GL_KHR_vulkan_glsl` specification. New Extensions: * `VK_EXT_conservative_rasterization`
70 lines
2.1 KiB
Plaintext
70 lines
2.1 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_external_semaphore.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2016-10-21
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Contributors*::
|
|
- Jason Ekstrand, Intel
|
|
- Jesse Hall, Google
|
|
- Tobias Hector, Imagination Technologies
|
|
- James Jones, NVIDIA
|
|
- Jeff Juliano, NVIDIA
|
|
- Matthew Netsch, Qualcomm Technologies, Inc.
|
|
- Ray Smith, ARM
|
|
- Chad Versace, Google
|
|
|
|
An application using external memory may wish to synchronize access to that
|
|
memory using semaphores.
|
|
This extension enables an application to create semaphores from which
|
|
non-Vulkan handles that reference the underlying synchronization primitive
|
|
can be exported.
|
|
|
|
=== New Object Types
|
|
|
|
None.
|
|
|
|
=== New Enum Constants
|
|
|
|
* ename:VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR
|
|
* ename:VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR
|
|
|
|
=== New Enums
|
|
|
|
* elink:VkSemaphoreImportFlagBitsKHR
|
|
|
|
=== New Structs
|
|
|
|
* slink:VkExportSemaphoreCreateInfoKHR
|
|
|
|
=== New Functions
|
|
|
|
None.
|
|
|
|
=== Issues
|
|
|
|
1) Should there be restrictions on what side effects can occur when waiting
|
|
on imported semaphores that are in an invalid state?
|
|
|
|
*RESOLVED*: Yes.
|
|
Normally, validating such state would be the responsibility of the
|
|
application, and the implementation would be free to enter an undefined
|
|
state if valid usage rules were violated.
|
|
However, this could cause security concerns when using imported semaphores,
|
|
as it would require the importing application to trust the exporting
|
|
application to ensure the state is valid.
|
|
Requiring this level of trust is undesireable for many potential use cases.
|
|
|
|
2) Must implementations validate external handles the application provides
|
|
as input to semaphore state import operations?
|
|
|
|
*RESOLVED*: Implementations must return an error to the application if the
|
|
provided semaphore state handle can not be used to complete the requested
|
|
import operation.
|
|
However, implementations need not validate handles are of the exact type
|
|
specified by the application.
|