`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.
* 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.
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.
* Make the color attachments `Option`-al in render pipelines, render passes, and render bundles
* vk: `Option`-al color attachments support
* dx12: sparse color_attachments support
* Only non-hole attachments is supported on wasm target and gl backend
* deno_webgpu: `Option`-al color attachments support
* Follow all suggestions
* Implement submission indexes
* Write some unit tests for poll
* Update wgpu/src/lib.rs
Co-authored-by: Jim Blandy <jimb@red-bean.com>
* Unify Maintain in both wgc and wgpu
Co-authored-by: Jim Blandy <jimb@red-bean.com>
* chore(deno_webgpu): bump deno_core to 0.114.0
ca75752e5a dates back to Aug 30 2021, so is nearly 5 months old.
There are no breaking changes updating `deno_core` to `0.114.0` (released 6 days ago)
Also by using the crate directly from cargo we avoid cloning https://github.com/denoland/deno and https://github.com/denoland/deno_third_party which can be quite large so crate DL/install is much faster
* bump cts_runner's deno crates
* minor cts_runner fixes
* CLEAR_COMMANDS extension is now more of a window into wgpu zero-init
this has mostly implications on the constraints, but also allows a more leaky documentation which makes sense for this non-standard function as there is no other place to look it up
* clear_texture via renderpasses wip
* 3D depth textures are no longer allowed, volumes are always cleared via CPY_DST
* cleanup texture's clear_views
* rename CLEAR_COMMANDS to CLEAR_TEXTURE
* separate clear_texture into reusable & more descriptive parts
* texture clear views are now created ahead of time
* discarded surface fixup goes through new clear_texture method now
* onq ueue texture initialization now goes threw clear_texture
pending inits need to store Stored textures now though, causing more ref count bumping
* texture init on queue_write_texture now also goes through new clear_texture
* transfer functions on commandbuffer use now new texture init route
* merge collect_zero_buffer_copies_for_clear_texture into clear_texture_via_buffer_copies
* clear functions now take TextureInitRange
* Fix clippy lints
* command_encoder_clear_texture no longer takes write lock on texture
* TextureClearMode encodes now is_color
* code cleanup, mostly about `use`
* Handle volume textures in clear_texture_via_render_passes properly
* texture clear no longer requires id::Stored
* init tracking fixes for volumes and init on partial subresource writes
* texture creation enforces COPY_DST only if absolutely necessary
* unrolled functional chain, reduce unsafe scope size
* fix clippy lints
* clear_texture test no longer creates 1D textures
see #2323
* 3D textures are no longer cleared as render target since this isn't supported on Metal
* fix deno building issue, fix formatting
* TextureInner::Surface can now be zero initialized
