Hi, @Apple Graphics The queue is serial type. The code calling dispatch_async_f does not run on the same queue. It's running on a separate worker thread. I used CACurrentMediaTime() to measure duration of dispatch_async_f. Duration still increases progressively from almost instant to 3ms while rendering a static scene for 2mins. @endecotp Yes the functions I enqueue do run. If i pause randomly, I land in this dispatch_async_f 50% of the times. Call statck shows dispatch_async_f()->dispatch_async_f_slow()->ulockWait(). Thanks

@endcopt I made i mistake. The actual callstack is dispatch_async_f()->dispatch_async_f_slow()->gcd_queue_item_enqueue_hook

Thanks @eskimo! That fixed the issue. Is the game doing something wrong to cause this?

Retain and then release the drawable in a handler fixed the issue. Thank you so much! Are you creating command buffers with -[MTLCommandQueue commandBufferWithUnretainedReferences] Yes we do. Does this occur after/during a resize of the window? It occurs at launch. I cannot confirm it happens on a resize. Are you double or triple buffered? Triple.

When I say the "debug button" I mean this one.

Found the issue: the "macOS Deployment Target" in the sample project was incorrect. While trying with a different sample I got this error message: [Metal Diagnostics Warning] Application Deployment Target Version (10.12) does not match OS Version (13.1) - diagnostics may be missing debug information Changing the target version to 13 fixed the shader debugger.

I must add that, in this example, I have 1 draw call per command buffer. Since there is only one command queue, i am expecting each draw to execute one after another.

After some investigation, it looks like this overlap in the graph is a bug in the Metal profiler. Let Texture_A be the output of the render pass (1) and the input of the compute pass (2). Playing with the content of Texture_A confirms that the compute pass runs after the render pass. Clearing Texture_A early in the frame has no effect on the compute pass. Clearing Texture_A between the render pass and the compute pass shows that the compute pass input has changed. I'll report this to Apple.

Thanks Alecazam. One important thing I didn't mention is that our game uses "untracked" ressources. In this same thread mentioned earlier, the Apple engineer mentions : You must use a fence to sychronize untracked resource across command buffers from the same queue. So if command buffer 1 writes to an untracked texture and later excute command buffer 2 which reads from it, you need a fence That is a little confusing. Apple's documentation states that the scope of a fence is limited to a single command buffer: An MTLFence synchronizes access to one or more resources across different passes within a command buffer. Use fences to specify any inter-pass resource dependencies within the same command buffer. I made a request to Apple to add a note in the documentation about that. Adding a fence fixed all the flickering on our side.

Right. I think what this bar chart explanation misses is: for iOS, when brightness is lowered, the peak luminance is also capped to keep headroom concistent.