Hm that's weird! The only thing that sticks out for me is that you're using the new MTL4CommandAllocator API. I see they have a reset instance method which can be called manually to free memory from command buffers. Since you are not encoding anything, perhaps the internal logic that would automatically free the memory doesn't trigger? That's my guess, worth adding a reset at the end to see if it fixes it. Still sounds like a bug so consider reporting it! I'm curious, what's the usecase for not encoding anything during a pass?

No AFAIK, it's the driver's job to effectively schedule GPU workloads. What makes you want to assign priorities? Are you getting performance issues?

True, it is a bit confusing without context. Argument tables basically put all power to you as the developer on how you want your rendering pipeline to interpret your GPU uploaded data. Also, you are free to replace the typical vertex input workflow (using stage_in and MTLVertexDescriptor) with raw buffer indexing in the shader. The "Drawing a triangle with Metal 4" sample demonstrates that. So with the attributeStride parameter you can (loosely) recreate what stride does on MTLVertexBufferLayoutDescriptor. It is true that the C++ side structs will determine the underlying buffer layout for the shader, but what if you wanna have multiple variants of the buffer types? e.g. struct { simd_float2 position; simd_float4 color; } VertexData1; struct { simd_float2 position; simd_float4 color; simd_float3 normal; simd_float2 uv; } VertexData2; E.g.: Imagine you have a big vertex buffer that contains lots of data, but not all shaders use the same vertex inputs. Maybe you are interleaving or otherwise packing vertex info like positions, normals, tangents, uvs etc. But you have multiple shaders, one that only processes positions and normals, and others that need the full set of attributes. So to avoid recreating slicing your original GPU buffers to subsets of the same data, you just create a different 'view' of your buffers, binding the same GPU buffer with different strides on the argument table. Hope this all makes sense, this is how I understand it. Having said that, I haven't used this API so the above is speculative.

Is it possible you're running this on Simulator? I've hit similar problems on my end with missing Metal4 symbols in the iOS Simulator SDK. But the sample runs fine when I try it on my device.

Is args the pointer you use for device.makeBuffer? If that's the case, as soon as you create the MTLBuffer you're free to discard the cpu side data, as the function copies the contents into GPU memory. From the docs: "Allocates a new buffer of a given length and initializes its contents by copying existing data into it."