LINUX.ORG.RU
ФорумGames

Игры в Linux: переходим в следующее поколение?

 , , , ,


7

4

Эта статья является переводом статьи из блога главного разработчика композитного менеджера KWin (используется в KDE) Мартина Гресслина. Оригинал вы можете прочесть по ссылке. Далее идёт повествование от автора. Прошу сильно не пинать за качество перевода.

В этой заметке я хотел бы поделиться мыслями о том, как улучшить игровой опыт в Linux.

Ситуация с X11

В X11 главная проблема для игр, это композитор. Играм необходим прямой доступ к графическому процессору (видеокарте), без каких либо посредников. Для сравнения, возьмём игровую консоль Playstation: когда вы запускаете игру, вы можете быть уверены, что она получила полный доступ к графическому процессору (GPU). Композитинг X11 предоставить такого не может. Композитор в X11 должен полностью скомпоновать сцену. Выглядит это так:

  • Игра рендерится через OpenGL/GLX;
  • X-сервер уведомляет композитор через расширение Xdamage;
  • Композитор рассчитывает область для перерисовки;
  • Композитор использует расширение Xcomposite для получения пиксельной карты для игрового окна;
  • Композитор связывает пиксельную карту с текстурой OpenGL;
  • Композитор рендерит текстуру, используя OpenGL/GLX поверх игрового окна;
  • X-сервер предоставляет готовое изображение из композитора через KMS.


При таком раскладе, мы имеем 5 вещей, которые не оптимальны для полноэкранных игр: проходы туда-сюда через композитор X-сервера, что добавляет серьёзные задержки. В такой ситуации, композитор всегда будет замедлять игру, так как будет выполнять вертикальную синхронизацию и так далее.

Обходные пути в X11

Существует готовое решение чтобы исправить это, известное как «unredirection full-screen window (отключить перенаправление для полноэкранных окон)». Идея заключается в том, что композитор не будет работать для полноэкранного приложения, и будет использована обычная, «не композитная» функциональность X-сервера.

На мой взгляд, это неправильное решение проблемы, потому что композитор по-прежнему работает, он по-прежнему получает события через XDamage (отслеживание областей для перерисовки, прим.перев.) (от, например, других окон) и работа композитора может внезапно возобновиться (например, при выводе уведомления на экран).

В KWin/Plasma, у нас есть лучшее решение: блокировка композитора. Мы можем это сделать, так как не требуем композитинга, в отличии от окружений с обязательным композитингом, где можно использовать только unredirection. У нас даже есть высокоуровневый API для игр, для того чтобы они могли сообщать, что необходимо заблокировать композитинг.

Это также объясняет, почему в KWin/Plasma не включена по умолчанию опция отключения полноэкранного композитинга. Это может вызвать проблемы в работе неигровых приложений (например тиринг в видеоплеере. прим.перев.), но рекомендуется для игр. Также это объясняет почему мне пофиг на тесты PTS (Phoronix Test Suite), так как по моему мнению они проводятся с неправильными настройками. Если бы нас это волновало, то можно было бы просто убедиться, что используемые в PTS игры, отключают композитинг.

Ситуация с Wayland.

В Wayland всё гораздо лучше, так как теперь нет X11-прослоек. Теперь процесс выглядит так:

  • Игра рендерится через OpenGL/EGL;
  • Композитор получает уведомление через wl_surface;
  • Композитор напрямую представляет wl_buffer через KMS, так как знает что тут больше не на что смотреть.


Так что ситуация значительно улучшилась. Хочу отметить, что KWin пока не поддерживает эти этапы и всё ещё рендерит через OpenGL, но мы движемся в этом направлении.

Однако, я думаю, ещё есть проблемы. Наш композитор (KWin) по-прежнему получает события от других окон, может «проснуться» и так далее. Запуск игры в режиме рабочего стола означает, что будут другие процессы в системе, с которыми игра должна разделить ресурсы. Мы хотим пойти по примеру Playstation: игре всё, остальным - ничего. Я не хочу чтобы KWin отбирал ресурсы CPU/GPU у игры.

