Code panics when setting up a bind group

[scott-wilson]

I'm very new to doing GPU programming, so there could be something that I'm doing that is obviously wrong.

But, a quick setup. I'm creating an add-on in Blender using Rust and WGPU to calculate rig weight assignments by treating the rig's bones as heaters and heating a voxel grid. This works when I do everything on the CPU, but I want to see if I can get better performance on the GPU (I believe the answer is yes, and I want to learn GPU computing so I see this as a win-win).

I'm getting a panic when I try to bind the textures to a bind group. More information (including code snippet) here: https://gist.github.com/scott-wilson/a2407f9c828ef7ce32562e7852e6a217

I'd appreciate any help I can get on this.

[cwfitzgerald]

Could you post the error you're getting?

[scott-wilson]

Thanks for replying back. I've managed to get further along, but I'm stuck on a new issue (code is updated in the gist) The trace is:

thread '<unnamed>' panicked at 'Error in Queue::submit: Validation Error

Caused by:
    Buffer (0, 1, Vulkan) is still mapped
', /home/scott/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.17.1/src/backend/direct.rs:2289:30
stack backtrace:
   0: rust_begin_unwind
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:67:14
   2: wgpu::backend::direct::Context::handle_error_fatal
   3: <T as wgpu::context::DynContext>::queue_submit
   4: wgpu::Queue::submit
   5: tokio::runtime::park::CachedParkThread::block_on
   6: tokio::runtime::context::runtime::enter_runtime
   7: tokio::runtime::runtime::Runtime::block_on
   8: rig_weight_impl::run
   9: rig_weight_impl::_::<impl rig_weight_impl::run::MakeDef>::DEF::trampoline
  10: <unknown>
  11: _PyObject_MakeTpCall
  12: _PyEval_EvalFrameDefault
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  27: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
  28: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[cwfitzgerald]

https://gist.github.com/scott-wilson/a2407f9c828ef7ce32562e7852e6a217#file-lib-rs-L191 you mark the buffer as mapped immediately, but never unmap it before submitting work using it.

[scott-wilson]

So, if I get the process right:

1. encoder.copy_texture_to_buffer(...)
2. buffer.unmap()
3. Submit queue

I thought that unmapping the buffer would clear the buffer before it is sent to the CPU. I assume that I could think of unmapping the buffer as "close the buffer from writing to in the GPU to be read from in the CPU"?

[cwfitzgerald]

I don't think you need to map that buffer at creation at all. It's recieving data.

I thought that unmapping the buffer would clear the buffer before it is sent to the CPU. I assume that I could think of unmapping the buffer as "close the buffer from writing to in the GPU to be read from in the CPU"?

You've got it flipped. Mapping allows cpu access of a buffer, by saying "allow me access once the GPU is done". The unmap operation is handing the ownership back to the GPU. Mapping does not modify the contents of the buffer at all, outside of what you explicitly change on the CPU while it's mapped.

[scott-wilson]

That seems to do the trick. Thanks!