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)

Это также сломает Alt+Tab (сворачивание игры, прим.перев.)

icculus & Co давно написали для стим-игр костыли для WM

https://mail.gnome.org/archives/wm-spec-list/2012-October/msg00001.html

интервью его от 2011 года — [Icculus] Про игры, Linux и повреждения головного мозга

2012 — Интервью с Райаном Гордоном

Сэм Лантинга (один из создателей SDL) работает в Valve и использует SDL для игр Valve. Это здорово. Одна из вещей, которые они хотят чтобы она работала лучше — полноэкранные игры. Сейчас с этим бардак. Приложение захватывает весь экран, изменяет разрешение, а может упасть, после чего рабочий стол исказится или может все окна пропадут. Проблема в том, что не та штука отвечает за изменение разрешения. Сэм и я и так и сяк миллион раз пробовали найти «правильный» способ и решили, что единственным верным решением для этого является захват экрана оконным менеджером. Я написал и отправил им патч и затаив дыхание жду ответа, может снова придётся решать эту проблему.

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

Т.е. сделать dnf install gnome-tweak-tool и в случае ниасиляторства (хотя для этого надо сильно постараться) отменить dnf history undo last — сложнее, чем читать какие-то форумы и потом представлять себе ужасы? =D

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

Серьезно, вынос игры на отдельный VT выглядит как костыль.

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

Sunderland93 ★★★★★
() автор топика

> При таком раскладе, мы имеем 5 вещей, которые не оптимальны для полноэкранных игр

Что за ерунда? 1). OpenGL (GLX) 2). DRI. Всё! Просто возьмите и сравните FPS в Doom III в Windows XP и в Linux (на GNOME2 без компиза) с одной и той же версией драйвера NVIDIA! Одинаковый! В Linux даже выше (на полтора FPS-а)!

Самое полезное в этой статье - заголовок. Необходимо что-то вроде devtoolset, только для мультимедии, чтобы пакетировать корпоративный софт.

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

ненужно detected, презираю и осуждаю

А ты сделал что-нибудь полезное, чтобы улучшить положение дел? Не нравится systemd - стал поддерживать и развивать любимую альтернативу? Нравятся иксы - предлагаешь теперь всем на них молиться? Хотя, что ещё ожидать от хейтера.

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

Пока что хейтер тут только ты - хейтер иксов и sysvinit. Ваши взгляды, как взгляды пессимиста и оптимиста на один стакан - ровно противоположные. Линус Торвальдс сказал «мне нравятся некоторые моменты в Systemd, то, как реализованы некоторые части. Мне не нравится сам подход: по мнению Поттеринга, если чему-то более 15 лет, значит это однозначно устарело и должно быть переписано. А по моему мнению, если чему-то более 15 лет, значит оно работает достаточно хорошо, что всех устраивало».

> Как там в 2007?

Если любишь мастурбировать на циферьки, бери супер новый IceWM - даже лучше будет!

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

Во-первых, частица «ка» пишется через дефис.

Во-вторых, systemd уже повсюду. В его составе есть logind, призванный упростить аутентификацию пользователей (супротив всяких consolekit'ов). Не использовать logind в угоду костылям было бы действительно странным. А вот задействование logind для сеанса Wayland выглядит как раз очень даже актуальным. Повторюсь: X'овая сессия KDE5 будет работать и без logind, сделано это для обеспечения обратной совместимости.

какие это такие профиты даёт systemd для kde5 что без него DE не работает?

Ещё раз: учи матчасть. logind нужно для осуществления аутентификации, сиречь для загрузки DE для конкретного пользователя. Именно для осуществления рабочих функций DE оно не требуется.

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

хейтер иксов и sysvinit

За что их любить? Два куска мамонтового говна, устаревшего многие годы назад.

Если любишь мастурбировать на циферьки

Всё понятно

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

logind не прибит гвоздями к Systemd (как и udev).

Верно. Поэтому хейтерство logind из-за неприятия systemd выглядит странно

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

здорово наверное играть с задержкой управления в пол-секунды?

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

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

Верно. Поэтому отвечать на вопрос «зачем нужен Systemd» «тем, что в его составе есть годный, хороший logind» - некорректно.

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

Полсекунды? Ты шутишь. 1920x1080, я резко дёргаю мышью - реакция отрисовки иксов мгновенная! Ну, с Bumblee полсекунды задержки отрисовки есть, но оно Deprecated в 2013 году в пользу PRIME.

ZenitharChampion ★★★★★
()

Самая идиотская идея, пользователи многомониторных конфигураций и любители поиграть в окне негодуют. Монопольный доступ к экрану оставьте в соснолях, а это десктоп.

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

я вообще чтот не могу найти, где там клавиши раскладки простые O_o http://itmages.ru/image/view/3346367/bf3cbdd8

http://itmages.ru/image/view/3346370/cfedef17

в обоих меню всё просмотрел, но чтот не увидел, видимо слепой.

А рашен федора чтот не может сихронизироваться никак...

erzentdd
()
Ответ на: комментарий от carasin

бла-бла-бла, не продолжай, я понял кто ты

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

пользователи многомониторных конфигураций

Видеовыход находится на видяхе, а не в иксах.

любители поиграть в окне негодуют

Почему эти клоуны ненужны?

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

А ты сделал что-нибудь полезное, чтобы улучшить положение дел?

а твой Лёня Потный сделал? напуркуа нам его высер в DE?! прибитый гвоздями

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

Нужно в настроиках видеодров pre-rendered frames(или как оно там у амд) уменьшить и отрубить vsync.

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

Полсекунды? Ты шутишь. 1920x1080, я резко дёргаю мышью - реакция отрисовки иксов мгновенная! Ну, с Bumblee полсекунды задержки отрисовки есть, но оно Deprecated в 2013 году в пользу PRIME.

Это я утрирую, но миллисекунд 200 сам видел, при этом FPS стабильно 60.

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

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

с Bumblee полсекунды задержки отрисовки есть

пруфы давай

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

у тебя же открытый код, какими гвоздями?

systemd нарушает идеологию unix тем что вместо набора простых инструментов поставляется как намертво склеенный комбайн, где, для того чтобы заменить одну маленькую детальку необходимо форкать весь проект целиком и потом целиком этот форк поддерживать

haku ★★★★★
()

Мы хотим пойти по примеру Playstation: игре всё, остальным - ничего. Я не хочу чтобы KWin отбирал ресурсы CPU/GPU у игры.

Ну и кому кроме геймеров нужна такая графическая подсистема ?
Что будет если игра попросту повиснет?
И не проще ли тогда просто работать через фреймбуфер?

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

Самое печальное, что если такое разрешить, якобы только для игрушек, то через некоторое время этим начнут пользоваться все подряд, видеоплееры, всякие визуализаторы mp3 и прочий шлак. Будет как с блокировками сайтов.

Khnazile ★★★★★
()

Статья, конечно, интересная, но «решение», которое ломает Alt+tab ненужно. DOS уже был и возвращаться туда никакого смысла нет.

Deleted
()
Ответ на: комментарий от Sunderland93

Разница в steamOS и debian весёлая ведь steamOS это и есть debian ::) что мешает юзать debian с режимом big picture как в steamOS? Да и вообще менять всё нахер исключительно для игруль и их потребностей? Ты серьёзно? Можно конечно, но в рамках отдельно взятого дистра.

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

С каких пор композитинг стал узким местом?

С тех самых пор когда производительность при композитинге стала падать до 100фпс в glxgears.

разница +-3 фпс на самых тяжёлых ааа тайтлах

А в steamos производительность получилась в 3 раза меньше чем должна быть.

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

С тех самых пор когда производительность при композитинге стала падать до 100фпс в glxgears.

Это вертикальная синхронизация небось, производительность тут не причем, да и glxgears не офигеть какой бенчмарк

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

А чё не так то? Я ж говорил что беда с драйверами) Вот так оно и есть)

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

vsync в играх часто дает инпут лаг.

Похожая проблема до недавнего времени наблюдалась на нвидия дровах в DE основанных на clutter: gnome3 и cinnamon, реально окна таскались с задержкой. Приходилось прописывать CLUTTER_VBLANK=False, но появлялся дикий тиринг. В последнее время проблема вроде как прошла

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

производительность
glxgears

простите, что?

steamos
производительность

серьёзно? проблема кривого композитора и/или кривого стима и/или кривых драйверов не является фатальным недостатком иксов.

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

У меня SteamOS 1.0 на базе Wheezy. Почему-то не наблюдаю тормозов, о которых писали на ЛОРе. Возможно, в композиторе steammgr - регрессия, которой нет в моём старом релизе системы...

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

Зато иногда помогает прибавить несколько fps, не так давно проверил на своём опыте :)

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

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

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

простите учточню:

«доисторическими» иксы делает то что «иксы» не переименовывают уже 20 лет,и не штампуют по 100версий в год,чтоб нагнать цифорку?
все верно?

ну вы поняли...

hello322
()
Ответ на: комментарий от torvn77

на плейстейшене,как и на всех консолях,с 90-х

две ОС с двумя отдельными процессорами видеокартой...всем отдельным-которые только выводятся на один «буфер»

та ОС-которая «меню»/пускалка игр-это первая ОС,и вторая ОС-эта та которая уже использует самый мощный ЦП и видео в консоли для игры,и если игра зависает или крашится целиком с ОС-первая ОС «меню» не крашиться никогда,тоесть будет раобтать

как две виртуалки,только на реальном железе

и да сравнения плейстейшена с ПК,и темболее сравнение «ОС» и метода их работы-не имеет смысла,по причине выше описанной

hello322
()
Ответ на: комментарий от erzentdd

Меня не спрашивай. Я честно пытался перелезть на GNOME 3, начиная с выпуска F23, но больше недели вытерпеть этот АД!!!!!!!!!!! не смог. KDE наше всё!

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