Управление видеорежимами в ядре (Kernel Mode-Setting, KMS) в играх.

Итак, что мы можем сделать? Я думал об этом и предлагаю кардинально решить проблему с играми в Linux: убрать оконную систему! Игры должны общаться с KMS напрямую, игры должны взаимодействовать с libinput (библиотека ввода, прим. перев.) напрямую. Давайте удалим все лишние прослойки, нам это не нужно, это только мешает игровой производительности.

Когда игра запустится в полноэкранном режиме, можно создать отдельную сессию на другом виртуальном терминале (tty) и предоставить управление этой сессией через logind. Это позволит игре открыть файлы для рендеринга и обработки ввода также, как это делает композитор Wayland. Рендеринг может быть осуществлён через EGL поверх DRM/GBM, также как в композиторе Wayland. Игра получит полный контроль над KMS. Нужно другое разрешение экрана? Без проблем, бери и выставляй. В режиме рабочего стола, это всегда проблематично (гораздо хуже в X11, но лучше в Wayland). Для игр в оконном режиме ничего не изменится, они так и будут запускаться в режиме рабочего стола. (Прим.перев. По сути автор предлагает давно известную концепцию «запуска в отдельных иксах», но лишённую кучи недостатков).

Конечно, это должно убрать все взаимодействия с окружением рабочего стола. Это то, что нужно рассматривать в первую очередь, например, как заставить, скажем, Mumble (программа для аудиоконференций, прим. перев.) работать с такой конфигурацией? Может игре нужно запускать собственный Wayland-сервер?

Это также сломает Alt+Tab (сворачивание игры, прим.перев.). Ну, не совсем, правда. Для X11, который захватывает клавиатуру в некоторых играх, Alt+Tab всё равно не работает, так что тут особо ничего не потеряешь. Но конечно, всегда можно будет переключиться через Ctrl+Alt+F1 в рабочую сессию. Игры также должны иметь общий путь для достижения этой цели, на мой взгляд.

Есть конечно ещё несколько вещей, которые ещё предстоит решить, например, как запустить отдельную сессию, как вернуться в рабочую сессию без необходимости разблокировать экран и т.д. Всё должно быть также хорошо, как на игровой консоли. Так что тут ещё есть над чем поработать, но я думаю, это лучше, чем пытаться заставлять хорошо работать игры в режиме рабочего стола, потому как это всё равно не будет работать лучше, чем на игровой консоли.

★★★★★

Последнее исправление: Sunderland93 (всего исправлений: 1)
Ответ на: комментарий от fang90

Наверное, ты отсутствовал на ЛОРе летом 2013 года, и не следил за новостями пристально? Была громкая новость о том, что NVIDIA реализовала Optimus. Вот официальный мануал: http://us.download.nvidia.com/XFree86/Linux-x86_64/358.16/README/randr14.html

Системные требования: Linux kernel 3.9, X-Server 1.13 (в версиях 1.17.0 и 1.17.1 сломано), X-Randr 1.4, драйвер xf86-video-modesetting (входит в X-Server начиная с версии 1.16, а в старых системах есть в репозитории) и драйвер NVIDIA 319.xx.

Конфиг /etc/X11/xorg.conf для X-Server 1.13 - 1.16:

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "nvidia"
    Inactive "intel"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "1:0:0"
EndSection

Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
    Option "AllowEmptyInitialConfiguration"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection

Конфиг для X-Server 1.17.2:

Section "Module"
    Load "modesetting"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "1:0:0"
    Option "AllowEmptyInitialConfiguration"
EndSection

Опциональные строки: 1). «Virtual 1600 900» (фиксит фулскрин в майнкрафте). 2). Кастомный DPI.

Конфига xorg.conf мало. Нужно ещё добавить в GDM/KDM консольные команды:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

Вот примеры конфигов: https://wiki.gentoo.org/wiki/NVIDIA_Driver_with_Optimus_Laptops#Display_manag..., https://wiki.archlinux.org/index.php/NVIDIA_Optimus#Display_Managers

