wgpu/documentation/best_practices/
dos_and_donts.rs

1/*!
2# Dos and Don'ts
3
4A short list of common performance pitfalls and the patterns that avoid
5them.
6
7### Don't: create temporary mapped buffers when updating data
8
9Instead, [`Queue::write_buffer`] and [`Queue::write_texture`] can be used
10conveniently. If you are uploading a lot of data that is generated (as
11opposed to already sitting in a data vector), it may be more efficient to
12recycle staging buffers in a pool.
13
14### Do: group resource bindings by change frequency, starting from the lowest
15
16For example, put per-frame resources into bind group 0, per-pass resources
17into bind group 1, and per-material resources into bind group 2. This allows
18the WebGPU implementation to keep the other bindings intact, reducing state
19changes.
20
21### Don't: create many resources (buffers or textures) per frame
22
23This puts pressure on the WebGPU memory allocator and tracker. Prefer
24coalescing smaller resources into larger ones. For buffers, you can create a
25large buffer and use different parts of it for different purposes. For
26textures, consider texture atlases and arrays.
27
28### Don't: submit many times per frame
29
30There is a visible CPU cost per submission, and resources are tracked per
31submission by the implementation. It is fine to have multiple
32[`CommandBuffer`]s per submission, but the number of [`Queue::submit`] calls
33should be limited to a few per frame (e.g. 1–5).
34*/
35
36use crate::{CommandBuffer, Queue};
wgpu/documentation/best_practices/dos_and_donts.rs

wgpu/documentation/best_practices/
dos_and_donts.rs
