641: Add optional SPIR-V shader validation r=kvark a=GabrielMajeri
This PR adds some basic validation for SPIR-V shaders when creating pipelines. Starts work towards #269.
Currently, I'm marking this as a draft because `naga` isn't mature enough to be able to parse shaders from the `wgpu-rs` examples.
For example:
- Trying to run `hello-triangle` from `wgpu-rs` results in the following error:
`Failed to parse shader SPIR-V code: UnsupportedInstruction(Function, Variable)`
- For `hello-compute` it is:
`Failed to parse shader SPIR-V code: UnsupportedInstruction(Type, TypeBool)`
Co-authored-by: Gabriel Majeri <gabriel.majeri6@gmail.com>
272: Force the wasm32 types to match Send / Sync with the native types r=kvark a=kyren
This is potentially a controversial change so this is just a draft to discuss it.
Currently, when building wgpu on wasm32, none of the interface types are Send or Sync, whereas on any other platform they are generally Send and Sync and this can cause a lot of pain, especially in the presence of async.
This PR is the nuclear option: lie and forcibly declare nearly all interface types to be Send or Send + Sync.
I think I understand the situation with proposed wasm32 threading a bit better now, and as of right now at least with my current understanding, it seems to me unlikely that javascript values held by rust could *ever* be sent transparently to another worker. The mechanism that rust apparently will use to implement transparent threading will be to use `SharedArrayBuffer` to share memory between multiple workers. Javascript provides a way for certain (serializable) objects to be shared with with other workers through `worker.postMessage()`, so Javascript has *some* story for sending javascript values to other threads, but only plain rust values that exist solely in the `SharedArrayBuffer` memory are send-able under this scheme. I've looked briefly through some of the wasm proposals like the interface types proposal, but I don't have a good sense if there's any proposed mechanism at all for interface types and threads to interact at all.
If that's true that's really unfortunate because it seems like any thread safe API shared by native and web is doomed to mismatch. This is even more unfortunate because many of the webgpu types in the draft standard are marked as 'Serializable', meaning that they *are* actually safe to send to another worker via `postMessage`, but there does not appear to be a planned way for rust to do this transparently.
I definitely could be misunderstanding the situation though and even if I am understanding it, the situation may have since changed. I also don't know the timing here, I don't know what the eventual timing of wasm32 threading support will be vs webgpu support and interface types support. *Right now* this PR is almost certainly sound, but there's definitely a possible future where it becomes unsound, and even maybe a possible future where it becomes unsound but then could later be made sound again.
Co-authored-by: kyren <kerriganw@gmail.com>
There are several things in this commit:
1) Add `Send` or `Send + Sync` bounds to most of the associated types in `Context`.
2) Force most of the handle types and future types returned by the web backend to be Send / Sync
3) Make `BufferReadMapping` and `BufferWriteMapping` `Send` again on native by
making the associated detail types implement `Send`.
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>
295: Remove wasm-bindgen patches r=grovesNL a=rukai
A new release occurred with the required fixes, so we no longer need to patch it.
Co-authored-by: Rukai <rubickent@gmail.com>