GDM - файл /etc/gdm/Init/Default:

#!/bin/sh
# Stolen from the debian kdm setup, aren't I sneaky
# Plus a lot of fun stuff added
#  -George
 
PATH="/usr/bin:$PATH"
OLD_IFS=$IFS
 
## XRANDR
exec xrandr --setprovideroutputsource modesetting NVIDIA-0
exec xrandr --auto

Я добавлял без «exec», и всё работало. GNOME2, если что.

LightDM: создать файл /etc/lightdm/display_setup.sh с содержимым:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

Сделать файл исполняемым: # chmod +x /etc/lightdm/display_setup.sh В конфиге /etc/lightdm/lightdm.conf найти [SeatDefaults] и добавить строку display-setup-script=/etc/lightdm/display_setup.sh.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 3)
Ответ на: комментарий от ZenitharChampion

Наверное, ты отсутствовал на ЛОРе летом 2013 года, и не следил за новостями пристально? Была громкая новость о том, что NVIDIA реализовала Optimus. Вот официальный мануал: http://us.download.nvidia.com/XFree86/Linux-x86_64/358.16/README/randr14.html

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

Khnazile ★★★★★
()
Ответ на: комментарий от ZenitharChampion
Section "Device"
    Identifier "intel"
    Driver "modesetting"
EndSection

лол, и как итог иметь кучу глюков, вроде бы modesetting должен быть железонезависим но его использование на интеле было мучительным, одна и та же версия иксов, грузимся на интеле имеем краши хрома и рандомные фризы, грузимся на радеоне с модесетингом все работает норм, почти так же как и на video-ati. Так что сочувствую пользователям официального прайма.

Novell-ch ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Да, видать упустил или что-то поломалось и забил:) В любом случае, спасибо, попробую) Главное, что б не грелось, а то смысл всего этого пропадает.

fang90 ★★★★★
()
Ответ на: комментарий от Novell-ch

у них все работает на нвидии, с драйвером нвидии, на интел только картинка оффлодится

Khnazile ★★★★★
()
Ответ на: комментарий от Novell-ch

Так это если использовать вместо i965. В этом случае даже OpenGL недоступен! А в связке NVIDIA-Intel, modesetting рисует чёрный квадрат, на который пробрасывается виртуальный десктоп, рисуемый на чипе NVIDIA. Здесь глючить нечему! Хотя нет - есть чему: тиринг. Если бы пробрасывалось на i965, а не на modesetting, то можно было бы на обоих устройствах запустить compton --vsync opengl. А так на NVIDIA VSync есть, а на Intel - нет.

P.S. На открытых драйверах каноничнее compton --vsync drm, но разницы ну вообще нет!

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Так это если использовать вместо i965

при чем тут i965? modesetting это драйвер иксов(DDX), родной DDX драйвер интела так и называется intel, i965 3д драйвер месы и его может использовать как и intel так и modesetting.

А в связке NVIDIA-Intel, modesetting рисует чёрный квадрат, на который пробрасывается виртуальный десктоп, рисуемый на чипе NVIDIA

смеялся до слез, вначале сделаем фичу на костылях типа для энергосбережения, в потом сделаем еще одни костыли что бы вернуть все в нормальное положение без энергосбережения.

Novell-ch ★★★★★
()
Ответ на: комментарий от Novell-ch

Это хуже, чем нормальное положение. В нормальном положении у нас одна-единственная видеокарта, а в этом костыльном целых две, но одна из них не нужна и жрет электричество просто так.

Khnazile ★★★★★
()
Ответ на: комментарий от fang90

Да. Когда я попробовал Bumblebee, была задержка отрисовки. Я резко двигаю мышкой, а прицел перемещается после ощутимой задержки. За снайпера в TF2 играть никак! Я вернулся на PRIME и не жалею! Всё мгновенно, как на дискретке!

