791: Unify `wgpu-core` and `wgpu-rs` types r=kvark a=GabrielMajeri
**Connections**
Closes#689.
**Description**
Moves a lot of types from `wgpu-rs` which were duplicated in `wgpu-core` to `wgpu-types`.
**Testing**
Checked with core, player and `wgpu-rs`.
Corresponding `wgpu-rs` PR: https://github.com/gfx-rs/wgpu-rs/pull/437
Co-authored-by: Gabriel Majeri <gabriel.majeri6@gmail.com>
790: core: make DeviceType repr(u8) r=kvark a=DavidPeicho
**Connections**
This PR will make gfx-rs/wgpu-native#43 mergeable.
**Description**
`DeviceType` wasn't made to be used in FFI. The enum is now set to `#[repr(u8)]`.
**Testing**
It's not tested 💯
Co-authored-by: David Peicho <david.peicho@gmail.com>
754: Implement MultiDrawIndirect Extensions r=kvark a=cwfitzgerald
**Connections**
Closes#742.
**Description**
These extensions, especially when combined with binding indexing, allow the creation of extremely cpu-efficient gpu powered pipelines.
Adds two extensions allowing various types of multi-draw-indirect
- MULTI_DRAW_INDIRECT (giving `multi_draw_indirect` and `multi_draw_indexed_indirect`)
- MULTI_DRAW_INDIRECT_COUNT (giving `multi_draw_indirect_count` and `multi_draw_indexed_indirect_count`)
This adds what I believe to be an extra restriction on the `*count` family of functions when compared to the underlying api. The buffer _must_ be large enough to draw `max_count` draws, even if that many draws are never drawn. This makes these operations no more unsafe than indirect would be, which is currently safe.
I did not implement these for renderbundles, but there's no reason they couldn't work, so those branches are marked with `unimplemented` as opposed to `unreachable`.
Additional Changes:
- Added some validation to the normal `draw_*_indirect` functions to prevent buffer overruns.
- The DX12 gfx-hal backend requires the strides to _always_ be non-zero, so I modified the normal indirect draws to use explicit strides.
- Made device limits and features `pub(crate)` as they need to be checked in random places in the code.
**Testing**
The change was tested using a modified version of wgpu-rs's texture-array example using a variety of permutations. I have not been able to test regular MULTI_DRAW_INDIRECT on mac, but I see no reason why that wouldn't work.
https://github.com/gfx-rs/wgpu-rs/pull/414
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
704: Pipeline layout validation r=cwfitzgerald a=kvark
**Connections**
Implements a solid part of #269
Starts converting the function to return results, related to #638
cc @GabrielMajeri
**Description**
This change matches shader bindings against the pipeline layout. It's *mostly* complete, minus some bugs and not handling the `storage_texture_format` properly.
The risk here is that Naga reflection may have bugs, or our validation may have bugs, and we don't want to break the user content while this is in flux. So the PR introduces an internal `WGPU_SHADER_VALIDATION` environment variable. Switching it to "0" skips Naga shader parsing completely and allows the users to unsafely use the API.
Another aspect of the PR is that some of the functions now return `Result`. The way I see us proceeding is that any errors that we don't expect users to handle should result in panics when `wgpu` is used natively (i.e. not from a browser). These panics would happen in the "direct" backend of wgpu-rs (as well as in wgpu-native), but the `Result` would not be exposed to wgpu-rs, so that it matches the Web behavior.
At the same time, browser implementations (Gecko and Servo) will check the result on their GPU process and implement the WebGPU error model accordingly. This means `wgpu-core` can be super Rusty and safe.
**Testing**
Running on wgpu-rs examples. Most of them fail to get parsed by Naga, but `boids` succeeds and passes validation 🎉
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
