I think if your buffer is less than 4k its recommended to use setVertexBytes, the question I have is can I keep hammering on setVertexBytes as the primary method to issue multiple draw calls within a render buffer and rely on Metal to figure out how to orphan and replace the target buffer?
A lot of the primitives I am drawing are less than 4k and the process of wiring down larger segments of memory for individual buffers for each draw primitive call seems to be a negative.
And it's just simpler to copy, submit and forget about buffer synchronization.
Yes, your approach is correct. setVertexBytes is designed for exactly this use case — small, frequently-changing data where you want to avoid the overhead of creating and managing MTLBuffer objects. You can call it as many times as you need within a render pass, each call copies the data and Metal manages the underlying transient storage. You don't need to worry about buffer synchronization or orphaning.
The 4KB limit and the recommended usage pattern are documented in the Metal Best Practices Guide under Buffer Bindings:
- For data less than 4KB: use
setVertexBytes— avoids the overhead of creating an intermediaryMTLBuffer - For data 4KB or larger: create an
MTLBufferand usesetVertexBuffer:offset:atIndex:
