// 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_win32.txt[]

*Last Modified Date*::
    2016-10-21
*IP Status*::
    No known IP claims.
*Contributors*::
  - James Jones, NVIDIA
  - Jeff Juliano, NVIDIA
  - Carsten Rohde, NVIDIA

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.

=== New Object Types

None.

=== New Enum Constants

  * ename:VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR
  * ename:VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR
  * ename:VK_STRUCTURE_TYPE_D3D12_FENCE_SUBMIT_INFO_KHR
  * ename:VK_STRUCTURE_TYPE_SEMAPHORE_GET_WIN32_HANDLE_INFO_KHR

=== New Enums

None.

=== New Structs

  * slink:VkImportSemaphoreWin32HandleInfoKHR
  * slink:VkExportSemaphoreWin32HandleInfoKHR
  * slink:VkD3D12FenceSubmitInfoKHR
  * slink:VkSemaphoreGetWin32HandleInfoKHR

=== New Functions

  * flink:vkImportSemaphoreWin32HandleKHR
  * flink:vkGetSemaphoreWin32HandleKHR

=== 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.