This pretty trivial change unfortunately required a loop to mutably borrow both
builder and manager at the same time, so I had to separate them. Perhaps a
cleaner solution would be to use an object with internal state instead of free
functions.
1008: Add helpers to convert passes to serialized forms r=grovesNL a=kvark
**Connections**
Stuff I needed to fix in the upcoming Gecko WebGPU update.
**Description**
It allows us to use the tracing `Command` more aggressively.
**Testing**
Tested in Gecko, doesn't need testing in wgpu
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1007: Improve cubemap validation r=kvark a=cwfitzgerald
**Connections**
Closes#952.
**Description**
We were missing depth-size and texture dimension validation when creating Cubemap and CubemapArray views.
I split the depth-size errors so I can give a more helpful error message in both cases.
**Testing**
Tested on the skybox example when made intensionally incorrect.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1000: Elide redundant set_pipeline calls. r=kvark a=Kimundi
**Description**
This adds an check in each `set_pipeline()` call for wether the same pipeline id has already been set previously. This should cause free performance wins for suboptimal usage of the wgpu API, while having neglible overhead otherwise.
An example scenario for where this would be useful is a game that just blindly sets all render state for each object, but has few actually different objects:
```rust
for game_obj in game_objs {
rpass.set_pipeline(...);
rpass.set_bind_group(...);
rpass.set_vertex_buffer(...);
rpass.draw(...);
}
```
**Testing**
Ideally we would have tests that check that pipeline changes have been ellided, but I'm not sure how to write them in the current codebase.
**Future work**
- We could extend this kind of redundant state change detection to most `.set_*` methods on `RenderPass`es.
- If we want to guarantee this behavior in the API, we should also document it.
Co-authored-by: Marvin Löbel <loebel.marvin@gmail.com>
998: Fix regression in device_create_swap_chain r=kvark a=qthree
**Description**
My app works fine with wgpu 0.6 but after upgrade to master branch of `wgpu-rs` it started to panic inside `Device::create_swap_chain`.
**Repro steps**
That happens when there are at least 3 windows opened right after app's startup. My [viewports](https://github.com/qthree/viewports) crate can reproduce this issue. Steps:
```
git clone -b wgpu-master https://github.com/qthree/viewports
cd viewports
RUST_BACKTRACE=1 cargo run --example wgpu --all-features
```
First run is OK, but if you drag two "virtual" windows out of native window and then restart app, it panics.
**Connections**
It's caused by the new behavior of `hub::Storage::remove` introduced in #925, it panics while trying to remove Element::Vacant.
**Proposed solution**
Previously `Storage::remove` returned `None` on `Element::Vacant` and this behavior was expected by `device::Global::device_create_swap_chain`. At least, [this code](8ce2530b69/wgpu-core/src/device/mod.rs (L3561)) doesn't look like it should panic implicitly.
After #925 `device::Global::device_create_swap_chain` was changed to use new `Storage::try_remove`, and it takes into account out of range access, but panics on Element::Vacant.
Since that's the only place where `Storage::try_remove` is used, i changed this function's body back to the body of old `Storage::remove`, and left new `Storage::remove` as is, because it's used in other places.
**Testing**
Since `Storage::try_remove` is used only in one place, `device::Global::device_create_swap_chain`, there shouldn't be any impact on another pieces of code. Also, function code is as same as on stable wgpu 0.6, so there shouldn't be any new bugs. Still, this fixed regression encountered by me, and `cargo test` of `wgpu-core` is passing.
I'm not sure if I should add unit test to cover this case, to save it from regressions in future (and what meaningful test would look like).
**Alternatives**
Don't call `Storage::try_remove` if it's first swapchain creation for surface. Probably, by checking id returned by `surface_id.to_swap_chain_id(B::VARIANT)` with `Storage::contains`. But `Storage::contains` will panic on out of range id.
Co-authored-by: qthree <qthree3@gmail.com>
990: Simplify descriptor writes r=cwfitzgerald a=kvark
**Connections**
Reverts #980 and #970
Takes advantage of https://github.com/gfx-rs/gfx/pull/3410
**Description**
Weighting all the pros and cons, I figured it's easier to adjust the Vulkan backend a little than treating it as a lowest common denominator for this issue.
**Testing**
Tested on wgpu-rs examples (on Vulkan).
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
* [glsl-in] Add initial pre-processor
* [glsl-in] Tweak preprocessor after review
- Add IfState struct
- Use FastHashMap to pre-defines
- Use ok-or() for some errors
* [glsl-in] Remove Option in defines arg
982: Fix debug markers in render passes (#981) r=kvark a=kazimuth
Hey, that was easy. Didn't change anything in the debug groups markers / command pass markers, since afaict they work correctly.
I didn't add a test here because I'm not sure how to use the `player` testing apparatus, but I figure since I'm just adding a line of code that's already there for compute passes ([here](https://github.com/gfx-rs/wgpu/blob/master/wgpu-core/src/command/compute.rs#L452)) it should be alright. Let me know if there's anything else I should add.
Co-authored-by: James Gilles <jameshgilles@gmail.com>
984: Fix locking of device lifetime tracker on resource drop r=kvark a=kvark
**Connections**
Fixes the player hang in #983
**Description**
It turns out the current type-level protection from locking device's lifetime tracker is not working properly. TODO is left.
**Testing**
Tested on the trace from #983
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
* [clippy] disable match_like_matches_macro for now
* [wgsl-in] Return error instead of panic
* [typifier] Convert panics to return error
Still one panic in clone impl for Resolution,
disabled clippy for that one
* [spv-in] REturn error instead of panic'ing
* [spv-out] Return error instead of panic'ing
* [typifier] Use IncompatibleOperand(s) error
Instead of just Other
* [typifier] Use Expression for op in Error
For IncompatibleOperands
* [typifier] revert last commit
980: Group binding writes by wgt::BindingType r=cwfitzgerald a=kvark
**Connections**
Follows up https://github.com/gfx-rs/wgpu/pull/970Fixes#979
**Description**
The problem was that Vulkan restriction applies to its own descriptor types, as specified in the layout. I originally interpret this as types specified in the descriptor set. So we erroneously considered `StorageTexture` and `SampledTexture` to be in the same descriptor write.
This PR makes it use the `wgt::BindingType` instead. It's a bit richer than Vulkan side, but still correct. We are just more conservative than we have to be.
I think gfx-hal API could be better here. Filed https://github.com/gfx-rs/gfx/issues/3408 to look more.
**Testing**
Tested on #979 test case (thanks!)
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
