Vulkan-Docs/appendices/VK_EXT_debug_utils.txt

378 lines
16 KiB
Plaintext
Raw Normal View History

Change log for March 7, 2018 Vulkan 1.1.70 spec update: * Vulkan 1.1 initial release. Bump API patch number and header version number to 70 for this update. The patch number will be used for both Vulkan 1.1 and Vulkan 1.0 updates, and continues to increment continuously from the previous Vulkan 1.0.69 update. NOTE: We are not publishing an updated 1.0.70 specification, or 1.1 reference pages, along with 1.1.70. There are still minor issues to work out with those build targets. However, we will soon generate all three types of documents as part of the regular spec update cycle. NOTE: The GitHub KhronosGroup/Vulkan-Docs repository now maintains the current specification in the `master` branch. The `1.0` branch is out of date and will not be maintained, since we will be generating both 1.1 and 1.0 specifications from the `master` branch in the future. Github Issues: * Clarify how mapped memory ranges are flushed in flink:vkFlushMappedMemoryRanges (public issue 127). * Specify that <<synchronization-pipeline-stages, Pipeline Stages>> are a list of tasks that each command performs, rather than necessarily being discrete pieces of hardware that one task flows through. Add a "`synchronization command`" pipeline type which all synchronization command execute (it's just TOP + BOTTOM), with an explanatory note (public issue 554). Internal Issues: * Regenerate all images used in the spec in Inkscape with a consistent look-and-feel, and adjust image size attributes so they're all legible, and not too large with respect to the spec body text (internal issue 701). * Document in the <<extensions,extensions>> appendix and in the style guide that `KHX` extensions are no longer supported or used in the Vulkan 1.1 timeframe (internal issue 714). * Remove the leftover equations_temp directory after PDF build completes (internal issue 925). * Update the <<credits, Credits (Informative)>> appendix to include contributors to Vulkan 1.1, and to list them according to the API version(s) they contributed to (internal issue 987). * Add a NOTE to the introduction explaining that interfaces defined by extensions which were promoted to Vulkan 1.1 are now expressed as aliases of the Vulkan 1.1 type (internal issue 991). * Instrument spec source conditionals so spec can be built with 1.1 features, extensions promoted to 1.1, or both (internal issues 992, 998). * Modify the XML schema and tools to support explicit aliasing of types, structures, and commands, and use this to express the promotion of 1.0 extensions to 1.1 core features, by making the extension interfaces aliases of the core features they were promoted to. Mark up promoted interfaces to allow still generating 1.0 + extension specifications (internal issue 991). * Platform names, along with corresponding preprocessor symbols to enable extensions specific to those platforms, are now reserved in vk.xml using the <platform> tag. Update the registry schema and schema specification to match (internal issue 1011). * Updated the <<textures-texel-replacement, Texel Replacement>> section to clarify that reads from invalid texels for image resources result in undefined values (internal issue 1014). * Modify description of patch version so it continues to increment across minor version changes (internal issue 1033). * Clarify and unify language describing physical device-level core and extension functionality in the <<fundamentals-validusage-extensions, Valid Usage for Extensions>>, <<fundamentals-validusage-versions, Valid Usage for Newer Core Versions>>, <<initialization-functionpointers Command Function Pointers>>, <<initialization-phys-dev-extensions, Extending Physical Device From Device Extensions>> <<extended-functionality-instance-extensions-and-devices, Instance Extensions and Device Extensions>> sections and for flink:vkGetPhysicalDeviceImageFormatProperties2. This documents that instance-level functionality is tied to the loader, and independent of the ICD; physical device-level functionality is tied to the ICD, and associated with device extensions; physical devices are treated more uniformly between core and extensions; and instance and physical versions can be different (internal issue 1048). * Updated the <<commandbuffers-lifecycle, Command Buffer Lifecycle>> section to clarify the ability for pending command buffers to transition to the invalid state after submission, and add a command buffer lifecycle diagram (internal issue 1050). * Clarify that some flink:VkDescriptorUpdateTemplateCreateInfo parameters are ignored when push descriptors are not supported (internal issue 1054). * Specify that flink:vkCreateImage will return an error if the image is too large, in a NOTE in the slink:VkImageFormatProperties description (internal issue 1078). * Remove near-duplicate NOTEs about when to query function pointers dynamically in the <<initialization, Initialization>> chapter and replace by extending the NOTE in the <<fundamentals-abi, Application Binary Interface>> section (internal issue 1085). * Restore missing references to "`Sparse Resource Features`" in the flink:VkBufferCreateFlagBits description (internal issue 1086). * Tidy up definitions of descriptor types in the `GL_KHR_vulkan_glsl` specification, the <<descriptorsets, Resource Descriptors>> section and its subsections, and the <<interfaces-resources-descset, Descriptor Set Interface>> for consistency, reduction of duplicate information, and removal of GLSL correspondance/examples (internal issue 1090). * Correctly describe code:PrimitiveId as an Input for tessellation control and evaluation shaders, not an Output (internal issue 1109). * Relax the requirements on chroma offsets for nearest filtering in <<textures-implict-reconstruction, Implicit Reconstruction>> (internal issue 1116). Other Issues: * Clarify the intended relationship between specification language and certain terms defined in the Khronos Intellectual Property Rights policy. Specific changes include: ** Rewrote IP/Copyright preamble and introduction to better agree with normative language both as laid out in the introduction, and the Khronos IPR policy. ** Added notion of fully informative sections, which are now tagged with "`(Informative)`" in their titles. ** Removed non-normative uses of the phrase "`not required`" ** Clarified the distinction between terms "`optional`" and "`not required:`" as they relate to the IPR Policy, and updated specification text to use terms consistent with the intent. ** Reduced additions to RFC 2119, and ensured the specification agreed with the leaner language. ** Removed the terms "`hardware`", "`software`", "`CPU`", and "`GPU`" from normative text. ** Moved several paragraphs that should not have been normative to informative notes. ** Clarified a number of definitions in the Glossary. ** Updated the document writing guide to match new terminology changes. * Explicitly state in the <<fundamentals-objectmodel-lifetime-acquire, application memory lifetime>> language that that for objects other than descriptor sets, a slink:VkDescriptorSetLayout object used in the creation of another object (such as slink:VkPipelineLayout or slink:VkDescriptorUpdateTemplateKHR) is only in use during the creation of that object and can be safely destroyed afterwards. * Updated the <<textures-scale-factor, Scale Factor Operation>> section to use the ratio of anisotropy, rather than the integer sample rate, to perform the LOD calculation. The spec still allows use of the sample rate as the value used to calculate the LOD, but no longer requires it. * Update `vulkan_ext.c` to include all platform-related definitions from the Vulkan platform headers, following the split of the headers into platform-specific and non-platform-specific files. * Fix bogus anchor name in the <<commandbuffers, Command Buffers>> chapter which accidentally duplicated an anchor in the pipelines chapter. There were no reference to this anchor, fortunately. * Add valid usage statement for slink:VkWriteDescriptorSet and slink:VkCopyDescriptorSet requiring that the slink:VkDescriptorSetLayout used to allocate the source and destination sets must not have been destroyed at the time flink:vkUpdateDescriptorSets is called. * Document mapping of subgroup barrier functions to SPIR-V, and clarify a place where subgroupBarrier sounds like it's execution-only in the standalone `GL_KHR_shader_subgroup` specification. * Use an HTML stylesheet derived from the Asciidoctor `colony` theme, with the default Arial font family replaced by the sans-serif Noto font family. * Numerous minor updates to README.adoc, build scripts, Makefiles, and registry and style guide specifications to support Vulkan 1.1 outputs, use them as defaults, and remove mention of `KHX` extensions, which are no longer supported. New Extensions: * `VK_EXT_vertex_attrib_divisor`
2018-03-07 12:18:52 +00:00
include::meta/VK_EXT_debug_utils.txt[]
*Last Modified Date*::
2017-09-14
*Revision*::
1
*IP Status*::
No known IP claims.
*Dependencies*::
- This extension is written against version 1.0 of the Vulkan API.
- Requires elink:VkObjectType
*Contributors*::
- Mark Young, LunarG
- Baldur Karlsson
- Ian Elliott, Google
- Courtney Goeltzenleuchter, Google
- Karl Schultz, LunarG
- Mark Lobodzinski, LunarG
- Mike Schuchardt, LunarG
- Jaakko Konttinen, AMD
- Dan Ginsburg, Valve Software
- Rolando Olivares, Epic Games
- Dan Baker, Oxide Games
- Kyle Spagnoli, NVIDIA
- Jon Ashburn, LunarG
Due to the nature of the Vulkan interface, there is very little error
information available to the developer and application.
By using the `VK_EXT_debug_utils` extension, developers can: obtain more
information.
When combined with validation layers, even more detailed feedback on the
application's use of Vulkan will be provided.
This extension provides the following capabilities:
- The ability to create a debug messenger which will pass along debug
messages to an application supplied callback.
- The ability to identify specific Vulkan objects using a name or tag to
improve tracking.
- The ability to identify specific sections within a sname:VkQueue or
sname:VkCommandBuffer using labels to aid organization and offline
analysis in external tools.
The main difference between this extension and `<<VK_EXT_debug_report>>` and
`<<VK_EXT_debug_marker>>` is that those extensions use
elink:VkDebugReportObjectTypeEXT to identify objects.
This extension uses the core elink:VkObjectType in place of
ename:VkDebugReportObjectTypeEXT.
The primary reason for this move is that no future object type handle
enumeration values will be added to ename:VkDebugReportObjectTypeEXT since
the creation of ename:VkObjectType.
In addition, this extension combines the functionality of both
`<<VK_EXT_debug_report>>` and `<<VK_EXT_debug_marker>>` by allowing object
name and debug markers (now called labels) to be returned to the
application's callback function.
This should assist in clarifying the details of a debug message including:
what objects are involved and potentially which location within a VkQueue or
VkCommandBuffer the message occurred.
=== New Object Types
* slink:VkDebugUtilsMessengerEXT
=== New Enum Constants
* Extending elink:VkStructureType:
** ename:VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT
** ename:VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_TAG_INFO_EXT
** ename:VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT
** ename:VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CALLBACK_DATA_EXT
** ename:VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT
* Extending elink:VkResult:
** ename:VK_ERROR_VALIDATION_FAILED_EXT
=== New Enums
* elink:VkDebugUtilsMessageSeverityFlagBitsEXT
* elink:VkDebugUtilsMessageTypeFlagBitsEXT
=== New Structures
* slink:VkDebugUtilsObjectNameInfoEXT
* slink:VkDebugUtilsObjectTagInfoEXT
* slink:VkDebugUtilsLabelEXT
* slink:VkDebugUtilsMessengerCallbackDataEXT
* slink:VkDebugUtilsMessengerCreateInfoEXT
=== New Functions
* flink:vkSetDebugUtilsObjectNameEXT
* flink:vkSetDebugUtilsObjectTagEXT
* flink:vkQueueBeginDebugUtilsLabelEXT
* flink:vkQueueEndDebugUtilsLabelEXT
* flink:vkQueueInsertDebugUtilsLabelEXT
* flink:vkCmdBeginDebugUtilsLabelEXT
* flink:vkCmdEndDebugUtilsLabelEXT
* flink:vkCmdInsertDebugUtilsLabelEXT
* flink:vkCreateDebugUtilsMessengerEXT
* flink:vkDestroyDebugUtilsMessengerEXT
* flink:vkSubmitDebugUtilsMessageEXT
=== New Function Pointers
* tlink:PFN_vkDebugUtilsMessengerCallbackEXT
=== Examples
**Example 1**
`VK_EXT_debug_utils` 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.
An application can: register callbacks even when no validation layers are
enabled, but they will only be called for loader and, if implemented, driver
events.
To capture events that occur while creating or destroying an instance an
application can: link a slink:VkDebugUtilsMessengerCreateInfoEXT structure
to the pname:pNext element of the slink:VkInstanceCreateInfo structure given
to flink:vkCreateInstance.
This callback is only valid for the duration of the flink:vkCreateInstance
and the flink:vkDestroyInstance call.
Use flink:vkCreateDebugUtilsMessengerEXT to create persistent callback
objects.
Example uses: Create three callback objects.
One will log errors and warnings to the debug console using Windows
code:OutputDebugString.
The second will cause the debugger to break at that callback when an error
happens and the third will log warnings to stdout.
[source,c++]
------------------------------------------------------------------------------
extern VkInstance instance;
VkResult res;
VkDebugUtilsMessengerEXT cb1, cb2, cb3;
// Must call extension functions through a function pointer:
PFN_vkCreateDebugUtilsMessengerEXT pfnCreateDebugUtilsMessengerEXT = (PFN_vkCreateDebugUtilsMessengerEXT)vkGetDeviceProcAddr(device, "vkCreateDebugUtilsMessengerEXT");
PFN_vkDestroyDebugUtilsMessengerEXT pfnDestroyDebugUtilsMessengerEXT = (PFN_vkDestroyDebugUtilsMessengerEXT)vkGetDeviceProcAddr(device, "vkDestroyDebugUtilsMessengerEXT");
VkDebugUtilsMessengeCreateInfoEXT callback1 = {
VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT, // sType
NULL, // pNext
0, // flags
VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT | // messageSeverity
VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,
VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT | // messageType
VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
myOutputDebugString, // pfnUserCallback
NULL // pUserData
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, &cb1);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
callback1.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT;
callback1.pfnCallback = myDebugBreak;
callback1.pUserData = NULL;
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, &cb2);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
VkDebugUtilsMessengerCreateInfoEXT callback3 = {
VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT, // sType
NULL, // pNext
0, // flags
VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT, // messageSeverity
VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT | // messageType
VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
mystdOutLogger, // pfnUserCallback
NULL // pUserData
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, &cb3);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY
}
...
// Remove callbacks when cleaning up
pfnDestroyDebugUtilsMessengerEXT(instance, cb1);
pfnDestroyDebugUtilsMessengerEXT(instance, cb2);
pfnDestroyDebugUtilsMessengerEXT(instance, cb3);
------------------------------------------------------------------------------
**Example 2**
Associate a name with an image, for easier debugging in external tools or
with validation layers that can print a friendly name when referring to
objects in error messages.
[source,c++]
----------------------------------------
extern VkDevice device;
extern VkImage image;
// Must call extension functions through a function pointer:
PFN_vkSetDebugUtilsObjectNameEXT pfnSetDebugUtilsObjectNameEXT = (PFN_vkSetDebugUtilsObjectNameEXT)vkGetDeviceProcAddr(device, "vkSetDebugUtilsObjectNameEXT");
// Set a name on the image
const VkDebugUtilsObjectNameInfoEXT imageNameInfo =
{
VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT, // sType
NULL, // pNext
VK_OBJECT_TYPE_IMAGE, // objectType
(uint64_t)image, // object
"Brick Diffuse Texture", // pObjectName
};
pfnSetDebugUtilsObjectNameEXT(device, &imageNameInfo);
// A subsequent error might print:
// Image 'Brick Diffuse Texture' (0xc0dec0dedeadbeef) is used in a
// command buffer with no memory bound to it.
----------------------------------------
**Example 3**
Annotating regions of a workload with naming information so that offline
analysis tools can display a more usable visualization of the commands
submitted.
[source,c++]
----------------------------------------
extern VkDevice device;
extern VkCommandBuffer commandBuffer;
// Must call extension functions through a function pointer:
PFN_vkQueueBeginDebugUtilsLabelEXT pfnQueueBeginDebugUtilsLabelEXT = (PFN_vkQueueBeginDebugUtilsLabelEXT)vkGetDeviceProcAddr(device, "vkQueueBeginDebugUtilsLabelEXT");
PFN_vkQueueEndDebugUtilsLabelEXT pfnQueueEndDebugUtilsLabelEXT = (PFN_vkQueueEndDebugUtilsLabelEXT)vkGetDeviceProcAddr(device, "vkQueueEndDebugUtilsLabelEXT");
PFN_vkCmdBeginDebugUtilsLabelEXT pfnCmdBeginDebugUtilsLabelEXT = (PFN_vkCmdBeginDebugUtilsLabelEXT)vkGetDeviceProcAddr(device, "vkCmdBeginDebugUtilsLabelEXT");
PFN_vkCmdEndDebugUtilsLabelEXT pfnCmdEndDebugUtilsLabelEXT = (PFN_vkCmdEndDebugUtilsLabelEXT)vkGetDeviceProcAddr(device, "vkCmdEndDebugUtilsLabelEXT");
PFN_vkCmdInsertDebugUtilsLabelEXT pfnCmdInsertDebugUtilsLabelEXT = (PFN_vkCmdInsertDebugUtilsLabelEXT)vkGetDeviceProcAddr(device, "vkCmdInsertDebugUtilsLabelEXT");
// Describe the area being rendered
const VkDebugUtilsLabelEXT houseLabel =
{
VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT, // sType
NULL, // pNext
"Brick House", // pLabelName
{ 1.0f, 0.0f, 0.0f, 1.0f }, // color
};
// Start an annotated group of calls under the 'Brick House' name
pfnCmdBeginDebugUtilsLabelEXT(commandBuffer, &houseLabel);
{
// A mutable structure for each part being rendered
VkDebugUtilsLabelEXT housePartLabel =
{
VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT, // sType
NULL, // pNext
NULL, // pLabelName
{ 0.0f, 0.0f, 0.0f, 0.0f }, // color
};
// Set the name and insert the marker
housePartLabel.pLabelName = "Walls";
pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);
// Insert the drawcall for the walls
vkCmdDrawIndexed(commandBuffer, 1000, 1, 0, 0, 0);
// Insert a recursive region for two sets of windows
housePartLabel.pLabelName = "Windows";
pfnCmdBeginDebugUtilsLabelEXT(commandBuffer, &housePartLabel);
{
vkCmdDrawIndexed(commandBuffer, 75, 6, 1000, 0, 0);
vkCmdDrawIndexed(commandBuffer, 100, 2, 1450, 0, 0);
}
pfnCmdEndDebugUtilsLabelEXT(commandBuffer);
housePartLabel.pLabelName = "Front Door";
pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);
vkCmdDrawIndexed(commandBuffer, 350, 1, 1650, 0, 0);
housePartLabel.pLabelName = "Roof";
pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);
vkCmdDrawIndexed(commandBuffer, 500, 1, 2000, 0, 0);
}
// End the house annotation started above
pfnCmdEndDebugUtilsLabelEXT(commandBuffer);
// Do other work
vkEndCommandBuffer(commandBuffer);
// Describe the queue being used
const VkDebugUtilsLabelEXT queueLabel =
{
VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT, // sType
NULL, // pNext
"Main Render Work", // pLabelName
{ 0.0f, 1.0f, 0.0f, 1.0f }, // color
};
// Identify the queue label region
pfnQueueBeginDebugUtilsLabelEXT(queue, &queueLabel);
// Submit the work for the main render thread
const VkCommandBuffer cmd_bufs[] = {commandBuffer};
VkSubmitInfo submit_info = {.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO,
.pNext = NULL,
.waitSemaphoreCount = 0,
.pWaitSemaphores = NULL,
.pWaitDstStageMask = NULL,
.commandBufferCount = 1,
.pCommandBuffers = cmd_bufs,
.signalSemaphoreCount = 0,
.pSignalSemaphores = NULL};
vkQueueSubmit(queue, 1, &submit_info, fence);
// End the queue label region
pfnQueueEndDebugUtilsLabelEXT(queue);
----------------------------------------
=== Issues
1) Should we just name this extension `VK_EXT_debug_report2`
**RESOLVED**: No.
There is enough additional changes to the structures to break backwards
compatibility.
So, a new name was decided that would not indicate any interaction with the
previous extension.
2) Will validation layers immediately support all the new features.
**RESOLVED**: Not immediately.
As one can imagine, there is a lot of work involved with converting the
validation layer logging over to the new functionality.
Basic logging, as seen in the origin
<<VK_EXT_debug_report,VK_EXT_debug_report>> extension will be made available
immediately.
However, adding the labels and object names will take time.
Since the priority for Khronos at this time is to continue focusing on Valid
Usage statements, it may take a while before the new functionality is fully
exposed.
3) If the validation layers won't expose the new functionality immediately,
then what's the point of this extension?
**RESOLVED**: We needed a replacement for
<<VK_EXT_debug_report,VK_EXT_debug_report>> because the
elink:VkDebugReportObjectTypeEXT enumeration will no longer be updated and
any new objects will need to be debugged using the new functionality
provided by this extension.
4) Should this extension be split into two separate parts (1 extension that
is an instance extension providing the callback functionality, and another
device extension providing the general debug marker and annotation
functionality)?
**RESOLVED**: No, the functionality for this extension is too closely
related.
If we did split up the extension, where would the structures and enums live,
and how would you define that the device behavior in the instance extension
is really only valid if the device extension is enabled, and the
functionality is passed in.
It's cleaner to just define this all as an instance extension, plus it
allows the application to enable all debug functionality provided with one
enable string during flink:vkCreateInstance.
=== Version History
* Revision 1, 2017-09-14 (Mark Young and all listed Contributors)
** Initial draft, based on <<VK_EXT_debug_report,VK_EXT_debug_report>> and
<<VK_EXT_debug_marker,VK_EXT_debug_marker>> in addition to previous
feedback supplied from various companies including Valve, Epic, and
Oxide games.