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

Если вы ищите универсальное решение, то таковых не существует. Wine — не операционная система и не эмулятор для запуска Windows. Это постоянно развивающаяся реализация Win32 API, по большей части разрабатываемая путём обратного инженеринга. Здесь много белых пятен и нередко встречаются регрессии. Но тенденции в целом, достаточно положительные. То, для запуска чего ещё год назад требовались долгие пляски с бубном, сегодня работает «из коробки».

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

Существует множество патчей для запуска отдельно взятых игр. И часто они действительно помогают. Но тот факт, что они не включены в основную ветку Wine и даже не являются частью Staging, говорит о том, что они ломают больше, чем чинят. Если вам предлагают сборку с заплатками на все известные проблемы, то скорее всего она будет работать хуже, чем сборка из репозитория вашего дистрибутива. Но мир Linux хорош тем, что если вам что-то предлагают, то совсем не значит, что это надо брать. Если одно решение не достаточно хорошее, то всегда найдётся другое. И в большинстве случаев не нужно платить деньги, чтобы убедиться в том, что решение вам не подходит. Ниже я приведу несколько примеров вполне стандартных приёмов, позволяющих выжать из Wine больше.

В первую очередь забудьте про команду «wine some_program.exe». В подавляющем большинстве случаев Wine используется для запуска игр. Ставьте каждую игру в отдельный префикс. Твики, полезные для одной игры, с вероятностью 50 на 50 повалят другую.

Держите под рукой несколько сборок Wine. Сборка из репозитория хороша для соблюдения зависимостей. В остальном же, это «чистая» копия того, что есть на WineHQ. В некоторых дистрибутивах можно найти Wine Staging. Но часто это сборки устаревших версий. Например, в вышедшей полгода назад Debian 10 версия wine — 4.0.2. Да, она помечена как стабильная. Но «стабильна» версия на сегодня — 4.0.3. Текущая же версия — 4.21. Staging отсутствует. Версия 4.0.2 в Debian будет самой новой ближайшие полтора года, до выхода Debian 11. Как ещё в поддерживаемой Stretch (9), самый свежий релиз Wine - версия 1.8.7. Для проекта Wine, это как два независимых форка, имеющих в далёком прошлом один источник.

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

Следите за версиями в инструкциях по установке той или иной игры. В Сети есть множество описаний установки чего-либо. Но актуальность этой информации часто вызывает оправданные сомнения. Даже на официальном сайте WineHQ часто можно найти ту или иную игру с пометкой «мусор» (не запускается), которая работает как часы на свежей версии. Или будет работать, если применить несколько несложных твиков.

Для старых версий Wine часто использовались твики с манипуляцией библиотеками Direct3D. Можно даже найти инструкции по установки DirectX в Wine. Проект Wine содержит собственную реализацию библиотек Direct3D. С помощью Wine невозможно поставить DirectX в чистом виде. Wine может работать с некоторыми нативными библиотеками DirectX, но в подавляющем большинстве случаев это отрицательно сказывается на производительности. Подобный «твик» может помочь с запуском отдельно взятой игры, но даже если не брать во внимание мнение самих разработчиков Wine, «твик» можно применить как последнее средство. Если больше ничего не помогает.

Одним из популярных твиков на сегодня является использование Esync (eventfd-based synchronization). Esync не подходит для всех игр, как и всё прочее в Wine, но в большинстве случаев заметно увеличивает производительность. Esync является частью проекта Wine Staging начиная с версии 4.6, но не входит в основную ветку Wine. В некоторых дистрибутивах поддержки Esync нет и в версиях моложе Staging 4.6. Для использования убедитесь, что в сборку входит патчсет Esync. В команду же запуска игры нужно добавить параметр «WINEESYNC=1». Ваш дистрибутив так же должен поддерживать Esync. Убедиться в этом можно с помощью команды «ulimit -Hn», введённой в терминале. Таким образом проверяется максимально возможное количество открытых файлов в системе. Если в выдаче будет число, равное, или выше 524288, то вы можете использовать Esync. Если число ниже, то это достаточно легко исправить.

Для дистрибутивов, использующих SystemD, в терминале перейдите в папку «/etc/systemd/» и с правами root отредактируйте в ней два файла. Файл «system.conf» и файл «user.conf». Найдите и раскомментируйте в них строку с параметром «DefaultLimitNOFILE=». Добавьте числовое значение, чтобы получилось «DefaultLimitNOFILE=524288». Если такой строки нет, то добавьте её в конец обоих файлов. После чего перезагрузите компьютер и снова воспользуйтесь командой «ulimit -Hn».

