wgpu 28 #17
wgpu 28 #17
Conversation
|
Before merging, I'd like to make sure we test it. This entry from the wgpu changelog has me a little worried: "Using both the wgpu command encoding APIs and CommandEncoder::as_hal_mut on the same encoder will now result in a panic." |
|
We'll also need to bump and publish v3 of this crate. |
|
yep it is currently panicking when running solari in the bevy repo with "Mixing the wgpu encoding API with the raw encoding API is not permitted". |
|
@ChristopherBiscardi try this 3c34a53. Note that some changes will be needed on Bevy's side as well - feel free to reach out to me over discord and I can assist. |
|
@JMS55 I've updated this PR with that diff, and some additional fixes to get it to compile/fix tests (which is in an additional commit here) bevyengine/bevy@53db3a5 is the bevy-side commit, which runs but the naga-oil enable issue now needs to be solved to confirm it all working. |
Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
…le_fail on examples
|
This has been tested with 5ab800e 
|
|
@ChristopherBiscardi Solari tests DLSS-RR, but please also run the anti_aliasing example with --features dlss to test regular DLSS! |
on the anti_aliasing example |
|
which is in the |
|
@ChristopherBiscardi try now |
|
lotta warnings: https://gist.github.com/ChristopherBiscardi/bb4b999cab974257874f721f3dbe2688 but it renders 
|
|
blegh that was the wrong screenshot. here's the dlss one: 
|
|
wait did you auto-commit that on github? |
|
had to rebase because of the github commit, should be up to date now |
|
Yeah I added a commit to this PR. |
|
Ignore those warnings, it's a known issue with the DLSS VK SDK https://github.com/bevyengine/dlss_wgpu?tab=readme-ov-file#validation-errors. Think we're good now! |
| /// ``` | ||
| /// | ||
| /// Failing to follow these rules is undefined behavior. | ||
| pub fn render( |
There was a problem hiding this comment.
@ChristopherBiscardi do you think it's worth adding #[must_use] to the render methods?
There was a problem hiding this comment.
I am under the impression that this would only impact the return type, which is already a Result which already has must_use on it.
Unless we're going to change the message for must_use I think this wouldn't have any effect
Upgrade to wgpu 28 > [!important] > This can't merge until bevyengine/naga_oil#132 does, and the dependency is updated from my fork to the release. > > Also requires wgpu 28 in dlss_wgpu: bevyengine/dlss_wgpu#17 > [!note] > This does not enable mesh shaders, and neither does the naga_oil PR. I chose to do an upgrade first, then go back and see about mesh shaders. Here's a general list of changes and what I did. Commits are grouped by feature except for the last one, which enabled solari when I ran the solari example. ## MipmapFilterMode is split from FilterMode - Split MipmapFilterMode from FilterMode #8314: gfx-rs/wgpu#8314 solution: implement From for `MipmapFilterMode`/`ImageFilterMode` since the values are the same. The split was because the spec indicates they are different types, even though they have the same values. ## Push Constants are now Immediates - gfx-rs/wgpu#8724 immediate_size is [a u32](https://docs.rs/wgpu/28.0.0/wgpu/struct.PipelineLayoutDescriptor.html#structfield.immediate_size) so use that instead of `PushConstantRange` ## Capabilities name changes - gfx-rs/wgpu#8671 Got new list from https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-core/src/device/mod.rs#L449 and copied it in. ## subgroup_{min,max}_size moved from Limits to AdapterInfo - gfx-rs/wgpu#8609 Update the limits to have the fields they have now, mirror the logic from the other limits calls. ## multiview_mask - gfx-rs/wgpu#8206 set to None because we don't use it currently. Its vaguely for VR. ## error scope is now a guard - gfx-rs/wgpu#8685 retain guard and then pop() it later --- I made one mistake during the PR, thinking set_immediates was going to be the size of the immediates and not the offset. I'd like reviewers to take a look at immediates offset and size sites specifically just in case I missed something. Here's a bunch of examples running <img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 47 22@2x" src="https://github.com/user-attachments/assets/83dcf4c8-69f5-480a-b724-86598530f25a" /> <img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 48 44@2x" src="https://github.com/user-attachments/assets/46d897fa-1ab2-44ef-8055-fe2fce740dbc" /> <img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49 10@2x" src="https://github.com/user-attachments/assets/6ae7a9bf-0473-4800-8dfc-233a6a41d6df" /> <img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49 31@2x" src="https://github.com/user-attachments/assets/89f84a26-cfbd-4196-bca8-111c3d20ba7b" /> ## Known Issues > [!NOTE] > > There are no current known issues. Everything previous has been solved. - [x] enable extensions can not be written in naga oil in a way that allows them to be used in composed modules. Update: this was fixed by introducing a flag in naga-oil to force shaders to allow ray queries in composed modules when using bevy_solari. This is temporary and will be different in WESL-future. <details><summary>old explanation</summary> This is blocking solari from working on nvidia (solari runs successfully on macos m1) because it needs `enable wgpu_ray_query;`. Putting the declaration before `#define_import_path` means it gets stripped out (afaict), and putting it after results in ``` error: expected global declaration, but found a global directive ┌─ embedded://bevy_solari/scene/raytracing_scene_bindings.wgsl:3:1 │ 3 │ enable wgpu_ray_query; │ ^^^^^^ written after first global declaration │ = expected global declaration, but found a global directive ``` </details> - [x] dlss_wgpu mixes apis which [causes panics now](bevyengine/dlss_wgpu#17 (comment)). <details><summary>Previous notes as dlss_wgpu was being fixed here</summary> The wgpu release notes don't mention which PR this was introduced in, only saying: > Using both the wgpu command encoding APIs and CommandEncoder::as_hal_mut on the same encoder will now result in a panic. It was caused by gfx-rs/wgpu#8373 which claimed to not know of any use cases > With record on finish, the actual ordering on the command buffer is deeply counter intuitive (all as_hal would come first) and I think it additionally was just flat out broken in some ways > - https://discord.com/channels/691052431525675048/743663924229963868/1453786307099758683 Possible path forward is using multiple command buffers: https://discord.com/channels/691052431525675048/743663924229963868/1453795633503670415 </summary> --------- Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
3 participants
currently broken, caused by gfx-rs/wgpu#8373