Wgpu: Overflow panic when creating a buffer of size 0

[rukai]

Creating a buffer of size 0 with create_buffer_mapped causes the following panic:

thread '<unnamed>' panicked at 'attempt to subtract with overflow', /home/rubic/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/993293f/wgpu-native/src/device.rs:527:21

I don't know if it should panic here, but it should at least have a better panic message.

Happy to make a PR for a better message if that's the correct solution.

[kvark]

Thanks for filing the bug! I think, regardless of which way the spec is going to define it (at some later point), we should just handle that internally (by fixing the rounding code). PR would be appreciated!

[rukai]

This is not trivial (at least for me)

Vulkan can not have a buffer of size 0 https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkBufferCreateInfo.html

So I guess create_buffer_mapped needs to set the size to 1 when it is 0.
But then when you call fill_from_slice it fails because the slice is smaller than the buffer.
How far should these hacks go?
Also the rust interface would then handle a case that the C interface doesnt?

[kvark]

We don't know what C interface needs to handle yet, because this edge case wasn't discussed by the working group.
I think there is a bit of value in supporting sizes of 0 transparently to the user. All we'd (ideally) need is to have a single place in code that decides to allocate 1 byte for such a buffer instead of 0. This way, all the operations we do with buffers at higher level should work as usual, including mapping.

[cloudhead]

I think there is a bit of value in supporting sizes of 0 transparently to the user.

Isn't that hiding a potential user error? Can't we call assert in create_buffer_mapped instead?

[vitvakatu]

The typical use-case can look like this:

let buffer = create_buffer_mapped(my_objects.len(), ...);
// later
for object in &my_objects {
    do_something_with_buffer();
}

So creating buffer with size 0 should be possible.