Use retained command buffer in sokol_gfx about sokol

[floooh]

There's a pretty big performance overhead with memory-managed command buffers unfortunately.

Best we could do is to add a Metal-specific config flag to sg_setup() which then just replaces the commandBufferWithUnretainedReferences with commandBuffer.

(e.g. next to mtl_force_managed_storage_mode a mtl_use_retained_command_buffers)

I would keep the resource life-time-extension code in place though even when retained command buffers are used to not have the two code paths diverge too much.

PS: that second retained command buffer I added in #762 didn't actually solve the problem in some cases btw. It might be that swapchain resources are already released by the command buffer before the swapchain code in MTKView is done with them (see #872)

[floooh]

Note: this will be fixed as 'drive-by-fix' in #985 via a new runtime config item sg_desc.mtl_use_command_buffer_with_retained_references.

[danielchasehooper]

What is the overhead due to? Is it more than an increment and decrement of the refcount for each resource?

[floooh]

Here's an old blog post (2016), in a stress-test the overhead (measured in the Instruments CPU profiler) for refcounting (time spent in objc_retain and objc_release calls relative to all other executed code) dropped from 20% (!) to 7% just by switching to commandBufferWithUnretainedReferences (the remaining 7% overhead could then be completely eliminated by only updating buffer offsets instead of "rebinding" buffers for each uniform update - those remaining 7% were mainly a side effect of using ARC though):

https://floooh.github.io/2016/01/14/metal-arc.html

If you just do a couple hundred draw calls, the refcounting overhead shouldn't matter much though (relative to the frame time at least).

(those findings were also the main reason why I changed the sokol headers to not require ARC anymore, because ARC needs so much hand holding to keep performance under control that manual refcounting is actually less hassle).