AMD iGPU + WebGpu + Wayland renders only when mouse move over the window

[Guara92]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Mutter

WezTerm version

wezterm 20230217-120342-3b39aa55

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

I'm trying the WebGpu front end and is unusable on my system with wayland enabled, with wayland disabled runs really smooth.

> wezterm.gui.enumerate_gpus()
[
    {
        "backend": "Vulkan",
        "device": 5710,
        "device_type": "IntegratedGpu",
        "driver": "radv",
        "driver_info": "Mesa 23.1.0-devel",
        "name": "AMD Radeon Graphics (RADV GFX1036)",
        "vendor": 4098,
    },
    {
        "backend": "Vulkan",
        "device": 0,
        "device_type": "Cpu",
        "driver": "llvmpipe",
        "driver_info": "Mesa 23.1.0-devel (LLVM 15.0.7)",
        "name": "llvmpipe (LLVM 15.0.7, 256 bits)",
        "vendor": 65541,
    },
    {
        "backend": "Gl",
        "device": 0,
        "device_type": "Other",
        "name": "AMD Radeon Graphics (gfx1036, LLVM 15.0.7, DRM 3.49, 6.1.12-xm1.0e20221004.fc37.x86_64)",
        "vendor": 4098,
    },
]

To Reproduce

No response

Configuration

enable_wayland = true,
front_end = "WebGpu",

Expected Behavior

No response

Logs

No response

Anything else?

No response

[wez]

Please share the the OpenGL version line from the debug overlay on your system

[Guara92]

OpenGL version: AMD Radeon Graphics (gfx1036, LLVM 15.0.7, DRM 3.49, 6.1.12-xm1.0e20221004.fc37.x86_64) 4.6 (Compatibility Profile) Mesa 23.1.0-devel

[colemickens]

I'm seeing the same, even when the debug overlay says its using WebGPU+Vulkan:

OpenGL version: WebGPU: name=AMD Radeon Graphics (RADV REMBRANDT), device_type=IntegratedGpu, backend=Vulkan, driver=radv, driver_info=Mesa 22.3.5, vendor=4098, device=5761

I'm on NixOS, but I've patched the wezterm derivation to include vulkan-loader and I don't see any obvious errors.

[VarLad]

Can confirm here as well.
@wez Interestingly, it renders when I move the mouse cursor, not otherwise.
Any idea whats going on here?

[wez]

No; sounds like a driver+wayland issue? I rarely have time to troubleshoot wayland (X11 just works so much better in many ways).

[colemickens]

Hi @wez, I try the latest tip build every week or two. I've also done some work on OpenGL/Vulkan NixOS stuffs so I have a rough idea about some parts at least.I'm willing to sink a bit of time into debugging it. Can you give me some hints on what I can track down?

[wez]

There are two possible paths to follow:

• Is this a general wezterm/wayland issue where the window is repainted as often as it should?
• Is this a problem with the amd drivers?

For the former, it's possible that wezterm is not invalidating/paintain in all the right places, depending on the wayland compositor that is in use. I would suggest trying a couple of different compositors from different families to see if things work better. It can be useful to set WAYLAND_DEBUG=1 in the environment when starting wezterm to see what is happening with the wayland protocol to see how the behavior differs and see if anything leaps out. I don't have a ton of wisdom to share on this.

For the latter: not super sure how to proceed; An obvious thing would be to try connecting a different GPU and see if that works better. Another option would be to reach out to the folks that maintain the AMD drivers and see what they have to suggest for troubleshooting.

It's important to note that wezterm doesn't change its behavior based on the driver; the only differences in wezterm are whether you are using EGL directly, or are using the WebGPU layer. Below that point, the actual heavy lifting is done by the drivers installed on the system.

[VarLad]

@Guara92 Is your issue same as

it renders when I move the mouse cursor over wezterm, not otherwise

If so, it'd be nice to update the issue accordingly.

[VarLad]

@wez I think this issue is GNOME specific since it happens on Intel cards as well. Any idea where could this be fixable from the code?

