mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-20 01:58:06 +00:00
56e0289318
* 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`
89 lines
3.0 KiB
Plaintext
89 lines
3.0 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_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.
|