-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MVK Access to Indirect Command Buffers #2247
Comments
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.)
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. |
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:
Thank you!
The text was updated successfully, but these errors were encountered: