Do's and Dont's

Table of Contents:

• Don't: create temporary mapped buffers when updating data.
• Do: group resource bindings by the change frequency, start from the lowest.
• Don't: create many resources (buffers or textures) per frame.
• Don't: submit many times per frame.

Don't: create temporary mapped buffers when updating data.

Instead, write_buffer and write_texture can be used on a Queue, conveniently. If you are uploading a lot of data that is generated (as opposed to already be sitting in a data vector), it may be more efficient to recycle staging buffers in a pool.

Do: group resource bindings by the change frequency, start from the lowest.

For example, put per-frame resources into bind group 0, per-pass resources into bind group 1, and per-material resources in bind group 2. This allows the WebGPU implementation to keep the other bindings intact, reducing the state changes.

Don't: create many resources (buffers or textures) per frame.

This puts pressure on WebGPU memory allocator and tracker. Prefer coalescing smaller resources into larger ones. For buffers, one can create a large buffer and use different parts of it for different purposes. For textures, one would consider texture atlases and arrays.

Don't: submit many times per frame.

There is a visible CPU cost per submission, and resources are tracked per submission by the implementation. It is fine to have multiple command buffers per submission, but the number of submit() calls should be limited to a few per frame (e.g. 1-5).