mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 12:35:11 +00:00
* 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`
79 lines
2.4 KiB
Plaintext
79 lines
2.4 KiB
Plaintext
// Copyright (c) 2016-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_external_semaphore.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2016-10-21
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Interactions and External Dependencies*::
|
|
- Promoted to Vulkan 1.1 Core
|
|
*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.
|
|
|
|
=== Promotion to Vulkan 1.1
|
|
|
|
All functionality in this extension is included in core Vulkan 1.1, with the
|
|
KHR suffix omitted.
|
|
The original type, enum and command names are still available as aliases of
|
|
the core functionality.
|
|
|
|
=== 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 undesirable 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 cannot be used to complete the requested
|
|
import operation.
|
|
However, implementations need not validate handles are of the exact type
|
|
specified by the application.
|