How to properly read back data to the CPU?

[geri1245]

Hi!

I am trying to read back some data from the GPU to the CPU. What I am trying to do is giving each object a unique ID and render that to a texture, so I can tell which object the mouse is hovering over. Rendering into the texture is working well, now I just have to get the data from the texture.

Seems like the way to read back data is using BufferSlice::map_async, but I don't understand exactly what is expected from the user. As I have seen the general usecase is that I call map_async with a callback that sets a flag, then call device.poll(...), then get_mapped_range() and after reading back the data, I should drop the mapped buffer (what is returned by 1get_mapped_range()) and then unmap the buffer. This all works, my goal is to avoid blocking the GPU, so no device.poll()`. To understand my options here, I would like to ask a few clarifying questions:

• Can I call buffer.slice(..).map_async() and then buffer.slice(..).get_mapped_range() or do I have to call these 2 methods on the same BufferSlice instance? Seems to be working on 2 different slices created from the same buffer, just want to make sure.
• In the documentation of map_async, queue.submit is also mentioned as a call that can complete the callback passed to map_async. However if I want to let my standard render loop's queue.submit (that I call every frame) complete the callback, then I get a validation error in one of the next frames stating that Buffer Id(392,1,d3d12) is still mapped. Is there a restriction about when a mapped or being mapped buffer must be unmapped? Does it need to be unmapped before the next queue.submit?
• To avoid the buffer is still mapped... issue, I tried checking the buffer mapping just before calling queue.submit each frame (I call this exactly once per frame). I tried device.poll(Poll), as that's said to not block, however, my frame rate seems to be tanking the same way when I call it with Wait. What exactly does device.poll() do? Does it simply check if everything has been submitted to the GPU that we put into the queue on the CPU side by that point?
• What's the fastest and correct way to do this? (I guess that would mean completely without blocking)

[kpreid]

However if I want to let my standard render loop's queue.submit (that I call every frame) complete the callback, then I get a validation error in one of the next frames stating that Buffer Id(392,1,d3d12) is still mapped. Is there a restriction about when a mapped or being mapped buffer must be unmapped? Does it need to be unmapped before the next queue.submit?

It sounds like you're trying to have a single buffer alternate between being written by the GPU and read by the CPU. This is not a practical solution — if you do it successfully, your frame rate will be terrible because of all the required waiting. Instead, have two buffers (“double buffering”) such that at most one of them is mapped at a time. That way, the CPU can be reading from the mapped buffer while the GPU writes to the unmapped buffer. Then, swap the roles of the two buffers while neither one is mapped.

[geri1245]

Thanks for the suggestion! Right now, I am creating a buffer each frame, as I didn't know how many frames it takes for me to be able to read back the data. Planning to use a ringbuffer later. But as of right now every buffer is used once: create buffer -> queue copy_texture_to_buffer -> map_async -> poll/submit/...? -> get the data -> unmap -> forget.
I am not sure what the relation between the queue.submits, the map_async calls and the unmaps is expected to be.

[BGR360]

I think your order is a bit wrong. It should be:

1. create buffer
2. queue copy_texture_to_buffer
3. submit
4. map_async
5. poll or wait for callback
6. get_mapped_range to read the data
7. drop all BufferViews
8. unmap

Take a look at usages of map_async in the wgpu examples.

This blurb from the docs should clarify why what you're currently doing isn't quite right:

While a buffer is mapped, you may not submit any commands to the GPU that access it. You may record command buffers that use the buffer, but if you submit them while the buffer is mapped, submission will panic.

When you call map_async before calling submit, you might have your callback called right away because the buffer is not in use by the GPU. Once you submit the work to copy data into the buffer on the GPU side, that's when you ask wgpu to tell you when the GPU is done copying (by calling map_async).

[geri1245]

That makes sense, thank you for your help!