Hi, I run a fairly simple Metal layer in my application that is synced with UIKit. My metal layer sits beneath some UIKit components which the user can interact with and which must be synchronised with the Metal layer beneath.
The Metal Draw calls are minimal. There are essentially three passes. A compute pass that does some processing on some camera input. An off-screen render pass that draws a simple object hierarchy to some screen-sized textures. A final render pass that blends the textures from the prior pass together.
I'm careful not to call currentDrawable until the final pass is ready to commence, and make use of triple-buffering. As I'm synchronising with UIKIt, as recommended I have set `.presentsWithTransaction` to `true` on my `MTKView`, and make use of `.waitUntilScheduled` on the draw call of my MTKView to ensure everything is synchronised, like so:
commandBuffer.commit()
commandBuffer.waitUntilScheduled()
view.currentDrawable?.present()
This generally works fine.
However, I've noticed that if I for some reason hit 100% CPU usage, things can get backed up. The command encoding is delayed, and this then has a knock on effect of drawables not being available with a whole string of grey 'thread blocked waiting for next drawable' for 30 or more frames.
What's the best way to *** this kind of backing up in the bud? It would probably be best just to skip encoding a frame or two at the point this happens, rather than the situation now where the main thread is being blocked each frame for an interderminate amount of time until the system regains stability.
Any tips on how to acheive this? Or, ideally a better alternative.
Thanks!