Add ImGui Vulkan extensions

[LouChiSoft]

I saw that in ticket #978 it was mentioned that there was a WIP for Vulkan extensions but it was not ready so not shipped. Is there a timeframe/roadmap for when they might be ready? I really love the concept of the Silk.NET but as it stands the only APIs I am currently interested is Vulkan and DX12 and ImGui is pretty much king of simple and easy to use GUIs.

[Beyley]

it will be released when someone finishes it

[BlakkM9]

Take a look at this.
Helped me a lot to get ImGui working in my project

[Beyley]

do not use projects in the lab as a starting point, they are only experiements and do not reflect the code quality we require in the main codebase

[BlakkM9]

do not use projects in the lab as a starting point, they are only experiements and do not reflect the code quality we require in the main codebase

sure, but i think in this case it's fine because that's pretty much just a translation of the original imgui vulkan backend, writing an imgui backend for vulkan is usually a custom task anyways (for me there is almost non of the original code left) and if he's using vulkan he probably knows what he is doing :)

but you should of course not just copy that code and put it in your project like this

[domportera]

this would be huge. I'm a contributor on the Tooll3 project which currently uses SharpDX + DearImGUI.Net and we would love to make the switch to Silk.Vulkan in a properly supported way, as we're hoping to be cross platform and enable embedding in other engines like Godot

[Beyley]

this would be huge. I'm a contributor on the Tooll3 project which currently uses SharpDX + DearImGUI.Net and we would love to make the switch to Silk.Vulkan in a properly supported way, as we're hoping to be cross platform and enable embedding in other engines like Godot

We would love to accept a PR containing a finished one, it's an interest of the team, but not something we are actively working on at the moment

[domportera]

this would be huge. I'm a contributor on the Tooll3 project which currently uses SharpDX + DearImGUI.Net and we would love to make the switch to Silk.Vulkan in a properly supported way, as we're hoping to be cross platform and enable embedding in other engines like Godot

We would love to accept a PR containing a finished one, it's an interest of the team, but not something we are actively working on at the moment

I know there is an experimental package - is there any documentation on what it needs to be considered complete? (aside from QA)

[domportera]

I got this one working, video as proof

It seems like the only thing that was stopping it was some unsupported validation mode being requested ("VK_Layer_KHRONOS_validation") on my machine. Modifying the code such that validation requests don't kill everything made it run just fine. Requesting the validation layers without the SDK installed causes Vk.CreateInstance to fail.

What's left in getting this completed and supported? I wasn't able to get things running the correct silk-contributor way, but symlinking the project directory into my own solution and replacing the csproj relative-file-style dependencies with their nuget dependencies worked for me.

Do we just need to pass all validation areas? It seems like it does with flying colors aside from the default "Best Practices" (no specific vendor/subcategory selected). These are the messages that are outputted:

BestPractices-specialuse-extension(WARN / SPEC): msgNum: 1734198062 - Validation Warning: [ BestPractices-specialuse-extension ] | MessageID = 0x675dc32e | vkCreateInstance():  Attempting to enable extension VK_EXT_debug_utils, but this extension is intended to support use by applications when debugging and it is strongly recommended that it be otherwise avoided.

    Objects: 0

WARNING-CreateInstance-status-message(INFO / SPEC): msgNum: 601872502 - Validation Information: [ WARNING-CreateInstance-status-message ] Object 0: handle = 0x23bca898160, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x23dfd876 | vkCreateInstance():  Khronos Validation Layer Active:

    Settings File: Found at C:\Users\Dom\AppData\Local\LunarG\vkconfig\override\vk_layer_settings.txt specified by VkConfig application override.

    Current Enables: VK_VALIDATION_FEATURE_ENABLE_GPU_ASSISTED_EXT, VK_VALIDATION_FEATURE_ENABLE_GPU_ASSISTED_RESERVE_BINDING_SLOT_EXT, VK_VALIDATION_FEATURE_ENABLE_BEST_PRACTICES_EXT, VK_VALIDATION_FEATURE_ENABLE_SYNCHRONIZATION_VALIDATION.

    Current Disables: None.



    Objects: 1

        [0] 0x23bca898160, type: 1, name: NULL

BestPractices-vkCreateDevice-physical-device-features-not-retrieved(WARN / SPEC): msgNum: 584333584 - Validation Warning: [ BestPractices-vkCreateDevice-physical-device-features-not-retrieved ] Object 0: handle = 0x23bca898160, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x22d43910 | vkCreateDevice():  called before getting physical device features from vkGetPhysicalDeviceFeatures().

    Objects: 1

        [0] 0x23bca898160, type: 1, name: NULL

