Лаги/статтеры/фризы nvidia

Примерно полгода назад последний раз заходил в linux десктоп - была видеокарта RX 570 и всё работало отлично с драйвером amdgpu.
Недавно обновил аппаратуру, теперь видео RTX 2070 Super. Наблюдаю следующую проблему с проприетарным драйвером:
в любом композитном менеджере (kwin, mutter, gala) при открытии любого окна, даже например всплывающего окна календаря, происходит очень заметный лаг/фриз/статтер.
Как проверяю - в браузере открывал vsynctester.com и дальше нажимаю на менюшки, запускаю приложения и вижу всплески на графике задержки vsynctester. Проблема в том, что фриз происходит всегда, то есть проблема судя по всему не в первичной подгрузке ассетов приложения, потому что при втором и следующих запусках происходит то же самое, хотя казалось бы кеш уже есть.
Проверял, повторюсь, везде - KDE (Kwin-lowlatency тоже пробовал - никаких улучшений), GNOME, Pantheon.
Более того, помимо Арча проверял в Федоре - там то же самое.
Что пробовал: force (full) composite pipeline, отключение flipping, выставление powermizer в производительный режим, включение тройной буферизации. Не работает ничего ни в каких комбинациях.
Вижу, что даже тут на форуме люди с Nvidia замечали, что интерфейс после обновлений стал дёрганный - подозреваю, именно это они и наблюдают. Нагуглил всего одну похожую проблему (https://github.com/PapirusDevelopmentTeam/arc-kde/issues/117), но там помогает смена темы в KDE - мне же не помогает даже смена DE. Куда ещё копать не представляю. Думал, может всё-таки дело в i/o или cpu планировщике - ставил разные ядра, включая realtime, пробовал разные планировщики для nvme - ничего не помогает.
1060 никаких фризов на квине и компизе.
nvidia-smi глянуть и nvtop
Глянул. Ну растёт загрузка GPU с 15% до 40%, потом резко вниз. Больше ничего не увидел.
marlock
Ну растёт загрузка GPU с 15% до 40%
Иногда бывает запаздывает рост частоты, карта и проц работают на минималках от того и фризы.
Можно проверить подгрузив немного чтобы частоты поднялись
например
 gputest /test=fur /width=840 /height=640
и попереключать окна.

Проверить еще что бы не было проблем с опенгл
glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:

И какой бакенд в квине включен ( надо опенгл)

Проверить /etc/X11/xorg.conf попробовать TripleBuffer включить

[oleg@vs220 ~]$ cat /etc/X11/xorg.conf
Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "PrimaryGPU" "no"
    ModulePath "/usr/lib/nvidia/xorg"
    ModulePath "/usr/lib/xorg/modules"
EndSection

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Samsung SMBX2231"
    HorizSync       30.0 - 81.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1060 3GB"
   EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "metamodes" "1920x1080_60 +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    Option         "TripleBuffer" "True"
    Option "Coolbits" "4"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

лог иксов глянуть на ошибки
При фоновой нагрузке ничего не меняется. Да, частота становится максимальной, статтеры всё равно продолжаются.

direct rendering: Yes

TrippleBuffer уже пробовал, попробовал ещё раз - не помогает (в т.ч. в комбинации с ForceFullCompositionPipeline)

В логах ошибок отрисовки нет.
marlock
Недавно обновил аппаратуру, теперь видео RTX 2070 Super
Размышления в слух.
Процессор остался старый? ... если да, то может он не успевает угнаться за этой новой видеокартой?
Тройная буферизация решает проблему задержки вывода изображения на монитор - процессор и видеокарта ожидают завершения показа обработанного и переданного на монитор изображения (новая порция готова к передаче, а прием запаздывает - не закончилось изображение предыдущей порции) … а при наличии дополнительного буфера, подготовленная информация передается в этот буфер, а процессор и видеокарта приступают к новой порции обработки.
А вот если процессор запаздывает передать видеокарте данные для обработки изображения, то наличие дополнительного буфера на решит прлоблему - хранить то не чего.

PS - погуглил эту видеокарту - замечания на микрофризы имеются ... и даже в винде, но в основном в играх. То есть при нормальном режиме все спокойно … потому и сделал такое предположение насчет запаздывания cpu.
Ошибки не исчезают с опытом - они просто умнеют
Процессор остался старый? 
Заменён на i9-9900. Думаю, окошки рисовать с эффектиками должно хватать. Во всяком случае, в оффтопике хватает.
marlock
Заменён на i9-9900
+ RTX 2070 Super - да ... серъезное железо стало.
Еще размышления в слух …
В части микрофризов, статтеров и пр. - распространенное явление, наблюдаемое после обновления железа, и причин этому несколько.
Если исключить проблемы, связанные с совместимостью, то можно грешить на следуюшие 2 основные проблемы
1. Блок питания, который в данном случае должен быть не менее 550 Вт
 GeForce RTX 2070 Super - On your average system we recommend a 550 Watt power supply unit.
Но скорее всего с этим тоже все в порядке.
2. Не знаю даже как это назвать, но эта причина в последнее время выходит на первое место - чем современнее железо, тем больше оно нашпиговано всякими новыми технологиям, которые частенько дают о себе знать. И в инете можно увидеть много топиков с жалобами, что имею мощное железо, а наблюдаю в играх микрофризы и др., что не наблюдалось на более слабом железе.
Причин этому, как выясняется много, например, некоторые из них
- всевозможные аппаратные таймеры, которые ведут подсчет количества разных системных событий и при достижении установленного значение создается прерывание - процессор приостанавливает текущую программу и реализует связанный с новой командой код
- разные энергосберегающие режимы, включая режима сна у неиспользующихся ядер
- внедрение скрытых, как бы это мягче сказать, систем наблюдения …
А, главное, все эти новшества не идеальны и дают сбои по не понятным разработчикам причинам. Как общеизвестный пример для Ryzen, связанный с состояниями процессора C и приводящий к зависаниям, борьба с которыми идет на протяжении уже нескольких лет.

В windows исключить микрофризы и статтеры частенько помогает отключение аппаратного таймера HPET (High Precision Event Timer - таймер событий высокой точности), который используется для обеспечения плавного воспроизведения аудио и видео в операционной системе и разгрузке таймеров процессора.
PS - кстати, при гуглении данной видеокарты встретился топик в котором описывалось наблюдение аудио фризов в играх.

Вообщем нужно влезать в это конкретно, а так одни гадания.
Ошибки не исчезают с опытом - они просто умнеют
marlock
статтеры всё равно
Для квина еще есть патч, для уменьшения задержек.
https://github.com/tildearrow/kwin-lowlatency
Можно попробовать , хотя и вряд ли дело в нем. Есть собранный в archlinuxcn/kwin-lowlatency 5.19.4-1 или аур aur/kwin-lowlatency 5.19.4-1

kwin_x11 --replace
кстати не на что не ругается? версию опегл и драйвера правильную показывает?
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1060 3GB/PCIe/SSE2
OpenGL version string: 3.1.0 NVIDIA 450.66
OpenGL shading language version string: 1.40 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 450.66
GPU class: Unknown
OpenGL version: 3.1
GLSL version: 1.40
X server version: 1.20.8
Linux kernel version: 5.8.3
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
и все-таки интересно посмотреть, что будет если отключить hpet - попробуй загрузиться с параметром hpet=disable

PS - перед отключением посмотри выводы # grep hpet /proc/timer_list и dmesg | grep hpet, чтобы потом сравнить их с отключенным hpet
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.