[jokeyrhyme]

This is happening for me in sway(wlroots) and COSMIC(smithay), and on both AMD and Intel GPUs, so not GNOME-specific

• I tried out WAYLAND_DEBUG=1 wezterm --config='front_end="WebGPU"'
• when I'm typing (and not seeing the output) the logs have entries like:

[  76172.959] wl_keyboard@14.key(21907, 42401238, 38, 1)
[  76173.037]  -> wl_pointer@16.set_cursor(0, nil, 0, 0)
[  76255.781] wl_keyboard@14.key(21908, 42401321, 38, 0)
[  76255.845]  -> wl_pointer@16.set_cursor(0, nil, 0, 0)
[  76483.950] wl_keyboard@14.key(21909, 42401549, 31, 1)
[  76484.028]  -> wl_pointer@16.set_cursor(0, nil, 0, 0)
[  76587.677] wl_keyboard@14.key(21910, 42401653, 31, 0)
[  76587.743]  -> wl_pointer@16.set_cursor(0, nil, 0, 0)
[  77422.957] wl_keyboard@14.key(21911, 42402488, 28, 1)
[  77423.039]  -> wl_pointer@16.set_cursor(0, nil, 0, 0)
[  77506.678] wl_keyboard@14.key(21912, 42402572, 28, 0)
[  77506.742]  -> wl_pointer@16.set_cursor(0, nil, 0, 0)

• and when I'm waving the mouse over the window

[ 176131.866] wl_pointer@28.enter(22289, wl_surface@21, 0.87890625, 419.77343750)
[ 176131.923]  -> wl_shm@4.create_pool(new id wl_shm_pool@46, fd 33, 1024)
[ 176132.109]  -> wl_shm_pool@46.resize(3328)
[ 176132.116]  -> wl_shm_pool@46.create_buffer(new id wl_buffer@44, 1024, 24, 24, 96, 0)
[ 176132.123]  -> wl_surface@27.set_buffer_scale(1)
[ 176132.126]  -> wl_surface@27.attach(wl_buffer@44, 0, 0)
[ 176132.129]  -> wl_surface@27.damage_buffer(0, 0, 24, 24)
[ 176132.132]  -> wl_surface@27.commit()
[ 176132.135]  -> wl_pointer@28.set_cursor(22289, wl_surface@27, 4, 4)
[ 176132.141] wl_pointer@28.frame()
[ 176132.143] wl_pointer@16.enter(22289, wl_surface@21, 0.87890625, 419.77343750)
[ 176132.149] wl_pointer@16.frame()
[ 176132.152] wl_pointer@28.frame()
[ 176132.153] wl_pointer@16.frame()
[ 176132.498] wl_buffer@44.release()
[ 176132.507] wl_surface@27.enter(wl_output@11)
[ 176135.877] wl_pointer@28.motion(42501201, 1.87890625, 419.77343750)
[ 176135.887] wl_pointer@16.motion(42501201, 1.87890625, 419.77343750)
[ 176135.895] wl_pointer@28.frame()
[ 176135.897] wl_pointer@16.frame()
[ 176135.929]  -> wl_surface@21.commit()
[ 176135.950]  -> wl_shm@4.create_pool(new id wl_shm_pool@41, fd 37, 1024)
[ 176136.089]  -> wl_shm_pool@41.resize(3328)
[ 176136.093]  -> wl_shm_pool@41.create_buffer(new id wl_buffer@57, 1024, 24, 24, 96, 0)
[ 176136.099]  -> wl_surface@17.set_buffer_scale(1)
[ 176136.102]  -> wl_surface@17.attach(wl_buffer@57, 0, 0)
[ 176136.105]  -> wl_surface@17.damage_buffer(0, 0, 24, 24)
[ 176136.107]  -> wl_surface@17.commit()
[ 176136.109]  -> wl_pointer@16.set_cursor(22289, wl_surface@17, 11, 12)
[ 176136.584] wl_buffer@57.release()
[ 176136.591] wl_surface@27.leave(wl_output@11)
[ 176136.597] wl_surface@17.enter(wl_output@11)
[ 176138.860] wl_pointer@28.motion(42501204, 2.87890625, 419.77343750)
[ 176138.870] wl_pointer@16.motion(42501204, 2.87890625, 419.77343750)
[ 176138.876] wl_pointer@28.frame()
[ 176138.878] wl_pointer@16.frame()
[ 176138.897]  -> wl_surface@21.commit()
[ 176138.906]  -> wl_surface@17.set_buffer_scale(1)
[ 176138.910]  -> wl_surface@17.attach(wl_buffer@57, 0, 0)
[ 176138.913]  -> wl_surface@17.damage_buffer(0, 0, 24, 24)
[ 176138.916]  -> wl_surface@17.commit()
[ 176138.919]  -> wl_pointer@16.set_cursor(22289, wl_surface@17, 11, 12)
[ 176139.432] wl_buffer@57.release()

