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