GPU frame timing: timestamp ordering guarantees

[GeneralGDA]

I'm implementing GPU frame-time measurements using wgpu 30.0.1. The goal is to measure one interval covering the frame’s compute and render passes, with asynchronous readback.

The write_timestamp docs warn that timestamps may be reordered relative to surrounding commands.

However, the official example brackets render and compute passes with two encoder timestamps, without explicit barriers, and tests that the outer interval covers both pass durations.

Is this the recommended pattern for GPU frame-time measurements? How should the warning be interpreted?

If additional synchronization or a different timestamp API is needed, what is the recommended wgpu-level approach without introducing CPU waits?

[xop01]

Yes. Two write_timestamp calls on the encoder, one before the passes and one after, is the pattern in the wgpu 30 example. Resolve the query set into a buffer and read that buffer on a later frame. Do not wait on the CPU in the same frame. Subtract the two values and multiply by the queue timestamp period to get nanoseconds.

The warning means a timestamp is not a hard fence. The driver may reorder it against nearby commands, and that depends on the backend and the driver. There is no extra wgpu call that makes the order strict, and you do not add a CPU wait to fix it.

For a whole frame, the two outer timestamps are the right measurement. On a driver that does reorder them, that interval can be a little off compared with the sum of the passes. That is the limit the docs are describing.

@GeneralGDA