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.
* Remove unused field `bundle::IndexState::pipeline_format`.
* Clean up render bundle index buffer tracking.
Put all state associated with an established index buffer within an
`Option`, so that the Rust types accurately represent value liveness.
Generate `MissingIndexBuffer` errors as needed for `DrawIndexed` and
indexed `MultiDrawIndirect` commands.
`wgpu_core::command::bundle::State::set_pipeline` marks a vertex
buffer slot dirty if the pipeline's stride or step mode for that
vertex buffer slot differs from what had been previously established.
The effect of marking the slot dirty is to ensure that a new
`SetVertexBuffer` command is inserted before the next draw command
that uses that vertex buffer. However, this is unnecessary:
`wgpu_hal::CommandEncoder::set_vertex_buffer` does not need to be
called simply because the stride or rate has changed.
Put some plumbing in place to accomodate the latest definition of
`GPURenderBundleEncoderDescriptor` in the WebGPU spec, which now has
separate `depthReadOnly` and `stencilReadOnly` members.
Rename `RenderPassDepthStencilAttachment::is_read_only` to
`depth_stencil_read_only`, and don't skip validation steps due to
early returns.
* First attempt of exposing create_surface_from_canvas for webgl
* Test Fix Compile For WebGL Offscreen Canvas
* Only specify web-sys feature version in wgpu-core, so that patch version is taken from workspace
* Reuse already existing fn create_surface_from_canvas
* Remove unnecessary unsafe
* Remove unsafe prefix also from top-level create_surface_from_canvas
* Add create_surface_from_offscreen_canvas() for webgl
* Cargo fmt
* Store webgl2_context instead of canvas, which works also for OffscreenCanvas
* Copy skybox example for OffscreenCanvas example
* Use offscreen_canvas instead in newly created example
* Update skypbox_offscreen readme.md
* Allow enabling OffscreenCanvas in examples via http://localhost:8000/?offscreen_canvas=true
* Fix cargo fmt
* [fix warning] Only import FromStr for wasm32
* [fix warning] Exclude offscreen_canvas_setup from non-wasm32
* [fix warning] Add ImageBitmap feature as well so that all related methods can be used
* Fix cargo fmt
* Fix emscripten build
* Remove `webgl` feature from wgpu-core as webgl is the only wasm32 backend
Co-authored-by: Zicklag <zicklag@katharostech.com>
* 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>
* surface.acquire_texture: pass Option<Duration> for timeout
A std::time::Duration allows for timeouts to be specified more clearly in
Rust using whatever units are convenient for the caller, and an Option also
makes it clearer in case no timeout is wanted, as opposed to passing a
bitwise !0 as special timeout value.
Notably there was an impedance mismatch with the Vulkan backend that
takes a 64bit timeout in nanoseconds and uses u64::MAX to indicate no
timeout and the backend was not mapping a given u32::MAX into a u64::MAX
* surface.acquire_texture: ignore timeout for Android < 11
Prior to Android 11 then Android's vkAcquireNextImageKHR implementation was
non-conformant and didn't support timeouts and additionally would log a
verbose warning if a timeout was requested.
For reference this version of AcquireNextImageKHR doesn't support timeouts:
https://android.googlesource.com/platform/frameworks/native/+/refs/tags/android-mainline-10.0.0_r13/vulkan/libvulkan/swapchain.cpp#1426
and this version does:
https://android.googlesource.com/platform/frameworks/native/+/refs/tags/android-mainline-11.0.0_r45/vulkan/libvulkan/swapchain.cpp#1438
(i.e. timeout support was added in Android 11)
This patch adds a dependency on the `android-properties` crate that provides
a simple wrapper for the `__system_property_set` syscall so that the
platform version can be read via the `ro.build.version.sdk` property
and then for versions < 30 (corresponds to Android 11) any timeout
given to `acquire_texture` will be ignored (and `u64::MAX` will be
passed to Vulkan)
This vector's contents always ended up identical to the
`RenderBundleEncoder`'s `BasePass`'s `dynamic_offsets` vector, so
we can just take values from there instead of copying them.
The `dynamic_offsets` and `is_dirty` flags only make sense when the
slot is occupied, so they should be inside the `Option`. This makes
`State::bind` into an `ArrayVec<Option<BindState>>`, and cleans up
various other bits.
