Vulkan.Extensions.VK_KHR_external_semaphore

Name

VK_KHR_external_semaphore - device extension

VK_KHR_external_semaphore

Name String

VK_KHR_external_semaphore

Extension Type

Device extension

Registered Extension Number

78

Revision

1

Extension and Version Dependencies

• Requires support for Vulkan 1.0
• Requires VK_KHR_external_semaphore_capabilities to be enabled for any device-level functionality

Deprecation state

• Promoted to Vulkan 1.1

Contact

• James Jones @cubanismo%0A*Here describe the issue or question you have about the VK_KHR_external_semaphore extension*

Other Extension Metadata

Last Modified Date

2016-10-21

IP Status

No known IP claims.

Interactions and External Dependencies

• Promoted to Vulkan 1.1 Core

Contributors

• Jason Ekstrand, Intel
• Jesse Hall, Google
• Tobias Hector, Imagination Technologies
• James Jones, NVIDIA
• Jeff Juliano, NVIDIA
• Matthew Netsch, Qualcomm Technologies, Inc.
• Ray Smith, ARM
• Chad Versace, Google

Description

An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to create semaphores from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Structures

• Extending SemaphoreCreateInfo:

  • ExportSemaphoreCreateInfoKHR

New Enums

• SemaphoreImportFlagBitsKHR

New Bitmasks

• SemaphoreImportFlagsKHR

New Enum Constants

• KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME

• KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION

• Extending SemaphoreImportFlagBits:

  • SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR

• Extending StructureType:

  • STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR

Issues

1) Should there be restrictions on what side effects can occur when waiting on imported semaphores that are in an invalid state?

RESOLVED: Yes. Normally, validating such state would be the responsibility of the application, and the implementation would be free to enter an undefined state if valid usage rules were violated. However, this could cause security concerns when using imported semaphores, as it would require the importing application to trust the exporting application to ensure the state is valid. Requiring this level of trust is undesirable for many potential use cases.

2) Must implementations validate external handles the application provides as input to semaphore state import operations?

RESOLVED: Implementations must return an error to the application if the provided semaphore state handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.

Version History

• Revision 1, 2016-10-21 (James Jones)

  • Initial revision

See Also

ExportSemaphoreCreateInfoKHR, SemaphoreImportFlagBitsKHR, SemaphoreImportFlagsKHR

Document Notes

For more information, see the Vulkan Specification

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

Documentation

pattern STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR :: StructureType

pattern SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR :: SemaphoreImportFlagBits

type SemaphoreImportFlagsKHR = SemaphoreImportFlags

type SemaphoreImportFlagBitsKHR = SemaphoreImportFlagBits

type ExportSemaphoreCreateInfoKHR = ExportSemaphoreCreateInfo

type KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION = 1

pattern KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION :: forall a. Integral a => a

type KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME = "VK_KHR_external_semaphore"

pattern KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a