ValveSoftware
Nvidia flicker
Hi, anyone experiences this flicker, too? How to fix? Geforce 1660ti on latest gamescope on arch linux.
https://www.youtube.com/watch?v=z9rk5lA2I0s
Oh, yea I'm experiencing the same kind of flickering. I asked, because I wanted to report the same thing. Because it's the same issue I'm going to expand upon the behavior I observed.
In my case it only seems to occur when running in embedded mode and with -h the same as -H (or the same as monitor's if -H is unspecified). Tested on multiple monitors (different resolutions, aspect ratios, refresh rates), with the same effect. All on DisplayPort, just in case that's relevant.
Workaround:
Using -h to change rendered resolution to something else (lower, higher, can be even off by 1 pixel) completely gets rid of the flicker.
Tested on 2070, EndeavourOS, using current up-to-date gamescope package from the Arch repo, up-to-date proprietary driver (nvidia-dkms)
I just tested with the Nvidia open driver (nvidia-open-dkms) and the issue ~~does NOT occur for me~~. It might be an Nvidia driver issue. EDIT: Never mind, I noticed it does still happen, although to a way lesser extent, sometimes even unnoticeable, as happened in my case ^^;
@DocMAX You also have a Turing card so you might want to try the open driver instead (nvidia-open or nvidia-open-dkms depending on what you're currently using), but it doesn't support G-sync among other things
trying the open drivers, but i get this? nvidia-utils is installed.
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:82] Creating headless backend
wlserver: [libseat] [libseat/libseat.c:73] Seat opened with backend 'seatd'
wlserver: [libseat] [libseat/backend/seatd.c:212] Enabling seat
wlserver: [backend/session/session.c:110] Successfully loaded libseat session
vulkan: selecting physical device 'NVIDIA GeForce GTX 1660 Ti': queue family 2
vulkan: physical device supports DRM format modifiers
vulkan: physical device has no primary node
Failed to initialize Vulkan
¯\_(ツ)_/¯ It works for me just fine. Are you sure you didn't uninstall something else while swapping out the driver? I guess you can switch back to proprietary if it causes issues for you.
Oh, yea I'm experiencing the same kind of flickering. I asked, because I wanted to report the same thing. Because it's the same issue I'm going to expand upon the behavior I observed.
In my case it only seems to occur when running in embedded mode and with
-hthe same as-H(or the same as monitor's if -H is unspecified). Tested on multiple monitors (different resolutions, aspect ratios, refresh rates), with the same effect. All on DisplayPort, just in case that's relevant.Workaround: Using
-hto change rendered resolution to something else (lower, higher, can be even off by 1 pixel) completely gets rid of the flicker.Tested on 2070, EndeavourOS, using current up-to-date
gamescopepackage from the Arch repo, up-to-date proprietary driver (nvidia-dkms)
Hey Chris I was having the same flickering and just changed 1 pixel and it's gone now thanks!!
Also how do you run gamescope on embedded mode? My Nvidia + arch doesn't seem to go well running on embedded
Also how do you run gamescope on embedded mode? My Nvidia + arch doesn't seem to go well running on embedded
What do you mean "doesn't go well"? It works for me just fine with gamescope [options] -- <game> if it's a standalone game and gamescope --steam [options] -- steam -tenfoot if I want to play a Steam game. My options are usually just -O <monitor> to pick monitor
Also how do you run gamescope on embedded mode? My Nvidia + arch doesn't seem to go well running on embedded
What do you mean "doesn't go well"? It works for me just fine with
gamescope [options] -- <game>if it's a standalone game andgamescope --steam [options] -- steam -tenfootif I want to play a Steam game. My options are usually just-O <monitor>to pick monitor
I'd run my games with gamescope nested but when I try to run gamescope on a different tty it just throws a lot of errors and for what I have been reading, Nvidia + gamescope embedded doesn't work yet. That's why I'm asking how did you make it work?
I'd run my games with gamescope nested but when I try to run gamescope on a different tty it just throws a lot of errors and for what I have been reading, Nvidia + gamescope embedded doesn't work yet. That's why I'm asking how did you make it work?
I didn't really put any effort into "making" it work, it just works for me, save for some visual glitches I reported here.
trying the open drivers, but i get this? nvidia-utils is installed.
No CAP_SYS_NICE, falling back to regular-priority compute and threads. Performance will be affected. wlserver: [backend/headless/backend.c:82] Creating headless backend wlserver: [libseat] [libseat/libseat.c:73] Seat opened with backend 'seatd' wlserver: [libseat] [libseat/backend/seatd.c:212] Enabling seat wlserver: [backend/session/session.c:110] Successfully loaded libseat session vulkan: selecting physical device 'NVIDIA GeForce GTX 1660 Ti': queue family 2 vulkan: physical device supports DRM format modifiers vulkan: physical device has no primary node Failed to initialize Vulkan
my fault. for some reason i had blacklisted the nvidia modules.
Also how do you run gamescope on embedded mode? My Nvidia + arch doesn't seem to go well running on embedded
What do you mean "doesn't go well"? It works for me just fine with
gamescope [options] -- <game>if it's a standalone game andgamescope --steam [options] -- steam -tenfootif I want to play a Steam game. My options are usually just-O <monitor>to pick monitorI'd run my games with gamescope nested but when I try to run gamescope on a different tty it just throws a lot of errors and for what I have been reading, Nvidia + gamescope embedded doesn't work yet. That's why I'm asking how did you make it work?
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317#note_1358617
And how exactly does this happen? If we're implementing implicit sync, it's the responsibility of the GL driver in use by glamor (and any kernel driver backing it), correct? That's where things get complicated. There's no clear command that signals the GL driver to "latch" the implicit sync fence from the dma-buf by using the ioctl() that converts it to an explicit sync FD, so we just have to continuously monitor all textures/images/whatever in use by any command buffer and try extracting an implicit fence from any of them that are backed by imported dmabufs every time we want to submit commands down the the hardware, in every application, not just Xwayland+glamor, because Xwayland+glamor use the GL driver just like any other app does. That's what I'm talking about by the complexity that I'd prefer to avoid. The performance benefit is precisely avoiding that complexity running in every app. Agreed that's just for our driver stack, and we are indeed working on patches to add the necessary support to X. We've only been wary of this because similar proposals have died in review before because there didn't seem to be sufficient resolve to close on some of the interaction issues, unless there was other offline conversation not reflected on-list: https://lists.x.org/archives/xorg-devel/2017-November/055172.html I can't speak to other driver stacks, but I know neither of the other major desktop IHVs are happy with the implicit sync status quo either, and have each proposed their own plans to move away from it. In particular, the patches from @jekstrand you mention are supposed to be just a crutch to get past the chicken-and-egg issue, enabling the work to convert to explicit sync more generally: https://lwn.net/Articles/814587/ And AMD doesn't seem too keen on implicit sync these days either: https://lists.freedesktop.org/archives/dri-devel/2021-April/303671.html
I speculate the flickering might be related to the fence issue with Nvidia drivers. If only Nvidia talked earlier then, the OSS community can make proper investments into explicit fencing.....
