When I take a frame capture of my application in Xcode, it shows a warning that reads "Your application created separate command encoders which can be combined into a single encoder. By combining these encoders you may reduce your application's load/store bandwidth usage."
In the minimal reproduction case I've identified for this warning, I have two render pipeline states: The first writes to the current drawable, the depth buffer, and a secondary color buffer. The second writes only to the current drawable.
Because these are writing to a different set of outputs, I was initially creating two separate render command encoders to handle the draws under each of these states.
My understanding is that Xcode is telling me I could only create one, however when I try to do that, I get runtime asserts when attempting to apply the second render pipeline state since it doesn't have a matching attachment configured for the second color buffer or for the depth buffer, so I can't just combine the encoders.
Is the only solution here to detect and propagate forward the color/depth attachments from the first state into the creation of the second state?
Is there any way to suppress this specific warning in Xcode?
Hello,
From the description, there are two logical stages in your render pipeline. These stages are referred to as "states" implying an order and dependence.
Metal Tools identified that these logical stages don't need to be separated into different command buffers. The same commands can be executed in the same order using a single command buffer. Commands are executed in order of submission within a command buffer.
Combining the two command buffers potentially halves the load/store cost. You can ignore the warning if the benefit doesn't significantly improve performance which you can verify with additional profiling.
The new combined command buffer requires a new PSO (pipeline state object) configured for both of the original stages. The front-end compiler won't allow you to execute commands without a correctly configured PSO. In this case the new PSO needs to write to the depth buffer, a secondary color buffer and the current drawable.
So combining command buffers implies that you combine PSOs.
Re: "Is the only solution here to detect and propagate forward the color/depth attachments from the first state into the creation of the second state?"
We don't know enough about how stage / state 1 and 2 depend on each other to definitely answer that question. This also suggests creating at least two PSOs when we only have one (combined).
If stage 2 depends the results of stage 1 e.g. depth buffer or secondary color buffer, you can synchronize the work within the command buffer with barriers. For the second color buffer you can use an intermediate render target with programmable blending to provide texture data to stage 2 without paying the cost of writing the result back to main memory.
