Add a way to name objects for validation messages

[Jasper-Bekkers]

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 like Cannot 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?

[TonyBarbour]

Addressed by 1f53907

[Jasper-Bekkers]

Does this also fix up all validation warnings to print the named object instead of the id?

…

On Thu, Jun 29, 2017, 21:04 Tony-LunarG ***@***.***> wrote: Addressed by 1f53907 <1f53907> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1880 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBuuxn8WNlqiw1d-wT9SfaWBVtrtelks5sI_VDgaJpZM4N8W6c> .

[TonyBarbour]

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.

[Jasper-Bekkers]

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.

[mark-lunarg]

@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!

[Jasper-Bekkers]

@mark-lunarg what's the status of that new extension?

[mark-lunarg]

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.

[Jasper-Bekkers]

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.

[gwihlidal]

+1 - this would be great to have!

[chaoticbob]

+1 comes up pretty frequently in discussions