As an incidental change, wgpu#2802 (de5fe90f2) changed the definitions
of the bitflags in `wgpu_types::Features` from looking like this:
const DEPTH24UNORM_STENCIL8 = 1 << 1;
to this:
const DEPTH24UNORM_STENCIL8 = Self::DEPTH_CLIP_CONTROL.bits << 1;
The intention was to make it easier to insert new flags at a logical
point in the list, and have the numbers automatically update
themselves.
Unfortunately, `cbindgen` can't cope with the new style of definition.
It produces definitions for these flags that look like this:
#define WGPUFeatures_DEPTH24UNORM_STENCIL8 (uint64_t)((WGPUFeatures_DEPTH_CLIP_CONTROL).bits << 1)
These are integer values, so the `.bits` field access is bogus.
This commit changes the definitions back to using direct numbering,
which `cbindgen` doesn't choke on.
* 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
The former use statically linked Android libc symbols while the latter loads them dynamically. This is required to support old and new versions of Android with the same binary. It unblocks updating wgpu in Gecko.
Fixes#2805.
* Add Limit::max_buffer_size.
* Prevent very large buffer with some drivers.
Some drivers run into issues when buffer sizes and ranges are larger than what fits signed 32 bit integer. Adapt the maximum buffer size accordingly.
in the thiserror error format string, `{0:?}` ends up referring to the
first named argument, not the first struct field or a compile error, so
the error was incorrectly
Dimension 32768 value 32768 exceeds the limit of 16384
instead of
Dimension X value 32768 exceeds the limit of 16384
* Change all the functions
* Return the set of supported TextureFormat specified by WebGPU
* Remove redundant filtering and use list directly
* Replace pops with first
* Remove now unused function
* Fix doc and clarify preffered format
* Dereference enums
* Remove unused list
* Remove fancy coode
* Update wgpu-core/src/device/mod.rs
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
Refactor `wgpu_core::command::bundle::State` to more closely resemble
the internal slots of a WebGPU `GPURenderBundleEncoder`, and add
validation required by the WebGPU specification.
Use `Option` to represent state that may be left unset on the encoder:
specifically, the pipeline and vertex buffers. (Previous commits have
already addressed index buffers and bind groups.) Use `.ok_or`, etc.
for unwrapping, to ensure that encoding state errors are reported.
Consolidate state derived from the pipeline in a new `PipelineState`
struct.
Remove `wgpu_core::command::bundle::PushConstantState::is_dirty`; just
represent push constant state as a vector of `PushConstantRange`
values. It's sufficient to simply zero the push constants whenever the
vector is non-empty.
Rename `bundle::State::flush_push_constants` to `zero_push_constants`a.
This is not a "flush pending state changes" function like all the
others; it just ensures that each pipeline's push constant state is
initialized.
The example says:
Using AMD RADV POLARIS12 (Vulkan)
The test says:
thread 'water' panicked at 'Image data mismatch! Outlier count 464 over limit 460. Max difference 213', wgpu/examples/water/../../tests/common/image.rs:134:13
I checked the `water-difference.png` file, and it's just a few dots
here and there. The example seems to run fine.
* Add a downlevel capability for rendering to floating point textures
* Rename capabilities to _capabilities
* Run cargo fmt
* Pass downlevel_flags to the adapter
* Add wgt::DownlevelFlags::COLOR_ATTACHMENT_FLOAT to dx11
* Remove downlevel_flags from the adapter and use is_ext_color_buffer_float_supported instead
* Add DownlevelFlags::WEBGPU_TEXTURE_FORMAT_SUPPORT
* Apply suggestions
This is used in various places around render pipelines, passes, and
bundles.
The public `wgpu_core::pipeline::VertexBufferLayout` could use
`VertexStep` as well, but I think it's best to let that continue to
resemble `GPUVertexBufferLayout`.
On Fedora, mesa-vulkan-drivers 22.0.3 AMD RADV POLARIS12 just colors
both the NE and SW corners red. There's no blue. (NW and SE are white,
as expected.) I suspect
this means that the primitive ID is always being passed as zero.
This is probably not just due to a difference in rasterization: I
tried enlarging the texture to 4x4 and shifting the triangles to
ensure that there was a pixel in each quadrant that was fully covered.
With Vulkan "llvmpipe (LLVM 14.0.0, 256 bits)", the unmodified test passes.
This is probably limited to Linux, but
`wgpu_tests::common::TestParameters` doesn't have a slot for that.
Fixes#2751.
