Very slow screen updates on NVIDIA

[czettnersandor]

I have an issue that may be library related, because I experience something similar with the Lapce editor. This is how I could best describe it: I launch a program, it appears swiftly and with the correct content. For example, Alacritty appears with a full render of Zellij, if it was already open in a different session. After that, I type something and it may appear or may not. If I move the mouse out of the window, then back again, the window updates with the content I typed earlier. Otherwise, it would take about 5-60 seconds for the change to appear on the screen. It seems to be getting worse the longer I stay in Niri. After about 5 minutes, only moving the mouse out, then into a window will update the window.

Native Niri windows, for example, the exit confirmation and the keyboard shortcut help appears to immune to this problem, but I would not know, since these have static content. I tried both with XWayland and native Wayland applications, same result.

System Information

• niri version: niri 0.1.1 (72c8f56)

• GPU: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)

• CPU: AMD Ryzen 9 5950X 16-Core Processor

[YaLTeR]

Hey! I've heard similar bug reports from NVIDIA users before. I'm not entirely sure what they are caused by.

Have you by chance enabled VRR / adaptive sync while using some other compositor or X11 before? In another issue similar artifacts were observed because Smithay does not currently reset the VRR state. So if you enabled VRR before, try running the same compositor where you did it and disabling it.

Otherwise, do the glitches still occur if you have something constantly redrawing on the screen, like having weston-simple-egl running and visible?

[czettnersandor]

@YaLTeR Thanks for the quick reply. VRR is off as reported by hyprctl monitors if I switch to hyprland. weston-simple-egl is behaving strangely, but does not affect any other window. The triangle is not moving at all, only moves when I move the mouse on the empty (dark grey) desktop area. That explains the other windows as well and they are actually updating when the mouse cursor is in the gap between them - and moving -, not when I move the mouse out and in.

[ids1024]

The latest Nvidia 550 beta driver fixes an issue with extremely slow rendering on 1000 series cards, that may be a bit like that. I'm not sure about 900 series cards.

[CheesecakeCG]

The latest Nvidia 550 beta driver fixes an issue with extremely slow rendering on 1000 series cards

The issues still happens on my GTX1660 (TU116) with the 550 drivers and FreeSync disable on the monitor.

[ids1024]

Interesting. That's a bit more surprising. I know with a 1650 Mobile (TU117) I see slow but usable performance (on cosmic-comp and Gnome Shell) for Intel+Nvidia prime. But using just the Nvidia card it seems to work perfectly fine, matching the monitors refresh rate.

I don't think I've tried niri on that system.

[ids1024]

With my 1650+Intel system, I see niri doesn't currently handle PRIME with Nvidia drivers properly. The correct solution for that is still waiting on driver improvements, but cosmic-comp has an awkward elem.sync.wait to deal with that. On Niri I get artifacting on Nvidia monitors. I also see windows not updating, perhaps the same synchronization issue. The applications don't seem to actually freeze.

But those issues seem to be PRIME related, and I'm not obviously seeing the same issue reported here.

[YaLTeR]

Does the wait-for-frame-completion-before-queueing debug config flag help with this, or is something different needed?

[ids1024]

wait-for-frame-completion-before-queueing seems to fix the visual artifacting. But the issue with windows not updating doesn't seem to be affected by that one. Not sure what's going on there.

Edit: And it seems to still happen with render-drm-device "/dev/dri/renderD129". Odd.

[YaLTeR]

Niri disables the color transform capability, could it be that?

Edit: there's a debug config flag for that too.

Edit 2: apparently I never documented it. enable-color-transformations-capability

[ids1024]

enable-color-transformations-capability doesn't seem to change anything for me.

Though anyway, I guess the issue I'm seeing (other than the one addressed by wait-for-frame-completion-before-queueing) is the same one others are reporting here. And not related to PRIME. It definitely doesn't happen with cosmic-comp, so something is different.

[czettnersandor]

I switched to nouveau driver briefly. All problems go away.

Lapce (the text editor) works Niri works as well

This is clearly an nvidia driver issue, or some Rust library that's common with Lapce does not play well with Nvidia. I forgot to mention I experience the same problem with my own game on Bevy if I enable the "wayland" feature on the bevy cargo package. Nothing moves after a few frames on the first few seconds. The picture freezes. Sound continues for a while, but then stops.

[czettnersandor]

After some issue search on Github, this resolved the issue on Lapce: FLOEM_FORCE_TINY_SKIA="1" lapce see: https://github.com/lapce/lapce/issues/2902 I'm going to try to start niri with the same env variable

[czettnersandor]

No change in behaviour using FLOEM_FORCE_TINY_SKIA. Which of course specific for Lapce, but I think it points to the right direction. Seems like Floem is using this flag to use software renderer with winit. Maybe a winit bug?

Enabling wait-for-frame-completion-before-queueing in the config file makes things worse, as now the mouse also freezes and there's no way to make anything to redraw.

[Uklosk]

I switched to nouveau driver briefly. All problems go away.

Lapce (the text editor) works Niri works as well

This is clearly an nvidia driver issue, or some Rust library that's common with Lapce does not play well with Nvidia. I forgot to mention I experience the same problem with my own game on Bevy if I enable the "wayland" feature on the bevy cargo package. Nothing moves after a few frames on the first few seconds. The picture freezes. Sound continues for a while, but then stops.

Do you have GSP enabled?

I have the same problems with GSP enabled in nouvaeu, without GSP it works just fine.

Sway works fine with GSP enabled.

[Uklosk]

It is fixed for me now in mesa-git.

EDIT: Nope, for some reason it works now under certain circunstances, but depends on the content displayed on the screen.

[cmeissl]

I also occasionally observe a similar behavior on an intel only laptop. Scrolling or keyboard input seems to be stuck until the pointer is moved or some other unknown condition happens. At first it looked like a frame scheduling issue as it seemed the window will refresh if something (clock, cpu, ...) in my bar changes. But I am not totally sure tbh.

[ids1024]

Seems to occur for me with Nouveau as well, so not an Nvidia driver issue specifically.

[cmeissl]

I finally managed to catch a WAYLAND_DEBUG log when this happens. (Note, this was from yesterday, so did not include the zero presentation time change)

The log also points in the direction of a frame callback issue as the callback is delayed until the next pointer move.

niri.alacritty.frame.issue.txt

[YaLTeR]

I'm getting reports that some of these problems were fixed in 0.1.3, so please feel free to try again and write if it works now.

[oatiz]

I'm getting reports that some of these problems were fixed in 0.1.3, so please feel free to try again and write if it works now.

---

It works! 😄

[YaLTeR]

I'm going to close this; if there are other niri-specific problems on NVIDIA please open a new issue so that it doesn't get conflated.