Multiple pipelines within a subpass

[kocsis1david]

If different materials can have different shaders and pipelines, how do you switch between them in a record_subpass? Or is Sceen 13 designed to be used with uber shaders?

[attackgoat]

Screen 13 doesn't put any sort of restrictions on these techniques beyond Vulkan; so you are free to choose what pattern you might want here:

• One pipeline that draws to your targets and has descriptors for all materials (uber shader)
• Multiple pipelines which each contain one material and you switch off repeatedly

For multiple pipelines, you might keep the same color attachments around and just render on top of the previous results - to do that draw with one pipeline and then just complete that pass, begin a new one, bind the second pipeline, and then re-do the "attach(0, my_img)"" builder functions so that the new pipeline draws into the existing textures.

The key thing behind your question might be LOAD/STORE ops between passes so that you can accumulate rendering ops. Does this clarify things? I can get on a Zoom call and help - send me an email [email protected]

See docs:
https://docs.rs/screen-13/latest/screen_13/graph/struct.PipelinePassRef.html#method.attach_color

[kocsis1david]

Thanks for the answer.
I modified the triangle example to have two passes. It works, but I wonder if it's efficient to have so many passes if there are a lot of pipelines for each material. I guess it would be better to minimize the number of pipelines, even though the README says it automatically merges passes.
I asked the question because I thought beginning multiple passes for each material is a bad idea for performance reasons.

screen_13.run(|frame| {
    let index_node = frame.render_graph.bind_node(index_buf.take().unwrap());
    let vertex_node = frame.render_graph.bind_node(vertex_buf.take().unwrap());

    frame
        .render_graph
        .begin_pass("Triangle Example")
        .bind_pipeline(&triangle_pipeline)
        .access_node(index_node, AccessType::IndexBuffer)
        .access_node(vertex_node, AccessType::VertexBuffer)
        .clear_color(0)
        .store_color(0, frame.swapchain_image)
        .record_subpass(move |subpass| {
            subpass.bind_index_buffer(index_node, vk::IndexType::UINT16);
            subpass.bind_vertex_buffer(vertex_node);
            subpass.draw_indexed(3, 1, 0, 0, 0);
        });

    frame
        .render_graph
        .begin_pass("Triangle Example 2")
        .bind_pipeline(&triangle_pipeline2)
        .access_node(index_node, AccessType::IndexBuffer)
        .access_node(vertex_node, AccessType::VertexBuffer)
        .attach_color(0, frame.swapchain_image)
        .record_subpass(move |subpass| {
            subpass.bind_index_buffer(index_node, vk::IndexType::UINT16);
            subpass.bind_vertex_buffer(vertex_node);
            subpass.draw_indexed(3, 1, 0, 0, 0);
        });

    index_buf = Some(frame.render_graph.unbind_node(index_node));
    vertex_buf = Some(frame.render_graph.unbind_node(vertex_node));
})

Using RenderDoc, it seems it creates two subpasses:

[attackgoat]

Sorry - replied incorrectly in the other thread this is my first Github "Discussion"

[attackgoat]

Let me also add more clarity on the "merge" part:

What Screen 13 is doing here is noticing that two passes were recorded onto the graph. Each seems to have a different pipeline, and that's okay, because their input/output images are compatible. So when it comes time to submit Screen 13 uses just a single vk::RenderPass and two subpasses, which allow for on-tile rendering.

[attackgoat]

This is the expected behavior; the two passes ("Triangle Example" and "Triangle Example 2") are merged into one vk::RenderPass as shown, and when submitted Screen 13 executes the first pass followed by each next pass.

More generally the "efficiency" problem I think is a general problem in the industry; lately I have been very excited about GPU-driven rendering and those approaches, but other people have gone into bindless and using shaders to lookup data dynamically.

Screen 13 supports all these techniques and does not impose a requirement that hardware supports bindless, because the provided descriptors are automatically pooled and allocated per call.

Two ideas to approach the efficiency topic:

• Do more work within record_subpass calls: You may change descriptors and keep the same pipelines bound, then make additional record_subpass calls.
• Explore draw_indirect(..) and let the GPU sort your data before drawing, so that you have manageable chunks

Also I think most people who are not Unity or Unreal just assign a target GPU usage and consider that okay, which of course everyone writing a metaverse lately seems like this is now a common problem?