645: Add a loom test for RefCount r=kvark a=paulkernfeld
A first effort at gfx-rs/wgpu-rs#96
loom testing is gated behind cfg(loom)
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
649: Proper maintenance of the command pools r=cart a=kvark
Fixes#648
This brings the memory consumption on the multi-threaded cube to constant 50Mb.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
351: Optionally support XCB windows on Unix r=kvark a=antonok-edm
`gfx-hal` supports XCB windows on Unix platforms, but it can't be used through `wgpu`. I added a new `xcb` feature to enable that support. `x11` support is now enabled using a default feature to remain backwards compatible.
Co-authored-by: Anton Lazarev <antonok35@gmail.com>
637: Wait for idle before destroying swapchains r=kvark a=kvark
Follow up to #636
I was trying to address the D3D12 error in https://github.com/gfx-rs/gfx/issues/3242
The debug messages complain about a resource being used by the queue while it's being destroyed. I thought forcing a wait there would help, but it does not. I think it's still a good change to land though.
In the meantime, I wonder if it considers the swapchain to be used because it's currently presented. Could be something else I'm missing here.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
636: Properly destroy swap chains r=kvark a=kvark
This is the last piece of the cleanup puzzle, I think, as closing an example becomes fully validation-free 🎉
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
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>
