Hi, I'm new to gpu programming, started learning GPGPU programming using Rust + wgpu recently. I was going through the wgpu repo and have a question

The map_async api lets us map a gpu-allocated buffer so that it can be accessed by the CPU. How does this actually work?

I was able to put-together the following with my limited understanding of wgpu.

• a call to map_async adds the buffer to LifetimeTracker's mapped field (I presume there's only one of lifetimetracker per wgpu app).
• when a call to device.poll is made (usually from another thread), we check to see if the gpu is finished with buffer (i.e. if the index of queue submission that uses the buffer has finished ) and if it is, we move the buffer (or its id) to read_to_map field and from this point on, the CPU is free to work on the buffer.

Is the above correct? If yes, would I also be right to say - mapping host buffers in wgpu does not involve adding any commands to the GPU command queue.

Hi, I'm new to gpu programming, started learning GPGPU programming using Rust + wgpu recently. I was going through the wgpu repo and have a question

The map_async api lets us map a gpu-allocated buffer so that it can be accessed by the CPU. How does this actually work?

I was able to put-together the following with my limited understanding of wgpu.

• a call to map_async adds the buffer to LifetimeTracker's mapped field (I presume there's only one lifetimetracker instance per wgpu app).
• when a call to device.poll is made (usually from another thread), we check to see if the gpu is finished with buffer (i.e. if the index of queue submission that uses the buffer has finished ) and if it is, we move the buffer (or its id) to read_to_map field and from this point on, the CPU is free to work on the buffer.

Is the above correct? If yes, would I also be right to say - mapping host buffers in wgpu does not involve adding any commands to the GPU command queue.

Hi, I'm new to gpu programming, started learning GPGPU programming using Rust + wgpu recently. I was going through the wgpu repo and have a question

The map_async api lets us map a gpu-allocated buffer so that it can be accessed by the CPU. How does this actually work?

I was able to put-together the following with my limited understanding of wgpu.

• a call to map_async adds the buffer to LifetimeTracker's mapped field (I presume there's only one lifetimetracker instance per wgpu app).
• when a call to device.poll is made (usually from another thread), we check to see if the gpu is finished with buffer (i.e. if the index of queue submission that uses the buffer has finished ) and if it is, we move the buffer (or its id) to the ready_to_map field and from this point on, the CPU is free to work on the buffer.

Is the above correct? If yes, would I also be right to say - mapping host buffers in wgpu does not involve adding any commands to the GPU command queue.

In reply to @jasperrlz:matrix.org
If a buffer can be mapped by the CPU, it's probably allocated on the CPU side, it's just that the GPU also has the ability to read/write from it across the PCIe bus

In reply to @codetoilet:matrix.org
but there is a webgpu best practices site I like to look at too, and some examples of more complicated things on GitHub too

In reply to @i509vcb:matrix.org
I know there is a downlevel flag for compute. What else was gles 3.0 using again that meant we couldn't use gles 2.0 in wgpu?