search

KhronosGroup / MoltenVK

MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
Apache License 2.0
4.76k stars 419 forks source link

MVK Access to Indirect Command Buffers #2247

Open EricAtPlanGrid opened 4 months ago

EricAtPlanGrid commented 4 months ago

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 commented 4 months ago
  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.)

  1. 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.