This may be related to a similar issues noticed on KDE (which doesnt support choosing the GBM backend yet) using the EGLStreams backend where similar xwayland windows rendering without vsync result in the display of what i can only assume is the wrong frame. If we assume a program is outputting frames 1,2,3,4,5,6,7,8,9,10 during this misrendering it appears as though frames are rendered 1,3,2,5,4,7,8,10,9. Anther way to describe this might be objects appear to jitter between their previous location and their current location.
bumping this thead with hope to get some devs attention to this issue, as its still not resolved as of 510.60.02 driver. flickering is heavy on xwayland windows and the only solution is to move the window around or force it to redraw somehow.
@aplattner sorry for a direct mention, but do you know what’s causing this strong flickering on many applications with wlroots (and sway) on Ampere GPUs?
I don’t see this issue on older cards.
All drivers from 490(or 495) to 510 and r515 are affected.
If we find the root cause we can get an issue opened to fix it in the future.
Somebody from the NVIDIA devs stated that Sway works flawlessly with GBM and this is true if there wasn’t flickering.
I think I’m experiencing the same issue, although it only surfaced with xorg-xwayland-hidpi. Perhaps the issue was there without the hidpi patch, but the scaling was so bad I never noticed. I’m on 4k with scale 2.
I can reproduce it two ways: a simple xwayland instance fullscreen and unfocused, OR xwayland in gamescope.
The symptoms are that there are artifacts and flickering in the same place I get tearing in Xorg (vsync? what’s that?), but instead of being simple tears, they have a black and white outline.
I’m also having this issue. It made Firefox unusable until I forced it to launch under Wayland, it makes Discord unusable, and it makes Bitwig Studio unusable. I only have a few days left to start a return on my 4090, and I’m seriously thinking about it after fighting with NVIDIA’s drivers for several weeks.