c – Why do I want two/three Vulkan pipelines for GUI presentation

For any that need to plumb Vulkan’s complication I want you nicely.
It is a badly documented software program SDK and this is an ideal instance of why it is by no means clear via context: I need to run an all-C rendering system as a result of I obtain headless variations with an identical software program to microcontrollers on robots in addition to management stations operating identical libraries and messages and many others.

I’m making an attempt to change a nuklear-glfw-vulkan Rapid Mode GUI from moppers

With out publicity to the internals it is a bit of like snipping spaghetti in a collander bowl, and it is by no means clear with documentation from Khronos, LunarG that reads like “a flux capacitor capacitances flux” you want to make 5 errors to disambiguate.

Inside mopper’s nuklear-glfw-vulkan.h header he passes Vulkan system occasion configuration knowledge in regards to the logical system and many others. however just one pointer to VkImageviews from his demo.cpp Vulkan creation the place his nuklear-glfw-vulkan creates picture reminiscences and binds to the nuklear-glfw-vulkan pipeline.

Right here is the code from overlay.c that passes the Imageview pointer from demo.cpp:

void init_overlay(GLFWwindow *_win, VkDevice logical_device,
                  VkPhysicalDevice physical_device,
                  uint32_t graphics_queue_family_index, VkQueue graphics_queue,
                  VkImageView *image_views, uint32_t image_views_len,
                  uint32_t width, uint32_t top, VkFormat color_format) {
  win = _win;
  ctx = nk_glfw3_init(win, logical_device, physical_device,
                      graphics_queue_family_index, image_views, image_views_len,
                      width, top, color_format, NK_GLFW3_INSTALL_CALLBACKS);

Here is mopper’s IM GUI header that implements Vulkan code for nuklear.h

However inside demo.cpp he has two pipelines: the triangle pipeline and the overlay pipeline.
However inside nuklear-glfw-vulkan he makes one other pipeline aiming on the overlay pipeline’s created vkImageViews that he creates imagememories for inside nuklear-glfw-vulkan.h.

Here is mopper’s demo.cpp creating TWO pipelines even after the nuklear-glfw-vulkan pipeline.

Here is his twin pipeline creation:

 void initVulkan() {
    createInstance();
    setupDebugCallback();
    createSurface();
    pickPhysicalDevice();
    createLogicalDevice();
    createSwapChain();
    createSwapChainImageViews();
    createOverlayImages();
    createOverlayImageViews();
    createRenderPass();
    createFramebuffers();
    createDescriptorSetLayout();
    createDescriptorPool();
    createDescriptorSets();
    createTriangleGraphicsPipeline();
    createOverlayGraphicsPipeline();
    createCommandPool();
    createCommandBuffers();
    createSemaphores();

    QueueFamilyIndices queueFamilyIndices = findQueueFamilies(physicalDevice);

    init_overlay(
        window, system, physicalDevice, queueFamilyIndices.graphicsFamily,
        graphicsQueue, overlayImageViews.knowledge(), overlayImageViews.measurement(),
        swapChainExtent.width, swapChainExtent.top, swapChainImageFormat);
  }

So right here is my query:

Why do you want the overlay pipeline along with his demoshaders (.vert and .frag) in an overlay pipeline whenever you additionally create the nuklear-glfw-vulkan pipeline?

He creates a triangle pipeline that exhibits an MVP triangle mannequin. He creates an Overlay pipeline with demoshaders. Then he creates a nuklear-glfw-vulkan pipeline with it is personal nuklear .vert .frag shaders that allocates reminiscences and binds to picture reminiscences for textures of the glyphs and icons drawn in a 2D method.

Is not the OverlayPipeline a redundancy?

In jherico’s response he factors on the binding of the overlay photos (that had been handed to nuklear-glfw-vulkan for pipeline create) into the createCommandBuffers():

for (size_t i = 0; i 

He factors out at line 974:

  vkCmdBindPipeline(commandBuffers[i], VK_PIPELINE_BIND_POINT_GRAPHICS,
                    overlayGraphicsPipeline);

that the command buffers created for the overlayGraphicsPipeline are the place the nuklear-glfw-vulkan third pipeline instructions should find yourself.

I feel he is at the very least partially right as a result of the Vulkan command buffers into the submit queue are:

triangle vertexes onerous coded into the trianglepipeline:

vkCmdBindPipeline(commandBuffers[i], VK_PIPELINE_BIND_POINT_GRAPHICS,                            triangleGraphicsPipeline);
      vkCmdDraw(commandBuffers[i], 3, 1, 0, 0);

Then overlay subsequent subpass submitted:

  vkCmdBindPipeline(commandBuffers[i], VK_PIPELINE_BIND_POINT_GRAPHICS,
                    overlayGraphicsPipeline);
  vkCmdBindDescriptorSets(
      commandBuffers[i], VK_PIPELINE_BIND_POINT_GRAPHICS,
      overlayPipelineLayout, 0, 1, &descriptorSets[i], 0, nullptr);
  vkCmdDraw(commandBuffers[i], 3, 1, 0, 0);

After which each command buffer ends attracts.

And this is the weird factor right here: Why are we resubmitting a triangle AFTER the overlaygraphics pipeline?

This does not make sense as a result of that triangle is after the nuklear drawing command buffers from command swimming pools which might be externally created in third pipeline? Is the one purpose for the second overlaypipeline that you simply draw a triangle ON TOP of the nuklear-glfw-vulkan drawing instructions.

Is there a option to scale back this duplication and solely draw the GUI with out the overlaypipeline?