Create interface for VulkanSceneGraph

[dov]

VulkanSceneGraph (VSG) is a high level interface to Vulkan under active development. I'd love to see an adapter for VKVG to VSG similar to the existing ImGui adapter.

References

• https://github.com/vsg-dev/VulkanSceneGraph
• https://github.com/vsg-dev/vsgImGui

[dov]

I tried looking at this myself, but I need some guidance:

• As far as I understand in Vulkan Scene Graph (vsg) the infrastructure already creates a CommandBuffer that you should record to. My problem is how I can interface this command buffer to the vkvgContext?

I'm trying to base my solution on the vsgImGui which interfaces VSG to imgGUI, which when recording calls out to:

            ImGui_ImplVulkan_RenderDrawData(ImDrawData *draw_data, VkCommandBuffer commandBuffer);

Is there a function doing the corresponding call to record the vkvg commands?

To me it seems like vkvg is currently hardcoded to create its own command buffer through vkvg_create(). Am I missing something?

[jpbruyere]

Here are some notes on the internal use of buffers: https://github.com/jpbruyere/vkvg/wiki/Internals.
I use 2 buffers and swap them for rendering. Could those buffers be declared as secondary buffers? There are multiple things to consider here:

• the target texture to draw on: vkvg handles textures and renderpasses.
• the synchronizations: I use one fence in the context or one timeline semaphore (compile option)
  vkvg is not designed to interface with existing command buffers, so there is no way in the api to do that. The use of 2 command buffers looks to me a blocking point for that idea.

Sharing the command buffer with the host app looks to me quiet invasive, if targeting secure applications, this looks a bad option for me. If cmd are passed as secondary buffers, this could be better maybe. The point is to be able to keep track of command buffers debug counters and timing.

I plan to crate a new structure: vkvg_path to holds multiple stroking and filling algorithms, that addition to the existing model could ease to implement such an idea.....

The error handling model of vkvg follows cairo principles: api could continue to be called even after faulting without halting host application, if vkvg is completely in error, the only problem must be a black screen, but the host operations should be able to continue. The status field in each structure must keep track of current error.

Feel free to expose more of your questioning so that I could help you.