Extend WgpuSetup, egui_kittest now prefers software rasterizers for testing

[Wumpf]

• Related to epaint software renderer #1129
• Needed for..
  • Use a software renderer for kittest rerun-io/rerun#8245
  • Make graphics adapter creation list all adapters one by one and inform why they weren't picked rerun-io/rerun#8475

WgpuSetup is now a lot more powerful:

• fully configure instance
• manual adapter selection on native

egui_kittest now uses this to prefer software rasterizers when possible.

Sidenote: request_adapter's force_fallback_adapter is not exposed since it will fail if there's no software rasterizer around (which is unfortunately the regular state of things on Mac). Since it also doesn't have any effect on WebGPU (unlike power preference!), I removed it again from WgpuSetup as it doesn't seem to be all that useful in general to me 🤷

TODO:

• remove force_fallback again
• green ci
• expose more InstanceDescriptor things, like instance flags / validation options!
• Figure out interaction with Add Harness::new_eframe and TestRenderer trait #5539 (comment)
• use this in Rerun to make sure I'm not missing something

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/5506-configurable-test-renderer
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

[lucasmerlin]

I refactored how the snapshots are rendered in #5539, introducing a new TestRenderer trait and a WgpuTestRenderer.
The renderer can now be initialized when the Harness is created, meaning we can now create a Harness from an eframe::App, tell it to create a wgpu renderer. Then custom rendering relying on eframe::Frame::wgpu_render_state and PaintCallback will just work ✨

[Wumpf]

My attempts to try out software rasterizing on Dx12 ran into a recent wgpu regression, took me quite a while

• Fix filtering out dx12 software adapters gfx-rs/wgpu#6843

[Wumpf]

I'm a lil bit uneasy about this actually. Requesting adapters for all backends when the user already settled on one has the potential to waste a lot of startup time. But I didn't want to break the list of adapters we provide.
Should reconsider this in the future.

[lucasmerlin]

I gave this a try on windows to see if the snapshot tests would work, they all seem fine, except for the rendering test, where the snapshot fails in the linear gradient section (but only at a scale of 1.0, for some reason):

Screen.Recording.2025-01-08.at.13.22.55.mov

I had to increase the threshold to 15.0 for the test to succeed. But this test is also failing on master, so it's not related to the software rasterizer.

Also, logging the AdapterInfo it is choosing vulkan over dx12, meaning it doesn't use the dx12 software rasterizer. I guess this would be fixed by gfx-rs/wgpu#6843?

[crates\egui-wgpu\src\lib.rs:238:9] adapter.get_info() = AdapterInfo {
    name: "AMD Radeon RX 5700 XT",
    vendor: 4098,
    device: 29471,
    device_type: DiscreteGpu,
    driver: "AMD proprietary driver",
    driver_info: "24.10.1 (AMD proprietary shader compiler)",
    backend: Vulkan,
}

[Wumpf]

Also, logging the AdapterInfo it is choosing vulkan over dx12, meaning it doesn't use the dx12 software rasterizer. I guess this would be fixed by gfx-rs/wgpu#6843?

Yep. That's fixed there, tried that locally :)
Note that generally (not using that custom selection there) wgpu prefers Vulkan over DX12 because the DX12 implementation has some shortcomings today (none of which are super relevant for our purposes here :))

[lucasmerlin]

Looks great!