Do's and Dont's

Table of Contents:

• Do: 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.

Do: create temporary mapped buffers when updating data.

Buffers are easy for a WebGPU implementation to re-use internally. Creating a buffer therefore is more often than not a lightweight operation that one can afford to do a few times per frame. Newly created vertex and index buffers can be used right away. For buffers of other usage it may be more convenient to issue a copy_buffer_to_buffer command to copy the newly uploaded data from the temporary buffer to a target buffer. For textures, copy_buffer_to_texture is the only way to update the contents.

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).