4

In the Metal Best Practices Guide, it states that for best performance one should "implement a triple buffering model to update dynamic buffer data," and that "dynamic buffer data refers to frequently updated data stored in a buffer."

Does an MTLTexture qualify as "frequently updated data stored in a buffer" if it needs to be updated every frame? All the examples in the guide above focus on MTLBuffers.

I notice Apple's implementation in MetalKit has a concept of a nextDrawable, so perhaps that's what's happening here?

Tricky
  • 7,025
  • 5
  • 33
  • 43

1 Answers1

4

If a command could be in flight and it could access (read/sample/write) the texture while you're modifying that same texture on the CPU (e.g. using one of the -replaceRegion:... methods or by writing to a backing IOSurface), then you will need a multi-buffering technique, yes.

If you're only modifying the texture on the GPU (by rendering to it, writing to it from a shader function, or using blit command encoder methods to copy to it), then you don't need multi-buffering. You may need to use a texture fence within the shader function or you may need to call -textureBarrier on the render command encoder between draw calls, depending on exactly what you're doing.

Yes, nextDrawable provides a form of multi-buffering. In this case, it's not due to CPU access, though. You're going to render to one texture while the previously-rendered texture may still be on its way to the screen. You don't want to use the same texture for both because the new rendering could overdraw the texture just before it's put on screen, thus showing corrupt results.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
  • Interesting, thanks. So in the case of a multi-pass render – i.e. one pass renders the background into a texture, the next renders an overlay into another texture, and a final pass that composites the previous two textures together, would that be subject to the same risk of corruption without multi-buffering the target textures for the first two passes in addition the the final pass? – Tricky Oct 16 '17 at 11:12
  • 1
    If I understand the scenario you're describing, then, no, that doesn't need multi-buffering. The compositing of the two textures for one frame will be completed before they are overwritten for the next frame (unless *you* enqueue the commands in the wrong order). – Ken Thomases Oct 16 '17 at 15:28