// 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_fence_win32.txt[] *Last Modified Date*:: 2017-05-08 *IP Status*:: No known IP claims. *Contributors*:: - Jesse Hall, Google - James Jones, NVIDIA - Jeff Juliano, NVIDIA - Cass Everitt, Oculus - Contributors to `<>` An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to export fence payload to and import fence payload from Windows handles. === New Object Types None. === New Enum Constants * ename:VK_STRUCTURE_TYPE_IMPORT_FENCE_WIN32_HANDLE_INFO_KHR * ename:VK_STRUCTURE_TYPE_EXPORT_FENCE_WIN32_HANDLE_INFO_KHR * ename:VK_STRUCTURE_TYPE_FENCE_GET_WIN32_HANDLE_INFO_KHR === New Enums None. === New Structs * slink:VkImportFenceWin32HandleInfoKHR * slink:VkExportFenceWin32HandleInfoKHR * slink:VkFenceGetWin32HandleInfoKHR === New Functions * flink:vkImportFenceWin32HandleKHR * flink:vkGetFenceWin32HandleKHR === Issues This extension borrows concepts, semantics, and language from `<>`. That extension's issues apply equally to this extension. 1) Should D3D12 fence handle types be supported, like they are for semaphores? *RESOLVED*: No. Doing so would require extending the fence signal and wait operations to provide values to signal / wait for, like sname:VkD3D12FenceSubmitInfoKHR does. A D3D12 fence can be signaled by importing it into a slink:VkSemaphore instead of a slink:VkFence, and applications can check status or wait on the D3D12 fence using non-Vulkan APIs. The convenience of being able to do these operations on sname:VkFence objects doesn't justify the extra API complexity.