| // Copyright 2016-2021 The Khronos Group, Inc. |
| // |
| // SPDX-License-Identifier: CC-BY-4.0 |
| |
| include::{generated}/meta/{refprefix}VK_KHR_external_semaphore_win32.txt[] |
| |
| === Other Extension Metadata |
| |
| *Last Modified Date*:: |
| 2016-10-21 |
| *IP Status*:: |
| No known IP claims. |
| *Contributors*:: |
| - James Jones, NVIDIA |
| - Jeff Juliano, NVIDIA |
| - Carsten Rohde, NVIDIA |
| |
| === Description |
| |
| An application using external memory may wish to synchronize access to that |
| memory using semaphores. |
| This extension enables an application to export semaphore payload to and |
| import semaphore payload from Windows handles. |
| |
| include::{generated}/interfaces/VK_KHR_external_semaphore_win32.txt[] |
| |
| === Issues |
| |
| 1) Do applications need to call code:CloseHandle() on the values returned |
| from flink:vkGetSemaphoreWin32HandleKHR when pname:handleType is |
| ename:VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR? |
| |
| *RESOLVED*: Yes, unless it is passed back in to another driver instance to |
| import the object. |
| A successful get call transfers ownership of the handle to the application. |
| Destroying the semaphore object will not destroy the handle or the handle's |
| reference to the underlying semaphore resource. |
| |
| 2) Should the language regarding KMT/Windows 7 handles be moved to a |
| separate extension so that it can be deprecated over time? |
| |
| *RESOLVED*: No. |
| Support for them can be deprecated by drivers if they choose, by no longer |
| returning them in the supported handle types of the instance level queries. |
| |
| 3) Should applications be allowed to specify additional object attributes |
| for shared handles? |
| |
| *RESOLVED*: Yes. |
| Applications will be allowed to provide similar attributes to those they |
| would to any other handle creation API. |
| |
| 4) How do applications communicate the desired fence values to use with |
| etext:D3D12_FENCE-based Vulkan semaphores? |
| |
| *RESOLVED*: There are a couple of options. |
| The values for the signaled and reset states could be communicated up front |
| when creating the object and remain static for the life of the Vulkan |
| semaphore, or they could be specified using auxiliary structures when |
| submitting semaphore signal and wait operations, similar to what is done |
| with the keyed mutex extensions. |
| The latter is more flexible and consistent with the keyed mutex usage, but |
| the former is a much simpler API. |
| |
| Since Vulkan tends to favor flexibility and consistency over simplicity, a |
| new structure specifying D3D12 fence acquire and release values is added to |
| the flink:vkQueueSubmit function. |
| |
| === Version History |
| |
| * Revision 1, 2016-10-21 (James Jones) |
| - Initial revision |
