`File::create` isn't available on wasm, so we can't actually write the
output image anywhere unless we target something else as the file
system (e.g. local storage)
591: Warn when binding a buffer that is still mapped r=kvark a=almarklein
Fixes#510
I'd like to make more contributions wrt validation. Though I'm quite new to Rust, so let's start small :)
From the discussion in #510 I concluded that in this case the buffer has actually been dropped, does the error message make sense like this?
Do the messages logged with `log::warn`, end up in the same logging system as the layer validation messages? So a solution to get those messages into Python (for wgpu-py) would work for both kinds of validation messages?
Co-authored-by: Almar Klein <almar.klein@gmail.com>
259: Remove zerocopy and replace with bytemuck. r=kvark a=StarArawn
fixes#146
I've removed `zerocopy` from the examples and replaced it with `bytemuck`. I ran all of the examples/tests and everything ran great in vulkan on my windows box.
Co-authored-by: StarToaster <startoaster23@gmail.com>
595: Derive swapchain layout off the load operation r=kvark a=kvark
Fixes https://github.com/gfx-rs/wgpu-rs/issues/258
It's fairly simple. We expect there to be exactly one `LoadOp::Clear` for the swapchain attachment, and for it to be the first pass in a frame using it. Any other passes need to do `LoadOp::Load`.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
583: Improve error messages when passing buffers with the wrong usage flags r=kvark a=HalfVoxel
e.g.
```
thread 'main' panicked at 'An invalid setIndexBuffer call has been made. The buffer usage is COPY_DST | VERTEX which does not contain required usage INDEX
```
Co-authored-by: Aron Granberg <aron.granberg@gmail.com>
584: Fix vertex format enum to match the native header r=kvark a=kvark
This was one of the problems to get wgpu-rs examples on the web.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
582: Track pipeline layout lifetime r=grovesNL a=kvark
Fixes#580
This one is interesting: it's not instantly destroyed when dropped, like bind group layouts. And it's not tracked for GPU usage like the resources. It's somewhat in-between. We have the following classes of tracking now:
1. no tracking, destroyed on drop. Applies to: bind group layouts, adapters
2. only CPU-side tracking. They go to "suspected" list on drop of self or anything that can point to them. Applies to: pipeline layouts
3. full GPU tracking. They go to "suspected" list on drop, then get associated with active submission before destruction. Applies to: buffers, textures, views, bind groups, pipelines
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
581: Fix buffer unmap warning r=kvark a=kvark
It's more consistent if neither map_buffer or unmap_buffer care about the status.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
570: Improve error message when bind group and bind group layout have different number of entries r=kvark a=HalfVoxel
Co-authored-by: Aron Granberg <aron.granberg@gmail.com>
251: cargo fmt the code and tweak format rules r=kvark a=chao-mu
Ran cargo fmt after removing rules per @kvark, two of which were because they needed nightly to run.
Co-authored-by: Hackpoetic <chao-mu@hackpoetic.com>
When multiple "replace" style transitions are happening,
we weren't properly retaining the "first" state, which
is required for proper stitching of command buffers.
This logic is fixed and fortified with a new set of
"change" and "merge" tests in the track module.
We were improperly detecting if a swapchain image has already
been used by a command buffer. In this case, we need to assume
that it's already in the PRESENT state.
