Closed kaini closed 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.
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!
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.
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!
It seems to be impossible to use
vkDebugMarkerSetObjectNameEXT
. The info-struct expects the handle to the object casted to anuint64_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