Linux nvidia nouveau tearing

Как убрать тиринг на Nvidia в Ubuntu Linux?

Многие владельцы видеокарт на базе Nvidia сталкиваются с проблемой тиринга на экране. Тиринг — это визуальные артефакты на экране, когда несколько кадров как бы склеиваются в один. Особенно заметен бывает тиринг на динамичных сценах фильмов, при прокрутке страницы или перетаскивании окна. В многомониторных конфигурациях иногда он появляется лишь на одном мониторе.

Проверить наличие тиринга можно на этом видеоролике в полноэкранном режиме.

Как убрать тиринг?

Как же избавиться от тиринга на Nvidia? На самом деле, все просто, и соответствующая опция старательно была добавлена разработчиками проприетарных драйверов.

Для начала следует удостовериться, что у вас установлены проприетарные драйвера Nvidia последней версии — это можно сделать из приложения «Дополнительные драйверы» в Ubuntu.

Далее запускаем приложение NVIDIA X Server Settings (nvidia-settings в терминале). Переходим во вкладку OpenGL Settings и удостовериваемся, что опции «Sync to VBlank» и «Allow Flipping» включены.

Далее переходим на вкладку X Server Display Configuration и нажимаем там Advanced для перехода к расширенным настройкам.

Следует поставить галочки напротив пунктов «Force Composition Pipeline» и «Force Full Composition Pipeline». Если вдруг таких пунктов нет — читаем дополнение ниже! Изменения можно тут же проверить — после нажатия Apply.

Если все хорошо, и тиринг ушел, изменения следует сохранить — для этого нажимаем Save to X Configuration File и сохраняем. Перезагружаемся.

Все, готово, теперь тиринга быть не должно!

Что делать, если опций в NVIDIA X Server Settings нет?

Если в NVIDIA X Server Settings отсутствуют опции «Force Composition Pipeline» и «Force Full Composition Pipeline» — это не проблема, их можно прописать вручную в конфигурационный файл. Однако вы это делаете на свой страх и риск.

Для начала устанавливаем для каждого монитора рабочее разрешение и частоту обновления 60 Гц. Нажимаем Apply, после чего Save to X Configuration File. Однако в файле конфигурации нам надо прописать данные опции, поэтому нажимаем Show preview для редактирования, разворачиваем окно.

Пролистываем файл до Section «Screen». Там должна быть опция metamodes, что-то вроде этого:

Option «metamodes» «1920x1080_60 +0+0»

(+0+0 — это так называемое смещение монитора, используется в случае многомониторных конфигураций)

Наша задача — прописать в конец эти опции, до закрывающих кавычек:

В результате должно получиться нечто следующее:

Сохраняем файл, перезагружаемся — должно работать!

Источник

Nouveau

This article covers the open-source Nouveau driver for NVIDIA graphics cards. For information about the proprietary driver, see NVIDIA.

Find your card’s code name (a more detailed list is available on Wikipedia), and compare it with the feature matrix for supported features.

Contents

Installation

Install the mesa package, which provides the DRI driver for 3D acceleration.

• For 32-bit application support, also install the lib32-mesa package from the multilib repostory.
• For the DDX driver (which provides 2D acceleration in Xorg), install the xf86-video-nouveau package.

Loading

The Nouveau kernel module should load automatically on system boot. If it does not happen, then:

• Make sure you do not have nomodeset or vga= as a kernel parameter, since Nouveau requires kernel mode-setting.
• Also, check that you do not have Nouveau disabled using any modprobe blacklisting technique within /etc/modprobe.d/ or /usr/lib/modprobe.d/ .
• If all above still fails to load nouveau check dmesg for an opcode error. Add nouveau.config=NvBios=PRAMIN to your Kernel parameters to prevent module unloading.[1]
• Check if /etc/X11/xorg.conf exists and is referencing nvidia driver. It is probably a good idea to rename the file.

Enable early KMS

Kernel mode setting (KMS) is required by the Nouveau driver. By default, the KMS is done after the other kernel modules are loaded. You will see the text «Loading modules» and the size of the text may change, possibly with an undesirable flicker. See the Nouveau KernelModeSetting page for more details.

