WebGPUBackend: Fix Timestamp Query

[ycw]

descriptor should set timestampWrites upon initTimestampQuery, w/o the prop, timestamps will not be capture in query set, demo the issue: https://jsfiddle.net/4zcayfn3/ (time spent identically per render context)

.resolveTimestampAsync() is currently immediate-resolved, results in info fails to catch up the render, it should await info get updated.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	339.51 79.09	339.51 79.09	+0 B +0 B
WebGPU	491 136.35	490.99 136.33	-12 B -15 B
WebGPU Nodes	490.46 136.24	490.45 136.22	-12 B -15 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	465.35 112.14	465.35 112.14	+0 B +0 B
WebGPU	560.3 151.75	560.28 151.74	-12 B -13 B
WebGPU Nodes	516.39 141.54	516.38 141.53	-12 B -13 B

[RenaudRohlinger]

Nice! Actually, on that note, I’m considering reworking the entire logic. The current approach is quite limited and can become unstable, especially when two buffers are allocated per renderContext. Once you exceed 50–100 compute or render programs per frame, many GPUs start to throw errors breaking the app.

Instead, I’m thinking of creating two instances of a new TimestampQueryPool class. Each context would simply append its offsets (beginningOfPassWriteIndex and endOfPassWriteIndex) to the pool. This seems far more stable, allowing to retrieve the full set of timestamp results at once, something like:

const timestamps = await renderer.timestampResolve();
// timestamps is a BigUint64Array
// also updates the Info class internally

This way, we avoid forcing intermediate await calls for each individual render/compute, which currently disrupts the rendering pipeline and hurts performance.

[ycw]

you may need multiple pool-pairs because query set count is max to 4096 ...