Not sure I understand that difficulty/guessing. You maintain a pool of staging buffers that are mapped, and once you use any of them, you request it for mapping again, and in the promise you bring it back into the pool. There shouldn't be any guesswork here.

And if you ever run out of space you can instantly create an additional mapped chunk using mappedAtCreation. That one chunk will be potentially less efficient the first time it is used, but follow-up mapping will be as efficient as the other chunks in your staging belt.

It's a bit old but there is a sketch of this idea here: https://github.com/gpuweb/gpuweb/blob/main/design/BufferOperations.md#updating-data-to-an-existing-buffer-like-webgls-buffersubdata

Chrome is not using WGPUFuture yet, but also we have a latency problem in Chrome that won't be immediately fixed by them.

I am surprised by the speed of mapAsync though! I thought just a plain dumb round trip took almost 1ms in chrome - but I guess that was a GL problem.

It did not create a new buffer every frame

Me too for ring buffer variant.

Looks like its a problem of current wgpu-rs implementation, will try dawn, thank you for this example. My point is that its strange api decision which leads to this kind of problems. API should fit user needs, not implementations. I cant imagine that someone will say "I need to map buffer memory". All you need is: write, write chunks, read, read chunks (chunks - I mean some kind of streaming). (reads and writes may be async)

Yep, after 6 hours of fighting with google's implementation, dawn's mapAsync is 300x times faster. But I still dont understand why I should do mapping, polling and all other stuff instead of just read* call (or 3 calls like begin_read, read, read_end).

@greggman

mapping, polling and all other stuff instead of just read* cal

requesting a mapping and then waiting for the map to happen is because the buffer might be in use and you need to wait for it to finish being used. polling should not happen and I think that's the point of the WGPUFuture thing that's being worked on: webgpu-native/webgpu-headers#199 I don't know if that will actually make your code any simpler. I think the point of map is that if you want efficient code, you should ask for the buffer to be mapped, then go do other stuff since the GPU might still be busy with the buffer.

I'm not sure I follow your suggestion of begin_read, read, read_end. I guess you want begin_read to halt the CPU and wait for the GPU (which is what your polling is currently doing).

It sounds like maybe you want mapSync? (which is being discussed here: #2217)

Year 2025, M1 Max, Metal backend, dawn native: Around 500us to map 256 bytes (not that the size of the buffer matters). Note that if I don't map/unmap and instead just ignore, the 500us disappears. This isn't a case of "the gpu is still using it", it's just plain slow.

Disregard my comments. This is just noise because I am learning. The map/unmap is definitely slow but maybe I am misusing it. It's also possible that it is due to security concerns that the API is built that way.