Для дистрибутивов без SystemD, или для дистрибутивов использующих «pam-limits.conf», в папке «/etc/security/» отредактируйте файл «limits.conf» и добавьте в него следующую строку:

username hard nofile 524288

Где «username» - имя пользователя, под которым вы работаете.
На сегодня все современные дистрибутивы должны поддерживать всё, что нужно для работы Esync. Скорее всего ваш - из их числа.

Так же одним из самых распространённых твиков является оптимизация вашей видеокарты. В первую очередь убедитесь, что используется свежий «драйвер». Модули ядра для поддержки видеокарт не всегда свежие во многих дистрибутивах. В Debian, на пример, версия неизменна в течении всего срока жизни версии ОС. Установка бинарников с официального сайта видеокарты в пакетный дистрибутив, тоже плохая идея. У вас могут возникнуть проблемы с зависимостями и наверняка возникнут проблемы с обновлениями. Для всех крупных дистрибутивов можно найти сторонние репозитории со свежими версиями.

На сегодняшний день запускать игры без проприетарного драйвера для карт NVidia практически бесполезно. Убедитесь, что для вашей карты NVidia установлен проприетарный драйвер. Параметр «__GL_THREADED_OPTIMIZATION=1» не имеет эффекта на игры, использующие Vulkan. На сегодня, это реализация поддержки Direct3D 12 от Wine (VKD3D) и сторонние проекты DXVK и D9VK с поддержкой Direct3D 10-11 и Direct3D 9, соответственно. То есть опция актуальна лишь для игр, использующих стандартную (на сегодня) реализацию Direct3D от Wine. Увеличивает производительность, используя многопоточность. Но при максимальной нагрузке на процессор снижает FPS. Опция автоматическая. Значение «1» включает её принудительно. Для принудительного выключения следует использовать «0».

Шейдеры в Linux должны создаваться на лету, из-за чего могут наблюдаться тормоза, в зависимости от железа. Шейдеры хранятся в кэше. Кэш Nvidia — 128 мегабайт для всех игр. Лучше использовать отдельный кэш для каждой игры. Опция «__GL_SHADER_DISK_CACHE=» со значением 1 (включено) и 0 (выключено) позволяет хранить кэш на диске. По умолчанию кэш будет храниться в том же каталоге, где и загрузчик игры. С помощью опции «__GL_SHADER_DISK_CACHE_PATH=/путь/до/папки_с_кэшем» можно указать место хранения кэша вручную.

Для видеокарт AMD в строку запуска игры добавьте параметр «mesa_glthread=true». Это решение подходит как для проприетарного AMDGPU Pro, так и для свободной реализации AMDGPU. Поскольку современные карты Intel так же используют Mesa, твик должен работать и в случаях с Intel.

Сборки Wine существуют в трёх видах: Сборки с поддержкой x86 (32-х разрядные); сборки с поддержкой x64 (64-х разрядные); сборки WoW с поддержкой обеих архитектур. На таких сборках можно создать как «чистый» 32-х разрядный префикс, так и «гибридный» 64-х разрядный. Например, в репозитории Debian есть только первые два типа. На первой будет работать только 32-х разрядные программы. Если сборка скомпилирована с поддержкой 16-ти разрядной архитектуры, то будут работать и старые программы под DOS, которые можно было запустить на Windows 9X. На второй сборке будут работать только 64-х разрядные программы. Есть множество 64-х разрядных программ, включающих в себя 32-х разрядные компоненты. Для таких программ нужна сборка WoW, работающая по принципу современных версий Windows, способная запускать как 32-х разрядные приложения, так и 64-х разрядные. Параметр «WINE_LARGE_ADDRESS_AWARE=1» не влияет на производительность, но решает проблему с вылетом 32-х разрядных игр на WoW сборках, в 64-х разрядном префиксе. Вылеты обычно случаются из-за ограничений оперативной на два гигабайта в 32-х разрядных играх. Сборка должна иметь поддержку данного параметра, иначе он бесполезен. На сегодня патч «Large Address Aware» не включён в мэйнстрим и не является частью Staging. Но в Сети много сборок с поддержкой данного параметра.

