51. Debugging
To aid developers in tracking down errors in the application’s use of Vulkan, particularly in combination with an external debugger or profiler, debugging extensions may be available.
The VkObjectType enumeration defines values, each of which corresponds to a specific Vulkan handle type. These values can be used to associate debug information with a particular type of object through one or more extensions.
// Provided by VK_VERSION_1_0
typedef enum VkObjectType {
VK_OBJECT_TYPE_UNKNOWN = 0,
VK_OBJECT_TYPE_INSTANCE = 1,
VK_OBJECT_TYPE_PHYSICAL_DEVICE = 2,
VK_OBJECT_TYPE_DEVICE = 3,
VK_OBJECT_TYPE_QUEUE = 4,
VK_OBJECT_TYPE_SEMAPHORE = 5,
VK_OBJECT_TYPE_COMMAND_BUFFER = 6,
VK_OBJECT_TYPE_FENCE = 7,
VK_OBJECT_TYPE_DEVICE_MEMORY = 8,
VK_OBJECT_TYPE_BUFFER = 9,
VK_OBJECT_TYPE_IMAGE = 10,
VK_OBJECT_TYPE_EVENT = 11,
VK_OBJECT_TYPE_QUERY_POOL = 12,
VK_OBJECT_TYPE_BUFFER_VIEW = 13,
VK_OBJECT_TYPE_IMAGE_VIEW = 14,
VK_OBJECT_TYPE_SHADER_MODULE = 15,
VK_OBJECT_TYPE_PIPELINE_CACHE = 16,
VK_OBJECT_TYPE_PIPELINE_LAYOUT = 17,
VK_OBJECT_TYPE_RENDER_PASS = 18,
VK_OBJECT_TYPE_PIPELINE = 19,
VK_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT = 20,
VK_OBJECT_TYPE_SAMPLER = 21,
VK_OBJECT_TYPE_DESCRIPTOR_POOL = 22,
VK_OBJECT_TYPE_DESCRIPTOR_SET = 23,
VK_OBJECT_TYPE_FRAMEBUFFER = 24,
VK_OBJECT_TYPE_COMMAND_POOL = 25,
// Provided by VK_VERSION_1_1
VK_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION = 1000156000,
// Provided by VK_VERSION_1_1
VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE = 1000085000,
// Provided by VK_VERSION_1_3
VK_OBJECT_TYPE_PRIVATE_DATA_SLOT = 1000295000,
// Provided by VK_KHR_surface
VK_OBJECT_TYPE_SURFACE_KHR = 1000000000,
// Provided by VK_KHR_swapchain
VK_OBJECT_TYPE_SWAPCHAIN_KHR = 1000001000,
// Provided by VK_KHR_display
VK_OBJECT_TYPE_DISPLAY_KHR = 1000002000,
// Provided by VK_KHR_display
VK_OBJECT_TYPE_DISPLAY_MODE_KHR = 1000002001,
// Provided by VK_EXT_debug_report
VK_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT = 1000011000,
// Provided by VK_KHR_video_queue
VK_OBJECT_TYPE_VIDEO_SESSION_KHR = 1000023000,
// Provided by VK_KHR_video_queue
VK_OBJECT_TYPE_VIDEO_SESSION_PARAMETERS_KHR = 1000023001,
// Provided by VK_NVX_binary_import
VK_OBJECT_TYPE_CU_MODULE_NVX = 1000029000,
// Provided by VK_NVX_binary_import
VK_OBJECT_TYPE_CU_FUNCTION_NVX = 1000029001,
// Provided by VK_EXT_debug_utils
VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT = 1000128000,
// Provided by VK_KHR_acceleration_structure
VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR = 1000150000,
// Provided by VK_EXT_validation_cache
VK_OBJECT_TYPE_VALIDATION_CACHE_EXT = 1000160000,
// Provided by VK_NV_ray_tracing
VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV = 1000165000,
// Provided by VK_INTEL_performance_query
VK_OBJECT_TYPE_PERFORMANCE_CONFIGURATION_INTEL = 1000210000,
// Provided by VK_KHR_deferred_host_operations
VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR = 1000268000,
// Provided by VK_NV_device_generated_commands
VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NV = 1000277000,
#ifdef VK_ENABLE_BETA_EXTENSIONS
// Provided by VK_NV_cuda_kernel_launch
VK_OBJECT_TYPE_CUDA_MODULE_NV = 1000307000,
#endif
#ifdef VK_ENABLE_BETA_EXTENSIONS
// Provided by VK_NV_cuda_kernel_launch
VK_OBJECT_TYPE_CUDA_FUNCTION_NV = 1000307001,
#endif
// Provided by VK_FUCHSIA_buffer_collection
VK_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA = 1000366000,
// Provided by VK_EXT_opacity_micromap
VK_OBJECT_TYPE_MICROMAP_EXT = 1000396000,
// Provided by VK_NV_optical_flow
VK_OBJECT_TYPE_OPTICAL_FLOW_SESSION_NV = 1000464000,
// Provided by VK_EXT_shader_object
VK_OBJECT_TYPE_SHADER_EXT = 1000482000,
// Provided by VK_KHR_pipeline_binary
VK_OBJECT_TYPE_PIPELINE_BINARY_KHR = 1000483000,
// Provided by VK_NV_external_compute_queue
VK_OBJECT_TYPE_EXTERNAL_COMPUTE_QUEUE_NV = 1000556000,
// Provided by VK_EXT_device_generated_commands
VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_EXT = 1000572000,
// Provided by VK_EXT_device_generated_commands
VK_OBJECT_TYPE_INDIRECT_EXECUTION_SET_EXT = 1000572001,
// Provided by VK_KHR_descriptor_update_template
VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR = VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE,
// Provided by VK_KHR_sampler_ycbcr_conversion
VK_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR = VK_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION,
// Provided by VK_EXT_private_data
VK_OBJECT_TYPE_PRIVATE_DATA_SLOT_EXT = VK_OBJECT_TYPE_PRIVATE_DATA_SLOT,
} VkObjectType;
| VkObjectType | Vulkan Handle Type |
|---|---|
|
Unknown/Undefined Handle |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If this Specification was generated with any such extensions included, they will be described in the remainder of this chapter.
51.1. Debug Utilities
Vulkan provides flexible debugging utilities for debugging an application.
The Object Debug Annotation section describes how to associate either a name or binary data with a specific Vulkan object.
The Queue Labels section describes how to annotate and group the work submitted to a queue.
The Command Buffer Labels section describes how to associate logical elements of the scene with commands in a VkCommandBuffer.
The Debug Messengers section describes how to create debug messenger objects associated with an application supplied callback to capture debug messages from a variety of Vulkan components.
51.1.1. Object Debug Annotation
It can be useful for an application to provide its own content relative to a specific Vulkan object.
The following commands allow application developers to associate
application-defined information with Vulkan objects.
These commands are device-level commands but they may reference
instance-level objects (such as VkInstance) and physical device-level
objects (such as VkPhysicalDevice) with a few restrictions:
* The data for the corresponding object may still be available after the
VkDevice used in the corresponding API call to set it is
destroyed, but access to this data is not guaranteed and should be
avoided.
* Subsequent calls to change the data of the same object across multiple
VkDevice objects, may result in the data being changed to the
most recent version for all VkDevice objects and not just the
VkDevice used in the most recent API call.
Object Naming
An object can be given an application-defined name by calling:
// Provided by VK_EXT_debug_utils
VkResult vkSetDebugUtilsObjectNameEXT(
VkDevice device,
const VkDebugUtilsObjectNameInfoEXT* pNameInfo);
-
deviceis the device that is associated with the named object passed in viaobjectHandle. -
pNameInfois a pointer to a VkDebugUtilsObjectNameInfoEXT structure specifying parameters of the name to set on the object.
The VkDebugUtilsObjectNameInfoEXT structure is defined as:
// Provided by VK_EXT_debug_utils
typedef struct VkDebugUtilsObjectNameInfoEXT {
VkStructureType sType;
const void* pNext;
VkObjectType objectType;
uint64_t objectHandle;
const char* pObjectName;
} VkDebugUtilsObjectNameInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
objectTypeis a VkObjectType specifying the type of the object to be named. -
objectHandleis the object to be named. -
pObjectNameis eitherNULLor a null-terminated UTF-8 string specifying the name to apply toobjectHandle.
Applications may change the name associated with an object simply by
calling vkSetDebugUtilsObjectNameEXT again with a new string.
If pObjectName is either NULL or an empty string, then any
previously set name is removed.
The graphicsPipelineLibrary
feature allows the specification of pipelines without the creation of
VkShaderModule objects beforehand.
In order to continue to allow naming these shaders independently,
VkDebugUtilsObjectNameInfoEXT can be included in the pNext
chain of VkPipelineShaderStageCreateInfo, which associates a static
name with that particular shader.
Object Data Association
In addition to setting a name for an object, debugging and validation layers may have uses for additional binary data on a per-object basis that have no other place in the Vulkan API.
For example, a VkShaderModule could have additional debugging data
attached to it to aid in offline shader tracing.
Additional data can be attached to an object by calling
vkSetDebugUtilsObjectTagEXT as defined below.
// Provided by VK_EXT_debug_utils
VkResult vkSetDebugUtilsObjectTagEXT(
VkDevice device,
const VkDebugUtilsObjectTagInfoEXT* pTagInfo);
-
deviceis the device that created the object. -
pTagInfois a pointer to a VkDebugUtilsObjectTagInfoEXT structure specifying parameters of the tag to attach to the object.
The VkDebugUtilsObjectTagInfoEXT structure is defined as:
// Provided by VK_EXT_debug_utils
typedef struct VkDebugUtilsObjectTagInfoEXT {
VkStructureType sType;
const void* pNext;
VkObjectType objectType;
uint64_t objectHandle;
uint64_t tagName;
size_t tagSize;
const void* pTag;
} VkDebugUtilsObjectTagInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
objectTypeis a VkObjectType specifying the type of the object to be named. -
objectHandleis the object to be tagged. -
tagNameis a numerical identifier of the tag. -
tagSizeis the number of bytes of data to attach to the object. -
pTagis a pointer to an array oftagSizebytes containing the data to be associated with the object.
The tagName parameter gives a name or identifier to the type of data
being tagged.
This can be used by debugging layers to easily filter for only data that can
be used by that implementation.
51.1.2. Queue Labels
All Vulkan work is submitted using queues. It is possible for an application to use multiple queues, each containing multiple command buffers, when performing work. It can be useful to identify which queue, or even where in a queue, something has occurred.
To begin identifying a region using a debug label inside a queue, you may use the vkQueueBeginDebugUtilsLabelEXT command.
Then, when the region of interest has passed, you may end the label region using vkQueueEndDebugUtilsLabelEXT.
Additionally, a single debug label may be inserted at any time using vkQueueInsertDebugUtilsLabelEXT.
A queue debug label region is opened by calling:
// Provided by VK_EXT_debug_utils
void vkQueueBeginDebugUtilsLabelEXT(
VkQueue queue,
const VkDebugUtilsLabelEXT* pLabelInfo);
-
queueis the queue in which to start a debug label region. -
pLabelInfois a pointer to a VkDebugUtilsLabelEXT structure specifying parameters of the label region to open.
The VkDebugUtilsLabelEXT structure is defined as:
// Provided by VK_EXT_debug_utils
typedef struct VkDebugUtilsLabelEXT {
VkStructureType sType;
const void* pNext;
const char* pLabelName;
float color[4];
} VkDebugUtilsLabelEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
pLabelNameis a pointer to a null-terminated UTF-8 string containing the name of the label. -
coloris an optional RGBA color value that can be associated with the label. A particular implementation may choose to ignore this color value. The values contain RGBA values in order, in the range 0.0 to 1.0. If all elements incolorare 0.0, then it is ignored.
A queue debug label region is closed by calling:
// Provided by VK_EXT_debug_utils
void vkQueueEndDebugUtilsLabelEXT(
VkQueue queue);
-
queueis the queue in which a debug label region should be closed.
The calls to vkQueueBeginDebugUtilsLabelEXT and vkQueueEndDebugUtilsLabelEXT must be matched and balanced.
A single label can be inserted into a queue by calling:
// Provided by VK_EXT_debug_utils
void vkQueueInsertDebugUtilsLabelEXT(
VkQueue queue,
const VkDebugUtilsLabelEXT* pLabelInfo);
-
queueis the queue into which a debug label will be inserted. -
pLabelInfois a pointer to a VkDebugUtilsLabelEXT structure specifying parameters of the label to insert.
51.1.3. Command Buffer Labels
Typical Vulkan applications will submit many command buffers in each frame, with each command buffer containing a large number of individual commands. Being able to logically annotate regions of command buffers that belong together as well as hierarchically subdivide the frame is important to a developer’s ability to navigate the commands viewed holistically.
To identify the beginning of a debug label region in a command buffer, vkCmdBeginDebugUtilsLabelEXT can be used as defined below.
To indicate the end of a debug label region in a command buffer, vkCmdEndDebugUtilsLabelEXT can be used.
To insert a single command buffer debug label inside of a command buffer, vkCmdInsertDebugUtilsLabelEXT can be used as defined below.
A command buffer debug label region can be opened by calling:
// Provided by VK_EXT_debug_utils
void vkCmdBeginDebugUtilsLabelEXT(
VkCommandBuffer commandBuffer,
const VkDebugUtilsLabelEXT* pLabelInfo);
-
commandBufferis the command buffer into which the command is recorded. -
pLabelInfois a pointer to a VkDebugUtilsLabelEXT structure specifying parameters of the label region to open.
A command buffer label region can be closed by calling:
// Provided by VK_EXT_debug_utils
void vkCmdEndDebugUtilsLabelEXT(
VkCommandBuffer commandBuffer);
-
commandBufferis the command buffer into which the command is recorded.
An application may open a debug label region in one command buffer and close it in another, or otherwise split debug label regions across multiple command buffers or multiple queue submissions. When viewed from the linear series of submissions to a single queue, the calls to vkCmdBeginDebugUtilsLabelEXT and vkCmdEndDebugUtilsLabelEXT must be matched and balanced.
There can be problems reporting command buffer debug labels during the recording process because command buffers may be recorded out of sequence with the resulting execution order. Since the recording order may be different, a solitary command buffer may have an inconsistent view of the debug label regions by itself. Therefore, if an issue occurs during the recording of a command buffer, and the environment requires returning debug labels, the implementation may return only those labels it is aware of. This is true even if the implementation is aware of only the debug labels within the command buffer being actively recorded.
A single debug label can be inserted into a command buffer by calling:
// Provided by VK_EXT_debug_utils
void vkCmdInsertDebugUtilsLabelEXT(
VkCommandBuffer commandBuffer,
const VkDebugUtilsLabelEXT* pLabelInfo);
-
commandBufferis the command buffer into which the command is recorded. -
pLabelInfois a pointer to a VkDebugUtilsLabelEXT structure specifying parameters of the label to insert.
51.1.4. Debug Messengers
Vulkan allows an application to register multiple callbacks with any Vulkan component wishing to report debug information. Some callbacks may log the information to a file, others may cause a debug break point or other application-defined behavior. A primary producer of callback messages are the validation layers. An application can register callbacks even when no validation layers are enabled, but they will only be called for the Vulkan loader and, if implemented, other layer and driver events.
A VkDebugUtilsMessengerEXT is a messenger object which handles passing
along debug messages to a provided debug callback.
// Provided by VK_EXT_debug_utils
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDebugUtilsMessengerEXT)
The debug messenger will provide detailed feedback on the application’s use of Vulkan when events of interest occur. When an event of interest does occur, the debug messenger will submit a debug message to the debug callback that was provided during its creation. Additionally, the debug messenger is responsible with filtering out debug messages that the callback is not interested in and will only provide desired debug messages.
A debug messenger triggers a debug callback with a debug message when an event of interest occurs. To create a debug messenger which will trigger a debug callback, call:
// Provided by VK_EXT_debug_utils
VkResult vkCreateDebugUtilsMessengerEXT(
VkInstance instance,
const VkDebugUtilsMessengerCreateInfoEXT* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkDebugUtilsMessengerEXT* pMessenger);
-
instanceis the instance the messenger will be used with. -
pCreateInfois a pointer to a VkDebugUtilsMessengerCreateInfoEXT structure containing the callback pointer, as well as defining conditions under which this messenger will trigger the callback. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter. -
pMessengeris a pointer to a VkDebugUtilsMessengerEXT handle in which the created object is returned.
The application must ensure that vkCreateDebugUtilsMessengerEXT is
not executed in parallel with any Vulkan command that is also called with
instance or child of instance as the dispatchable argument.
The definition of VkDebugUtilsMessengerCreateInfoEXT is:
// Provided by VK_EXT_debug_utils
typedef struct VkDebugUtilsMessengerCreateInfoEXT {
VkStructureType sType;
const void* pNext;
VkDebugUtilsMessengerCreateFlagsEXT flags;
VkDebugUtilsMessageSeverityFlagsEXT messageSeverity;
VkDebugUtilsMessageTypeFlagsEXT messageType;
PFN_vkDebugUtilsMessengerCallbackEXT pfnUserCallback;
void* pUserData;
} VkDebugUtilsMessengerCreateInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis0and is reserved for future use. -
messageSeverityis a bitmask of VkDebugUtilsMessageSeverityFlagBitsEXT specifying which severity of event(s) will cause this callback to be called. -
messageTypeis a bitmask of VkDebugUtilsMessageTypeFlagBitsEXT specifying which type of event(s) will cause this callback to be called. -
pfnUserCallbackis the application callback function to call. -
pUserDatais user data to be passed to the callback.
For each VkDebugUtilsMessengerEXT that is created the
VkDebugUtilsMessengerCreateInfoEXT::messageSeverity and
VkDebugUtilsMessengerCreateInfoEXT::messageType determine when
that VkDebugUtilsMessengerCreateInfoEXT::pfnUserCallback is
called.
The process to determine if the user’s pfnUserCallback is triggered
when an event occurs is as follows:
-
The implementation will perform a bitwise AND of the event’s VkDebugUtilsMessageSeverityFlagBitsEXT with the
messageSeverityprovided during creation of the VkDebugUtilsMessengerEXT object.-
If the value is 0, the message is skipped.
-
-
The implementation will perform bitwise AND of the event’s VkDebugUtilsMessageTypeFlagBitsEXT with the
messageTypeprovided during the creation of the VkDebugUtilsMessengerEXT object.-
If the value is 0, the message is skipped.
-
-
The callback will trigger a debug message for the current event
The callback will come directly from the component that detected the event, unless some other layer intercepts the calls for its own purposes (filter them in a different way, log to a system error log, etc.).
An application can receive multiple callbacks if multiple
VkDebugUtilsMessengerEXT objects are created.
A callback will always be executed in the same thread as the originating
Vulkan call.
A callback can be called from multiple threads simultaneously (if the application is making Vulkan calls from multiple threads).
// Provided by VK_EXT_debug_utils
typedef VkFlags VkDebugUtilsMessengerCreateFlagsEXT;
VkDebugUtilsMessengerCreateFlagsEXT is a bitmask type for setting a
mask, but is currently reserved for future use.
Bits which can be set in
VkDebugUtilsMessengerCreateInfoEXT::messageSeverity, specifying
event severities which cause a debug messenger to call the callback, are:
// Provided by VK_EXT_debug_utils
typedef enum VkDebugUtilsMessageSeverityFlagBitsEXT {
VK_DEBUG_UTILS_MESSAGE_SEVERITY_VERBOSE_BIT_EXT = 0x00000001,
VK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXT = 0x00000010,
VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT = 0x00000100,
VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT = 0x00001000,
} VkDebugUtilsMessageSeverityFlagBitsEXT;
-
VK_DEBUG_UTILS_MESSAGE_SEVERITY_VERBOSE_BIT_EXTspecifies the most verbose output indicating all diagnostic messages from the Vulkan loader, layers, and drivers should be captured. -
VK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXTspecifies an informational message such as resource details that may be handy when debugging an application. -
VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXTspecifies use of Vulkan that may expose an application bug. Such cases may not be immediately harmful, such as a fragment shader outputting to a location with no attachment. Other cases may point to behavior that is almost certainly bad when unintended such as using an image whose memory has not been filled. In general if you see a warning but you know that the behavior is intended/desired, then simply ignore the warning. -
VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXTspecifies that the application has violated a valid usage condition of the specification.
|
Note
|
The values of VkDebugUtilsMessageSeverityFlagBitsEXT are sorted based on severity. The higher the flag value, the more severe the message. This allows for simple boolean operation comparisons when looking at VkDebugUtilsMessageSeverityFlagBitsEXT values. For example:
In addition, space has been left between the enums to allow for later addition of new severities in between the existing values. |
// Provided by VK_EXT_debug_utils
typedef VkFlags VkDebugUtilsMessageSeverityFlagsEXT;
VkDebugUtilsMessageSeverityFlagsEXT is a bitmask type for setting a
mask of zero or more VkDebugUtilsMessageSeverityFlagBitsEXT.
Bits which can be set in
VkDebugUtilsMessengerCreateInfoEXT::messageType, specifying
event types which cause a debug messenger to call the callback, are:
// Provided by VK_EXT_debug_utils
typedef enum VkDebugUtilsMessageTypeFlagBitsEXT {
VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT = 0x00000001,
VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT = 0x00000002,
VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXT = 0x00000004,
// Provided by VK_EXT_device_address_binding_report
VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT = 0x00000008,
} VkDebugUtilsMessageTypeFlagBitsEXT;
-
VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXTspecifies that some general event has occurred. This is typically a non-specification, non-performance event. -
VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXTspecifies that something has occurred during validation against the Vulkan specification that may indicate invalid behavior. -
VK_DEBUG_UTILS_MESSAGE_TYPE_PERFORMANCE_BIT_EXTspecifies a potentially non-optimal use of Vulkan, e.g. using vkCmdClearColorImage when setting VkAttachmentDescription::loadOptoVK_ATTACHMENT_LOAD_OP_CLEARwould have worked. -
VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXTspecifies that the implementation has modified the set of GPU-visible virtual addresses associated with a Vulkan object.
// Provided by VK_EXT_debug_utils
typedef VkFlags VkDebugUtilsMessageTypeFlagsEXT;
VkDebugUtilsMessageTypeFlagsEXT is a bitmask type for setting a mask
of zero or more VkDebugUtilsMessageTypeFlagBitsEXT.
The prototype for the
VkDebugUtilsMessengerCreateInfoEXT::pfnUserCallback function
implemented by the application is:
// Provided by VK_EXT_debug_utils
typedef VkBool32 (VKAPI_PTR *PFN_vkDebugUtilsMessengerCallbackEXT)(
VkDebugUtilsMessageSeverityFlagBitsEXT messageSeverity,
VkDebugUtilsMessageTypeFlagsEXT messageTypes,
const VkDebugUtilsMessengerCallbackDataEXT* pCallbackData,
void* pUserData);
-
messageSeverityspecifies the VkDebugUtilsMessageSeverityFlagBitsEXT that triggered this callback. -
messageTypesis a bitmask of VkDebugUtilsMessageTypeFlagBitsEXT specifying which type of event(s) triggered this callback. -
pCallbackDatacontains all the callback related data in the VkDebugUtilsMessengerCallbackDataEXT structure. -
pUserDatais the user data provided when the VkDebugUtilsMessengerEXT was created.
The callback returns a VkBool32, which is interpreted in a
layer-specified manner.
The application should always return VK_FALSE.
The VK_TRUE value is reserved for use in layer development.
The definition of VkDebugUtilsMessengerCallbackDataEXT is:
// Provided by VK_EXT_debug_utils
typedef struct VkDebugUtilsMessengerCallbackDataEXT {
VkStructureType sType;
const void* pNext;
VkDebugUtilsMessengerCallbackDataFlagsEXT flags;
const char* pMessageIdName;
int32_t messageIdNumber;
const char* pMessage;
uint32_t queueLabelCount;
const VkDebugUtilsLabelEXT* pQueueLabels;
uint32_t cmdBufLabelCount;
const VkDebugUtilsLabelEXT* pCmdBufLabels;
uint32_t objectCount;
const VkDebugUtilsObjectNameInfoEXT* pObjects;
} VkDebugUtilsMessengerCallbackDataEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis0and is reserved for future use. -
pMessageIdNameisNULLor a null-terminated UTF-8 string that identifies the particular message ID that is associated with the provided message. If the message corresponds to a validation layer message, then this string will be the VUID. -
messageIdNumberis the ID number of the triggering message. If the message corresponds to a validation layer message, then this number is an internal hash of the VUID. -
pMessageisNULLifmessageTypesis equal toVK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT, or a null-terminated UTF-8 string detailing the trigger conditions. If the message corresponds to a validation layer message, then this will contain the main message with the specification text and link. -
queueLabelCountis a count of items contained in thepQueueLabelsarray. -
pQueueLabelsisNULLor a pointer to an array of VkDebugUtilsLabelEXT active in the currentVkQueueat the time the callback was triggered. Refer to Queue Labels for more information. -
cmdBufLabelCountis a count of items contained in thepCmdBufLabelsarray. -
pCmdBufLabelsisNULLor a pointer to an array of VkDebugUtilsLabelEXT active in the currentVkCommandBufferat the time the callback was triggered. Refer to Command Buffer Labels for more information. -
objectCountis a count of items contained in thepObjectsarray. -
pObjectsis a pointer to an array of VkDebugUtilsObjectNameInfoEXT objects related to the detected issue. The array is roughly in order or importance, but the 0th element is always guaranteed to be the most important object for this message.
|
Note
|
This structure should only be considered valid during the lifetime of the triggered callback. |
Since adding queue and command buffer labels behaves like pushing and
popping onto a stack, the order of both pQueueLabels and
pCmdBufLabels is based on the order the labels were defined.
The result is that the first label in either pQueueLabels or
pCmdBufLabels will be the first defined (and therefore the oldest)
while the last label in each list will be the most recent.
|
Note
|
Likewise, |
// Provided by VK_EXT_debug_utils
typedef VkFlags VkDebugUtilsMessengerCallbackDataFlagsEXT;
VkDebugUtilsMessengerCallbackDataFlagsEXT is a bitmask type for
setting a mask, but is currently reserved for future use.
The definition of VkDeviceAddressBindingCallbackDataEXT is:
// Provided by VK_EXT_device_address_binding_report
typedef struct VkDeviceAddressBindingCallbackDataEXT {
VkStructureType sType;
void* pNext;
VkDeviceAddressBindingFlagsEXT flags;
VkDeviceAddress baseAddress;
VkDeviceSize size;
VkDeviceAddressBindingTypeEXT bindingType;
} VkDeviceAddressBindingCallbackDataEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkDeviceAddressBindingFlagBitsEXT specifying additional information about the binding event that caused the callback to be called. -
baseAddressis a GPU-accessible virtual address identifying the start of a region of the virtual address space associated with a Vulkan object, as identified by thepObjectsmember of VkDebugUtilsMessengerCallbackDataEXT. -
sizeis the size in bytes of a region of GPU-accessible virtual address space. -
bindingTypeis a VkDeviceAddressBindingTypeEXT specifying the type of binding event that caused the callback to be called.
If the reportAddressBinding feature
is enabled and the implementation binds or unbinds a region of virtual
address space associated with a Vulkan object, the implementation must
submit a debug message with the following properties:
-
messageSeverityequal toVK_DEBUG_UTILS_MESSAGE_SEVERITY_INFO_BIT_EXT -
messageTypesequal toVK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT -
VkDebugUtilsMessengerCallbackDataEXT::pObjectsmust identify the associated Vulkan object -
VkDeviceAddressBindingCallbackDataEXTmust be included in thepNextchain ofVkDebugUtilsMessengerCallbackDataEXT
These debug messages must be emitted both for GPU virtual address space
regions that are explicitly bound to a Vulkan object via the
vkBind*Memory/vkBind*Memory2 functions, and for those that are
implicitly generated via memory allocation or importing external memory.
An implementation may report binding events associated with a Vulkan object
via VkDebugUtilsMessengerEXT prior to the object becoming visible to
an application via other Vulkan commands.
For example, object creation functions may report binding events that occur
during an objects creation.
In such cases, VkDeviceAddressBindingCallbackDataEXT::flags
must include VK_DEVICE_ADDRESS_BINDING_INTERNAL_OBJECT_BIT_EXT.
Object handles reported in this manner are not valid object handles, and must not be used as an input parameter to any Vulkan command.
Any valid object handle returned by an object creation function must match the handle specified via any previously reported binding events associated with the object’s creation.
Bits which can be set in
VkDeviceAddressBindingCallbackDataEXT::flags specifying
additional information about a binding event are:
// Provided by VK_EXT_device_address_binding_report
typedef enum VkDeviceAddressBindingFlagBitsEXT {
VK_DEVICE_ADDRESS_BINDING_INTERNAL_OBJECT_BIT_EXT = 0x00000001,
} VkDeviceAddressBindingFlagBitsEXT;
-
VK_DEVICE_ADDRESS_BINDING_INTERNAL_OBJECT_BIT_EXTspecifies that VkDeviceAddressBindingCallbackDataEXT describes a Vulkan object that has not been made visible to the application via a Vulkan command.
// Provided by VK_EXT_device_address_binding_report
typedef VkFlags VkDeviceAddressBindingFlagsEXT;
VkDeviceAddressBindingFlagsEXT is a bitmask type for setting a mask of zero or more VkDeviceAddressBindingFlagBitsEXT.
The VkDeviceAddressBindingTypeEXT enum is defined as:
// Provided by VK_EXT_device_address_binding_report
typedef enum VkDeviceAddressBindingTypeEXT {
VK_DEVICE_ADDRESS_BINDING_TYPE_BIND_EXT = 0,
VK_DEVICE_ADDRESS_BINDING_TYPE_UNBIND_EXT = 1,
} VkDeviceAddressBindingTypeEXT;
-
VK_DEVICE_ADDRESS_BINDING_TYPE_BIND_EXTspecifies that a new GPU-accessible virtual address range has been bound. -
VK_DEVICE_ADDRESS_BINDING_TYPE_UNBIND_EXTspecifies that a GPU-accessible virtual address range has been unbound.
To intentionally submit a debug message, call:
// Provided by VK_EXT_debug_utils
void vkSubmitDebugUtilsMessageEXT(
VkInstance instance,
VkDebugUtilsMessageSeverityFlagBitsEXT messageSeverity,
VkDebugUtilsMessageTypeFlagsEXT messageTypes,
const VkDebugUtilsMessengerCallbackDataEXT* pCallbackData);
-
instanceis the debug stream’s VkInstance. -
messageSeverityis a VkDebugUtilsMessageSeverityFlagBitsEXT value specifying the severity of this event/message. -
messageTypesis a bitmask of VkDebugUtilsMessageTypeFlagBitsEXT specifying which type of event(s) to identify with this message. -
pCallbackDatacontains all the callback related data in the VkDebugUtilsMessengerCallbackDataEXT structure.
The call will propagate through the layers and generate callback(s) as
indicated by the message’s flags.
The parameters are passed on to the callback in addition to the
pUserData value that was defined at the time the messenger was
registered.
To destroy a VkDebugUtilsMessengerEXT object, call:
// Provided by VK_EXT_debug_utils
void vkDestroyDebugUtilsMessengerEXT(
VkInstance instance,
VkDebugUtilsMessengerEXT messenger,
const VkAllocationCallbacks* pAllocator);
-
instanceis the instance where the callback was created. -
messengeris the VkDebugUtilsMessengerEXT object to destroy.messengeris an externally synchronized object and must not be used on more than one thread at a time. This means thatvkDestroyDebugUtilsMessengerEXTmust not be called when a callback is active. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter.
The application must ensure that vkDestroyDebugUtilsMessengerEXT is
not executed in parallel with any Vulkan command that is also called with
instance or child of instance as the dispatchable argument.
51.2. Debug Markers
Debug markers provide a flexible way for debugging and validation layers to receive annotation and debug information.
The Object Annotation section describes how to associate a name or binary data with a Vulkan object.
The Command Buffer Markers section describes how to associate logical elements of the scene with commands in the command buffer.
51.2.1. Object Annotation
The commands in this section allow application developers to associate application-defined information with Vulkan objects at will.
An object can be given an application-defined name by calling:
// Provided by VK_EXT_debug_marker
VkResult vkDebugMarkerSetObjectNameEXT(
VkDevice device,
const VkDebugMarkerObjectNameInfoEXT* pNameInfo);
-
deviceis the device that created the object. -
pNameInfois a pointer to a VkDebugMarkerObjectNameInfoEXT structure specifying the parameters of the name to set on the object.
The VkDebugMarkerObjectNameInfoEXT structure is defined as:
// Provided by VK_EXT_debug_marker
typedef struct VkDebugMarkerObjectNameInfoEXT {
VkStructureType sType;
const void* pNext;
VkDebugReportObjectTypeEXT objectType;
uint64_t object;
const char* pObjectName;
} VkDebugMarkerObjectNameInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
objectTypeis a VkDebugReportObjectTypeEXT specifying the type of the object to be named. -
objectis the object to be named. -
pObjectNameis a null-terminated UTF-8 string specifying the name to apply toobject.
Applications may change the name associated with an object simply by
calling vkDebugMarkerSetObjectNameEXT again with a new string.
To remove a previously set name, pObjectName should be an empty
string.
In addition to setting a name for an object, debugging and validation layers
may have uses for additional binary data on a per-object basis that has no
other place in the Vulkan API.
For example, a VkShaderModule could have additional debugging data
attached to it to aid in offline shader tracing.
To attach data to an object, call:
// Provided by VK_EXT_debug_marker
VkResult vkDebugMarkerSetObjectTagEXT(
VkDevice device,
const VkDebugMarkerObjectTagInfoEXT* pTagInfo);
-
deviceis the device that created the object. -
pTagInfois a pointer to a VkDebugMarkerObjectTagInfoEXT structure specifying the parameters of the tag to attach to the object.
The VkDebugMarkerObjectTagInfoEXT structure is defined as:
// Provided by VK_EXT_debug_marker
typedef struct VkDebugMarkerObjectTagInfoEXT {
VkStructureType sType;
const void* pNext;
VkDebugReportObjectTypeEXT objectType;
uint64_t object;
uint64_t tagName;
size_t tagSize;
const void* pTag;
} VkDebugMarkerObjectTagInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
objectTypeis a VkDebugReportObjectTypeEXT specifying the type of the object to be named. -
objectis the object to be tagged. -
tagNameis a numerical identifier of the tag. -
tagSizeis the number of bytes of data to attach to the object. -
pTagis a pointer to an array oftagSizebytes containing the data to be associated with the object.
The tagName parameter gives a name or identifier to the type of data
being tagged.
This can be used by debugging layers to easily filter for only data that can
be used by that implementation.
51.2.2. Command Buffer Markers
Typical Vulkan applications will submit many command buffers in each frame, with each command buffer containing a large number of individual commands. Being able to logically annotate regions of command buffers that belong together as well as hierarchically subdivide the frame is important to a developer’s ability to navigate the commands viewed holistically.
The marker commands vkCmdDebugMarkerBeginEXT and
vkCmdDebugMarkerEndEXT define regions of a series of commands that are
grouped together, and they can be nested to create a hierarchy.
The vkCmdDebugMarkerInsertEXT command allows insertion of a single
label within a command buffer.
A marker region can be opened by calling:
// Provided by VK_EXT_debug_marker
void vkCmdDebugMarkerBeginEXT(
VkCommandBuffer commandBuffer,
const VkDebugMarkerMarkerInfoEXT* pMarkerInfo);
-
commandBufferis the command buffer into which the command is recorded. -
pMarkerInfois a pointer to a VkDebugMarkerMarkerInfoEXT structure specifying the parameters of the marker region to open.
The VkDebugMarkerMarkerInfoEXT structure is defined as:
// Provided by VK_EXT_debug_marker
typedef struct VkDebugMarkerMarkerInfoEXT {
VkStructureType sType;
const void* pNext;
const char* pMarkerName;
float color[4];
} VkDebugMarkerMarkerInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
pMarkerNameis a pointer to a null-terminated UTF-8 string containing the name of the marker. -
coloris an optional RGBA color value that can be associated with the marker. A particular implementation may choose to ignore this color value. The values contain RGBA values in order, in the range 0.0 to 1.0. If all elements incolorare 0.0, then it is ignored.
A marker region can be closed by calling:
// Provided by VK_EXT_debug_marker
void vkCmdDebugMarkerEndEXT(
VkCommandBuffer commandBuffer);
-
commandBufferis the command buffer into which the command is recorded.
An application may open a marker region in one command buffer and close it
in another, or otherwise split marker regions across multiple command
buffers or multiple queue submissions.
When viewed from the linear series of submissions to a single queue, the
calls to vkCmdDebugMarkerBeginEXT and vkCmdDebugMarkerEndEXT
must be matched and balanced.
A single marker label can be inserted into a command buffer by calling:
// Provided by VK_EXT_debug_marker
void vkCmdDebugMarkerInsertEXT(
VkCommandBuffer commandBuffer,
const VkDebugMarkerMarkerInfoEXT* pMarkerInfo);
-
commandBufferis the command buffer into which the command is recorded. -
pMarkerInfois a pointer to a VkDebugMarkerMarkerInfoEXT structure specifying the parameters of the marker to insert.
51.3. Debug Report Callbacks
Debug report callbacks are represented by VkDebugReportCallbackEXT
handles:
// Provided by VK_EXT_debug_report
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDebugReportCallbackEXT)
Debug report callbacks give more detailed feedback on the application’s use of Vulkan when events of interest occur.
To register a debug report callback, an application uses vkCreateDebugReportCallbackEXT.
// Provided by VK_EXT_debug_report
VkResult vkCreateDebugReportCallbackEXT(
VkInstance instance,
const VkDebugReportCallbackCreateInfoEXT* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkDebugReportCallbackEXT* pCallback);
-
instanceis the instance the callback will be logged on. -
pCreateInfois a pointer to a VkDebugReportCallbackCreateInfoEXT structure defining the conditions under which this callback will be called. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter. -
pCallbackis a pointer to a VkDebugReportCallbackEXT handle in which the created object is returned.
The definition of VkDebugReportCallbackCreateInfoEXT is:
// Provided by VK_EXT_debug_report
typedef struct VkDebugReportCallbackCreateInfoEXT {
VkStructureType sType;
const void* pNext;
VkDebugReportFlagsEXT flags;
PFN_vkDebugReportCallbackEXT pfnCallback;
void* pUserData;
} VkDebugReportCallbackCreateInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkDebugReportFlagBitsEXT specifying which event(s) will cause this callback to be called. -
pfnCallbackis the application callback function to call. -
pUserDatais user data to be passed to the callback.
For each VkDebugReportCallbackEXT that is created the
VkDebugReportCallbackCreateInfoEXT::flags determine when that
VkDebugReportCallbackCreateInfoEXT::pfnCallback is called.
When an event happens, the implementation will do a bitwise AND of the
event’s VkDebugReportFlagBitsEXT flags to each
VkDebugReportCallbackEXT object’s flags.
For each non-zero result the corresponding callback will be called.
The callback will come directly from the component that detected the event,
unless some other layer intercepts the calls for its own purposes (filter
them in a different way, log to a system error log, etc.).
An application may receive multiple callbacks if multiple
VkDebugReportCallbackEXT objects were created.
A callback will always be executed in the same thread as the originating
Vulkan call.
A callback may be called from multiple threads simultaneously (if the application is making Vulkan calls from multiple threads).
Bits which can be set in
VkDebugReportCallbackCreateInfoEXT::flags, specifying events
which cause a debug report, are:
// Provided by VK_EXT_debug_report
typedef enum VkDebugReportFlagBitsEXT {
VK_DEBUG_REPORT_INFORMATION_BIT_EXT = 0x00000001,
VK_DEBUG_REPORT_WARNING_BIT_EXT = 0x00000002,
VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXT = 0x00000004,
VK_DEBUG_REPORT_ERROR_BIT_EXT = 0x00000008,
VK_DEBUG_REPORT_DEBUG_BIT_EXT = 0x00000010,
} VkDebugReportFlagBitsEXT;
-
VK_DEBUG_REPORT_ERROR_BIT_EXTspecifies that the application has violated a valid usage condition of the specification. -
VK_DEBUG_REPORT_WARNING_BIT_EXTspecifies use of Vulkan that may expose an application bug. Such cases may not be immediately harmful, such as a fragment shader outputting to a location with no attachment. Other cases may point to behavior that is almost certainly bad when unintended such as using an image whose memory has not been filled. In general if you see a warning but you know that the behavior is intended/desired, then simply ignore the warning. -
VK_DEBUG_REPORT_PERFORMANCE_WARNING_BIT_EXTspecifies a potentially non-optimal use of Vulkan, e.g. using vkCmdClearColorImage when setting VkAttachmentDescription::loadOptoVK_ATTACHMENT_LOAD_OP_CLEARwould have worked. -
VK_DEBUG_REPORT_INFORMATION_BIT_EXTspecifies an informational message such as resource details that may be handy when debugging an application. -
VK_DEBUG_REPORT_DEBUG_BIT_EXTspecifies diagnostic information from the implementation and layers.
// Provided by VK_EXT_debug_report
typedef VkFlags VkDebugReportFlagsEXT;
VkDebugReportFlagsEXT is a bitmask type for setting a mask of zero or
more VkDebugReportFlagBitsEXT.
The prototype for the
VkDebugReportCallbackCreateInfoEXT::pfnCallback function
implemented by the application is:
// Provided by VK_EXT_debug_report
typedef VkBool32 (VKAPI_PTR *PFN_vkDebugReportCallbackEXT)(
VkDebugReportFlagsEXT flags,
VkDebugReportObjectTypeEXT objectType,
uint64_t object,
size_t location,
int32_t messageCode,
const char* pLayerPrefix,
const char* pMessage,
void* pUserData);
-
flagsspecifies the VkDebugReportFlagBitsEXT that triggered this callback. -
objectTypeis a VkDebugReportObjectTypeEXT value specifying the type of object being used or created at the time the event was triggered. -
objectis the object where the issue was detected. IfobjectTypeisVK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT,objectis undefined. -
locationis a component (layer, driver, loader) defined value specifying the location of the trigger. This is an optional value. -
messageCodeis a layer-defined value indicating what test triggered this callback. -
pLayerPrefixis a null-terminated UTF-8 string that is an abbreviation of the name of the component making the callback.pLayerPrefixis only valid for the duration of the callback. -
pMessageis a null-terminated UTF-8 string detailing the trigger conditions.pMessageis only valid for the duration of the callback. -
pUserDatais the user data given when the VkDebugReportCallbackEXT was created.
The callback must not call vkDestroyDebugReportCallbackEXT.
The callback returns a VkBool32, which is interpreted in a
layer-specified manner.
The application should always return VK_FALSE.
The VK_TRUE value is reserved for use in layer development.
object must be a Vulkan object or VK_NULL_HANDLE.
If objectType is not VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT and
object is not VK_NULL_HANDLE, object must be a Vulkan
object of the corresponding type associated with objectType as defined
in VkDebugReportObjectTypeEXT and Vulkan Handle Relationship.
Possible values passed to the objectType parameter of the callback
function specified by
VkDebugReportCallbackCreateInfoEXT::pfnCallback, specifying the
type of object handle being reported, are:
// Provided by VK_EXT_debug_marker, VK_EXT_debug_report
typedef enum VkDebugReportObjectTypeEXT {
VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT = 0,
VK_DEBUG_REPORT_OBJECT_TYPE_INSTANCE_EXT = 1,
VK_DEBUG_REPORT_OBJECT_TYPE_PHYSICAL_DEVICE_EXT = 2,
VK_DEBUG_REPORT_OBJECT_TYPE_DEVICE_EXT = 3,
VK_DEBUG_REPORT_OBJECT_TYPE_QUEUE_EXT = 4,
VK_DEBUG_REPORT_OBJECT_TYPE_SEMAPHORE_EXT = 5,
VK_DEBUG_REPORT_OBJECT_TYPE_COMMAND_BUFFER_EXT = 6,
VK_DEBUG_REPORT_OBJECT_TYPE_FENCE_EXT = 7,
VK_DEBUG_REPORT_OBJECT_TYPE_DEVICE_MEMORY_EXT = 8,
VK_DEBUG_REPORT_OBJECT_TYPE_BUFFER_EXT = 9,
VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT = 10,
VK_DEBUG_REPORT_OBJECT_TYPE_EVENT_EXT = 11,
VK_DEBUG_REPORT_OBJECT_TYPE_QUERY_POOL_EXT = 12,
VK_DEBUG_REPORT_OBJECT_TYPE_BUFFER_VIEW_EXT = 13,
VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_VIEW_EXT = 14,
VK_DEBUG_REPORT_OBJECT_TYPE_SHADER_MODULE_EXT = 15,
VK_DEBUG_REPORT_OBJECT_TYPE_PIPELINE_CACHE_EXT = 16,
VK_DEBUG_REPORT_OBJECT_TYPE_PIPELINE_LAYOUT_EXT = 17,
VK_DEBUG_REPORT_OBJECT_TYPE_RENDER_PASS_EXT = 18,
VK_DEBUG_REPORT_OBJECT_TYPE_PIPELINE_EXT = 19,
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT_EXT = 20,
VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_EXT = 21,
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_POOL_EXT = 22,
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_SET_EXT = 23,
VK_DEBUG_REPORT_OBJECT_TYPE_FRAMEBUFFER_EXT = 24,
VK_DEBUG_REPORT_OBJECT_TYPE_COMMAND_POOL_EXT = 25,
VK_DEBUG_REPORT_OBJECT_TYPE_SURFACE_KHR_EXT = 26,
VK_DEBUG_REPORT_OBJECT_TYPE_SWAPCHAIN_KHR_EXT = 27,
VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT = 28,
VK_DEBUG_REPORT_OBJECT_TYPE_DISPLAY_KHR_EXT = 29,
VK_DEBUG_REPORT_OBJECT_TYPE_DISPLAY_MODE_KHR_EXT = 30,
VK_DEBUG_REPORT_OBJECT_TYPE_VALIDATION_CACHE_EXT_EXT = 33,
// Provided by VK_VERSION_1_1 with VK_EXT_debug_report, VK_KHR_sampler_ycbcr_conversion with VK_EXT_debug_report
VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT = 1000156000,
// Provided by VK_VERSION_1_1 with VK_EXT_debug_report
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT = 1000085000,
// Provided by VK_EXT_debug_report with VK_NVX_binary_import
VK_DEBUG_REPORT_OBJECT_TYPE_CU_MODULE_NVX_EXT = 1000029000,
// Provided by VK_EXT_debug_report with VK_NVX_binary_import
VK_DEBUG_REPORT_OBJECT_TYPE_CU_FUNCTION_NVX_EXT = 1000029001,
// Provided by VK_KHR_acceleration_structure with VK_EXT_debug_report
VK_DEBUG_REPORT_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR_EXT = 1000150000,
// Provided by VK_EXT_debug_report with VK_NV_ray_tracing
VK_DEBUG_REPORT_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV_EXT = 1000165000,
// Provided by VK_EXT_debug_report with VK_NV_cuda_kernel_launch
VK_DEBUG_REPORT_OBJECT_TYPE_CUDA_MODULE_NV_EXT = 1000307000,
// Provided by VK_EXT_debug_report with VK_NV_cuda_kernel_launch
VK_DEBUG_REPORT_OBJECT_TYPE_CUDA_FUNCTION_NV_EXT = 1000307001,
// Provided by VK_EXT_debug_report with VK_FUCHSIA_buffer_collection
VK_DEBUG_REPORT_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA_EXT = 1000366000,
// VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_EXT is a deprecated alias
VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_EXT = VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT,
// VK_DEBUG_REPORT_OBJECT_TYPE_VALIDATION_CACHE_EXT is a deprecated alias
VK_DEBUG_REPORT_OBJECT_TYPE_VALIDATION_CACHE_EXT = VK_DEBUG_REPORT_OBJECT_TYPE_VALIDATION_CACHE_EXT_EXT,
// Provided by VK_KHR_descriptor_update_template with VK_EXT_debug_report
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT = VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT,
// Provided by VK_KHR_sampler_ycbcr_conversion with VK_EXT_debug_report
VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR_EXT = VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT,
} VkDebugReportObjectTypeEXT;
| VkDebugReportObjectTypeEXT | Vulkan Handle Type |
|---|---|
|
Unknown/Undefined Handle |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note
|
The primary expected use of |
To inject its own messages into the debug stream, call:
// Provided by VK_EXT_debug_report
void vkDebugReportMessageEXT(
VkInstance instance,
VkDebugReportFlagsEXT flags,
VkDebugReportObjectTypeEXT objectType,
uint64_t object,
size_t location,
int32_t messageCode,
const char* pLayerPrefix,
const char* pMessage);
-
instanceis the debug stream’s VkInstance. -
flagsspecifies the VkDebugReportFlagBitsEXT classification of this event/message. -
objectTypeis a VkDebugReportObjectTypeEXT specifying the type of object being used or created at the time the event was triggered. -
objectis the object where the issue was detected.objectcan be VK_NULL_HANDLE if there is no object associated with the event. -
locationis an application-defined value. -
messageCodeis an application-defined value. -
pLayerPrefixis the abbreviation of the component making this event/message. -
pMessageis a null-terminated UTF-8 string detailing the trigger conditions.
The call will propagate through the layers and generate callback(s) as
indicated by the message’s flags.
The parameters are passed on to the callback in addition to the
pUserData value that was defined at the time the callback was
registered.
To destroy a VkDebugReportCallbackEXT object, call:
// Provided by VK_EXT_debug_report
void vkDestroyDebugReportCallbackEXT(
VkInstance instance,
VkDebugReportCallbackEXT callback,
const VkAllocationCallbacks* pAllocator);
-
instanceis the instance where the callback was created. -
callbackis the VkDebugReportCallbackEXT object to destroy.callbackis an externally synchronized object and must not be used on more than one thread at a time. This means thatvkDestroyDebugReportCallbackEXTmust not be called when a callback is active. -
pAllocatorcontrols host memory allocation as described in the Memory Allocation chapter.
51.4. Device Loss Debugging
51.4.1. Device Diagnostic Checkpoints
Device execution progress can be tracked for the purposes of debugging a device loss by annotating the command stream with application-defined diagnostic checkpoints.
Device diagnostic checkpoints are inserted into the command stream by calling vkCmdSetCheckpointNV.
// Provided by VK_NV_device_diagnostic_checkpoints
void vkCmdSetCheckpointNV(
VkCommandBuffer commandBuffer,
const void* pCheckpointMarker);
-
commandBufferis the command buffer that will receive the marker -
pCheckpointMarkeris an opaque application-provided value that will be associated with the checkpoint.
Note that pCheckpointMarker is treated as an opaque value.
It does not need to be a valid pointer and will not be dereferenced by the
implementation.
If the device encounters an error during execution, the implementation will
return a VK_ERROR_DEVICE_LOST error to the application at some point
during host execution.
When this happens, the application can call
vkGetQueueCheckpointData2NV to retrieve information on the most recent
diagnostic checkpoints that were executed by the device.
// Provided by VK_NV_device_diagnostic_checkpoints with VK_VERSION_1_3 or VK_KHR_synchronization2
void vkGetQueueCheckpointData2NV(
VkQueue queue,
uint32_t* pCheckpointDataCount,
VkCheckpointData2NV* pCheckpointData);
-
queueis the VkQueue object the caller would like to retrieve checkpoint data for -
pCheckpointDataCountis a pointer to an integer related to the number of checkpoint markers available or queried, as described below. -
pCheckpointDatais eitherNULLor a pointer to an array ofVkCheckpointData2NVstructures.
If pCheckpointData is NULL, then the number of checkpoint markers
available is returned in pCheckpointDataCount.
Otherwise, pCheckpointDataCount must point to a variable set by the
application to the number of elements in the pCheckpointData array,
and on return the variable is overwritten with the number of structures
actually written to pCheckpointData.
If pCheckpointDataCount is less than the number of checkpoint markers
available, at most pCheckpointDataCount structures will be written.
The VkCheckpointData2NV structure is defined as:
// Provided by VK_NV_device_diagnostic_checkpoints with VK_VERSION_1_3 or VK_KHR_synchronization2
typedef struct VkCheckpointData2NV {
VkStructureType sType;
void* pNext;
VkPipelineStageFlags2 stage;
void* pCheckpointMarker;
} VkCheckpointData2NV;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
stageindicates a single pipeline stage which the checkpoint marker data refers to. -
pCheckpointMarkercontains the value of the last checkpoint marker executed in the stage thatstagerefers to.
The stages at which a checkpoint marker can be executed are implementation-defined and can be queried by calling vkGetPhysicalDeviceQueueFamilyProperties2.
If the device encounters an error during execution, the implementation will
return a VK_ERROR_DEVICE_LOST error to the application at a certain
point during host execution.
When this happens, the application can call
vkGetQueueCheckpointDataNV to retrieve information on the most recent
diagnostic checkpoints that were executed by the device.
// Provided by VK_NV_device_diagnostic_checkpoints
void vkGetQueueCheckpointDataNV(
VkQueue queue,
uint32_t* pCheckpointDataCount,
VkCheckpointDataNV* pCheckpointData);
-
queueis the VkQueue object the caller would like to retrieve checkpoint data for -
pCheckpointDataCountis a pointer to an integer related to the number of checkpoint markers available or queried, as described below. -
pCheckpointDatais eitherNULLor a pointer to an array ofVkCheckpointDataNVstructures.
If pCheckpointData is NULL, then the number of checkpoint markers
available is returned in pCheckpointDataCount.
Otherwise, pCheckpointDataCount must point to a variable set by the
application to the number of elements in the pCheckpointData array,
and on return the variable is overwritten with the number of structures
actually written to pCheckpointData.
If pCheckpointDataCount is less than the number of checkpoint markers
available, at most pCheckpointDataCount structures will be written.
The VkCheckpointDataNV structure is defined as:
// Provided by VK_NV_device_diagnostic_checkpoints
typedef struct VkCheckpointDataNV {
VkStructureType sType;
void* pNext;
VkPipelineStageFlagBits stage;
void* pCheckpointMarker;
} VkCheckpointDataNV;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
stageis aVkPipelineStageFlagBitsvalue specifying which pipeline stage the checkpoint marker data refers to. -
pCheckpointMarkercontains the value of the last checkpoint marker executed in the stage thatstagerefers to.
The stages at which a checkpoint marker can be executed are implementation-defined and can be queried by calling vkGetPhysicalDeviceQueueFamilyProperties2.
51.4.2. Device Fault Diagnosis
To retrieve diagnostic information about faults that may have caused device loss, call:
// Provided by VK_EXT_device_fault
VkResult vkGetDeviceFaultInfoEXT(
VkDevice device,
VkDeviceFaultCountsEXT* pFaultCounts,
VkDeviceFaultInfoEXT* pFaultInfo);
-
deviceis the logical device from which to query the diagnostic fault information. -
pFaultCountsis a pointer to a VkDeviceFaultCountsEXT structure in which counts for structures describing additional fault information are returned. -
pFaultInfoisNULLor a pointer to a VkDeviceFaultInfoEXT structure in which fault information is returned.
If pFaultInfo is NULL, then the counts of corresponding additional
fault information structures available are returned in the
addressInfoCount and vendorInfoCount members of
pFaultCounts.
Additionally, the size of any vendor-specific binary crash dump is returned
in the vendorBinarySize member of pFaultCounts.
If pFaultInfo is not NULL, pFaultCounts must point to a
VkDeviceFaultCountsEXT structure with each structure count or size
member (addressInfoCount, vendorInfoCount,
vendorBinarySize) set by the application to the number of elements in
the corresponding output array member of pFaultInfo
(pAddressInfos and pVendorInfos), or to the size of the output
buffer in bytes (pVendorBinaryData).
On return, each structure count member is overwritten with the number of
structures actually written to the corresponding output array member of
pFaultInfo.
Similarly, vendorBinarySize is overwritten with the number of bytes
actually written to the pVendorBinaryData member of pFaultInfo.
If the vendor-specific crash dumps
feature is not enabled, then implementations must set
pFaultCounts->vendorBinarySize to zero and must not modify
pFaultInfo->pVendorBinaryData.
If any pFaultCounts structure count member is less than the number of
corresponding fault properties available, at most structure count
(addressInfoCount, vendorInfoCount) elements will be written to
the associated pFaultInfo output array.
Similarly, if vendorBinarySize is less than the size in bytes of the
available crash dump data, at most vendorBinarySize elements will be
written to pVendorBinaryData.
If pFaultInfo is NULL, then subsequent calls to
vkGetDeviceFaultInfoEXT for the same device must return
identical values in the addressInfoCount, vendorInfoCount and
vendorBinarySize members of pFaultCounts.
If pFaultInfo is not NULL, then subsequent calls to
vkGetDeviceFaultInfoEXT for the same device must return
identical values in the output members of pFaultInfo
(pAddressInfos, pVendorInfos, pVendorBinaryData), up to
the limits described by the structure count and buffer size members of
pFaultCounts (addressInfoCount, vendorInfoCount,
vendorBinarySize).
If the sizes of the output members of pFaultInfo increase for a
subsequent call to vkGetDeviceFaultInfoEXT, then supplementary
information may be returned in the additional available space.
If any pFaultCounts structure count member is smaller than the number
of corresponding fault properties available, or if
pFaultCounts->vendorBinarySize is smaller than the size in bytes of
the generated binary crash dump data, VK_INCOMPLETE will be returned
instead of VK_SUCCESS, to indicate that not all the available
properties were returned.
If pFaultCounts->vendorBinarySize is less than what is necessary to
store the binary crash dump header, nothing
will be written to pFaultInfo->pVendorBinaryData and zero will be
written to pFaultCounts->vendorBinarySize.
The VkDeviceFaultCountsEXT structure is defined as:
// Provided by VK_EXT_device_fault
typedef struct VkDeviceFaultCountsEXT {
VkStructureType sType;
void* pNext;
uint32_t addressInfoCount;
uint32_t vendorInfoCount;
VkDeviceSize vendorBinarySize;
} VkDeviceFaultCountsEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
addressInfoCountis the number of VkDeviceFaultAddressInfoEXT structures describing either memory accesses which may have caused a page fault, or the addresses of active instructions at the time of the fault. -
vendorInfoCountis the number of VkDeviceFaultVendorInfoEXT structures describing vendor-specific fault information. -
vendorBinarySizeis the size in bytes of a vendor-specific binary crash dump, which may provide additional information when imported into external tools.
The VkDeviceFaultInfoEXT structure is defined as:
// Provided by VK_EXT_device_fault
typedef struct VkDeviceFaultInfoEXT {
VkStructureType sType;
void* pNext;
char description[VK_MAX_DESCRIPTION_SIZE];
VkDeviceFaultAddressInfoEXT* pAddressInfos;
VkDeviceFaultVendorInfoEXT* pVendorInfos;
void* pVendorBinaryData;
} VkDeviceFaultInfoEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
descriptionis an array ofVK_MAX_DESCRIPTION_SIZEcharcontaining a null-terminated UTF-8 string which is a human readable description of the fault. -
pAddressInfosisNULLor a pointer to an array of VkDeviceFaultAddressInfoEXT structures describing either memory accesses which may have caused a page fault, or describing active instruction pointers at the time of the fault. If notNULL, each element ofpAddressInfosdescribes the a bounded region of GPU virtual address space containing either the GPU virtual address accessed, or the value of an active instruction pointer. -
pVendorInfosisNULLor a pointer to an array of VkDeviceFaultVendorInfoEXT structures describing vendor-specific fault information. -
pVendorBinaryDataisNULLor a pointer tovendorBinarySizenumber of bytes of data, which will be populated with a vendor-specific binary crash dump, as described in Vendor Binary Crash Dumps.
An implementation should populate as many members of VkDeviceFaultInfoEXT as possible, given the information available at the time of the fault and the constraints of the implementation itself.
Due to hardware limitations, pAddressInfos describes ranges of GPU
virtual address space, rather than precise addresses.
The precise memory address accessed or the precise value of the instruction
pointer must lie within the region described.
|
Note
|
Each element of
Comparison of the GPU virtual addresses described by |
The VkDeviceFaultAddressInfoEXT structure is defined as:
// Provided by VK_EXT_device_fault
typedef struct VkDeviceFaultAddressInfoEXT {
VkDeviceFaultAddressTypeEXT addressType;
VkDeviceAddress reportedAddress;
VkDeviceSize addressPrecision;
} VkDeviceFaultAddressInfoEXT;
-
addressTypeis either the type of memory operation that triggered a page fault, or the type of association between an instruction pointer and a fault. -
reportedAddressis the GPU virtual address recorded by the device. -
addressPrecisionis a power of two value that specifies how precisely the device can report the address.
The combination of reportedAddress and addressPrecision allow
the possible range of addresses to be calculated, such that:
lower_address = (pInfo->reportedAddress & ~(pInfo->addressPrecision-1))
upper_address = (pInfo->reportedAddress | (pInfo->addressPrecision-1))
|
Note
|
It is valid for the |
Possible values of VkDeviceFaultAddressInfoEXT::addressType are:
// Provided by VK_EXT_device_fault
typedef enum VkDeviceFaultAddressTypeEXT {
VK_DEVICE_FAULT_ADDRESS_TYPE_NONE_EXT = 0,
VK_DEVICE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT = 1,
VK_DEVICE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT = 2,
VK_DEVICE_FAULT_ADDRESS_TYPE_EXECUTE_INVALID_EXT = 3,
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_UNKNOWN_EXT = 4,
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_INVALID_EXT = 5,
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_FAULT_EXT = 6,
} VkDeviceFaultAddressTypeEXT;
-
VK_DEVICE_FAULT_ADDRESS_TYPE_NONE_EXTspecifies that VkDeviceFaultAddressInfoEXT does not describe a page fault, or an instruction address. -
VK_DEVICE_FAULT_ADDRESS_TYPE_READ_INVALID_EXTspecifies that VkDeviceFaultAddressInfoEXT describes a page fault triggered by an invalid read operation. -
VK_DEVICE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXTspecifies that VkDeviceFaultAddressInfoEXT describes a page fault triggered by an invalid write operation. -
VK_DEVICE_FAULT_ADDRESS_TYPE_EXECUTE_INVALID_EXTdescribes a page fault triggered by an attempt to execute non-executable memory. -
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_UNKNOWN_EXTspecifies an instruction pointer value at the time the fault occurred. This may or may not be related to a fault. -
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_INVALID_EXTspecifies an instruction pointer value associated with an invalid instruction fault. -
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_FAULT_EXTspecifies an instruction pointer value associated with a fault.
|
Note
|
The instruction pointer values recorded may not identify the specific instruction(s) that triggered the fault. The relationship between the instruction pointer reported and triggering instruction will be vendor-specific. |
The VkDeviceFaultVendorInfoEXT structure is defined as:
// Provided by VK_EXT_device_fault
typedef struct VkDeviceFaultVendorInfoEXT {
char description[VK_MAX_DESCRIPTION_SIZE];
uint64_t vendorFaultCode;
uint64_t vendorFaultData;
} VkDeviceFaultVendorInfoEXT;
-
descriptionis an array ofVK_MAX_DESCRIPTION_SIZEcharcontaining a null-terminated UTF-8 string which is a human readable description of the fault. -
vendorFaultCodeis the vendor-specific fault code for this fault. -
vendorFaultDatais the vendor-specific fault data associated with this fault.
Vendor Binary Crash Dumps
Applications can store the vendor-specific binary crash dump data retrieved by calling vkGetDeviceFaultInfoEXT for later analysis using external tools.
However, the format of this data may depend on the vendor ID, device ID,
driver version, and other details of the device.
To enable external applications to identify the original device from which a
crash dump was generated, the initial bytes written to
VkDeviceFaultInfoEXT::pVendorBinaryData must begin with a valid
crash dump header.
Version one of the crash dump header is defined as:
// Provided by VK_EXT_device_fault
typedef struct VkDeviceFaultVendorBinaryHeaderVersionOneEXT {
uint32_t headerSize;
VkDeviceFaultVendorBinaryHeaderVersionEXT headerVersion;
uint32_t vendorID;
uint32_t deviceID;
uint32_t driverVersion;
uint8_t pipelineCacheUUID[VK_UUID_SIZE];
uint32_t applicationNameOffset;
uint32_t applicationVersion;
uint32_t engineNameOffset;
uint32_t engineVersion;
uint32_t apiVersion;
} VkDeviceFaultVendorBinaryHeaderVersionOneEXT;
-
headerSizeis the length in bytes of the crash dump header. -
headerVersionis a VkDeviceFaultVendorBinaryHeaderVersionEXT enum value specifying the version of the header. A consumer of the crash dump should use the header version to interpret the remainder of the header.headerVersionmust be written as exactly 4 bytes. -
vendorIDis theVkPhysicalDeviceProperties::vendorIDof the implementation. -
deviceIDis theVkPhysicalDeviceProperties::deviceIDof the implementation. -
driverVersionis theVkPhysicalDeviceProperties::driverVersionof the implementation. -
pipelineCacheUUIDis an array ofVK_UUID_SIZEuint8_tvalues matching theVkPhysicalDeviceProperties::pipelineCacheUUIDproperty of the implementation. -
applicationNameOffsetis zero, or an offset from the base address of the crash dump header to a null-terminated UTF-8 string containing the name of the application. IfapplicationNameOffsetis non-zero, this string must match the application name specified via VkApplicationInfo::pApplicationNameduring instance creation. -
applicationVersionmust be zero or the value specified by VkApplicationInfo::applicationVersionduring instance creation. -
engineNameOffsetis zero, or an offset from the base address of the crash dump header to a null-terminated UTF-8 string containing the name of the engine (if any) used to create the application. IfengineNameOffsetis non-zero, this string must match the engine name specified via VkApplicationInfo::pEngineNameduring instance creation. -
engineVersionmust be zero or the value specified by VkApplicationInfo::engineVersionduring instance creation. -
apiVersionmust be zero or the value specified by VkApplicationInfo::apiVersionduring instance creation.
Unlike most structures declared by the Vulkan API, all fields of this structure are written with the least significant byte first, regardless of host byte-order.
The C language specification does not define the packing of structure members. This layout assumes tight structure member packing, with members laid out in the order listed in the structure, and the intended size of the structure is 56 bytes. If a compiler produces code that diverges from that pattern, applications must employ another method to set values at the correct offsets.
Possible values of the headerVersion value of the crash dump header
are:
// Provided by VK_EXT_device_fault
typedef enum VkDeviceFaultVendorBinaryHeaderVersionEXT {
VK_DEVICE_FAULT_VENDOR_BINARY_HEADER_VERSION_ONE_EXT = 1,
} VkDeviceFaultVendorBinaryHeaderVersionEXT;
-
VK_DEVICE_FAULT_VENDOR_BINARY_HEADER_VERSION_ONE_EXTspecifies version one of the binary crash dump header.
51.5. Active Tooling Information
Information about tools providing debugging, profiling, or similar services, active for a given physical device, can be obtained by calling:
// Provided by VK_VERSION_1_3
VkResult vkGetPhysicalDeviceToolProperties(
VkPhysicalDevice physicalDevice,
uint32_t* pToolCount,
VkPhysicalDeviceToolProperties* pToolProperties);
or the equivalent command
// Provided by VK_EXT_tooling_info
VkResult vkGetPhysicalDeviceToolPropertiesEXT(
VkPhysicalDevice physicalDevice,
uint32_t* pToolCount,
VkPhysicalDeviceToolProperties* pToolProperties);
-
physicalDeviceis the handle to the physical device to query for active tools. -
pToolCountis a pointer to an integer describing the number of tools active onphysicalDevice. -
pToolPropertiesis eitherNULLor a pointer to an array of VkPhysicalDeviceToolProperties structures.
If pToolProperties is NULL, then the number of tools currently
active on physicalDevice is returned in pToolCount.
Otherwise, pToolCount must point to a variable set by the application
to the number of elements in the pToolProperties array, and on return
the variable is overwritten with the number of structures actually written
to pToolProperties.
If pToolCount is less than the number of currently active tools, at
most pToolCount structures will be written.
The count and properties of active tools may change in response to events outside the scope of the specification. An application should assume these properties might change at any given time.
The VkPhysicalDeviceToolProperties structure is defined as:
// Provided by VK_VERSION_1_3
typedef struct VkPhysicalDeviceToolProperties {
VkStructureType sType;
void* pNext;
char name[VK_MAX_EXTENSION_NAME_SIZE];
char version[VK_MAX_EXTENSION_NAME_SIZE];
VkToolPurposeFlags purposes;
char description[VK_MAX_DESCRIPTION_SIZE];
char layer[VK_MAX_EXTENSION_NAME_SIZE];
} VkPhysicalDeviceToolProperties;
or the equivalent
// Provided by VK_EXT_tooling_info
typedef VkPhysicalDeviceToolProperties VkPhysicalDeviceToolPropertiesEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
nameis a null-terminated UTF-8 string containing the name of the tool. -
versionis a null-terminated UTF-8 string containing the version of the tool. -
purposesis a bitmask of VkToolPurposeFlagBits which is populated with purposes supported by the tool. -
descriptionis a null-terminated UTF-8 string containing a description of the tool. -
layeris a null-terminated UTF-8 string containing the name of the layer implementing the tool, if the tool is implemented in a layer - otherwise it may be an empty string.
Bits which can be set in
VkPhysicalDeviceToolProperties::purposes, specifying the
purposes of an active tool, are:
// Provided by VK_VERSION_1_3
typedef enum VkToolPurposeFlagBits {
VK_TOOL_PURPOSE_VALIDATION_BIT = 0x00000001,
VK_TOOL_PURPOSE_PROFILING_BIT = 0x00000002,
VK_TOOL_PURPOSE_TRACING_BIT = 0x00000004,
VK_TOOL_PURPOSE_ADDITIONAL_FEATURES_BIT = 0x00000008,
VK_TOOL_PURPOSE_MODIFYING_FEATURES_BIT = 0x00000010,
// Provided by VK_EXT_debug_report with VK_EXT_tooling_info, VK_EXT_debug_utils with VK_EXT_tooling_info
VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT = 0x00000020,
// Provided by VK_EXT_debug_marker with VK_EXT_tooling_info, VK_EXT_debug_utils with VK_EXT_tooling_info
VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT = 0x00000040,
// Provided by VK_EXT_tooling_info
VK_TOOL_PURPOSE_VALIDATION_BIT_EXT = VK_TOOL_PURPOSE_VALIDATION_BIT,
// Provided by VK_EXT_tooling_info
VK_TOOL_PURPOSE_PROFILING_BIT_EXT = VK_TOOL_PURPOSE_PROFILING_BIT,
// Provided by VK_EXT_tooling_info
VK_TOOL_PURPOSE_TRACING_BIT_EXT = VK_TOOL_PURPOSE_TRACING_BIT,
// Provided by VK_EXT_tooling_info
VK_TOOL_PURPOSE_ADDITIONAL_FEATURES_BIT_EXT = VK_TOOL_PURPOSE_ADDITIONAL_FEATURES_BIT,
// Provided by VK_EXT_tooling_info
VK_TOOL_PURPOSE_MODIFYING_FEATURES_BIT_EXT = VK_TOOL_PURPOSE_MODIFYING_FEATURES_BIT,
} VkToolPurposeFlagBits;
or the equivalent
// Provided by VK_EXT_tooling_info
typedef VkToolPurposeFlagBits VkToolPurposeFlagBitsEXT;
-
VK_TOOL_PURPOSE_VALIDATION_BITspecifies that the tool provides validation of API usage. -
VK_TOOL_PURPOSE_PROFILING_BITspecifies that the tool provides profiling of API usage. -
VK_TOOL_PURPOSE_TRACING_BITspecifies that the tool is capturing data about the application’s API usage, including anything from simple logging to capturing data for later replay. -
VK_TOOL_PURPOSE_ADDITIONAL_FEATURES_BITspecifies that the tool provides additional API features/extensions on top of the underlying implementation. -
VK_TOOL_PURPOSE_MODIFYING_FEATURES_BITspecifies that the tool modifies the API features/limits/extensions presented to the application. -
VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXTspecifies that the tool reports additional information to the application via callbacks specified by vkCreateDebugReportCallbackEXT or vkCreateDebugUtilsMessengerEXT -
VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXTspecifies that the tool consumes debug markers or object debug annotation, queue labels, or command buffer labels
// Provided by VK_VERSION_1_3
typedef VkFlags VkToolPurposeFlags;
or the equivalent
// Provided by VK_EXT_tooling_info
typedef VkToolPurposeFlags VkToolPurposeFlagsEXT;
VkToolPurposeFlags is a bitmask type for setting a mask of zero or more VkToolPurposeFlagBits.
51.6. Frame Boundary
The VkFrameBoundaryEXT structure is defined as:
// Provided by VK_EXT_frame_boundary
typedef struct VkFrameBoundaryEXT {
VkStructureType sType;
const void* pNext;
VkFrameBoundaryFlagsEXT flags;
uint64_t frameID;
uint32_t imageCount;
const VkImage* pImages;
uint32_t bufferCount;
const VkBuffer* pBuffers;
uint64_t tagName;
size_t tagSize;
const void* pTag;
} VkFrameBoundaryEXT;
-
sTypeis a VkStructureType value identifying this structure. -
pNextisNULLor a pointer to a structure extending this structure. -
flagsis a bitmask of VkFrameBoundaryFlagBitsEXT that can flag the last submission of a frame identifier. -
frameIDis the frame identifier. -
imageCountis the number of images that store frame results. -
pImagesis a pointer to an array of VkImage objects with imageCount entries. -
bufferCountis the number of buffers the store the frame results. -
pBuffersis a pointer to an array of VkBuffer objects with bufferCount entries. -
tagNameis a numerical identifier for tag data. -
tagSizeis the number of bytes of tag data. -
pTagis a pointer to an array oftagSizebytes containing tag data.
The application can associate frame boundary information to a queue
submission call by adding a VkFrameBoundaryEXT structure to the
pNext chain of queue submission,
VkPresentInfoKHR,
or VkBindSparseInfo.
|
Note
|
The frame identifier is used to associate one or more queue submissions to a frame. It is meant to be unique within a frame lifetime, i.e. it is possible (though not recommended) to reuse frame identifiers, as long as any two frames that may have overlapping queue submissions (as in the example above) use different frame identifiers. Since the concept of frame is application-dependent, there is no way to validate the use of frame identifier. It is good practice to use a monotonically increasing counter as the frame identifier and not reuse identifiers between frames. |
The pImages and pBuffers arrays contain a list of images and
buffers which store the "end result" of the frame.
As the concept of frame is application-dependent, not all frames may
produce their results in images or buffers, yet this is a sufficiently
common case to be handled by VkFrameBoundaryEXT.
Note that no extra information, such as image layout is being provided,
since the images are meant to be used by tools which would already be
tracking this required information.
Having the possibility of passing a list of end-result images makes
VkFrameBoundaryEXT as expressive as vkQueuePresentKHR, which is
often the default frame boundary delimiter.
The application can also associate arbitrary extra information via tag data
using tagName, tagSize and pTag.
This extra information is typically tool-specific.
The bit which can be set in VkFrameBoundaryEXT::flags is:
// Provided by VK_EXT_frame_boundary
typedef enum VkFrameBoundaryFlagBitsEXT {
VK_FRAME_BOUNDARY_FRAME_END_BIT_EXT = 0x00000001,
} VkFrameBoundaryFlagBitsEXT;
-
VK_FRAME_BOUNDARY_FRAME_END_BIT_EXTspecifies that this queue submission is the last one for this frame, i.e. once this queue submission has terminated, then the work for this frame is completed.
Note that in the presence of timeline semaphores, the last queue submission might not be the last one to be submitted, as timeline semaphores allow for wait-before-signal submissions. In the context of frame boundary, the queue submission that should be done flagged as the last one is the one that is meant to be executed last, even if it may not be the last one to be submitted.
// Provided by VK_EXT_frame_boundary
typedef VkFlags VkFrameBoundaryFlagsEXT;
VkFrameBoundaryFlagsEXT is a bitmask type for setting a mask of zero or more VkFrameBoundaryFlagBitsEXT.