It is also possible to start the KMS as early as possible in the boot process, when the initramfs is loaded.

To do this, add nouveau to the MODULES array in /etc/mkinitcpio.conf (module names are separated by spaces):

If you are using a custom EDID file, you should embed it into initramfs as well:

Re-generate the initial ramdisk image:

If you are experiencing troubles with Nouveau leading to rebuild nouveau-drm several times for testing purposes, do not add nouveau to the initramfs. It is too easy to forget to rebuild the initramfs and it will just make any testing harder. Just use «Late start» until you are confident the system is stable. There might be additional problems with initramfs if you need a custom firmware (generally not advised).

Tips and tricks

Keep NVIDIA driver installed

If you want to keep the proprietary NVIDIA driver installed (and are not using OpenGL), but want to use the Nouveau driver, comment out nouveau blacklisting in /etc/modprobe.d/nouveau_blacklist.conf , /usr/lib/modprobe.d/nvidia.conf , or /usr/lib/modprobe.d/nvidia-dkms.conf modifying it as follows:

And tell Xorg to load nouveau instead of nvidia by creating the file /etc/X11/xorg.conf.d/20-nouveau.conf with the following content:

If you already used the NVIDIA driver, and want to test Nouveau without reboot, make sure the ‘nvidia’ module is no longer loaded:

Then load the ‘nouveau’ module:

And check that it loaded fine by looking at kernel messages:

Installing the latest development packages

To get the latest Nouveau improvements

Dual head

See Multihead#RandR how to setup multiple monitors by using RandR.

Setting console resolution

You can pass the resolution to nouveau with the video= kernel line option (see KMS).

Power management

