* Split Blendability and Filterability into Two Different TextureFormatFeatureFlags
* Update CHANGELOG.md
* Split out individual booleans to improve readability
* Make sure blendablity is correctly set for guaranteed format features of WebGPU
* Cargo fmt
Co-authored-by: Xander Warnez <xander.warnez@materialise.be>
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
* set GL vendor for id Mesa and Apple
* match on "apple m" to mark M2 cpu as integrated in gles
* document AdapterInfo::vendor if the vendor has no PCI id
This change is to help with an attempt to allow the Context type in wgpu to be swappable at runtime. In order to do that, the functions provided by Context and it's associated types need to be object safe. Instead of passing a impl trait that combines both HasRawWindowHandle and HasRawDisplayHandle, we seperate the types into their RawDisplayHandle and RawWindowHandle parts internally to reduce some of the hal implementation code mess.
Change `Instance::as_hal<A>` to simply return an
`Option<&A::Instance>`, rather than passing it to a callback. We're
just borrowing a reference to some `wgpu_hal::Api::Instance` owned by
the `wgpu_core::instance::Instance`, so there's no special scoping or
locking magic required here.
* Document that `write_buffer_with` is sound to read from.
To a reader informed about Rust's memory model, the existing claim that
> dereferencing it to a `&[u8]` panics
without further context sounds awfully like someone thinks they've
invented a write-only reference, and that the API might actually be
exposing undefined behavior via an uninitialized `&mut [u8]`. Therefore,
let's specify what happens if you *do* read through the mutable
reference. The text added in this commit is based on what was said in
the review when `write_buffer_with` was added:
https://github.com/gfx-rs/wgpu/pull/2777/files#r901392551
This is also relevant information to someone considering using
`write_buffer_with()` for performance gains: for example, it suggests
that it might be a bad idea to write data into the view and then sort
it in-place. (Or is that not a bad idea? Is it not slow if the CPU
already wrote over all the memory contiguously? I don't know.)
* Changelog addition (+ fixing duplicate documentation section)
The function's does not depend on the `canvas` argument meeting the
given requirements to avoid undefined behavior, so it should just be a
normal contract, not a safety contract.
* Use () instead of PhantomData as IdentityManager's Input type.
PhantomData suggests that there's some sort of persuasion required
for lifetime variance inference or other sorts of arcana, but it
doesn't seem to be necessary at all. `()` works just fine.
Vulkan prohibits including `VkPhysicalDeviceVulkan12Features` structures in the chain passed to `VkCreateDevice` along with other more specific features structs. Similiar restrictions apply to the `...Properties` structures.
Fixes#2925.
* Have `prepare_staging_buffer` take a raw hal Device.
This helps the borrow checker understand that we can borrow
`pending_writes`'s encoder and the raw Device at the same time.
* Always free staging buffers.
We must ensure that the staging buffer is not leaked when an error
occurs, so allocate it as late as possible, and free it explicitly when
those fallible operations we can't move it past go awry.
Fixes#2959.
* Some tests for texture and buffer copies.
* Add CHANGELOG.md entry.
Since `wgpu-core`'s public functions are supposed to validate their
parameters, the internal `track` module skips many of Rust's usual
run-time checks in release builds. However, some `wgpu-core` users are
happy to pay the performance cost in exchange for more safety. The
`"strict_asserts"` feature causes `wgpu_core` to perform the same
checks in release builds as it does in debug builds.
* Validate that map_async's range is not negative.
map_async already checks that the range's end is within the bounds of the buffer, so this also ensures the range start is within bounds.
* Add an entry in the changelog.
