New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device::create_buffer_init() provides no indication that the buffer is only filled with use of Queue::submit() #5585
Comments
interesting corner case! I believe this should be fixed by either not finishing the read mapping as long as there's data scheduled to be copied to the buffer (which we then document to only be able to finish during a Naturally this isn't specific to the Is this still observable without |
Is this still observable without MAPPABLE_PRIMARY_BUFFERS? It doesn't appear to be -- this code runs with the unexpected behavior without MAPPABLE_PRIMARY_BUFFERS:
I personally would prefer the latter option as well, but I don't use wgpu for the web. I think the underlying problem is that it can be confusing for a utility function from |
Description
Device::create_buffer_init() will not fill the created buffer, instead requiring Queue::submit(), but this isn't reflected in the documentation. This doesn't affect using buffers with gpu because you use Queue::submit() there, but does matter if trying to get data back from buffer immediately.
Repro steps
Expected vs observed behavior
zeros are printed because the buffer wasn't filled.
queue.submit([]) fixes this.
[docs] (https://docs.rs/wgpu/latest/wgpu/struct.Device.html#method.create_buffer_init) says:
This is misleading as the buffer may not be filled.
Platform
I am running Ubuntu 22 on an Inspiron 14.
The text was updated successfully, but these errors were encountered: