Add a way to name objects for validation messages #34
Comments
|
Addressed by 1f53907 |
|
Does this also fix up all validation warnings to print the named object On Thu, Jun 29, 2017, 21:04 Tony-LunarG [email protected] wrote:
|
|
It does to an extent. Anything logged through debug_report_log_message will prepend a string "SrcObject name = ". Other objects referenced in the message will still only have their handles printed. |
|
Cool, that's already a pretty nice improvement over what was done before. Though it was something that you could easily do app side as well by just keeping the name somewhere and matching it against the object passed back to you in the debug callback. However the other objects referenced in the message are also very important (case in point: the message that started this big report), so I would like to include the other referenced objects within the scope of this issue as well. |
|
@Jasper-Bekkers, this family of capabilities is meant to be addressed through a new debug report extension which is currently under development. It will allow the output of multiple objects through the main interface (among many other things). This change is what we can reasonably do in the short-term. Thanks for prodding us to get this in! |
|
@mark-lunarg what's the status of that new extension? |
|
Still winding it's way through Khronos towards ratification. Hey @Jasper-Bekkers, if you compile a summary of the messages you'd like to see reworked, we can probably get that done sooner rather than later. Even after the new extension becomes available work will still need to be done to expand the message output and have neither the bandwidth nor inclination to reformat every validation layer error message. Point out the ones which'll help you and we'll work to get this issue closed. |
|
I just did a quick few greps through the code base and it looks like PRIxLEAST64 might be the best indication of what to replace (there are some false positives when printing sizes / alignments instead of object IDs). This yields about ~160 results, which TBH it a lot less then I expected. I'm fine with this issue staying open until all (or most) of these are fixed. If at some point there is an easy replacement for HandleToUint64 that returns a string (either debug name or object ID) we can probably work together and do the menial task of fixing up the messages. |
|
+1 - this would be great to have! |
|
+1 comes up pretty frequently in discussions |
|
Since this seems to still be an issue every day for pretty much anybody using the validation layer, could we get a status update on this? It's been a few months and all that happened is that seemingly this issue got down-promoted even though there is quite a bit of demand for this. |
|
@Jasper-Bekkers, the extension has been approved and will probably wind up in the release after 1.0.66. However, using the new extension will require modifying the current log messages. If you can point to some favorites we can move these to the top of the list, as I don't think we'll implement blanket coverage, at least to begin with. |
|
It's been a while and it looks like VK_EXT_debug_utils (which I'm assuming is the right extension) has been out for a while too. What's the status of the error messages that need conversion? |
|
@Jasper-Bekkers, we're going to need help with identifying the error messages that need conversion. It is impractical (at least at this time) to convert all of the log_msg calls -- but we will certainly work to cover the ones where it'd provide the most benefit. |
|
Have any been covered at all? Like I mentioned before, one could easily go over the ~160 or so instances of PRIxLEAST64 and patch them by hand. This is - other then vague / unclear messages - probably the number one productivity killer in the Vulkan ecosystem so it's sad to see such a response. |
|
@Jasper-Bekkers, I apologize -- my response was relating to outputting multiple objects to the debug callback. We have already begun an effort to revamp log_msg() which would automatically provide the labeling functionality along with many other improvements, see PR #2475. It is coming! |
|
Triage notes: Looking for HandleToUint64, PRIxLEAST64 and PRIx64 replacing these with something like |
|
I'd really like to see this done mainly for image layout errors as per the original report - display the debug name of the image rather than just a handle. It's difficult to trace back to which image is affected for the errors that are reported at submit time rather than during the command that's at fault, having the debug name there would make the error a lot more useful. |
|
@aejsmith Are you using |
|
Additional triage/design notes: The validation layer developers had intended for the Since this interface supports passing only one object for this list, you'll only ever see one object displayed. I think the intent was to go ahead and have the main message remain as-is, where only the handles are embedded in the message. But then there would be the "decoder" list of objects after the main message where the reader would go to find the additional object info. However, the current interface supports only one object. So one approach (JohnZ's) would be to replace something like: log_msg(report_data, VK_DEBUG_REPORT_ERROR_BIT_EXT, VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT, HandleToUint64(image),
"VUID-VkRenderPassBeginInfo-framebuffer-parameter",
"Render Pass begin with renderpass 0x%" PRIx64 " uses framebuffer 0x%" PRIx64 " where pAttachments[%" PRIu32
"] = image view 0x%" PRIx64 ", which refers to an invalid image",
HandleToUint64(renderpass), HandleToUint64(framebuffer), attachment_index, HandleToUint64(image_view));with log_msg(report_data, VK_DEBUG_REPORT_ERROR_BIT_EXT, VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT, HandleToUint64(image),
"VUID-VkRenderPassBeginInfo-framebuffer-parameter",
"Render Pass begin with renderpass %s uses framebuffer %s where pAttachments[%" PRIu32
"] = image view %s, which refers to an invalid image",
HandleToMessageString(renderpass).c_str(), HandleToMessageString(framebuffer).c_str(), attachment_index, HandleToMessageString(image_view).c_str());where The other approach would be to replace the 4th argument ( Both approaches involve a lot of manual editing of a large number of |
|
@karl-lunarg No, I'm currently still using the older |
|
This has been subsumed by tracking issue #679. |
Issue by Jasper-Bekkers (MIGRATED)
Friday Jun 16, 2017 at 11:42 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1880
Hi,
Right now often you'll get validation errors like this
Cannot submit cmd buffer using image (0x9a) [sub-resource: aspectMask 0x1 array layer 0, mip level 0], with layout .... In our engine we have a policy of naming all objects we create for debugging purposes so it would be extremely useful to pass these along to the validation layers for easier debugging so we can get a message likeCannot submit cmd buffer using image (LinearRenderTarget1) [sub-resource: aspectMask 0x1 array layer 0, mip level 0], with layout ...instead.Can we make validation layers respect VK_EXT_debug_marker or have the validation layers expose some other kind of extension to provide names to it?
The text was updated successfully, but these errors were encountered: