[meta] Locking on Metal

[kvark]

This is a meta-issue to track all the locking we do in Metal backend. We need to check if they are appropriate, assume the worst use case, and try to optimize them.

• service pipes - Optimize locking of ServicePipes #2227 . They are locked quite a bit in various places.
• pass descriptor. Locked in begin_render_pass, so that we can mutate it and start a real pass. The problem is that an app can do a dozen of render passes from multiple threads on the same framebuffer. And starting one is accidentally the single heaviest operation of the backend...
• shared queue. It is accessed on submission as well as any time we need to spawn a new command buffer. These shouldn't take long, so I'd not expect a congestion, but it does show up in the profile.
• shared device. Locked whenever we need to create a resource, pipeline, or a new state. The cost should largely go away as the application warms up, but we need to double-check.
• command buffer inner - Bring back UnsafeCell for command buffer internals of Metal #2226 . I don't think RefCell has any locking overhead.
• descriptor pool inner - Metal pools improved #2235
• fences - CommandBuffer based fencing in Metal #2252
• swapchain frames. It doesn't look to matter so far. Changing the acquire to be blocking doesn't nearly affect the framerate.

[kvark]

I received a general advice from Nathan Froyd to use https://github.com/Amanieu/parking_lot . We need to check it out and benchmark.

[kvark]

Major issues are fixed, I believe.

[kvark]

Reviving this, since apparently our performance doesn't scale well enough from 2 to 4 cores. Not sure what else, if not locking, would affect it.