WebGPURenderer: Fix "getArrayBufferAsync" to avoid severe GC pressure

[gkjohnson]

Description

When using "getArrayBufferAsync" a new array buffer is always created and returned rather than either allowing the user to provide a buffer to write into, as WebGLRenderer's readRenderTargetPixels functions do (it looks like this has been removed from WebGPU's version, for some reason), or allowing the user to determine when to release the buffer back to the GPU.

If using this read back function frequently this can create a ton of unnecessary GC pressure.

I see that a new GPU buffer is also created every call, which feels unnecessary, and then is subsequently never destroyed, presumably leading to a memory leak.

Solution

1. Add a "target buffer" argument to the getArrayBufferAsync function:

const data = new Uint32Array( storageAttribute.count * storageAttribute.itemSize );
renderer.getArrayBufferAsync( storageAttribute, data.buffer );

2. Provide a new class that allows for managing the mapped data the data back to the GPU when the user is through with it. If the "MappedStoragedBufferData" is not provided when a new instance can be returned:

class MappedStoragedBufferData {
  size: number,
  array: ArrayBuffer,
  release(): void;
  dispose(): void;
}

// ...

const mappedData = new MappedStorageBuffer( storageAttribute.count * storageAttribute.itemSize );
renderer.getArrayBufferAsync( storageAttribute, mappedData );

// ... do something with the data including processing it, copying it...

mappedData.release();
// ...
mappedData.dispose();

Alternatives

None

Additional context

No response

[NssGourav]

Thinking of adding back a targetBuffer param in getArrayBufferAsync / readRenderTargetPixelsAsync so we can copy via .set() from the mapped range instead of slice(0). Will also explicitly destroy() the staging buffer post unmap to avoid the current leak. For frequent readbacks, a MappedStorageBufferData helper should help manage reusable staging buffers cleanly.

[gkjohnson]

Perhaps multiple argument types can be accepted but my strong preference would be for a mechanism like "MappedStorageBufferData" that lets the user manage this so a "set" call isn't automatically and unnecessarily incurred.

User's can easily copy the buffer immediately and unmap the mapped buffer data instance if that's what they need:

// creates a new mapped data instance if not provided
const mappedData = renderer.getArrayBufferAsync( storageAttribute );
myBuffer.set( new Uint32Array( mappedData.array ) );
mappedData.destroy();

[NssGourav]

Yeah, that makes sense. Returning a MappedStorageBufferData feels cleaner since it gives direct access to the mapped range and lets the user decide how/when to read instead of forcing a .set().

I’ll go ahead with this approach and make sure the staging buffers are properly cleaned up in dispose().

[NssGourav]

Hello @gkjohnson, I have implemented the getArrayBufferAsync refactor according to your suggestions. Please take a look at the PR (#33298) and share your reviews.

[gkjohnson]

This issue is not fully addressed

[sunag]

This issue is not fully addressed

@gkjohnson At no point in our conversation did I understand that we were also talking about sharing the GPU buffer; I hope that’s what is missing for your need. #33315