На текущий момент поддержка Direct3D в Wine оставляет желать лучшего. Для лучшей производительности в играх лучше использовать DXVK (DirectX 10, 10.1, 11) и D9VK (DirectX 9). Реализация Direct3D в Wine перенаправляет вызовы Direct3D в OpenGL. OpenGL на три года старше, выпущенного в 1995-ом году Direct3D от Microsoft. Последняя версия OpenGL вышла летом 2017-го года. Эту дату смело можно считать датой завершения проекта. На смену отвечавшего за 2D и 3D графику OpenGL пришёл Vulkan. OpenGL по прежнему используется в Linux, но Vulkan современнее и быстрее. DXVK и D9VK транслируют вызовы Direct3D в Vulkan, что заметно увеличивает как производительность, так и совместимость. Видеокарта должна поддерживать Vilkan. Если ваша карта относительно новая, то она поддерживает Vulkan. Уточните на официальном сайте производителя своей видеокарты. Если ваша карта работает с DirectX 12, то поддержка Vulkan в ней так же должна быть.

Манипуляции с библиотеками Direct3D, упомянутые выше — основная причина того, что игры глючит при работе через DXVK. Нередко в инструкциях по установке чего-либо под Wine, можно встретить такой твик: «winetricks d3dcompiler_43 d3dcompiler_47 d3dx9». Если при этом использовать D9VK, то с вероятностью в 90% игра либо не заведётся, либо будет работать с серьёзными ошибками в графике и текстурах. При том, что необходимость применения «d3dx9» спорна даже в старых версиях Wine, «d3dcompiler_» в сочетании с DXVK гарантированно приведёт к проблемам.

В DXVK, как и в случае с Nvidia используется кэш, но одними картами Nvidia это не ограничено. Кэширование по умолчанию включено и кэш хранится в папке с загрузчиком игры. Если по каким-то причинам вам нужно его отключить, то можно использовать параметр «DXVK_STATE_CACHE=0». Указать место хранения кэша вручную можно при помощи параметра «DXVK_STATE_CACHE_PATH=/путь/до/папки_с_кэшем»

Так же DXVK не любит библиотеки, связанные с Nvidia, такие как «nvapi» / «nvapi64», «nvcuda», «nvcuvid», «nvencodeapi» / «nvencodeapi64». Данные библиотеки не входят в мэйнстрим, но поставляются в составе Wine Staging. В теории они должны помочь выжать больше из карт Nvidia. На практике же отключение этих библиотек — самый распространённый твик, когда что-то не работает, или работает не так. Убедитесь, что при использовании DXVK или D9VK эти библиотеки отключены. По крайней мере «nvapi» и «nvapi64». Сделать это можно при помощи Winetricks. Например, командой «winetricks nvapi64=disabled» (не забывайте указывать путь к префиксу и сборке Wine при работе с Winetricks). Так же их можно отключить с помощью «winecfg», во вкладке «библиотеки». Самый простой вариант — использование сборок, в которых этих библиотек нет.

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

Погоня за наибольшим количеством FPS не только нагружает видеокарту, но и часто приводит к сваливанию. Количество PPS в игре не должно превышать частоту вашего монитора. Если частота обновления вашего монитора - 60Hz, то больше 60 FPS он просто не потянет. Видеокарта может выдать и 500, но результат будет только в повышенной и бесполезной нагрузке. V-Sync на стороне игры, синхронизирующий FPS с частотой монитора - так же ресурсоемкий процесс. Существует проект Libstrangle. Поищите в репозитории своего дистрибутива. Для Arch Libstrangle есть в AUR. Libstrangle позволяет установить лимит на FPS в команде запуска игры. Пример:

WINEPREFIX="/путь/до/prefix" strangle 60 /путь/до/сборки/bin/wine /путь/до/some_game.exe

Значение в два раза ниже частоты монитора может дать лучше результат, чем равное. В зависимости от ряда условий игра будет реже сваливаться в 15-20 FPS и будет придерживаться указанному значению.

