MVK Access to Indirect Command Buffers

[EricAtPlanGrid]

My application (CAD visualization) is heavily draw-call bound. As a result we find that on larger models we spend upwards of 80% of frametime simply encoding these calls. I was able to prototype a simple Metal renderer which encodes the drawcalls upfront using ICBs, which was able to reduce the CPU usage from 100% during rendering to about 10%.

My question here is in two parts:

1. is there a reason that Vulkan secondary command buffers cannot be treated as ICBs?
2. if the answer to one is "yes", have you considered / is there a known way to work around this somehow so that performance critical applications could still benefit from ahead-of-time encoding?

Thank you!

[cdavis5e]

1. is there a reason that Vulkan secondary command buffers cannot be treated as ICBs?

Yes, because not everything that can be encoded to a secondary command buffer can be represented in an ICB. In particular, IMR GPUs on Intel Macs don't support compute from ICBs. (Admittedly, this particular instance should become less of a problem as Intel Macs become rarer and rarer.)

2. if the answer to one is "yes", have you considered / is there a known way to work around this somehow so that performance critical applications could still benefit from ahead-of-time encoding?

It should actually be mostly straightforward--I wouldn't quite say "trivial"--to implement secondary command buffers with ICBs. The big sticking point I think would be checking if all commands could be encoded to the ICB, and, if not, falling back to the old path.