I'm attempting to put two mesh draws into a MTLRenderCommandEncoder with a memory barrier between them. I'm also using image blocks in the fragment functions in the two pipelines. Something like this: [encoder setRenderPipelineState:pipeline1]; [encoder drawMeshThreadgroups:threadgroupsPerGrid threadsPerObjectThreadgroup:threadsPerObjectThreadgroup threadsPerMeshThreadgroup:threadsPerMeshThreadgroup]; [encoder memoryBarrierWithScope:MTLBarrierScopeBuffers afterStages:MTLRenderStageMesh beforeStages:MTLRenderStageObject]; [encoder setRenderPipelineState:pipeline2]; [encoder drawMeshThreadgroups:threadgroupsPerGrid threadsPerObjectThreadgroup:threadsPerObjectThreadgroup threadsPerMeshThreadgroup:threadsPerMeshThreadgroup]; I get a strange error: Execution of the command buffer was aborted due to an error during execution. Too many unique viewports, scissor rectangles or depth-bias values to support memoryless render pass attachments. (0000000c:kIOGPUCommandBufferCallbackErrorExceededHardwareLimit) I'm not using multiple viewports or scissor rectangles and I'm not using depth bias. I don't have memoryless attachments, though as mentioned, I am using imageblocks. Without the memory barrier I don't get the error. Using memoryBarrierWithResources rather than memoryBarrierWithScope This is on an M2 Max running 14.3 Beta (23D5033f) I can't tell if I encountered a real limitation or a Metal driver bug.

I've been object/mesh shaders using MTLRenderPipelineState built from MTLMeshRenderPipelineDescriptor with visible function tables. However, it seems that some functionality that is present on other MTL*RenderPipelineDescriptor types is missing. Namely, it lacks max<Stage>CallStackDepth() and setSupportAdding<Stage>BinaryFunctions(). The latter isn't too bad: I can always rebuild the the pipeline states from scratch if I want to add new linked functions. However, not being able to set the max call stack depth is limiting. I assume that means I only get a depth of 1 as that is the default value for the other descriptor types. In practice it seems that I can go up to 2 with the functions I'm using before I start getting kIOGPUCommandBufferCallbackErrorSubmissionsIgnored errors due to "prior/excessive GPU errors". I'm curious if the lack of this functionality on MTLMeshRenderPipelineDescriptor is a simple oversight. In my case I only am using VFTs and linked functions in the fragment stage. I suspect it should be possible since the other render pipeline descriptor types expose max call depths and adding binary functions in the fragment stage. FWIW I'm also using Metal-CPP (which is fantastic!) but I don't see this functionality in the Swift/Obj-C docs either.