• without really know much about what I'm talking about here, I think it's the damage_buffer() calls that tell compositors that a surface needs to be re-rendered? maybe? or the other way around? 🤷

[jdelkins]

A few other cases with the same symptoms. Common elements seem to be Wayland and webgpu.

The following is with a polaris10 GPU using amdvlk under Gnome Wayland, sway, or hyprland.

Debug Overlay
wezterm version: 20230320-124340-559cb7b0 x86_64-unknown-linux-gnu
Window Environment: Wayland
OpenGL version: WebGPU: name=AMD Radeon RX 480 Graphics, device_type=DiscreteGpu, backend=Vulkan, driver=AMD open-source driver, driver_info=2022.Q4.4 (LLPC), vendor=4098, device=26591
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
15:35:56.755 WARN wezterm_gui::termwindow::resize > cannot resize window to match Some(RowsAndCols { rows: 66, cols: 125 }) because window_state is MAXIMIZED
> wezterm.gui.enumerate_gpus()
[
    {
        "backend": "Vulkan",
        "device": 26591,
        "device_type": "DiscreteGpu",
        "driver": "AMD open-source driver",
        "driver_info": "2022.Q4.4 (LLPC)",
        "name": "AMD Radeon RX 480 Graphics",
        "vendor": 4098,
    },
    {
        "backend": "Gl",
        "device": 0,
        "device_type": "Other",
        "name": "AMD Radeon RX 480 Graphics (polaris10, LLVM 15.0.7, DRM 3.49, 6.2.8-zen1-1-zen)",
        "vendor": 4098,
    },
]

Same issue with nvidia GTX970 using proprietary drivers (sway run with --unsupported-gpu)

Debug Overlay
wezterm version: 20230320-124340-559cb7b0 x86_64-unknown-linux-gnu
Window Environment: Wayland
OpenGL version: WebGPU: name=NVIDIA GeForce GTX 970, device_type=DiscreteGpu, backend=Vulkan, driver=NVIDIA, driver_info=525.89.02, vendor=4318, device=5058
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
16:24:26.192 WARN wezterm_gui::termwindow::resize > cannot resize window to match Some(RowsAndCols { rows: 62, cols: 125 }) because window_state is MAXIMIZED
> wezterm.gui.enumerate_gpus()
[
    {
        "backend": "Vulkan",
        "device": 5058,
        "device_type": "DiscreteGpu",
        "driver": "NVIDIA",
        "driver_info": "525.89.02",
        "name": "NVIDIA GeForce GTX 970",
        "vendor": 4318,
    },
    {
        "backend": "Gl",
        "device": 0,
        "device_type": "Other",
        "name": "NVIDIA GeForce GTX 970/PCIe/SSE2",
        "vendor": 4318,
    },
]

[develop7]

Confirming the issue for NVIDIA RTX 3080 in GNOME 44.0 on openSUSE Tumbleweed 20230405:

