Name
VK_EXT_device_address_binding_report - device extension
VK_EXT_device_address_binding_report
- Name String
VK_EXT_device_address_binding_report
- Extension Type
Device extension
- Registered Extension Number
355
- Revision
1
- Ratification Status
Ratified
- Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_EXT_debug_utils
- Special Uses
- Contact
Other Extension Metadata
- Last Modified Date
2020-11-23
- Interactions and External Dependencies
- Contributors
Description
This extension enables applications to track the binding of regions of
the GPU virtual address space, and to associate those regions with
Vulkan objects. This extension is primarily intended to aid in crash
postmortem, where applications may wish to map a faulting GPU address to
a Vulkan object.
For example, a page fault triggered by accessing an address located
within a region of the GPU virtual address space that was previously
reported as bound and then unbound may indicate a use-after-free error.
Similarly, faults generated by accessing virtual addresses outside the
limits of a bound region of GPU virtual address space may indicate
indexing beyond the bounds of a resource.
New Structures
New Enums
New Bitmasks
New Enum Constants
Issues
) Should this extend VK_EXT_debug_utils or
VK_EXT_device_memory_report?
RESOLVED: Extend VK_EXT_debug_utils. VK_EXT_device_memory_report
focuses on memory allocations and would not normally trigger callbacks
in all of the situations where VK_EXT_device_address_binding_report is
expected to.
) Should this extension cover all Vulkan object types, or only
resources such as buffers and images?
RESOLVED: The extension covers all Vulkan objects, and is not
restricted to objects backed by VkDeviceMemory objects.
) Should reallocation be identified explicitly, or as an unbind/bind
pair?
RESOLVED: Reallocation should be represented as an unbind/bind
pair.
) Can multiple Vulkan objects share an overlapping virtual address
range?
RESOLVED: Yes. This can be expected to occur due to resources
aliasing.
) Can a single Vulkan object be associated with multiple virtual
address ranges concurrently?
RESOLVED: Yes. These should be reported via multiple calls to the
reporting callback.
) Should the virtual address ranges associated with internal
allocations such as memory pools be reported?
RESOLVED: Virtual address ranges associated with internal
allocations should only be reported when they become associated with a
specific Vulkan object. In the case of internal pool allocations, a bind
event should be reported when resources from the pool are assigned to a
Vulkan object, and an unbind event should be reported when those
resources are returned to the pool. Implementations should not report
the binding or unbinding of virtual address ranges for which there are
no related API objects visible to the application developer.
) Can an implementation report binding a virtual address range at
VkImage or VkImageView creation, rather than in response to
vkBindImageMemory?
RESOLVED: Yes. Virtual address range binding should be reported at
the appropriate point at which it occurs within the implementation. This
extension does not mandate when that should occur, and applications
should anticipate receiving callback events at any point after
registering callbacks.
) Can reporting of binding/unbinding be deferred until a resource is
referenced by an executing command buffer?
RESOLVED: Changes to the virtual address ranges associated with a
Vulkan object should be reported as close as possible to where they
occur within the implementation. If virtual address binding is deferred,
then the callback should also be deferred to match.
) Do bind/unbind callbacks have to form matched pairs? Can a large
region be bound, and then subregions unbound, resulting in
fragmentation?
RESOLVED: Splitting of virtual address regions, and unmatched
bind/unbind callbacks may occur. Developers should anticipate that
sparse memory may exhibit this behavior.
) The specification mandates that a callback must be triggered
whenever a GPU virtual address range associated with any Vulkan object
is bound or unbound. Do we need queries or properties indicating which
Vulkan objects will report binding modifications?
RESOLVED: No. This extension is not intended to mandate how and when
implementations bind virtual ranges to objects. Adding queries or
properties would constrain implementations, which might otherwise vary
how virtual address bindings occur based on usage.
) Should vkAllocateMemory and vkFreeMemory trigger reporting
callbacks?
RESOLVED: If an implementation binds a GPU virtual address range
when vkAllocateMemory is called, then the callbacks must be triggered
associating the virtual address range with the VkDeviceMemory object. If
the device memory is subsequently bound to a buffer or image via
vkBind*Memory, the callbacks should be triggered a second time,
reporting the association between virtual address range and the
buffer/image.
) Should binding reports be emitted for vkQueueBindSparse()
operations?
RESOLVED: binding reports for sparse objects are best effort, some
implementations might report events on vkQueueBindSparse() other
implementations might report events on sparse object
creation/destruction.
Version History
See Also
No cross-references are available
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.