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>
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>
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.
