Safety of MTLTexture reuse across MTLCommandQueues

Question

Does Metal's built-in hazard tracking (MTLHazardTrackingMode.tracked) ensure that writing a texture from one command queue does not collide with usage of that same texture on a different command queue, or do I need to synchronize this access manually? My context is conceptually similar to this unanswered question on the Apple developer forum, where one "writer" queue is handling textures at a potentially different rate than a "reader" queue which renders the results.

Answer 1

Yes, MTLHazardTrackingMode.tracked ensures that writing a texture from one command queue does not interfere with usage on a different command queue, but it can cause delays.

From Apple's Documentation:

If you submit a command that modifies the resource, Metal delays that command from executing until prior commands accessing that resource are complete, and prevents future commands from executing until the modifications are complete.

For optimal performance you would want to synchronize manually, Apple adds:

For better performance, use untracked resources and synchronize access yourself.