Debug Overlay
wezterm version: 20230326.111934.3666303c x86_64-unknown-linux-gnu
Window Environment: Wayland
OpenGL version: WebGPU: name=NVIDIA GeForce RTX 3080, device_type=DiscreteGpu, backend=Vulkan, driver=NVIDIA, driver_info=525.105.17, vendor=4318, device=8726
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
> wezterm.gui.enumerate_gpus()
[
    {
        "backend": "Vulkan",
        "device": 8726,
        "device_type": "DiscreteGpu",
        "driver": "NVIDIA",
        "driver_info": "525.105.17",
        "name": "NVIDIA GeForce RTX 3080",
        "vendor": 4318,
    },
    {
        "backend": "Vulkan",
        "device": 0,
        "device_type": "Cpu",
        "driver": "llvmpipe",
        "driver_info": "Mesa 23.0.1 (LLVM 16.0.0)",
        "name": "llvmpipe (LLVM 16.0.0, 256 bits)",
        "vendor": 65541,
    },
    {
        "backend": "Gl",
        "device": 0,
        "device_type": "Other",
        "name": "NVIDIA GeForce RTX 3080/PCIe/SSE2",
        "vendor": 4318,
    },
]

[jokeyrhyme]

Okay, I finally took a look at the source code

I instrumented this WaylandWindowInner.invalidate() function:

• called during keyboard input (typing whilst focused), does NOT call do_paint()
• called during mouse movement over the window, DOES call do_paint() (expected)
• called during mouse click in the window, does NOT call do_paint()
• called during resizing the window while focused, does NOT call do_paint()
• called whenever shell output changes (running yes), does NOT call do_paint()
• NOT called during resizing the window while not focused (expected, this is not the outer WaylandWindow?)

But, I short-circuited it so that it always sets self.invalidated = true and calls do_paint() and that still didn't fix it

After some more instrumentation, I think the problem is that this part of do_paint() doesn't run when we need it to

I removed the check at the top of do_paint(), and that does seem to fix the issue, but focusing another window and then focusing wezterm again causes the issue to come back

[jokeyrhyme]

With direction from @wez , this seems to have fixed it, at least for me under sway(wlroots):
40bb053

But, I'm not sure if this breaks anything else, and I'm not sure if doing this is a no-no according to the wayland specification, etc

It'd be great if this could be tested under some other wayland compositors (both with and without WebGPU) to confirm that system resource usage hasn't substantially-increased (or if there are any other bugs)

It'd also be great if someone who understands wayland more than me could take a look and see if this isn't the worst approach

The long-term fix might not look like this at all, too

[jokeyrhyme]

Okay, with more direction, and without bypassing those frame checks, trying wayland with the different PresentModes https://docs.rs/wgpu/latest/wgpu/enum.PresentMode.html here

wezterm/wezterm-gui/src/termwindow/webgpu.rs

Line 323 in 56ae2fe

present_mode: wgpu::PresentMode::Fifo,

• AutoVsync: bug
• AutoNoVsync: bug
• Fifo (current value in main branch): bug
• FifoRelaxed: thread 'main' panicked at 'Error in Surface::configure: requested present mode FifoRelaxed is not in the list of supported present modes: [Mailbox, Fifo]'
• Immediate: thread 'main' panicked at 'Error in Surface::configure: requested present mode Immediate is not in the list of supported present modes: [Mailbox, Fifo]'
• Mailbox: bug

[jokeyrhyme]

Okay, new patch up: jokeyrhyme@2574933

I tried both with WebGPU and without, focused and not focused, switching to different workspaces and back, seems like the suggested patch has fixed it

[jokeyrhyme]

I've raised a PR: #3467

[jokeyrhyme]

Haha, I'll drop the PR :P

[wez]

Thanks for working through this @jokeyrhyme !
I just pushed a version of the commit with a bit more exposition in the comments

[wez]

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

[VarLad]

This does fix the issue, thanks!
On the other hand now, another issue I notice now is, continuous button presses are rather slow, in the webgpu frontend.

I think that needs its own issue though

[Guara92]

Thanks, fixed for me too!

[colemickens]

Wezterm has finally taken its throne as my daily driver under Sway with webgpu! Thanks @wez and @jokeyrhyme!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.