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>
1578: Fix destruction of resources r=kvark a=kvark
**Connections**
Fixes#1552
Also fixes the VVL about swapchain frame destruction.
**Description**
Swapchain view was never registered in the device's root Hub. So the old logic of adding it to "suspected resources" didn't fire up correctly. The new logic goes straight into the submission tracker.
This path will cease to exist when either Hubs are removed, or API changes of https://github.com/webgpu-native/webgpu-headers/issues/89 are accepted.
The other resource destruction errors happened because we gathered all the resources that were abandoned by the user, and held alive only by the submitted command buffers, and we added them to the suspected list. Then we'd scan the list in `maintain`, see that they can be removed, and try to associate their destruction with one of the submissions. But the current submission was not added yet! So the logic thinks it can just remove the resources right away in this case, assuming the submission is not found because it's long gone in past.
**Testing**
Tested on our examples.
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
