britzl
Vulkan Support
Since all of Defold’s default targets are moving to Vulkan, it would be nice to have Vulkan support. P.S. I’m going to try adding Vulkan support, but I have no idea if it’s even possible.
It should be possible yes. Dear-ImGUI has a vulkan implementation here:
https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_vulkan.cpp
You need to update imconfig.h and set a different define if vulkan is present:
https://github.com/britzl/extension-imgui/blob/master/imgui/src/imgui/imconfig.h
The question is how to answer "if vulkan is present?". There might be a define we can check.
It should be possible yes. Dera-ImGUI has a vulkan implementation here:
I know, but you are using additional GL libs. Something similar might be required for Vulkan?
You need to update imconfig.h and set a different define if vulkan is present:
https://github.com/britzl/extension-imgui/blob/master/imgui/src/imgui/imconfig.h
The question is how to answer "if vulkan is present?". There might be a define we can check.
If I manage to come this far, I’ll let you know :)
If I manage to come this far, I’ll let you know :)
I guess it is not possible without accessing the built-in(Defold's) Vulkan context’s surface, render pass, etc. (at least for me). I tried to initialize Vulkan (device, pool, swapchain, framebuffer, etc.) separately, but couldn’t manage properly. I also think this is not the proper way (creating a separate Vulkan context + might require MoltenVK for mac); it’s way beyond my knowledge. There might be a simpler way that I can’t figure out...
If you can figure out what you need from the context we can expose those things in the vulkan DMSDK header: https://github.com/defold/defold/blob/dev/engine/graphics/src/dmsdk/graphics/graphics_vulkan.h
Perhaps a way forward would be to take some other implementation and then figure out what you need from defold and then we can provide those mechanisms via the sdk.
If you can figure out what you need from the context we can expose those things in the vulkan DMSDK header:
I will try...
Perhaps a way forward would be to take some other implementation and then figure out what you need from defold and then we can provide those mechanisms via the sdk.
There is actually a vulkan + glfw example: https://github.com/ocornut/imgui/blob/master/examples/example_glfw_vulkan/main.cpp. We need to pass the init_info for start:
static VkAllocationCallbacks* g_Allocator = nullptr;
static VkInstance g_Instance = VK_NULL_HANDLE;
static VkPhysicalDevice g_PhysicalDevice = VK_NULL_HANDLE;
static VkDevice g_Device = VK_NULL_HANDLE;
static uint32_t g_QueueFamily = (uint32_t)-1;
static VkQueue g_Queue = VK_NULL_HANDLE;
static VkDebugReportCallbackEXT g_DebugReport = VK_NULL_HANDLE;
static VkPipelineCache g_PipelineCache = VK_NULL_HANDLE;
static VkDescriptorPool g_DescriptorPool = VK_NULL_HANDLE;
static ImGui_ImplVulkanH_Window g_MainWindowData;
static uint32_t g_MinImageCount = 2;
static bool g_SwapChainRebuild = false;
....
ImGui_ImplVulkan_InitInfo init_info = {};
//init_info.ApiVersion = VK_API_VERSION_1_3; // Pass in your value of VkApplicationInfo::apiVersion, otherwise will default to header version.
init_info.Instance = g_Instance;
init_info.PhysicalDevice = g_PhysicalDevice;
init_info.Device = g_Device;
init_info.QueueFamily = g_QueueFamily;
init_info.Queue = g_Queue;
init_info.PipelineCache = g_PipelineCache;
init_info.DescriptorPool = g_DescriptorPool;
init_info.RenderPass = wd->RenderPass;
init_info.Subpass = 0;
init_info.MinImageCount = g_MinImageCount;
init_info.ImageCount = wd->ImageCount;
init_info.MSAASamples = VK_SAMPLE_COUNT_1_BIT;
init_info.Allocator = g_Allocator;
init_info.CheckVkResultFn = check_vk_result;
ImGui_ImplVulkan_Init(&init_info);
https://github.com/ocornut/imgui/wiki/Integrating-with-Vulkan#vulkan-components-that-are-needed-for-dear-imgui
-
VkInstance -
VkPhysicalDevice -
VkDevice -
VkQueueFamily -
VkQueue -
VkDescriptorPool -
VkCommandPool -
VkCommandBuffer -
VkRenderPass -
VkFramebuffer
We have everything in VulkanContext in graphics_vulkan_private.h:
https://github.com/defold/defold/blob/dev/engine/graphics/src/vulkan/graphics_vulkan_private.h#L362
We have everything in VulkanContext in graphics_vulkan_private.h:
Great news, thank you. Looks like this is a step toward the public API, unless you’d rather I take my chances with the private one?
Looks like this is a step toward the public API, unless you’d rather I take my chances with the private one?
I will add functions to graphics_vulkan.h in dmSDK!
Looks like this is a step toward the public API, unless you’d rather I take my chances with the private one?
I will add functions to graphics_vulkan.h in dmSDK!
Task has been taken over by @ekharkunov
Why does this extension even use a direct graphics API? Wouldn't it be simpler to use the engine's internal API, meshes, textures, and so on? It's much simpler and more accurate than trying to bind every direct API instead of a single implementation, which would also be significantly smaller.
