- mtl_read_texels runs on the game's own thread outside a submission, where no pool drains what Metal autoreleases (the command buffer, the blit encoder, the read-back buffer), and that thread lives for good: every GPU read-back stayed alive. It runs under an @autoreleasepool now. MacNativeGames 635fb31 measured Breath of the Wild's ~130 read-backs a second holding 3.7 GB of GPU memory after 30 minutes.
- arena_alloc's buffer out-parameter is __strong: an unqualified id * is __autoreleasing under ARC, which put the arena buffer in the autorelease pool at every call (a few per draw). The arena also keeps its length, so an allocation, arena_new and the idle trim send no message. MacNativeGames 0531f28: autorelease 2.63% -> 1.73% of replay time.
- The texture / sampler registry lock g_rmu is an os_unfair_lock, which lends a waiter's priority to its owner. Game threads (priority 46) take it to register textures and samplers, the submit thread (97) for every argument encode; preempted while holding the mutex, they kept the submit thread waiting 1.8 ms a frame in a Tears of the Kingdom shrine (MacNativeGames 5f5de5e: 155 -> ~0 ms/s of waiting, frame time unchanged there). t_stencil_view, t_view_levels and t_view_swizzle take the lock the same way.
Aleksandr Svidchenkov
5a81e13f24