Currently, we only increment the internal buffer/texture counters when creating them in the regular way (not when creating them from externally built hal objects (create_texture_from_hal/create_buffer_from_hal). However we decrement the counter in all cases, which makes the counters incorrect when these externally created resources are involved.
This commit fixes it by adding hooks (add_raw_buffer and add_raw_texture) in the hal device abstractions to inform when buffer or textures are created externally.
In `wgpu_hal`:
- Document that `wgpu_hal` guarantees that shaders will not access buffer
contents beyond the bindgroups' bound regions, rounded up to some
adapter-specific alignment. Introduce the term "accessible region" for
the portion of the buffer that shaders can actually get at.
- Document that all bets are off if you disable bounds checks with
`ShaderModuleDescriptor::runtime_checks`.
- Provide this alignment in `wgpu_hal::Alignments`. Update all backends
appropriately.
- In the Vulkan backend, use Naga to inject bounds checks on buffer accesses
unless `robustBufferAccess2` is available; `robustBufferAccess` is not
sufficient. Retrieve `VK_EXT_robustness2`'s properties, as needed to discover
the alignment above.
In `wgpu_core`:
- Use buffer bindings' accessible regions to determine which parts of the buffer
need to be initialized.
In `wgpu_types`:
- Document some of the possible effects of using
`ShaderBoundsChecks::unchecked`.
Fixes#1813.
Remove the `pub(crate)` visibility marking from various associated
functions of `Device` that are defined in, and not used outside of,
the `wgpu_core::device::resource` module.
Change various functions that have no need to create an owning
reference to the `Device` to accept `&self` instead of `&Arc<Self>`.
Change `ParentDevice::same_device` to accept `&Device` as the point of
comparison, not `&Arc<Device>`. Call sites will use Deref conversion,
so no callers need to be changed.
In `Device::create_bind_group`, name the functions that convert
resource ids to Arcs `resolve_foo`, not `map_foo`:
- The types that hold Arcs are usually called `ResolvedBlah`.
- The name `map_buffer` is misleading.
Add a new module `lock::observing`, enabled by the `observe-locks`
feature, that records all nested lock acquisitions in trace files.
Add a new utility to the workspace, `lock-analyzer`, that reads the
files written by the `observe-locks` feature and writes out a new
`define_lock_ranks!` macro invocation that covers all observed lock
usage, along with comments giving the held and acquired source
locations.
`std::mem::{size,align}_of{,_val}` was added to `std::prelude` in Rust
1.80; see
[`rust`#123168](https://github.com/rust-lang/rust/pull/123168/).
However, we don't have an MSRV at 1.80 or higher yet. So, let's work
around it by importing these items fully. Since neither `clippy` nor
`rustc` lint against shadowed `prelude` items yet (see also a [proposed
`clippy` lint] for such), that lets us remove the explicit `std::mem::*`
imports later at our leisure.
[proposed `clippy` lint]: https://github.com/rust-lang/rust-clippy/issues/8439
`flush_mapped_ranges` needs to be called when mappings are not coherent.
We can also omit flushing for write-mapped buffers since we always flush them on unmap.