WarningBitExt ValidationBitExtValidation Warning: [ BestPractices-vkCreateDevice-physical-device-features-not-retrieved ] Object 0: handle = 0x23bca898160, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x22d43910 | vkCreateDevice():  called before getting physical device features from vkGetPhysicalDeviceFeatures().

2455824335200 2455928110864

BestPractices-vkCreateCommandPool-command-buffer-reset(WARN / PERF): msgNum: 141128897 - Validation Performance Warning: [ BestPractices-vkCreateCommandPool-command-buffer-reset ] | MessageID = 0x86974c1 | vkCreateCommandPool(): pCreateInfo->flags VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT is set. Consider resetting entire pool instead.

    Objects: 0

WarningBitExt PerformanceBitExtValidation Performance Warning: [ BestPractices-vkCreateCommandPool-command-buffer-reset ] | MessageID = 0x86974c1 | vkCreateCommandPool(): pCreateInfo->flags VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT is set. Consider resetting entire pool instead.

BestPractices-vkAllocateMemory-small-allocation(WARN / PERF): msgNum: -40745094 - Validation Performance Warning: [ BestPractices-vkAllocateMemory-small-allocation ] | MessageID = 0xfd92477a | vkAllocateMemory():  Allocating a VkDeviceMemory of size 131072. This is a very small allocation (current threshold is 262144 bytes). You should make large allocations and sub-allocate from one large VkDeviceMemory.

    Objects: 0

WarningBitExt PerformanceBitExtValidation Performance Warning: [ BestPractices-vkAllocateMemory-small-allocation ] | MessageID = 0xfd92477a | vkAllocateMemory():  Allocating a VkDeviceMemory of size 131072. This is a very small allocation (current threshold is 262144 bytes). You should make large allocations and sub-allocate from one large VkDeviceMemory.

BestPractices-vkBindMemory-small-dedicated-allocation(WARN / PERF): msgNum: -1727217761 - Validation Performance Warning: [ BestPractices-vkBindMemory-small-dedicated-allocation ] | MessageID = 0x990cbf9f | vkBindImageMemory():  vkBindImageMemory(): : Trying to bind VkImage 0x5eb05e000000003b[] to a memory block which is fully consumed by the image. The required size of the allocation is 131072, but smaller images like this should be sub-allocated from larger memory blocks. (Current threshold is 1048576 bytes.)

    Objects: 0

WarningBitExt PerformanceBitExtValidation Performance Warning: [ BestPractices-vkBindMemory-small-dedicated-allocation ] | MessageID = 0x990cbf9f | vkBindImageMemory():  vkBindImageMemory(): : Trying to bind VkImage 0x5eb05e000000003b[] to a memory block which is fully consumed by the image. The required size of the allocation is 131072, but smaller images like this should be sub-allocated from larger memory blocks. (Current threshold is 1048576 bytes.)

BestPractices-vkBeginCommandBuffer-simultaneous-use(WARN / PERF): msgNum: 1231549373 - Validation Performance Warning: [ BestPractices-vkBeginCommandBuffer-simultaneous-use ] | MessageID = 0x4967f3bd | vkBeginCommandBuffer(): pBeginInfo->flags (VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT) has VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT.

    Objects: 0

WarningBitExt PerformanceBitExtValidation Performance Warning: [ BestPractices-vkBeginCommandBuffer-simultaneous-use ] | MessageID = 0x4967f3bd | vkBeginCommandBuffer(): pBeginInfo->flags (VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT) has VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT.

[domportera]

I fixed the device features validation warning by retrieving the PhysicalDeviceFeatures, but it's no use if we're not actually using those features. What is the minimal subset of features required that we would want to check for?

[domportera]

update: aside from the code quality issues, so far I've found a couple of things that need work -

1. the actual draw example isn't working off of a shader a user could reasonably expect to replace without setting up the compilation themselves?
2. related to 1, the general shader loading portion of the code needs finishing/cleaning. The user would likely expect to pass in their own background pipeline
3. the ImGuiController class doesn't match the functionality or "interface" of the same class in the OpenGL implementation, which can cause confusion

[domportera]

Question - how do we feel like using Dynamic Rendering with Shader Objects by default? As far as vulkan templates go, this is probably the most new-user-friendly mode of operation anyway. This is more or less how I'm attempting to set up the pipeline for tooll3, and I'd be happy to share the result if/when I succeed. The biggest caveat for this is mobile support, as it requires vulkan 1.3 and support for the extensions involved, which may only currently exist for recent/high-end mobile devices.