-
Notifications
You must be signed in to change notification settings - Fork 939
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.
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.
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.
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.
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).