1525: Add Naga bypass to allow feeding raw SPIR-V shader data to the backend. r=kvark a=ElectronicRU
**Connections**
Fixes#1520 .
**Description**
While Naga checking is undoubtedly very useful, it currently lags behind
what is possible in SPIR-V and even what is promised by WGPU (ie binding
arrays). This adds an unsafe method to wgpu::Device to allow feeding
raw SPIR-V data into the backend, and adds a feature flag to request a
backend supporting this operation.
**Testing**
`texture_arrays` example is runnable now, which uncovers an additional bug in Vulkan backend - binding arrays are instead treated like sole bindings, and indices shift, too. Lots of errors from validation layer ensue.
Co-authored-by: Alex S <alex0player@gmail.com>
- Remove Cow from wgpu-hal API surface. You graze on in our hearts.
- Rename feature flag to SPIRV_SHADER_PASSTHROUGH in anticipation
of crate feature `spirv` to reduce confusion.
- Add some more documentation about behaviour and intended avenues of
use to the feature.
1527: Fix wgpu-hal incorrectly ignoring arrays of bindings. r=kvark a=ElectronicRU
**Connections**
Fixes#1526.
**Description**
Even though binding sizes could potentially be derived from resource array lengths and binding indices, current implementation
flat out ignored that. Metal did a more sensible (?) thing and bound only the first resource in each array, Vulkan did a less
sensible thing and bound as many resources as there are bindings, obtaining them from unwrapped arrays.
(IE on Vulkan, if you bound two arrays, [view1, view2] and [view3, view4], it would actually bind [view1, <invalid>] and [view2, <invalid>]).
This aims to fix the issue.
**Testing**
After #1525 is merged, `cargo run --example texture-arrays` would be working as intended for Vulkan. Unfortunately, I can think of no easy way to test this on Metal - the shader support isn't there yet.
Co-authored-by: Alex S <alex0player@gmail.com>
- rename ShaderInput variants
- rename feature flag
- hard error on Metal backend trying to compile SPIR-V
- fix test failing because of feature flag bits changing
Potentially needs more testing - Metal's binding model is quite
different from Vulkan and WGPU, but as far as I understand from the
documentation, arrays of textures occupy a contiguous range of binding
slots, so unwrapping and binding one-by-one should be fine.
Someone should actually go and test this on a Mac, maybe.
While Naga checking is undoubtedly very useful, it currently lags behind
what is possible in SPIR-V and even what is promised by WGPU (ie binding
arrays). This adds an unsafe method to wgpu::Device to allow feeding
raw SPIR-V data into the backend, and adds a feature flag to request a
backend supporting this operation.
1521: Better compile error for not using resolver=2. r=kvark a=ElectronicRU
**Connections**
Usability fix proposed in #1517 with some re-wording to make the intent clearer.
**Description**
Provide a useful compile error in case a downstream project is using old Cargo resolver, instead of the deluge of obscure errors they get r/n if not on MacOS.
**Limitations**
On MacOS, vulkan feature is totally valid, so we cannot detect resolver=1 on Mac.
Co-authored-by: Alex S <alex0player@gmail.com>
1511: Added storage texture array support. r=kvark a=ElectronicRU
**Description**
Arrays of storage images (*f*image*n*D in GLSL parlance) should now be supported.
I also took the liberty to refactor texture format checking a bit,
and tighten up sampled texture support detection for Metal as well.
**Testing**
Not completely sure what's the proper testing approach here, open to suggestions.
Co-authored-by: Alex S <alex0player@gmail.com>
