1054: Flush write_texture staging memory r=kvark a=kvark
**Connections**
Fixes part of https://github.com/gfx-rs/wgpu-rs/issues/648
**Description**
Adds the missing flush to the staging buffer in `write_texture`
**Testing**
Untested
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1051: Register init-destination buffer in the pending writes r=kvark a=kvark
**Connections**
Fixes#1049
**Description**
At some recent point we introduced the map of destination buffers for copies, and I missed the case where buffers are mapped at creation.
**Testing**
Tested on the test-case in #1049
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1050: player: use the wgpu-cores's gfx-select macro r=kvark a=kvark
**Connections**
Looks like I broke the player in #1034, surprised we didn't notice, and that `cargo test` still passed. The problem was having the `Empty` backend for the device.
**Description**
Fixes the `device` backend in the player, switches the backend set to be `PRIMARY`, and re-uses the `wgc::gfx-select`.
**Testing**
Replaying a trace from #1049
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1048: Make VertexFormat::size a const fn r=kvark a=Imberflur
**Connections**
Addresses #836
**Description**
The `vertex_attr_array!` macro uses this function. This change enables the macro to be used in `const` contexts and for instance allows returning a `VertexBufferDescriptor` constructed in function without having the difficulties of ensuring the array from `vertex_attr_array!` lives long enough.
**Testing**
I don't believe testing is needed for this.
<!--
Non-trivial functional changes would need to be tested through:
- [wgpu-rs](https://github.com/gfx-rs/wgpu-rs) - test the examples.
- [wgpu-native](https://github.com/gfx-rs/wgpu-native/) - check the generated C header for sanity.
Ideally, a PR needs to link to the draft PRs in these projects with relevant modifications.
See https://github.com/gfx-rs/wgpu/pull/666 for an example.
If you can add a unit/integration test here in `wgpu`, that would be best.
-->
Co-authored-by: Imbris <imbrisf@gmail.com>
1041: Update gpu-alloc and naga with linear allocation fixes r=kvark a=kvark
**Connections**
Fixes#1038
**Description**
Includes b807b5fb41
**Testing**
Tested on the API trace
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1034: Fearless object creation r=kvark a=kvark
**Connections**
Fixes#977Fixes#1032
**Description**
Requiring a separate `xxx_error()` is very convenient for `wgpu-core`, but getting repetitive and complicated for all the users of the API. This PR changes it so we return an object ID unconditionally, and sometimes it's an error. The actual error is passed on the side.
**Testing**
Tested on https://github.com/gfx-rs/wgpu-rs/pull/633
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1037: Add Ids to PassErrorScope r=kvark a=scoopr
Also makes it pub, and the places it is used.
Tweak some error messages.
Co-authored-by: Mikko Lehtonen <scoopr@iki.fi>
1036: Stop using Borrow<RefCount> r=scoopr a=kvark
**Connections**
Follow-up to #931
**Description**
Takes advantage of the new `trait Resource` in the state tracker, reducing the code.
**Testing**
Not tested outside of `cargo test`
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1033: Missing label queries r=kvark a=scoopr
I missed few bits needed for labeling the resources in the errors.
Co-authored-by: Mikko Lehtonen <scoopr@iki.fi>
931: Retain labels for resources r=kvark a=scoopr
This is wip, mostly a conversation starter.
I've attempted to have some labels show up in the errors, outside of only creation errors.
Steps to do that include,
1. Retain the label in the underlying struct (here, `Buffer`). It is guarded by `debug_assertions`
2. Add the label option to the error variant, and show it
3. Add label option to the `Element::Error` variant, so that invalid ids retain the label also. Didn't guard it with `debug_assertions` yet, but probably should. `buffer_error` now takes the label option.
4. Added a query for invalid id labels
5. Add `Global::buffer_label` for returning the label from the struct, or the invalid id.
6. Change the error variants to query the `buffer_label` when creating the error
with that (and little bit of fudging to get in to the error state), I can get
```
wgpu error: Validation error
Caused by:
In CommandEncoder::copy_buffer_to_buffer
buffer (0, 1, Metal) (label: Some("Staging buffer")) is invalid
```
instead of
```
wgpu error: Validation error
Caused by:
In CommandEncoder::copy_buffer_to_buffer
buffer (0, 1, Metal) is invalid
```
Some of the hub handling etc. is a bit iffy for me, I really have no idea what I'm doing.
The point would be to massage this to the point that there would be a simple steps to follow on how to decorate all the errors with labels to whatever they refer to.
Other ideas I had, included trying to have `impl Debug for Id<BufferId>` to print out the label (from the struct, wouldn't work for invalid ids), but in that context I don't think I have access to the Global, so I'm not sure how resolve the id to anything useful. I suppose there could a whole separate singleton storage for id to label maps which could be easier to access in any context. Then the errors could just store the Id, and not have a separate label field.
Co-authored-by: Mikko Lehtonen <scoopr@iki.fi>
1023: Drop surfaces and adapters r=cwfitzgerald a=kvark
**Connections**
Not very connected
**Description**
Refactors our destruction paths a bit
**Testing**
tested on wgpu-rs
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1021: Normalize `Err(x)?` to `return Err(x.into())` r=kvark a=Kimundi
Just a tiny change based on some matrix discussion.
Co-authored-by: Marvin Löbel <loebel.marvin@gmail.com>
1018: Add context for errors originating from commads in a Pass r=kvark a=Kimundi
**Description**
This adds some error context information for some errors that can happen in a `{Render,Compute}Pass` to make error messages more clear.
Combined with https://github.com/gfx-rs/wgpu-rs/pull/613, errors in passes will look like this:
```
wgpu error: Validation error
Caused by:
In a RenderPass
In a draw command
index 3600 extends beyond limit 38
```
Co-authored-by: Marvin Löbel <loebel.marvin@gmail.com>
