major graphics problems when using DirectX12 as a backend

[adsick]

some of the problems probably are already known, but the point of this issue is to make you aware that DirectX12 backend is basically broken now so if you encounter problems with it you should try switching to Vulkan backend. this issue is actually seems on wgpu/gfx side but untill it is not fixed by their developers team, Bevy devs should know that this problems exists.

Bevy version

0.5 (from Git repo)

Operating system & version

Windows 10

Hardware:

AMD Ryzen 3500U with Vega 8 graphics

this appears on DirectX12 backend only, switching to Vulkan or older DirectX11 solves both the artifacts and the leak.

What you did

Run different 3D examples

What you expected to happen

Fancy 3D graphics rendered correctly

What actually happened

Image is flooded with red color and has many artifacts

Additional information

running vanilla load_gltf example with dx12 backend looks like the following: (also note how memory usage growth and then falls when I close the application) when resizing the window, ugly glitches can be observed:

proof that everything works fine with Vulkan (memory is also ok) btw noticed, that in this example dx11 (which is also ok) uses like twice less RAM than the Vulkan version

[mockersf]

this issue is actually seems on wgpu/gfx side

Can you reproduce those graphic glitches running examples from wgpu? They may have already fixed it. Do you know if there's an issue?

For memory usage, this is (as you know) #1804

[adsick]

Ok, I will try to run some wgpu examples with different backends tomorrow. That requires a bit o time.

[adsick]

so I've nearly burned my notebook during wgpu compilation, set it to Dx12 backend and it seems fine. I tested both debug and release builds and those problems were not encountered.

[mockersf]

Could you check again after a cargo update? There has been a dependency related to dx12 that has been updated

[adsick]

I updated the deps, saw it actually updated that dx12 related gfx thing, but unfortunately the artifacts reamain the same as they were before (except memory now does not growth up to infinity)

[kvark]

If the issue is with wgpu/gfx, and it's not filed there, then waiting for it to be fixed is not the most efficient. Here is what would help us to investigate:

1. file this on gfx-rs repo
2. record an API trace - https://github.com/gfx-rs/wgpu/wiki/Debugging-wgpu-Applications#tracing-infrastructure . I don't know how Bevy exposes this.
3. run the app from within Visual Studio and copy out the Output window, which would show the DX runtime warnings

[mockersf]

@kvark this is very probably an issue in Bevy, discussion continued in https://github.com/bevyengine/bevy/issues/1930 where an alignement issue was found, but not yet identified and fixed

[kvark]

Since wgpu's goal is to be fully safe and maximum portable, it seems like it would still be our problem, even if you are doing something unexpected.

[cart]

Since wgpu's goal is to be fully safe and maximum portable, it seems like it would still be our problem, even if you are doing something unexpected.

I appreciate this approach :smile:

[adsick]

Is it possible to just switch default bevy wgpu backend to vulkan (or dx11)?

In situation when you want the game to work on end user machine the last thing you want is to tell him words "set the BEVY_WGPU_BACKEND env variable to vulkan"

Honestly I'm a noob, but I don't find these env variable good/flexible, esp in gamejam scenario

[cart]

I think ultimately it is wgpu's job to pick the best / most compatible backend. Currently it sounds like it favors DX12, but that results in inconsistent behavior. If DX12 really should be the "preferred" backend on windows, then this is just a bug that needs to be fixed in wgpu's DX12 backend. If the inconsistency cannot be fixed (or Vulkan is the better backend to prefer), then they should change that on their end.

We could force vulkan on windows, but I think the wgpu team is better equipped / positioned to make that call on our behalf.

[kvark]

Vulkan has always been our first candidate. If Bevy doesn't forbid it, we'd try it first, and only proceed to DX12 if the adapters it exposes fit better. See https://github.com/gfx-rs/wgpu/issues/1416 for some more details.

Here is an example where you can get DX12 today, but maybe don't expect it:

• the machine has an Intel Haswell iGPU and an NVidia GPU
• user requests a LowPower adapter, with a mask that permits all backends
• we query Vulkan adapters and only get NVidia GPU one, since Haswell doesn't support Vulkan on Windows
• we query DX12 adapters and get separate adapters for Intel and Nvidia
• DX12 Intel iGPU is picked, since it's the only LowPower candidate

[adsick]

Can we just disable dx12 for now as it does not work correctly?

[mockersf]

Could someone with DX12 run (and exit as soon as the model is displayed and red)

cargo run --example load_gltf --features wgpu_trace

This will create a wgpu_trace folder. Then please file an issue in https://github.com/gfx-rs/wgpu with this folder and any log from Bevy

[adsick]

sorry for being a slowpoke, the problem is still present. I did the run with wgpu_trace and filed an issue at wgpu.

[mockersf]

In the meantime, Bevy is rewriting its rendering stack and wgpu is rewriting its dx12 stack... There may be hope!

[DavidBChristensen]

I can reproduce on a low powered AMD Athlon Gold / Radeon Graphics computer and am available for testing if needed. Switching to Vulkan is my current work-around.

[inodentry]

This issue is very old and probably stale. Bevy has had a renderer rewrite since this issue was created, and wgpu has had several major releases. The DX12 backend recently became the default on Windows. Closing this issue.

Feel free to reopen if it is still relevant / the issues are still present.