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>
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>