NVIDIA PRIME использует технологию DMA-BUF, которую добавили в Linux 3.5 (на Опеннете подробно описывалась драмма, связанная с неправильной лицензией на неё). Эта технология позволяет видеочипу NVIDIA записывать картинку во фреймбуфер Intel напрямую. А в Bumblebee она до сих пор не используется - вот и причина задержки. Да и сам Bumblebee давно не обновлялся...

А ещё когда запускается игра, в выводе в консоль пишут сколько у меня VRAM. В случае с PRIME её 1023 Мб. С Bumblebee - 256 Мб!

Что касается температуры. Я пробовал эксперимент: включил иксы на Intel, а NVIDIA ни для чего не задействовал. Затем включал программу для CUDA (NVIDIA нагрелась). Температура в норме. Потом задействовал CPU (BOINC, 80% на каждое из 4 ядер). Температура на пределе. Последний штрих - игра на Intel. Ноут выключался от перегрева.

Так вот. В конфигурации PRIME последнее, третье действие, никогда не будет выполнено. Intel всегда будет работать на 1% мощности.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 2)
Ответ на: комментарий от ZenitharChampion

Да. Когда я попробовал Bumblebee, была задержка отрисовки. Я резко двигаю мышкой, а прицел перемещается после ощутимой задержки. За снайпера в TF2 играть никак! Я вернулся на PRIME и не жалею! Всё мгновенно, как на дискретке!

Это точно не задержка из-за включенной вертикальной синхронизации? Для primusrun вертикальную синхронизацию можно отключать (vblank_mode=0), все равно он работает таким образом, что разрывов не будет. Но не стоит добавлять это в .profile, если вы используете композитор, т.к. это выключит вертикальную синхронизацию и для него.

Khnazile ★★★★★
()
Ответ на: комментарий от Khnazile

Я не уверен. Я знаю только, что если запускать игру на всё том же i965 (с VSync), то всё отрисовывается мгновенно. А если запускать на NVIDIA, то есть задержка. Был ли Vsync или нет, я уже не помню!

На PRIME VSync в любом случае не работает. Возможно, именно поэтому не реализовали:

There is no synchronization between the images rendered by the NVIDIA GPU and the output device. This means that the output device can start reading the next frame of video while it is still being updated, producing a graphical artifact known as “tearing”. Tearing is currently expected due to limitations in the design of the X.Org X server.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 3)
Ответ на: комментарий от ZenitharChampion

Попробовал. Температура терпимая 50-54 C (без NVIDIA 45-48). Только один косяк при работе с двумя мониторами, мыша уползает на второй(внешний) и никак не хочет возвращаться на основной.
upd. По поводу FPS, и правда, заметный буст наблюдается. По крайней мере в gpxspheres 844FPS, против 400-500 на примусе.

fang90 ★★★★★
()
Последнее исправление: fang90 (всего исправлений: 2)
Ответ на: комментарий от fang90

В любом случае, спасибо, попробую

Не, лучше бамблби. А вообще лучше не покупать ноутбуки с гибридной графикой вообще, конечно, абсолютно бесполезная вещь.

Freyr69 ★★★
()
Ответ на: комментарий от fang90

заметный буст

gpxspheres

Запусти что-нибудь с шейдерами вроде unigine valley и наблюдай (почти)отсутствие буста.

anonymous
()
Ответ на: комментарий от Freyr69

Не, лучше бамблби

фломастеры, такие фломастеры.

лучше не покупать ноутбуки с гибридной графикой

не покупай, чего ко мне пристал-то?:)

fang90 ★★★★★
()
Ответ на: комментарий от fang90

в gpxspheres 844FPS, против 400-500 на примусе

gpxspheres

LOL, в играх смотреть надо а не шестерёнки с шариками + выше 60 кадров может мухи замечают или ещё какие кузнечики

amorpher ★★★★★
()
Последнее исправление: amorpher (всего исправлений: 1)
Ответ на: комментарий от Freyr69

А что, на рынке много ноутов с дискреткой без встройки?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.