615: Use General allocator at all times for now r=grovesNL a=kvark
In all user-managed resources, we don't have control of the lifetime. Since we don't know when it's released, we can't use any more specific allocator kind than `General`.
Previously, we assumed that buffers created for MAP_READ+COPY_SRC, for example, were one-time buffers created to copy data. However, there appear to be cases where they were used to fill data in once, and then persistently used as a copy source destination.
In the future, one WebGPU data transfer story is settled, we'll be able to use `Linear` kind again for all internally managed uploads. I.e. writeBuffer, writeTexture, and createBuffeMappedOnlyAtStart.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
596: Remove wgpu-native and wgpu-remote r=grovesNL a=kvark
Closes#587
I'm still not sure if it's a good idea. Feedback is welcome!
For instance, even after we remove these two things, the repo will still contain a bunch of logic that Gecko wouldn't necessarily be interested in, such as the surface/swapchains logic.
It's also not clear to me how to properly organize the workflow with the wgpu-native being separate (btw, it's https://github.com/gfx-rs/wgpu-native). Do we still have the workspace here? Or do we just introduce a separate repo that will include all the stuff as sub-modules and have a single workspace?
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
598: Enable READ access for texture storage r=kvark a=kvark
This is a short-term workaround until we properly implement #597
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
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>
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>
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.
