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.

After some try and fail: img_block.slice(0) 0 because i am reading from color attachment 0;

Sure! I created a feedback ticket and attached Code sample and Metal captures. FB16427191

Regarding this, an Apple Engineer in charge of our product reached out to me. He pointed out that writing to the UAV disables lossless compression and causes the slow down. Thank you for taking the time to answer.