1612: Update `web-sys` r=grovesNL a=a1phyr
`wgpu` uses unstable APIs so the version has to be pinned and manually updated.
No breaking changes happened in `0.3.51` so this update is easy.
Co-authored-by: Benoît du Garreau <bdgdlm@outlook.com>
1607: Fix Downlevel Vertex Stage Storage Buffer Check r=kvark a=cwfitzgerald
**Connections**
Fixes a bug in #1599. Also follows up on #1583 marking all of hello-compute as a failure.
**Testing**
Tests now pass on rpi4.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1604: Upgrade `arrayvec` to 0.7 r=kvark a=a1phyr
Upgrade `arrayvec` to version 0.7 (using const generics).
Co-authored-by: Benoît du Garreau <bdgdlm@outlook.com>
1606: Fix macos build r=cwfitzgerald a=scoopr
Building on macos failed with
```
Compiling wgpu-hal v0.9.0 (/Users/scoopr/Code/ext/wgpu/wgpu-hal)
error[E0609]: no field `entry` on type `&vulkan::Instance`
--> /Users/scoopr/Code/ext/wgpu/wgpu-hal/src/vulkan/instance.rs:267:61
|
267 | let metal_loader = ext::MetalSurface::new(&self.entry, &self.shared.raw);
| ^^^^^ unknown field
|
= note: available fields are: `shared`, `extensions`
error: aborting due to previous error
```
The PR fixes the issue.
Co-authored-by: Mikko Lehtonen <scoopr@iki.fi>
1599: Fix Limits for lava/llvmpipe and re-enable and re-work CI r=kvark,groves,wumpf a=cwfitzgerald
**Connections**
No longer fixes#1551.
**Description**
This PR has a couple things going on at once.
- Fixes limits for llvmpipe, lavapipe, and rpi4.
- Added a downlevel limit to express that RPI4 does not allow storage buffers in vertex shaders on GL.
- Added a `Limits::downlevel_default()` that takes minimum limits from GLES and adds some more documentation on how to choose limits.
- Moved all examples to the new downlevel limits
- Reworks CI to re-enable software testing and unify instructions.
**Testing**
It is
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1600: Vulkan Timeline Semaphores r=kvark a=kvark
**Connections**
None
**Description**
One of the non-straightforward design decisions in wgpu-hal was to expose the fences with `D3D12Fence` semantics. Now that we got Vulkan, Metal, and GLES3, it became a bit concerning that all of these backends implemented this new fence API in the same convoluted way: via managing a pool of binary fences internally, which requires maintenance (done on submit() only). If that's the expected implementation, then the abstraction is wrong.
For this reason, it was important for me to try implementing this new semantics in a modern Vulkan way - via timeline semaphores. With this, we have 1:1 relation between `Api::Fence` and a Vulkan object. I believe the experiment is a success: Vulkan is now very efficient at fences!
**Testing**
Works on the examples!
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
1598: Fix memory leak in acquiring encoders r=kvark a=kvark
**Connections**
Fixes#1501Fixes#1531
**Description**
It was ... interesting. We were creating new command encoders all the time, but still trying to add them to the pool to re-use later. So we were constantly allocating and never freeing them, up until the end. Therefore, program as a whole was valid and non-leaking, if analyzed after termination.
**Testing**
Observed memory manually
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
1597: hal/metal: bump storage limits r=kvark a=kvark
**Connections**
Fixes#1596
**Description**
The limits where just copied from the defaults. Then we updated the defaults...
**Testing**
Just ran locally
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1594: Generation of memory reports for Hubs r=cwfitzgerald a=kvark
**Connections**
Part of #1501
**Description**
Tried to see if we aren't accidentally growing the hubs.
**Testing**
Examples...
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
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>
1592: Detailed limits check and error r=cwfitzgerald a=kvark
**Connections**
Related to #1590
**Description**
The old comparison "A < B" was simply wrong, because it would do every field in order and could bail out mid-way without reaching for all limits.
**Testing**
Untested
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1591: Expose calayer r=kvark a=Sineaggi
**Description**
This pr restores the ability to create a surface from a pre-existing CAMetalLayer. This is required for wgpu-native.
Co-authored-by: Clayton Walker <cwalker@sofi.org>
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>
1587: hal/metal: mark buffer immutability r=kvark a=kvark
**Connections**
This improves Metal performance.
**Description**
Extracting data from Naga to mark some buffers as immutable.
**Testing**
Just ran the examples.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1586: Assorted Fixes of Testing-Infra r=kvark a=cwfitzgerald
**Connections**
Couple of low hanging fruit issues solved here. The biggest thing done is moving the masks to associated functions instead of being members of the bitflags, this is done so `all()` only includes the actual members.
Follows up on 579de425e5 to mark vk/mipmap as passing
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.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>
