Update wgpu (and ash, to avoid duplicate deps).

[eddyb]

For updating wgpu, these backwards-incompatible changes required fixes:

• Convert map_async from being async to being callback based gfx-rs/wgpu#2698
• get_supported_formats: sort like the old get_preferred_format and simplify return type gfx-rs/wgpu#2786
• Update raw-window-handle to v0.5.0 rust-windowing/winit#2376
• Cleanup Surface API gfx-rs/wgpu#3236

The original hope was that with newer wgpu we'll get newer naga which might fix the bug breaking the mouse shader (likely gfx-rs/naga#1977 - at least with SPIR-T) - but alas, no such luck
(however, replacing the for loop with a while loop, and turning off SPIR-T with RUSTGPU_CODEGEN_ARGS=--no-spirt works around naga bugs, and is enough for testing).

---

I've also took the liberty of tweaking a couple dependency versions and (selectively) running cargo update -p ... to reduce duplicates in Cargo.lock, hence the larger amount of changes than might be expected (and the dependency on EmbarkStudios/ash-molten#71).

---

One thing I have not figured out yet is why the mouse shader (with the locally applied workaround) doesn't render new frames except on input events only with X11 (Wayland is fine) - there may be a "power saving" setting that has changed default in wgpu/winit?

EDIT: turns out that was us using winit as if we were a GUI application, in "only redraw after events" mode (not sure my workaround here is the best approach, but it works, and enabling VSync makes it acceptable).

[eddyb]

This is incredible, the cargo-deny failure is because of something needed for font rendering.

Why would we need to render text? Well, we don't, except... Look at what winit needs to support Wayland:

• Remove SCTK on Wayland and migrate to wayland-client rust-windowing/winit#1802
  • (this issue was closed effectively as "wontfix" and does remain a problem)

So according to that, there's this "SCTK" (smithay-client-toolkit) which among other things handles CSDs on Wayland (where CSD is "Client-Side Decoration", i.e. letting an app have a custom titlebar).

But why would winit default to CSD? Surely custom window decorations are optional, right?
Well, GNOME appears to have forced the custom mode on everyone.

Not just that but some of them even posted to KDE venues proposing KDE also do the same (i.e. remove perfectly good WM-side window decorations and force everyone to use custom "CSD" ones).

My only hope is that I can turn this stuff off and maybe cargo-deny will then be happy but I have doubts.
EDIT: doubts were justified, cargo-deny doesn't ignore disabled optional dependencies.

EDIT2: ah, nice, rust-windowing/winit#2438 replaces the problematically-licensed dependency, and I switched winit to a git dep, but that might block this PR until a new winit version is released.

[eddyb]

This change was found by @fu5ha because macOS apparently doesn't support Mailbox (did this ever work? I think main might be broken too).

[eddyb]

Note that in the latest version of this PR, I've changed it to AutoVsync because AutoNoVsync was doing excessive redraws (thousands of frames per second).

[ValorZard]

All the stuff that was blocking this PR got merged, so does that mean that wgpu can be updated now?

[eddyb]

All the stuff that was blocking this PR got merged, so does that mean that wgpu can be updated now?

@ValorZard To be clear, none of my links above have changed status since I posted them. I was linking already merged PRs, some of them just to describe why certain changes where needed.

The only blocker link AFAICT is there's no new release containing e.g. the crossfont->ab_glyph change (rust-windowing/winit@f9b41fd - note how GitHub doesn't list any tags as containing it).

You can also see it's still under the "Unreleased" section in the CHANGELOG right now:

• On Wayland, wayland-csd-adwaita now uses ab_glyph instead of crossfont to render the title for decorations.

We're basically waiting for winit to release 0.28, which I'm not seeing a timeline for.

---

For now, this update is not that important, at least not for Naga, until these issues are fixed:

• [spv-in] Naga miscompiles SPIR-V with branches that exit more than one level of structured control flow gfx-rs/wgpu#4449
• [spv-in] Conditional loop backedge not lowered to Statement::Loop with break_if expression gfx-rs/naga#1977 (comment)

We should just make it possible to use the raw SPIR-V (i.e. bypassing Naga entirely) until Naga improves.

[eddyb]

winit 0.28 has since been released (and since then some further patch releases too).

I've further updated winit, wgpu (and a few other miscellaneous crates), but also changed how we handle wgpu's naga dependency, so that we don't have to update wgpu to get newer naga.

That was in part motivated by a desire to maybe try fixing naga bugs ourselves, and being on the the latest from git would make that much easier - but also we could try out e.g. wgpu raytracing support, before it lands.

EDIT: the naga part was a bad idea, it creates noise on every Cargo command, took it out for now.

[eddyb]

Got Android building (and WASM for that matter, but it doesn't work, I get a lot of errors I haven't looked into).

This is what I can get out of cargo apk run -p example-runner-wgpu --lib --target x86_64-linux-android, after starting the Android emulator with -no-snapshot -feature Vulkan,GLDirectMem:

I'm not sure what's wrong with the texture format, but the na-winit-wgpu example has the same problem.

[eddyb]

Opened a separate PR with the the addition I was using to test the WASM path:

• Reduce global import usage gfx-rs/naga#1016

Which will have to wait until the massive problem with wgpu::backend::web is fixed:

• Dynamic dispatch layer breaks on web gfx-rs/wgpu#3430

So this PR is truly unblocked, just needs a review now!