Question: I'm currently implementing a basic deferred renderer with multithreading in Vulkan. Since my G-Buffer should have the same resolution as the final image I want to do it in a single render-pass with multiple sub-passes, according to [this](https://www.khronos.org/assets/uploads/developers/library/2016-vulkan-devday-uk/6-Vulkan-subpasses.pdf) presentation, on slide 44 (page 138). It says:

* vkCmdBeginCommandBuffer
* vkCmdBeginRenderPass
* vkCmdExecuteCommands
* vkCmdNextSubpass
* vkCmdExecuteCommands
* vkCmdEndRenderPass
* vkCmdEndCommandBuffer

I get that in the first sub-pass, you iterate the scene graph and record one secondary commandbuffer for each entity/mesh. What I don't get is how you are supposed to do the shading pass with secondary command buffers. Do you somehow spit the screen into parts and render each part in a separate thread or just record one secondary commandbuffer for the entire second sub-pass?

Answer: 
> 
> What I don't get is how you are supposed to do the shading pass with secondary command buffers.
> 
> 
> 

The shading pass (assumably the second subpass) would possibly take the G-buffers created by the first subpass as an *Input Attachment*. Then it would draw to equally sized screen-size quad using data from the G-buffers + from a set of lights (or whatever your deferred shader tries to defer).

The presentation you link tries to hint at this structure style starting at page 13 (marked "Page 107").

First step would be to make it working. Use e.g. this [SW example](https://github.com/SaschaWillems/Vulkan/tree/master/deferred). Then the next step of optimizing it into single renderpass should be easier.
To me, like you said, you can need to multi thread your command buffer for the "building g-buffer subpass". However for the shading pass, it must depends on how are you doing things. To me (again), you do not need to multi thread your shading subpasses. However, you must take into consideration that you can have one "by region dependency".

So, I encourage you to procede that way.
Before to begin your RenderPass, use a Compute Shader to splat all your lights on the screen (here you have a kind of array of "quad").

By splatting I mean this kind of thing. You have a point light (for example), the idea is to compute the quad in screen space affected by the light. With that you have 4 vertices (that represents a quad) that you put into a SSBO and you can use it as a vertex Buffer in the shading subpass.

Now you begin the render pass.

1. MT the scene graph rendering if needed. and do your vkCmdExecuteCommands();
2. NextSubpass
3. Use the "array of quads" you create from the earlier compute shader (do not forget a VK\_SUBPASS\_EXTERNAL dependency).
4. NextSubpass and so on

However, you said 

> 
> you iterate the scene graph and record one secondary commandbuffer for each entity/mesh.
> 
> 
> 

I am not sure I really understand what you meant, but if you intend to have one secondary command buffer for one mesh, I really advice you to change the way you are doing. You must use batching. Let's say you have 64 000 different meshes to draw. You could for exemple create 64 command buffers (that you dispatch on 4 threads) and each command buffers have 1000 meshes to draw. (The number are took randomly, so profile your application).

So to answer your question for the shading subpass, I would not use command buffers or only very few (by kind of lights (punctual, directional))