О микро замираний в играх на системах с Wayland, обеспечения плавности работы. На примере KDE Plasma, когда игра запускается именно в режиме работы с Wayland напрямую, вместо эмуляции X11 средствами xwayland, и в качестве среды используется KDE Plasma.
Имеет смысл начать с переключения
P-States у видеокарты, а далее уже настраивать сами игры и графический стек в ОС.
В самих играх выполняется:
- Отключение V-Sync (вертикальная синхронизация).
- Отключение VRR — адаптивный V-Sync.
- Ограничение FPS в два раза выше желаемой.
Зачем и почемуKWin, являющийся Wayland-композитором в KDE, использует тройную буферизацию или другие подходы ради плавного вывода красивой картинки на экран (отсутствия разрывов в картинке — борьба с tearing'ом). Эти меры часто конфликтуют с настройками игры, такими как вертикальная синхронизация или ограничения кадров движком игры. Проявляется крайне неприятной нестабильностью потока отрисовываемых кадров (frame rate, 0.1% FPS).
Отключить защиту от tearing?Муторно, придётся прописывать у KWin правила для каждой игры в отдельности через KDE «System Settings» -> «Window Rules». Привила приходится создавать для отдельных игр, где нужна киберспортивная реакция на мышь/геймпад, для устранения «ватность» реакции.
Так делать приходится, поскольку далеко не всегда срабатывает разрешение тиринга в полноэкранных окнах (System Settings -> Display Configuration -> Screen tearing: Allow in fullscreen windows). Это связано с тем, что игры и KWin по разному могут понимать полноэкранность.
Конкретика с примерамиДопустим, нужна стабильная и плавная работа без замираний (0.1% FPS) на мониторе в режиме 60 Гц. Тогда, в игре отключается V-Sync, а максимальная частота кадров ставится в 120 (желаемые 60 FPS × 2 = 120). Ограничение же в 60 FPS будет производиться на уровне графического стека, средствами MangoHud — либо через конфигурацию, либо через переменную окружения: MANGOHUD_FPS_LIMIT.
Игры на базе DirectX 9/10/11 требовали/предполагали DXVK_FRAME_RATE, но работало это ограничение внутри DXVK не очень стабильно. Имеет смысл заменить на использование MANGOHUD_FPS_LIMIT, так же как и для игра на базе DirectX 12, Vulkan и OpenGL.
Когда сама игра запускается через:
$: gamemoderun mangohud /тот/или/иной/wine /путь/к/файлу/игры.exeТо перед этим выставляется несколько переменных окружения. Универсальных немного, таких как MANGOHUD_FPS_LIMIT, почти все специфичны для конкретного стека, на котором игра реализована. И может быть изрядное количество:
- если DirectX 9/10/11, такие переменные как DXVK_ASYNC или DXVK_GPLASYNC, DXVK_USE_EARLY_DISCARD, XDG_CACHE_HOME
- если Vulkan, то XDG_VULKAN_HOME
- если OpenGL, то: mesa_glthread, force_glsl_extensions, wq_tearing_control, vblank_mode
- если DirectX 12, то: VKD3D_CONFIG, VKD3D_FEATURE_LEVEL, VKD3D_SHADER_CACHE_PATH, VKD3D_SHADER_MODEL
Универсальная, для систем с AMD видеокартами: MESA_SHADER_CACHE_MAX_SIZE=10G
Так же, через переменные окружения можно объяснить wine, что работать следует напрямую с Wayland — сбросив переменную DISPLAY прописав пустое значение, либо запуская через:
$: env -u DISPLAY gamemoderun mangohud /путь/wine /путь/игра.exeКонфигурация MangoHudМожно массово и для всех сразу выставить ограничение на FPS через конфигурацию MangoHud. Однако, иногда OpenGL-игры лучше работают, если для них персонально лимит будет другим.
Что вообще можно и полезно в
~/.config/MangoHud дописать:
...
fps_metrics=0.001
no_display
toggle_hud=Shift_R+F12
fps_limit_method=earlyТ.е. отображаемые сведения не будут показываться по умолчанию, появятся только после нажатия на правый Shift+F12.
Ничего принципиально нового, просто конкретика и примеры в канве ранее
упомянутого подхода. Т.е. ко всему прочему в системе надо включить современный
eBPF планировщик и запуск игр желательно выполнять через gamemodrun, чтобы планировщик гарантированно подхватил-понял.
#
smooth-gameplay #
linux #
kde #
plasma #
wayland #
mangohud #
linuxgaming #
games #
gaming #
игры #
lang_ru @
Russia
