FacticiusVir / SharpVk

C# Bindings for the Vulkan API & SPIR-V
MIT License
147 stars 18 forks source link

Device.DebugMarkerSetObjectName unusable because it needs a raw handle (ulong) #24

Closed kaini closed 7 years ago

kaini commented 7 years ago

It seems to be impossible to use vkDebugMarkerSetObjectNameEXT. The info-struct expects the handle to the object casted to an uint64_t. This does not seem to be possible with SharpVk, because the library never exposes the raw handles. See at the bottom of this bug report for the XML definition.

I suggest to expose the raw handles to all Vulkan resources via a property, for example RawHandle. This is not a very elegant solution for this problem, but I think the raw handles should be exposed anyway, in case someone has to interact with native code or manually loaded extensions.

If you want to I can take a look at this and provide a pull request.


https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/vk.xml#L1686

<type category="struct" name="VkDebugMarkerObjectNameInfoEXT">
<member values="VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT"><type>VkStructureType</type> <name>sType</name></member>
<member>const <type>void</type>*                      <name>pNext</name></member>                    <!-- Pointer to next structure -->
<member><type>VkDebugReportObjectTypeEXT</type>       <name>objectType</name></member>               <!-- The type of the object -->
<member><type>uint64_t</type>                         <name>object</name></member>                   <!-- The handle of the object, cast to uint64_t -->
<member len="null-terminated">const <type>char</type>* <name>pObjectName</name></member>             <!-- Name to apply to the object -->
</type>
FacticiusVir commented 7 years ago

To provide compatibility with the types & delegates in the Interop namespace, the RawHandle field will likely have to expose the corresponding interop type for each handle type (e.g. SharpVk.Interop.Instance for SharpVk.Instance). Those interop handles will then have something like a ToInt64() method to map the internal representation (IntPtr for dispatch handles, ulong for non-dispatch). I'll see about making that tweak tonight.

FacticiusVir commented 7 years ago

Okay, I've added the property (though with a ToUInt64 method, as we're talking about ulongs facepalm); it's in the repo and there's a pre-release package on Nuget I can't test the code right now as the VK_EXT_debug_marker extension isn't supported on my nVidia device, so I'll have to dig out some different hardware to test - let me know if the update works for you!

kaini commented 7 years ago

I did a quick test and it works for me. Thank you very much for this feature!

I can't test the code right now as the VK_EXT_debug_marker extension isn't supported on my nVidia device, so I'll have to dig out some different hardware to test - let me know if the update works for you!

This extension is most likely not provided by the hardware itself, but only by additional layers. If you use VK_LAYER_RENDERDOC_Capture the VK_EXT_debug_marker should be available. Also note that this extension seems to be incompatible with VK_LAYER_GOOGLE_unique_objects and might segfault if you enable both.

FacticiusVir commented 7 years ago

Ah, makes sense, I haven't done much work with RenderDoc so far. Now I've got that set up it seems to be working fine for me as well. Glad you're finding it useful!