634: Make assertions more verbose in src/command r=kvark a=paulkernfeld
This contributes to #485
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
615: Use General allocator at all times for now r=grovesNL a=kvark
In all user-managed resources, we don't have control of the lifetime. Since we don't know when it's released, we can't use any more specific allocator kind than `General`.
Previously, we assumed that buffers created for MAP_READ+COPY_SRC, for example, were one-time buffers created to copy data. However, there appear to be cases where they were used to fill data in once, and then persistently used as a copy source destination.
In the future, one WebGPU data transfer story is settled, we'll be able to use `Linear` kind again for all internally managed uploads. I.e. writeBuffer, writeTexture, and createBuffeMappedOnlyAtStart.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
596: Remove wgpu-native and wgpu-remote r=grovesNL a=kvark
Closes#587
I'm still not sure if it's a good idea. Feedback is welcome!
For instance, even after we remove these two things, the repo will still contain a bunch of logic that Gecko wouldn't necessarily be interested in, such as the surface/swapchains logic.
It's also not clear to me how to properly organize the workflow with the wgpu-native being separate (btw, it's https://github.com/gfx-rs/wgpu-native). Do we still have the workspace here? Or do we just introduce a separate repo that will include all the stuff as sub-modules and have a single workspace?
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
598: Enable READ access for texture storage r=kvark a=kvark
This is a short-term workaround until we properly implement #597
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
591: Warn when binding a buffer that is still mapped r=kvark a=almarklein
Fixes#510
I'd like to make more contributions wrt validation. Though I'm quite new to Rust, so let's start small :)
From the discussion in #510 I concluded that in this case the buffer has actually been dropped, does the error message make sense like this?
Do the messages logged with `log::warn`, end up in the same logging system as the layer validation messages? So a solution to get those messages into Python (for wgpu-py) would work for both kinds of validation messages?
Co-authored-by: Almar Klein <almar.klein@gmail.com>
595: Derive swapchain layout off the load operation r=kvark a=kvark
Fixes https://github.com/gfx-rs/wgpu-rs/issues/258
It's fairly simple. We expect there to be exactly one `LoadOp::Clear` for the swapchain attachment, and for it to be the first pass in a frame using it. Any other passes need to do `LoadOp::Load`.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
