Contact
-
Mike Blumenkrantz [GitHub]zmike
Other Extension Metadata
- Last Modified Date
-
2025-04-09
- Interactions and External Dependencies
-
-
Interacts with Vulkan 1.1.
-
Interacts with
VK_KHR_get_physical_device_properties2
.
-
- IP Status
-
No known IP claims.
- Contributors
-
-
Hans-Kristian Arntzen, VALVE
-
Mike Blumenkrantz, VALVE
-
Tobias Hector, AMD
-
Faith Ekstrand, Collabora
-
Ricardo Garcia, Igalia
-
Jan-Harald Fredriksen, ARM
-
Spencer Fricke, LunarG
-
Description
By default, Vulkan provides no guarantees that device memory allocated through vkAllocateMemory is cleared to zero. This means that applications wanting resources to be zero-initialized must execute a command such as vkCmdFillBuffer or vkCmdClearColorImage on the device to ensure a deterministic result. This can be wasteful if the underlying platform either:
-
Already performs that zero clear anyway, due to e.g. security concerns.
-
Can be performed more efficiently in implementation, by e.g. clearing pages to zero in the background after device memory is freed.
This extension also has uses in API layering and porting efforts, where zero memory behavior may be more strict than Vulkan. Different OS platforms also have wildly different behaviors here, which leads to implementations needing to apply workarounds to paper over these issues in the wild. If an extension exists to make allocation behavior explicit, we hopefully achieve a more robust ecosystem for Vulkan.
New Enum Constants
-
VK_EXT_ZERO_INITIALIZE_DEVICE_MEMORY_EXTENSION_NAME
-
VK_EXT_ZERO_INITIALIZE_DEVICE_MEMORY_SPEC_VERSION
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_ZERO_INITIALIZED_EXT
-
-
Extending VkMemoryAllocateFlagBits:
-
VK_MEMORY_ALLOCATE_ZERO_INITIALIZE_BIT_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ZERO_INITIALIZE_DEVICE_MEMORY_FEATURES_EXT
-
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.