Недавно компания Valve анонсировала Fsync, как замену Esync. По мнению разработчиков, Fsync справляется со своей задачей лучше, чем Esync. На сегодня Fsync находится в экспериментальной стадии, но уже присутствует в текущей версии Proton и включена по умолчанию. Fsync должны поддерживать как сборка Wine, так и ядро Linux. Fsync работает поверх Esync, так что в сборках с Fsync так же присутствует и Esync. Для включения нужно использовать параметр «WINEFSYNC=1». Если ядро не поддерживает Fsync, то автоматически будет использоваться Esync. Если ядро поддерживает Fsync, то после ввода команды запуска игры, в терминале появится сообщение, что Fsync обнаружен и работает. До включения соответствующих патчей в мэйнстрим ядра, можно воспользоваться сторонними сборками ядра. Например, для Arch ядро с поддержкой Fsync есть в AUR. Для Debian и Ubuntu так же есть отдельные сборки.

Кроме Fsync, из Proton в Wine пришёл патч, отключающий композитор рабочего стола, когда игра запущена в полноэкранном режиме. Патч не добрался пока до основной ветки Wine, но присутствует во многих сторонних сборках. Для использования не требуется никаких специальных команда. Если сборка это поддерживает, то композитор будет отключаться при запуске игры и включаться после выхода из неё. Отрисовка теней, прозрачность окон и прочее — всё это красиво, но замедляет игры даже на достаточно актуальном оборудовании.

Ядро Linux, в подавляющем количестве дистрибутивов, одной «сборки». То есть оно собрано с расчётом охвата как можно большего разнообразия конфигураций железа. Ядро, собранное под определённую конфигурацию обычно даёт лучшую производительность. Так же «планировщик выполнения задач» (process scheduler) по умолчанию в ядре — CFS. Существуют и другие стабильные, но не вошедшие в мэйнстрим планировщики. MuQSS даёт лучшую производительность в играх, чем дефолтный CFS. Ещё большую производительность можно выжать с помощью PDS. То есть разница на глаз между CFS и PDS, в играх, выглядит как апгрейд железа. Одна и так же сборка Wine, та же OS, но другое ядро, и FPS в среднем выше в два раза. К сожалению разработчик PDS прекратил поддержку планировщика в пользу приемника — BMQ, который в играх схож с дефолтным CFS. Пользователи Arch и производных могут воспользоваться портированным кодом PDS в современную ветку ядра благодаря TK-Glitch, но рано или поздно PDS устареет. MuQSS, на сегодня — то, на что стоит обратить внимание. Если вы поищите информацию на эту тему для своего дистрибутива, то наверняка найдёте приемлемый вариант.

Если замена ядра - слишком радикальное решение, то существует инструмент GameMode. GameMode — комбинация демона и библиотеки, позволяющая игре запрашивать временную оптимизацию на стороне ОС, и/или запущенного процесса игры. Другими словами, распределение ресурсов оптимизируется для большей производительности, пока игра запущена. При выходе из игры всё возвращается к состоянию «как было». Поищите в репозитории своего дистрибутива. Возможно, GameMode уже там. После установки скопируйте конфигурационный файл в пользовательский каталог.

cp /usr/share/doc/gamemode/example/gamemode.ini ~/.config/gamemode.ini

Настроек в текущей версии не много и те, что закомментированы — экспериментальные. Лучше их не трогать. Вполне достаточно тех, что по умолчанию. Используйте параметр «gamemoderun» при запуске игры. Пример:

WINEPREFIX="/путь/до/prefix" gamemoderun /путь/до/сборки/bin/wine /путь/до/some_game.exe

Команда «gamemoded -s» покажет статус. Если всё работает, то в выдаче будет соответствующее сообщение. Если игра не запущена, то вы увидите сообщение, что GameMode неактивен.

Всё, что перечислено выше (кроме манипуляций с ядром), доступно в Lutris. Через Lutris вы можете настроить любые параметры запуска. Часть из них включается простым переключателем, часть можно прописать вручную. Lutris так же может быть источником сборок Wine. Там так же можно использовать сторонние сборки. Но я не рекомендую Lutris для установки игр. Как и любой другой «автоматизатор», Lutris использует пользовательские скрипты установки. Вы не можете выбрать версию Wine и убрать устаревшие параметры. Среди скриптов хватает как и откровенно нерабочих, написанных «чтобы было», так и устаревших. Игра может работать «из коробки» на современной сборке Wine, Lutris же скачает 2.18, создаст 32-х разрядный префикс в режиме Windows XP, насуёт туда кучу интересного с помощью Winetricks и, может быть, даже запустит игру. Но вы можете подключить к Lutris уже созданный префикс с установленной игрой и запускать её со всеми твиками. Lutris так же работает с GameMode. Если GameMode установлен в системе, то Lutris его распознает и будет использовать при запуске игр.