The lack of proper power management in the nouveau driver is one of the most important causes of performance issues, since most cards will remain in their lower power state with lower clocks during their use. Experimental support for GPU reclocking is available for some cards (see the Nouveau PowerManagement page) and since kernel 4.5 can be controlled through a debugfs interface located at /sys/kernel/debug/dri/*/pstate .

For example, to check the available power states and the current setting for the first card in your system, run:

It is also possible to manually set/force a certain power state by writing to said interface:

Fan control

If it is implemented for your card you can configure fan control via /sys .

pwm1_enable can be set to 0, 1 or 2 meaning NONE, MANUAL and AUTO fan control. If set to manual fan control, you can set pwm1 manually, for example to 40 for 40%.

You can also set it by udev rule:

Optimus

You have two solutions to use Optimus on a laptop (aka hybrid graphics, when you have two GPUs on your laptop): bumblebee and PRIME

Vertical Sync

The factual accuracy of this article or section is disputed.

Xorg compositors are prone to show issues with Nouveau. Unlike most of them, Picom offers lots of options to tweak for a smoother and tearing free result. A configuration which is expected to deliver a good result would be the following:

Troubleshooting

Add drm.debug=14 and log_buf_len=16M to your kernel parameters to turn on video debugging:

Create verbose Xorg log:

View loaded video module parameters and values:

Disable MSI

If you are still having problems loading the module or starting X server append nouveau.config=NvMSI=0 to your Kernel parameters.

Phantom output issue

It is possible for the nouveau driver to detect «phantom» outputs. For example, both VGA-1 and LVDS-1 are shown as connected but only LVDS-1 is present.

This causes display problems and/or prevent suspending on lid closure.

Kernel parameters

The problem can be overcome by disabling the phantom output (VGA-1 in the examples given) with Kernel parameters:

Where d = disable.

The nouveau kernel module also has an option to disable TV-out detection [2]:

Xorg configuration

The phantom output can be disabled in Xorg by adding the following to /etc/X11/xorg.conf.d/20-nouveau.conf :

Xrandr

Xrandr can disable the output:

This can be added to the xinit configuration.

Random lockups with kernel error messages

Specific Nvidia chips with Nouveau may give random system lockups and more commonly throw many kernel messages, seen with dmesg. Try adding the nouveau.noaccel=1 kernel parameter. See Fedora:Common kernel problems#Systems with nVidia adapters using the nouveau driver lock up randomly for more information.

As an alternative you can also use the QT_XCB_FORCE_SOFTWARE_OPENGL=1 environment variable to disable OpenGL acceleration in Qt applications.

Flat Panel Table Invalid

This article or section needs expansion.

NVIDIA graphics cards with recent chipsets can cause startup issues — this includes X11 being unable to start and lspci freezing indefinitely[3][4][5][6][7].

This can break live distributions/installation media. This can be detected either by running lspci, or checking the systemd journal for the error:

The system may start if the Nouveau driver is disabled by passing the following kernel parameters:

The Nouveau driver can then be loaded using

The system should then function correctly. If you have another Nvidia graphics card, or just want to be safe, you can disable the offending card using:

The NVIDIA proprietary driver currently works correctly (version 381).

Источник

Arch Linux

You are not logged in.

#1 2017-06-06 20:49:11

[Solved] Screen Tearing (again) with Nvidia Drivers

Screen Tearing with Nvidia Drivers
Hello,

My computer used to be screen tear free, until recently. This was achieved by using the proprietary driver and compton. Recently though, I’ve noticed that my screen tearing is coming back. Before I only had screen tearing with the XFCE compositor, and would have no screen tearing with either no compositor or using compton. Is anyone else having this issue? I know that the nvidia driver is prone to screen tearing so I fear that there they may be no solution.

GPU: Nvidia GTX960
CPU: Intel i7-4790
Kernel: 4.11.2-1-ARCH 4.11.2-1-ARCH
Xorg-server: 1.19.3-2
Nvidia: 381.22-2

Please let me know if any more information is needed,
Thank you!

Last edited by Disco Dave (2017-06-13 01:35:36)

#2 2017-06-06 20:56:55

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

Does command in terminal, as user:

I possess a device, in my pocket, that is capable of accessing the entirety of information known to man.
I use it to look at funny pictures of cats and to argue with strangers.

#3 2017-06-06 20:57:48

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

One thing I still use to this day and which has fixed most tearing issues for me, was exporting

in /etc/profile or similar, at least with KWin there was a race condition between the KWin compositor and the driver which switching to USLEEP for yielding. Some people reported other issues with that, although I haven’t seen any and most of my tearing woes are gone.

#4 2017-06-06 21:04:45

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

@V1Del: No cigar on that one, thanks though.

@dockland: That did actually remove some screen tearing and least took it to a more tolerable level, however it disabled my other monitor. Sorry I neglected to mention that I use two monitors. The randr setup I’m using as follows

#5 2017-06-06 21:06:46

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

Just for the sanity check, you did log out and back in? These variables aren’t exported just from adding them to the file

#6 2017-06-06 21:11:04

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

Just for the sanity check, you did log out and back in? These variables aren’t exported just from adding them to the file

Yes, I rebooted my system after adding your suggested line to /etc/profile

#7 2017-06-06 21:28:21

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

@V1del, he’s using compton.

The check in kwin is due to sched_yield() causing busy waits (with cpu load) when blocking for the vblank signal (only applies when double buffering, triple buffering doesn’t block)
USLEEP will usleep(0) («no» cpu load) in this case.

Be aware that while this may improve things, only one output can be synced (this is a hardware limitation, I’m at hand not sure how daisy chained DPs would behave)

Online

#8 2017-06-07 01:50:59

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

@V1del, he’s using compton.

The check in kwin is due to sched_yield() causing busy waits (with cpu load) when blocking for the vblank signal (only applies when double buffering, triple buffering doesn’t block)
USLEEP will usleep(0) («no» cpu load) in this case.

Be aware that while this may improve things, only one output can be synced (this is a hardware limitation, I’m at hand not sure how daisy chained DPs would behave)

Thanks for the suggestions, but sadly i still had screen tearing on both monitors with and withouyt a compositor enabled.

#9 2017-06-07 02:10:21

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

Last edited by trytipARCH (2017-06-11 03:52:08)

#10 2017-06-07 05:51:28

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

You need to restart X11 and must not have a global Xorg.conf to have this applied.

This brings us to questions about your setup 😉

a) your desktop manager (GDM?)
b) your xorg log
c) the output of «glxinfo»
d) the output of xrandr -q
e) you compton config
f) compton command line (whether you just run «compton» or pass some more parameters to it) and compton shell output.

Online

#11 2017-06-08 23:08:15

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

@V1del, he’s using compton.

The check in kwin is due to sched_yield() causing busy waits (with cpu load) when blocking for the vblank signal (only applies when double buffering, triple buffering doesn’t block)
USLEEP will usleep(0) («no» cpu load) in this case.

Be aware that while this may improve things, only one output can be synced (this is a hardware limitation, I’m at hand not sure how daisy chained DPs would behave)

This took my screen tearing a reasonable amout with an occasional small tear that I can live with.

You need to restart X11 and must not have a global Xorg.conf to have this applied.

This brings us to questions about your setup 😉

a) your desktop manager (GDM?)
b) your xorg log
c) the output of «glxinfo»
d) the output of xrandr -q
e) you compton config
f) compton command line (whether you just run «compton» or pass some more parameters to it) and compton shell output.

a) XFCE and XFWM
b) Here is my /var/log/Xorg.0.log

c) glxinfo output

e) My compton.config

f) I start the compton in my Sessions and Startups on XFCE with the following command

#12 2017-06-09 22:20:36

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

I used to have screen tearing too, was a nightmare with mpv and scrolling in browsers, i use compton and the proprietary driver too.

However it’s been months since i had the issue, what i think fixed it was having:

inside the Section «Device» of my /etc/X11/xorg.conf.d/20-nvidia.conf

Looking at my compton config and yours i see no difference, here is the part relating to my nvidia card from 20-nvidia.conf file and compton file:

* To those suggesting the forcefullcomposition option, note although it can fix the issue sometimes, it makes gaming terrible (low fps)

#13 2017-06-10 12:11:42

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

You are all showing configs that use a line: vsync = «opengl-swc». That setting introduces pretty terrible latency for me compared to vsync = «opengl». I notice this when moving a window around. The mouse pointer gets a lot less in front of the spot where I grabbed the window when I use «opengl».

Another thing about that, the «sw-opti = true» setting together with «opengl-swc» perhaps reduces this latency, but it makes animations look less smooth.

The relevant settings in my compton.conf are this here (no tearing for me, but I only use one monitor, not two):

This is using nvidia drivers. In the Xorg config, there’s nothing special.

[. ] The randr setup I’m using as follows

I remember something about the graphics card having two clock generators that are used for the signals it outputs through the DVI/HDMI ports while the DisplayPort connectors are using something else on the card for their signal. Did you maybe change how you connect the monitors when the tearing starting showing up again for you? Perhaps connecting both monitors through DVI/HDMI or both through DisplayPort can change something about how the card and driver work with regards to vsync.

Last edited by Ropid (2017-06-10 12:23:20)

#14 2017-06-10 12:22:48

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

«pretty terrible latency» — not sure about the «terrible» but the description of that sounds like glXWaitVideoSync* calls which isn’t supported by nvidia and latter SNI, no idea about kms, but it’s quite likely that you simply do not sync at all, resp. there’s a double sync in the global pipeline (some «tearfree» driver setting?)

Online

#15 2017-06-10 12:37:30

Re: [Solved] Screen Tearing (again) with Nvidia Drivers

«pretty terrible latency» — not sure about the «terrible» but the description of that sounds like glXWaitVideoSync* calls which isn’t supported by nvidia and latter SNI, no idea about kms, but it’s quite likely that you simply do not sync at all, resp. there’s a double sync in the global pipeline (some «tearfree» driver setting?)

No, this is definitely not the case with vsync being done by something else. Compton really is the thing that does the vsync. About it being «terrible latency» or not, I think it’s perhaps the other way around, «opengl-swc» shows the normal latency I remember from enabling vsync in games, while using «opengl» makes compton manage to do something special where latency is minimized.

I do not have that driver setting ForceFullCompositionPipeline in my X config (it makes animations in games look bad), the «sync to vblank» check box in nvidia-settings is not checked, and there’s no «__GL_SYNC_TO_VBLANK» environment variable set.

Источник