1// Copyright 2016-2021 The Khronos Group, Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_KHR_external_fence_win32.txt[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2017-05-08 11*IP Status*:: 12 No known IP claims. 13*Contributors*:: 14 - Jesse Hall, Google 15 - James Jones, NVIDIA 16 - Jeff Juliano, NVIDIA 17 - Cass Everitt, Oculus 18 - Contributors to `apiext:VK_KHR_external_semaphore_win32` 19 20=== Description 21 22An application using external memory may wish to synchronize access to that 23memory using fences. 24This extension enables an application to export fence payload to and import 25fence payload from Windows handles. 26 27include::{generated}/interfaces/VK_KHR_external_fence_win32.txt[] 28 29=== Issues 30 31This extension borrows concepts, semantics, and language from 32`apiext:VK_KHR_external_semaphore_win32`. 33That extension's issues apply equally to this extension. 34 351) Should D3D12 fence handle types be supported, like they are for 36semaphores? 37 38*RESOLVED*: No. 39Doing so would require extending the fence signal and wait operations to 40provide values to signal / wait for, like sname:VkD3D12FenceSubmitInfoKHR 41does. 42A D3D12 fence can be signaled by importing it into a slink:VkSemaphore 43instead of a slink:VkFence, and applications can check status or wait on the 44D3D12 fence using non-Vulkan APIs. 45The convenience of being able to do these operations on sname:VkFence 46objects does not justify the extra API complexity. 47 48=== Version History 49 50 * Revision 1, 2017-05-08 (Jesse Hall) 51 - Initial revision 52