wgpu-rs couldn't compile on the Apple M1 (arm64) macs due to a compilation
problem in winit. winit 0.24.0 has the fix so upgrade the dependency.
Link to the fix's pull request in winit:
https://github.com/rust-windowing/winit/pull/1752
685: Replace futures crate with pollster. r=grovesNL a=parasyte
This PR removes all of the `futures` dependencies. `std::future` does not contain a lot of useful helpers available in `futures`. The obvious ones are `join_all`, `FutureExt::map`, and `block_on`.
- `join_all` is replaced with a `Vec<T>` and an `async` block.
- `FuturesExt::map` in the web backend is replaced by rolling the `map` function into the `MakeSendFuture` type.
- `block_on` is provided by `pollster`.
The original code using `join_all` ignored the result type yielded by the Future from `map_async`. This code does the same, but makes dropping the result a little more obvious.
These should not be troublesome. Figured I would call them out anyway.
The last big change is replacing `futures-executor` in the examples with `async-executor`. A new concrete `Spawner` type is used in the example framework instead of an implementation of `futures_task::LocalSpawn`.
Fixes#628
Co-authored-by: Jay Oster <jay@kodewerx.org>
This PR removes all of the `futures` dependencies. `std::future` does not contain a lot of useful helpers available in futures. The obvious ones are `join_all`, `FutureExt::map`, and `block_on`.
* `join_all` is replaced with a `Vec<T>` and async blocks.
* `FuturesExt::map` in the web backend is replaced by rolling the `map` function into the `MakeSendFuture` type.
* `block_on` is provided by `pollster`.
The original code using `join_all` ignored the result type yielded by the Future from `map_async`. This code does the same, but makes dropping the result a little more obvious.
These should not be troublesome. Figured I would call them out anyway.
The last big change is replacing `futures-executor` in the examples with `async-executor`. A new concrete `Spawner` type is used in the example framework instead of an implementation of `futures_task::LocalSpawn`.
1112: Expose adapter specific formats features via Extension, support for storage read+write r=kvark a=Wumpf
**Connections**
Draft until https://github.com/gfx-rs/gfx/pull/3559 landed (then update and comment two lines in)
New & improved replacement for #1109
PR for wgpu-rs to be opened once there's some confidence that this is that it should look like. [Preview](https://github.com/gfx-rs/wgpu-rs/compare/master...Wumpf:texture-format-feature-query?expand=1)
**Description**
Adapter exposes now per texture format specific features. Feature struct defined as allowed usages + flags. Flags describe only storage texture usage so far.
Query not used for validation unless `TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES` feature is enabled on a device. Otherwise uses hardcoded feature set guaranteed by webgpu.
Storage read/write binding can then be used as a consequence (storage atomic has no effect yet).
**Testing**
Manual testing with my fluid sim project through wgpu-rs which covers storage r/w for a few different formats and storage in general for formats that don't support this usage by default at all.
Ran tests and a couple of samples to see if anything broke with the feature disabled.
Co-authored-by: Andreas Reich <r_andreas2@web.de>
1134: Never prefer CPU devices over GPUs r=kvark a=myfreeweb
**Connections**
Rebase of #969 onto master
**Description**
See #969
Co-authored-by: Greg V <greg@unrelenting.technology>
699: Fixed inconsistent framerate in examples. r=kvark a=Wumpf
Does not affect web builds.
Previously, framerate would float between 30-40 fps depending on how many events would come in. Fast mouse movements over the window lead to higher framerates since request_redraw was called every 20ms (-> 50fps) AND all events were consumed, additionally the event loop would wake up only every 10ms, so actual rate of request_redraw depended on how often we'd wake up.
Fixed this by setting the max sleep time of the event loop to the remaining time until hitting the desired time interval since the last frame.
Co-authored-by: Andreas Reich <r_andreas2@web.de>
Does not affect web builds.
Previously, framerate would float between 30-40 fps depending on how many events would come in. Fast mouse movements over the window lead to higher framerates since request_redraw was called every 20ms (-> 50fps) AND all events were consumed, additionally the event loop would wake up only every 10ms, so actual rate of request_redraw depended on how often we'd wake up.
Fixed this by setting the max sleep time of the event loop to the remaining time until hitting the desired time interval since the last frame.
The difference is most visible on the spinning cubes in the shadow example since the cubes currently spin with a fixed angle per frame (independent of frame timings).
697: Remove wgpu-subscriber -> subscriber alias in examples r=kvark a=manugildev
Fixes#686
> All examples should be able to be copied into their own project and missing crates filled in based on errors alone.
Co-authored-by: Manuel Gil <manugildev@gmail.com>
1127: Fix API traced dynamic offsets and markers r=critical a=kvark
**Connections**
This was a regression from #1106, discovered while investigating #1123
**Description**
When running a pass, it was mutably used for "convenience". Once we moved the tracing of that pass from the beginning of the function to the end, the "convenience" eliminated our dynamic offsets and markers.
The solution is to stop mutating the passes inside our big functions.
**Testing**
Re-traced Terra
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
1126: Check swapchain frame to still be in use r=harmless a=kvark
**Connections**
Fixes#1123
**Description**
What happened there is - the same command buffer was used to record work into multiple swapchain frames.
The ID management of those is a bit special, so the error wasn't very descriptive, internal logic caught inconsistency.
Now there is a proper error, and the old error is better.
Note that ideally we'd want "present" to work like "destroy" on textures, but essentially the users would have to fix it anyway. It's not going to make their life easier (in fact - only harder), so we can defer this to a follow-up.
**Testing**
Tested on wgpu-rs examples as well as on Terra.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
1125: Fix UB in populating dynamic offsets r=kvark a=kvark
**Connections**
Related to the traces in #1123
**Description**
The dynamic offsets arrays appear to be empty in the traces, which makes no sense. We are populating them unconditionally, and I double-checked on the `shadow` example that the traces we record contain the offsets. So my only guess is that the reported traces are taken from a release build, and our code that does `slice::from_raw_parts()` on the offsets is UB because the pointer can be garbage (if length is 0). This is what the PR fixes.
**Testing**
Untested
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
1124: Fix range tracker merging r=kvark a=kvark
**Connections**
Fixes#1123
**Description**
The merge routine was not properly updating the end pointer in some branches.
**Testing**
A unit test is added with the data extracted from the user case.
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
1121: Implement render bundle freeing r=straightforward a=kvark
**Connections**
Fixes#1120
**Description**
Since render bundles were added the relevant bits of logic to free them were just missing.
**Testing**
Untested
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1119: Lock device tracker after the resources r=kvark a=kvark
**Connections**
Fixes #1118
**Description**
Added a comment above `struct Device` explaining the problem and constraints.
We may have a few other cases that need to be handled gracefully by the type system.
For this fix we at least ensure that the device tracker is always locked temporarily.
**Testing**
Untested.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1115: Request buffer FAST_DEVICE_ACCESS only with some non MAP or COPY usage r=kvark a=fintelia
**Connections**
Fixes#1113
**Description**
On Linux AMD (and likely elsewhere) buffers with FAST_DEVICE_ACCESS are very slow to access when mapped. This makes sure that upload/download buffers don't request it unless those buffers are leveraging MAPPABLE_PRIMARY_BUFFERS for some non-map/copy usage.
**Testing**
I reran the failing reproduction case in the linked issue.
Co-authored-by: Jonathan Behrens <fintelia@gmail.com>
1117: Free associated staging buffers r=cwfitzgerald a=kvark
**Connections**
Reported on the Matrix. Having a loop that creates mapped buffers and drops them results in OOM.
**Description**
We are now checking for the map state when destroying buffers.
**Testing**
Ran through an ad-hoc example.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1114: Fixed error message for BindingTypeMaxCountError r=cwfitzgerald a=Wumpf
Previously, `BindingTypeMaxCountError` would incorrectly report the binding count as the violated limit. Now it reports both the limit and the count that violated it.
Example error message before:
```
wgpu error: Validation Error
Caused by:
In Device::create_bind_group_layout
note: label = `BindGroupLayout write scalar`
too many bindings of type StorageTextures in stage COMPUTE, limit is 5
```
Example error message after:
```
wgpu error: Validation Error
Caused by:
In Device::create_bind_group_layout
note: label = `BindGroupLayout write scalar`
too many bindings of type StorageTextures in stage COMPUTE, limit is 4, count was 5
```
Co-authored-by: Andreas Reich <r_andreas2@web.de>
690: Add `RenderEncoder` r=kvark a=0x182d4454fb211940
It seems like `RenderPass` and `RenderBundleEncoder` share many methods in common (`set_pipeline`, `draw_indexed`, etc). By creating a shared trait, it allows more reusable code. For instance:
```rust
impl RedCircle {
fn new(...) -> Self { .. }
fn draw<'a>(&'a self, encoder: &mut impl RenderEncoder<'a>) { .. }
}
```
This code would then work for both structs.
Moving the previous methods from their `impl`s to the trait's would break previous code, as to use these methods code would now have to import `RenderEncoder`. To avoid this, it is implemented by calling the direct methods.
It may be worth considering moving this to `wgpu::util`.
Co-authored-by: 0x182d4454fb211940 <nathanwoodformal@gmail.com>
1106: Encode render passes while command buffer is only read-locked r=cwfitzgerald a=kvark
**Connections**
Could fix#1104 to some extent
**Description**
The heaviest part of the render pass encoding doesn't need a write lock. Only in the end we need it.
**Testing**
Untested.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
