1593: Fix VVL on halmark example r=kvark a=kvark
**Connections**
We have a bunch of VVL related to resource destruction on the halmark example.
It also seems to leak memory quite a ton and eventually hang the system.
**Description**
This PR fixes the logic of changing the command pools in halmark, its initialization sequence, and its destruction.
**Testing**
Tested on halmark and others
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1585: hal/egl fix support for context extensions r=cwfitzgerald a=kvark
**Connections**
Follow-up to #1584
Closes #1577
**Description**
TIL that EGL extensions work differently from the EGL-1.5 stuff, and we are now treating them properly.
**Testing**
Basic testing on AMD
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1584: Update testing limits for rpi4 r=kvark a=cwfitzgerald
**Connections**
Related to #1574. Exposed #1583.
**Description**
Changes the reftesting limits to be tolerant of how the RPI4 renders. Fixes the debug half of #1577.
Fixes some naming issues as well.
**Testing**
It is
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
DYNAMIC_INDEXING is checked by default, since WGPU doesn't allow
for any kind of specialization constants and constant indexing is
nigh useless.
STORAGE_RESOURCE_BINDING_ARRAY is enabled iff the device supports:
- both or neither of uniform and buffer arrays with dynamic indexing;
- both or neither of sampled and storage images with dynamic indexing.
NONUNIFORM_INDEXING is enabled iff for ALL types of descriptor arrays
*that are supported for dynamic indexing*, nonuniform indexing is
also allowed.
These flags have a limitation in that some platforms
(eg.
https://vulkan.gpuinfo.org/displayreport.php?id=11692#features_core_12)
may support a strange subset of those features (example device
supporting non-uniform indexing for textures and storage buffers,
but NOT for storage textures or uniform buffers). In that case feature
will be reported as missing, even though it is partially present.
In the author's opinion, this flag set is convenient for the
users to query; however, due to aforementioned limitations, it would be
desirable to obtain statistics about "edge-case" platforms and what
percentage of reports they comprise.
1559: Query support fixes r=kvark a=Wumpf
**Connections**
Fixes#1374 for master
If PR is accepted,I already have a fix for 0.9 which came out as a sideproduct: https://github.com/Wumpf/wgpu/tree/v0.9-fix-buffer-init-on-query-resolve
**Description**
Fixes:
* (affects master, v0.8, v0.9) query resolve operation not marking buffers as initialized
* (affects master) Broken query stride handling for Vulkan
* (affects master) Vulkan not advertising query support
**Testing**
* added new test
* mipmap sample
Co-authored-by: Andreas Reich <r_andreas2@web.de>
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>
