This wasn't being done even if the VK_EXT_depth_clip_enable was present
causing validation errors when requesting DEPTH_CLIP_CONTROL in the
device.
Strangely this was being done for raw calls to `wgpu_hal::Adapter::open`
because it calls `physical_device_features` and then
`from_extensions_and_requested_features`.
* Introduce SamplerBindingType enum and fix bug in validation
This matches the WebGPU spec more closely and also lets us implement the
validation as it's written in the spec[1]. This fixes a bug which
previously prevented the "shadow" example from running in Firefox.
Previously the validation would check whether the filtering was
appropiate even if it was a comparison sampler. This didn't matter when
running the shadow example natively since the example was setting
`filtering: true` in addition to `comparison: true`. But this failed
when running through a browser since there the used WebIDL has the
proper enum representation and eventually resulted in `filtering: false`
being passed to wgpu-core which would then fail validation.[2]
[1]: https://gpuweb.github.io/gpuweb/#bind-group-creation
[2]: 674b6582ba/dom/webgpu/ipc/WebGPUChild.cpp (L502-L513)
* Fix remaining examples
* Fix deno_webgpu
* Creation of max compute workgroup size limits
* Implemented for Vulkan and Dx12
* Follow up of gfx-rs/wgpu#1808
* Check if current dispatch operation is under the limit
* Typos and some forgotten fixes
* Port to GLES
* Port to Metal with default limits
* Change Vulkan max_workroup_size_per_dims to pick the min of the reported dimensions
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Currently the configure function reuses the surface texture if it
already exist, and will call Glow::Context::tex_storage_2d to
reconfigure the texture. However doing so on an already configured
texture will cause the browser warning:
WebGL warning: texStorage(Multisample)?: Specified texture is immutable.
and will NOT apply the new configuration such as new dimensions.
Co-authored-by: Nicklas Warming Jacobsen <nwj@skybox.gg>
* new test for clearing textures of all formats
* clear_texture is now always implemented in wgpu-core instead of wgpu-hal
* add 1D/array/volume texture to clear_texture test
* set mip_level_count to 1 for D1 textures in clear_texture test
* fix warning & clippy lints
* Fix web build
* [pr feedback] fix potentially skipped resource transition, fix wrong mip size for texture clear
* collect_zero_buffer_copies_for_clear_texture aligns rows now properly
* Do MTL feature check for Depth Clamping
(cherry picked from commit ae6e83c3b2e695918ffcd8bbf7ce3a1b32e2b36e)
# Conflicts:
# wgpu-hal/src/metal/adapter.rs
* make feature support check conform
* clean code
* avoid same featureset checks multiple times
* cargo fmt'ed
* enable CLEAR_COMMANDS feature for all adapters
* replaced fill_buffer with clear_buffer (minus variable value)
* Improve clear buffer/texture test
and remove unused clear-buffer.ron test
* renamed clear_image to clear_texture
* skeleton for new wgpu-hal clear_texture
* clear_texture implementation for vulkan
* clear_texture now restricts usage
* clear_texture implementation for dx12
* Implemented clear_texture for Metal backend
* Clean up GLES clear_buffer and leave note on how to implement clear_texture in the future
* fix linux compilation & formatting issues
* comment & namespace fixes
* Extent3d has now a simple mipmap calculating function
Fix incorrect use of texture.size in clear_texture for metal/dx12
Fix incorrect mip/layer ranges in clear_texture for metal/dx12
* hal/metal: support Features::NON_FILL_POLYGON_MODE
* Document Metal support for NON_FILL_POLYGON_MODE
* Split Features::NON_FILL_POLYGON_MODE in two
Adds two new features: `LINE_POLYGON_MODE` and `POINT_POLYGON_MODE`.
Allows metal to support `PolygonMode::Line` while not being required to
support `PolygonMode::Point`.
* Formatting
* Rename {LINE,POINT}_POLYGON_MODE to POLYGON_MODE_{LINE,POINT}
The backend panics while trying to process uniform global variables
when the variable's name is not found in the emitted ReflectionInfo.
This patch converts the panicking line into an explicit check, and
ignores the corresponding global variable if the name iis not found.
Resolves#1803
1732: Fix Tests on DX12/GL r=kvark a=cwfitzgerald
**Connections**
Marks #1730 as known failure
Closes#1695
**Description**
This fixes up tests on both DX12 and GL
**Testing**
Tests
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1609: [Vulkan] Initialize wgpu objects from raw handles r=kvark a=zarik5
**Connections**
This PR is a successor of https://github.com/gfx-rs/gfx/pull/3762
**Description**
The `handle_is_external` flag mechanism was not enough to ensure safety, when for example the Instance is wrapped in `Arc<>` and a library cannot keep track of all its clones. This is the case with the bevy render rewrite. The solution was to let wgpu be in charge of destroying the handles, but it also has to keep a reference to a "drop guard" which is always dropped after the handle is destroyed. For the OpenXR integration, this drop guard will be `xr::Instance`.
For now this is just a proof of concept. Only instance creation is handled, and there is even type error in `wgc::Instance::from_hal()`.
I have a few concerns:
* Is it ok to expose `hal::Instance` from the wgpu crate? Or should the user pass all the parameters so `hal::Instance` can be constructed internally? This second options is more disruptive, since the wgpu-types crate would need to import all platform-specific crates to define the structure/enum to hold the raw handles.
* Without counting the call to create the `hal::Instance`, there are 4 indirection calls to save the raw instance. Can this be optimized in any way?
Do you think it is possible to merge wgpu-hal into wgpu-core? This could help with reducing the distance from the surface level API to the platform specific APIs even more.
**Testing**
Vulkan/Android (Oculus Quest) using [this sample](https://github.com/zarik5/openxrs/blob/wgpu-test/openxr/examples/vulkan.rs).
Co-authored-by: Riccardo Zaglia <riccardo.zaglia5@gmail.com>
1717: Work Around Fastclear Bug for Web and Native GL r=cwfitzgerald,kvark a=zicklag
**Connections**
Resolves#1627
**Description**
Works around Mesa fastclear bug by doing a manual shader clear on effected platforms
**Testing**
Tested on Mesa Intel(R) UHD Graphics (CML GT2) (Gl)
Co-authored-by: Zicklag <zicklag@katharostech.com>
1713: hal/dx12: rewrite view creation, use arrays more aggressively r=kvark a=kvark
**Connections**
**Description**
D3D12 has this thing where you can't create a 2D view with non-zero base array index.
So we have special logic now to fall back to 2D array views in these cases.
**Testing**
Tested on the Shadow example.
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1602: New DX12 backend (unfinished) r=kvark a=kvark
**Connections**
Continuation of #1471
**Description**
Mostly fresh implementation on DX12 backend for wgpu-hal
Core changes:
- texture usage is filtered before passing to `create_texture_view`, so that wgpu-hal can assume every bit is important.
- all the copies involving textures are limited to one array layer at a time
- remove render pass boundary usages
**Testing**
Examples (not running yet)
Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
1607: Fix Downlevel Vertex Stage Storage Buffer Check r=kvark a=cwfitzgerald
**Connections**
Fixes a bug in #1599. Also follows up on #1583 marking all of hello-compute as a failure.
**Testing**
Tests now pass on rpi4.
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1604: Upgrade `arrayvec` to 0.7 r=kvark a=a1phyr
Upgrade `arrayvec` to version 0.7 (using const generics).
Co-authored-by: Benoît du Garreau <bdgdlm@outlook.com>
1599: Fix Limits for lava/llvmpipe and re-enable and re-work CI r=kvark,groves,wumpf a=cwfitzgerald
**Connections**
No longer fixes#1551.
**Description**
This PR has a couple things going on at once.
- Fixes limits for llvmpipe, lavapipe, and rpi4.
- Added a downlevel limit to express that RPI4 does not allow storage buffers in vertex shaders on GL.
- Added a `Limits::downlevel_default()` that takes minimum limits from GLES and adds some more documentation on how to choose limits.
- Moved all examples to the new downlevel limits
- Reworks CI to re-enable software testing and unify instructions.
**Testing**
It is
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
1593: Fix VVL on halmark example r=kvark a=kvark
**Connections**
We have a bunch of VVL related to resource destruction on the halmark example.
It also seems to leak memory quite a ton and eventually hang the system.
**Description**
This PR fixes the logic of changing the command pools in halmark, its initialization sequence, and its destruction.
**Testing**
Tested on halmark and others
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1585: hal/egl fix support for context extensions r=cwfitzgerald a=kvark
**Connections**
Follow-up to #1584
Closes #1577
**Description**
TIL that EGL extensions work differently from the EGL-1.5 stuff, and we are now treating them properly.
**Testing**
Basic testing on AMD
Co-authored-by: Dzmitry Malyshau <kvark@fastmail.com>
1584: Update testing limits for rpi4 r=kvark a=cwfitzgerald
**Connections**
Related to #1574. Exposed #1583.
**Description**
Changes the reftesting limits to be tolerant of how the RPI4 renders. Fixes the debug half of #1577.
Fixes some naming issues as well.
**Testing**
It is
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
DYNAMIC_INDEXING is checked by default, since WGPU doesn't allow
for any kind of specialization constants and constant indexing is
nigh useless.
STORAGE_RESOURCE_BINDING_ARRAY is enabled iff the device supports:
- both or neither of uniform and buffer arrays with dynamic indexing;
- both or neither of sampled and storage images with dynamic indexing.
NONUNIFORM_INDEXING is enabled iff for ALL types of descriptor arrays
*that are supported for dynamic indexing*, nonuniform indexing is
also allowed.
These flags have a limitation in that some platforms
(eg.
https://vulkan.gpuinfo.org/displayreport.php?id=11692#features_core_12)
may support a strange subset of those features (example device
supporting non-uniform indexing for textures and storage buffers,
but NOT for storage textures or uniform buffers). In that case feature
will be reported as missing, even though it is partially present.
In the author's opinion, this flag set is convenient for the
users to query; however, due to aforementioned limitations, it would be
desirable to obtain statistics about "edge-case" platforms and what
percentage of reports they comprise.
1559: Query support fixes r=kvark a=Wumpf
**Connections**
Fixes#1374 for master
If PR is accepted,I already have a fix for 0.9 which came out as a sideproduct: https://github.com/Wumpf/wgpu/tree/v0.9-fix-buffer-init-on-query-resolve
**Description**
Fixes:
* (affects master, v0.8, v0.9) query resolve operation not marking buffers as initialized
* (affects master) Broken query stride handling for Vulkan
* (affects master) Vulkan not advertising query support
**Testing**
* added new test
* mipmap sample
Co-authored-by: Andreas Reich <r_andreas2@web.de>
1525: Add Naga bypass to allow feeding raw SPIR-V shader data to the backend. r=kvark a=ElectronicRU
**Connections**
Fixes#1520 .
**Description**
While Naga checking is undoubtedly very useful, it currently lags behind
what is possible in SPIR-V and even what is promised by WGPU (ie binding
arrays). This adds an unsafe method to wgpu::Device to allow feeding
raw SPIR-V data into the backend, and adds a feature flag to request a
backend supporting this operation.
**Testing**
`texture_arrays` example is runnable now, which uncovers an additional bug in Vulkan backend - binding arrays are instead treated like sole bindings, and indices shift, too. Lots of errors from validation layer ensue.
Co-authored-by: Alex S <alex0player@gmail.com>
- Remove Cow from wgpu-hal API surface. You graze on in our hearts.
- Rename feature flag to SPIRV_SHADER_PASSTHROUGH in anticipation
of crate feature `spirv` to reduce confusion.
- Add some more documentation about behaviour and intended avenues of
use to the feature.
1527: Fix wgpu-hal incorrectly ignoring arrays of bindings. r=kvark a=ElectronicRU
**Connections**
Fixes#1526.
**Description**
Even though binding sizes could potentially be derived from resource array lengths and binding indices, current implementation
flat out ignored that. Metal did a more sensible (?) thing and bound only the first resource in each array, Vulkan did a less
sensible thing and bound as many resources as there are bindings, obtaining them from unwrapped arrays.
(IE on Vulkan, if you bound two arrays, [view1, view2] and [view3, view4], it would actually bind [view1, <invalid>] and [view2, <invalid>]).
This aims to fix the issue.
**Testing**
After #1525 is merged, `cargo run --example texture-arrays` would be working as intended for Vulkan. Unfortunately, I can think of no easy way to test this on Metal - the shader support isn't there yet.
Co-authored-by: Alex S <alex0player@gmail.com>
- rename ShaderInput variants
- rename feature flag
- hard error on Metal backend trying to compile SPIR-V
- fix test failing because of feature flag bits changing
Potentially needs more testing - Metal's binding model is quite
different from Vulkan and WGPU, but as far as I understand from the
documentation, arrays of textures occupy a contiguous range of binding
slots, so unwrapping and binding one-by-one should be fine.
Someone should actually go and test this on a Mac, maybe.
While Naga checking is undoubtedly very useful, it currently lags behind
what is possible in SPIR-V and even what is promised by WGPU (ie binding
arrays). This adds an unsafe method to wgpu::Device to allow feeding
raw SPIR-V data into the backend, and adds a feature flag to request a
backend supporting this operation.
1521: Better compile error for not using resolver=2. r=kvark a=ElectronicRU
**Connections**
Usability fix proposed in #1517 with some re-wording to make the intent clearer.
**Description**
Provide a useful compile error in case a downstream project is using old Cargo resolver, instead of the deluge of obscure errors they get r/n if not on MacOS.
**Limitations**
On MacOS, vulkan feature is totally valid, so we cannot detect resolver=1 on Mac.
Co-authored-by: Alex S <alex0player@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>
