Registered Extension Number

309

Revision

1

Extension and Version Dependencies

  • Requires Vulkan 1.0

Contact

Other Extension Metadata

Last Modified Date

2020-01-14

IP Status

No known IP claims.

Contributors
  • Aidan Fabius, Core Avionics

  • Mark Bellamy, ARM

Description

Many safety critical environments are required to contend with single event upsets (SEUs). These occur when a bit in a physical device’s memory or register is inadvertently flipped. It is typical for host memory to include automatic error detection (EDC) or correction (ECC) on platforms where this a concern. However, device-accessible memory may not have these protections. In that case, the data must be periodically refreshed.

Unextended Vulkan provides a variety of methods to mitigate SEUs. Image and buffer objects can be bound to SEU-safe memory, and many object types can be refreshed explicitly by the application by reloading or regenerating the object’s data. However, implementations may store internal object-specific data in non-SEU-safe memory, and unextended Vulkan provides no clear method to determine which object types this applies to or how to refresh that data.

This extension adds a mechanism to query which object types store implementation-internal data in device regions susceptible to SEUs, and to explicitly refresh that implementation-internal data.

New Commands

New Structures

New Enums

New Bitmasks

New Enum Constants

  • VK_KHR_OBJECT_REFRESH_EXTENSION_NAME

  • VK_KHR_OBJECT_REFRESH_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_REFRESH_OBJECT_LIST_KHR

Issues

1) Should this extension refresh object data, or validate whether or not the data has been corrupted?

RESOLVED This extension should refresh data, not validate it. This reduces application error-handling complexity, and invalid data would have to be refreshed anyway.

2) Should object refreshes be done using the host or with command buffers?

RESOLVED Object refreshes should be done with command buffers. This reduces the synchronization complexity.

3) Refresh operations will need a pipeline barrier so that subsequent commands will see the results of the refresh. What access flags and pipeline stage should apply to refresh operations? Should they use new flags and stages, or re-use an existing one?

RESOLVED Object refreshes are considered to be a transfer operation for the purposes of pipeline barriers.

4) Should this extension add a feature bit?

RESOLVED A feature bit is not necessary. In the case of this extension being promoted to core, implementations that do not support or require refreshing of any object types will return 0 for the count parameter of vkGetPhysicalDeviceRefreshableObjectTypesKHR.

Examples

None.

Version History

  • Revision 1, 2020-01-14

See Also

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.

Copyright 2014-2021 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0