`RenderBundleEncoder::set_index_buffer` and `set_vertex_buffer`
interpret a `size` of `None` to mean "from the given offset to the end
of the buffer", but `std::num::NonZeroU64::new` produces `None` when
its argument is zero, which is quite different. Fix this similarly to
the way it's handled in `op_webgpu_render_pass_set_index_buffer`.
The WebGPU spec says this should work; filed as #3170.
* 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.
* Fix opening renderdoc lib
Renderdoc needs to not be opened by us, but instead open the existing copy.
Unfortunately this requires OS specific flags for opening, plus `libloading`
doesn't have full API coverage currently.
* Added changelog entry for #2930
* Hide RTLD_NOLOAD behind a cfg for unix
Co-authored-by: ABuffSeagull <reecevanatta@hey.com>
* StagingBelt: check for free chunks in the `receiver` as well as `free_chunks`.
Previously, chunks would only be taken from the GPU callback receiver
and put on `free_chunks` during `finish()`. So, there might be chunks
that are actually available for use but wouldn't be used.
Now, we consult the receiver whenever we're about to consult the
`free_chunks`, so the reuse of chunks will be as good as possible (given
the application's uses of operations that trigger `map_async` callbacks).
* Changelog entry.
* Record that the buffer is mapped when its size is zero.
* Avoid internally trying to map a zero-sized buffer if mapped_at_creation is true.
* Add an entry in the changelog.
* Ensure the BufferMapAsyncCallback is always called.
This solves two issues on the Gecko side:
- The callback cleans up after itself (the user data is deleted at the end of the callback), so dropping the callback without calling it is a memory leak. I can't think of a better way to implement this on the C++ side since there can be any number of callback at any time living for an unspecified amount of time.
- This makes it easier to implement the error reporting of the WebGPU spec.
* Update the changelog.
1563: Fix stray header in changelog r=cwfitzgerald a=HalfVoxel
It's definitely released by now. I'm guessing it was part of 0.8.1.
Co-authored-by: Aron Granberg <aron.granberg@gmail.com>
1511: Added storage texture array support. r=kvark a=ElectronicRU
**Description**
Arrays of storage images (*f*image*n*D in GLSL parlance) should now be supported.
I also took the liberty to refactor texture format checking a bit,
and tighten up sampled texture support detection for Metal as well.
**Testing**
Not completely sure what's the proper testing approach here, open to suggestions.
Co-authored-by: Alex S <alex0player@gmail.com>
* humble beginnings
* Current progress
* More precise NonZeroU32 change
* Fix typo
* Changelog enough to get my game to compile again
* Fix type change line
