VK_EXT_debug_marker should take structs via const pointers

[dennis-hamester]

The following functions from VK_EXT_debug_marker take their structs via non-const pointers:

• vkDebugMarkerSetObjectTagEXT
• vkDebugMarkerSetObjectNameEXT
• vkCmdDebugMarkerBeginEXT
• vkCmdDebugMarkerInsertEXT

These should probably all be const pointers, since a Vulkan implementation is not supposed to write to any of them.

[oddhack]

Apparently I can't assign this to @baldurk since he's not in KhronosGroup. Anyway, we will look at this inside Khronos.

[MarkY-LunarG]

One thing I just discovered is the desktop Vulkan loader does translate VkPhysicalDevice and VkSurface handles in place inside vkDebugMarkerSetObjectTagEXT and vkDebugMarkerSetObjectNameEXT because the loader has to maintain its own information about each of those. I'm working on pushing up a change which will work with the new "const" pointers in case this happens, but I'm unsure of what would happen with older loaders. Either way, a newer loader will work as long as it's built after LVL MR !1900 has been integrated.

[dennis-hamester]

I think it's totally fine to cast the const away for an implementation detail like this in the loader.

An older loader binary should still work, if the pointers are changed to const. Const/non-const shouldn't have any impact on code generation in C/C++, because of potential pointer aliasing.

Anyway, can I take this as a confirmation, that const is the correct choice here and it will be changed in a future spec revision?

[MarkY-LunarG]

As @oddhack mentioned, we'll discuss it internally in Khronos. I just wanted to make a change which could have caused issues.

[MarkY-LunarG]

After some discussion internally, Khronos is planning on making this change. There is a very low probability people will hit an issue with this change with an older loader. If they do, they can easily update the desktop loader to a newer version.

[oddhack]

This should be fixed in the 1.0.55 spec update.