Про Wine, Proton, и их компоненты
В этой статье будет рассказано о том, как работает Wine, чем Proton отличается от Wine, почему DXVK повышает производительность и т.д.
Wine (рекурсивный акроним от Wine Is Not an Emulator - Wine не является эмулятором) - это слой совместимости для запуска игр и приложений из Windows в других системах (Linux, macOS, FreeBSD и т.д.). Как указано в его названии, он не эмулятор, а транслятор.
Чем эмуляция отличается от трансляции? Если запуск происходит в пределах одной архитектуры, то для этого нужно реализовать лишь те компоненты, которые есть в другой системе. Так сказать, создать родную среду. Так как не нужно эмулировать процессор другой архитектуры, то теоретическая производительность будет высокой.
Рассмотрим трансляцию в Wine поподробнее. Машинный код в пределах одной архитектуры процессора один и тот же. Но различаются всякие системные штуки. Простой пример: чтобы напечатать текст в консоли, у Windows и Linux различаются функции для этого. Wine берёт, и преобразовывает виндовый вывод в консоль в линуксовый (или в макосевый, смотря какая ОС) (хотя это и не совсем верно, так как у Wine есть своя консоль, свой аналог cmd.exe). И так со всем. Работа с окнами, с файловой системой, всё-всё-всё - Wine воссоздаёт родную среду для виндовых приложений в других системах.
Ещё отличается структура исполняемого файла. Хоть машинный код и не отличается, но у каждой системы структура исполняемых файлов своя. У Windows это Portable Executable, у Linux (и некоторых других UNIX-систем) это ELF, в macOS это Mach-O. Разница между форматами исполняемых файлов состоит в том, какие возможности он поддерживает (например, можно ли добавить иконку), в каком месте лежит машинный код и т.д. В случае с EXE, Wine берёт на себя всю работу по "обучению" системы пониманию формата.
Таким же образом будут работать эмуляторы PS4. Так как в консолях теперь та же архитектура процессора, то достаточно (хотя это слишком просто звучит) воссоздать окружение PS4. Короче, всё то же, что и с Wine.
Конечно, у Wine есть много ограничений. Например, нельзя работать напрямую с оборудованием (даже с USB он работать не умеет), нельзя установить драйверы (по этой же причине не работают некоторые античиты, т.к. они сделаны в виде драйверов), потому что они работают в пространстве ядра. Не поддерживается UWP.
Wine - это оригинальный проект. Существует с 1993 года. Началось всё с запуска приложений для Windows 3.1 в Linux.
Proton - это версия Wine специально для работы в Steam. Имеет в себе некоторые улучшения, которые потом появляются в оригинальном Wine.
proton-ge - это версия Proton с экспериментальными патчами, которые потом идут в Proton. Чуть лучше поддержка игр, есть фиксы.
Crossover - это платная версия Wine для Linux и macOS. В первую очередь обеспечивается совместимость с различным платным софтом, вроде Microsoft Office. Все улучшения потом тоже переносятся в оригинальный Wine.
Game Porting Toolkit, который используется в macOS, тоже использует под капотом Wine.
А ещё когда-то был Wineskin. Он позволял упаковать приложение для Windows так, чтобы его можно было запустить в OSX без установки Wine. Полностью Portable, без дополнительных зависимостей.
Ещё интересное отличие Wine от Proton заключается в том, что у Proton на каждую игру создаётся свой префикс. Префикс - это... ну, короче, C:\Windows, Program Files, и вот это вот всё. В Wine префикс всё ещё может засраться так, что даже гарантированно рабочие приложения просто не запустятся.
Изначально трансляция Direct3D (т.е. того компонента DirectX, который отвечает за 3D) шла в OpenGL. OpenGL - это открытый и свободный API для отрисовки 3D графики. Но проблема в том, что и Direct3D, и OpenGL - это высокоуровневые API. Если говорить совсем просто, то писать с их использованием проще, а под капотом они делают очень много. Из-за чего производительность трансляции оказалась очень низкой. Позже появился патч CSMT, добавляющий поддержку многопоточной трансляции, но производительность всё ещё была далека от идеала. В этом плейлисте есть сравнение Gallium Nine и стандартного транслятора (Wine D3D).
Потом появился Gallium Nine. Это реализация Direct3D 9 прямо в видеодрайвере. Производительность резко возросла, и иногда была даже выше, чем в Windows. Но были две проблемы. Первая - для Direct3D 10 и 11 такой штуки нет. Вторая - это работало только на свободных видеодрайверах (т.е. не на Nvidia). Ну и ещё потом добавилась третья: некоторые игры стали плохо работать с Gallium Nine.
А уже потом появился DXVK. Известный пользователям Windows как "поднимаем производительность в GTA 4". DXVK - это пачка DLL-библиотек. Никаких особых требований к видеодрайверам (разве что требуется свежая версия Vulkan). Закинул и играешь.
Он транслирует Direct3D 9, 10, 11 в Vulkan. Изначально 9, 10 и 11 были разделены на разные проекты (D9VK и DXVK), потом подтянулись vkd3d (Direct3D 12) и D8VK (Direct3D 8). Это очень хорошо сказалось на производительности, ведь Vulkan является низкоуровневым API. Более гибким (и более сложным для программистов).
Теперь производительность игр высокая везде, даже на Nvidia. Но на AMD сначала были проблемы с компиляцией шейдеров. Каждый раз при компиляции игра зависала на несколько секунд. Но спасибо Габену, Valve разработали новый компилятор шейдеров под названием ACO, с которым вообще всё это незаметно. Т.е. вы просто берёте, запускаете игру, и она работает без всяких там статтеров и подлагиваний. Это ли не чудо?
В macOS используется трансляция в Metal. Metal тоже низкоуровневый, как и Vulkan. Он используется, например, в Game Porting Toolkit.
Ещё будет очень важно упомянуть, что если игра сразу использует OpenGL или Vulkan, то затыка по производительности в графической части не будет. Будет меньше накладных расходов.
Из-за многих факторов.
Код DXVK (и прочих) местами просто лучше написан. К тому же есть непроверенная информация о том, что рендеринг в DXVK не очень точный (но я не сравнивал). Плюс, как я уже писал выше, Vulkan низкоуровневый, что позволяет рисовать картинку эффективнее, чем на Direct3D 9/10/11.
К сожалению, повышаются требования к процессору. Совсем немного, но повышаются. Например, процессор при использовании DXVK будет загружен сильнее, чем в Windows. Вы сразу заметите разницу, если переведёте процессор в энергосберегающий режим. В Wine FPS сильно упадёт, тогда как в Windows он снизится только в каких-то загруженных сценах, или требовательных к процессору.
Ещё немного повышает производительность более эффективное использование некоторых часто выполняемых системных вызовов. Для этого существуют такие штуки, как esync и fsync. Чтобы их включить, их поддержка должна быть в ядре (насколько я знаю, в свежих версиях ядра есть как минимум esync). fsync новее, чем esync, и немного эффективнее.
Дело в том, что код в пространстве ядра работает гораздо производительнее, чем в пространстве пользователя, ибо ресурсы для него выделяются в приоритете. Пространство пользователя - это все обычные приложения. А esync и fsync выполняются именно в пространстве ядра.
Сейчас в разработке находится NTsync.
Сложно, непонятно, да... В общем, остаётся просто ждать. Скорее всего, раньше всех это завезут в Steam Deck.
Ну и вообще, любой желающий может заглянуть в код Wine. Он открытый. И могут предложить свои фиксы или улучшения. Просто потому что людей много, и кто-нибудь может найти какой-нибудь способ увеличить производительность без ущерба для функциональности.
Я сюда притаскивал новость про Winlator. Это Wine, но для Android. Но как он работает, если архитектуры процессоров разные?
Ух, а вот в случае с Winlator всё несколько сложнее. В нём разворачивается контейнер с Linux для ARM, в ARM разворачивается Box86 (и Box64), а уже в нём Wine.
Что такое Box86 и Box64? Это прослойка для запуска приложений для x86 на ARM. Свободный аналог Rosetta.
Некоторые античиты работают как драйверы. Это позволяет им следить за всеми процессами в системе, и не быть обнаруженными читами. Их нельзя заблокировать (потому что не хватит привилегий). И вообще-то так делать небезопасно (ибо драйвером можно натворить больше, чем простым приложением), но имеем, что имеем.
И с реализацией таких механик в Wine есть проблемы. Как я уже писал выше, в Wine не поддерживаются драйверы для Windows. Вообще. Возможно, когда-нибудь в будущем наконец-то смогут добавить костылями поддержку, но далеко не факт.
Наверное, эта статья не такая подробная, какой должна быть. Но думаю, что для начала этого достаточно.
В конце хотелось бы добавить про то самое пресловутое сообщество, которым так кичатся линуксоиды. У Wine оно действительно большое. И поддержка игр для Windows уже давно на уровне "кликнул и играешь". Это не значит, что проблем нет вообще. Однако я помню, как много лет назад мы всем селом ждали поддержку Max Payne 3 в Wine. Несколько лет ждали. Сейчас фиксы игр (если они требуются) прилетают, ну максимум, в течение месяца.
Иногда есть шанс запустить какую-нибудь древнюю игру, которая в Windows работает плохо или не работает вообще.
Ну и надо понимать, что это запуск приложений для совершенно другой платформы. И без проблем и пердолинга точно не будет, по крайней мере ещё много лет.
Короче, я мог забыть написать про многое, так что может быть дополню статью в будущем.
