Нет, и не буду делать. Это не благодарное дело, я проходил уже это, делал форк пакетов Arch Linux. Выхлоп и отдача от этого 0, забирает кучу личного времени, и деньги на хостинг файлов.
Про "поделие" вы конечно завернули. Wayland давно уже готов к использованию. Насчет инпут лага у меня есть, что вам ответить, процитирую автора sway:
No. A well-optimized vsync compositor has comparable latency to tearing content updates. Instead of investing efforts in tearing, invest efforts in improving vsync.
X11 сложнее в реализации, с кучей расширений и багов, отсюда он использует больше ресурсов, Wayland же более легкий и современный протокол. Самое главное в Wayland нет разрывов и статеров, цена тому задержка не превышающая 1 кадр, что на 240гц мониторе вы даже не заметите, при этом будет более плавная картинка, в шутеры играть со статерами ужасно, и я проходил это в X11. Задержку можно уменьшить включив VRR, который сейчас используют большинство мониторов. По личному опыту играть в Apex в X11 c Proton очень сложно, дикие статеры, картинка скачет, 240гц ощущаются как 60гц, все реагирует с заметным запозданием. При этом в Sway у меня плавная картинка, и все отзывчиво на команды от мыши и клавиатуры. Потому, что кроме vsync инпут лаг вносит кучу компонентов в системе. И есть вполне объективные способы проверить, что стало лучше, есть бенчмарки AIM. Например в Apex чем ниже инпут лаг тем легче контролить спрей в точку т.к. игра быстрее реагирует на мышь. Если есть инпут лаг, то спрей контролить сложнее, это очень заметно в такой игре как Apex. Плюс например в Overwatch 2 можно запустить VAXTA и сравнить результаты на Widow и Soldier 76, точность вырастает, и можно трекать более мелкие движения и больше попадать в голову. Я сравнивал Windows, Gamescope(запуск как DE без прослойки из композитора), KDE X11 и инпут лаг в Sway не хуже. Ну а если у вас монитор 60гц, то это не про игру в шутеры, нормальных результатов там не добиться с 60гц, можно забыть про инпут лаг и играть, что-то казуальное.
Fedora is going to completely remove X11 for certain desktop environments and is going to use wayland now.
В Wine-tkg старая версия FSync патча. Я переносил вручную, обновленную версию из Proton, там больше функций синхронизации она поддерживает. dxvk и vkd3d-proton нет смысла собирать используя левый репозиторий, просто клонируете dxvk и vkd3d-proton и собираете, месу да в ручную собираю, но со своими патчами, про один из патчей я написал во второй части статьи. Кастомные ядра кривые, у меня свое ядро, плюс многие оптимизации про которые пишут в интернете таковыми не являются, например меня порадовала безграмотность специалистов из убунты, которые не понимают, что делают, и приписывают параметрам ядра из статьи ниже Low Latency, когда там почти все параметры заставляют экономить энергопотребление, пропуская работу некоторых функций ядра, что полезно например для ноутбуков и никаким Low Latency там не пахнет, и Latency увеличивается от этих параметров. https://www.phoronix.com/news/Ubuntu-Low-Lat-Generic-Kernel
Отсюда доверяй, но проверяй! Изучайте сами параметры ядра, тестируйте, и не копируйте чужие ошибки.
Самое главное почему писалась статья, ни официальный Proton, ни GE не умеют работать нативно в Wayland! И скорее всего поддержку Wayland не завезут даже в Proton 9 из-за отсутствия некоторого функционала в Wine Wayland, и будет он добавлен только в Wine 10 в следующем году. А мне же удалось запустить игры Steam, и с помощью самописного патча добавить Raw Input в Wine Wayland. С учетом, что все переходят на Wayland, а я на Wayland уже несколько лет, то этот опыт будет полезен другим людям.
Proton не стабилен из грязных специфичных хаков для определенных игр. Эти хаки грязнее чем патчи из Wine-Staging. Отсюда вы их чаще всего никогда не увидите в основном Wine. Отсюда могут быть разные ошибки, и не стабильная работа в некоторых играх. Моя задача была получить лучший результат в шутерах, в которые я играю.
Wine 9.0 из дистрибутивов не стабилен и содержит ошибки. Мною же ошибки были пофиксены с помощью патчей. В дистрибутивах обычно есть только Esync т.к. применяют патчи Wine-Staging, но нет FSync и темболее NtSync. Чем лучше FSync и NtSync вы можете загуглить в интернете.
Лучше поддержка Native Wayland чем в Wine 9.0.
У меня FPS плюс минус такой же, но зато инпут лаг заметно ниже, меньше пропусков кадров и статеров, особенно это заметно в игре Apex Legends. При этом результат на 240гц мониторе, лучше чем в Windows, или X11 c Proton. На удивление игры имеют лучшую производительность в Wine чем в Windows. Про специфику протона написано во второй части статьи, она выйдет в пятницу.
Очень часто люди спрашивают, как запустить Steam игры в Wine c Native Wayland. Ставят Steam в Wine, и это не работает. Я один из первых кто еще в декабре смог запустить Steam игры в Wine Wayland.
Объяснить специфику ручной сборки Wine и Proton. Официальный протон собирается в контейнере и скрипты сборки сложны для изучения новичками не знакомыми с Proton.
Нет, Линус Торвальдс не принял патчи по причине того, что якобы можно для этого еще использовать написанный им perf, но я нигде не видел как это сделать. Теоретически можно использовать AutoFDO, но когда я с ним игрался и с ядром ничего хорошего из этого не вышло, профиль нормально не собирался. Чистой воды политика.
Я там ничего не ускорял, перечитайте внимательно статью, там все изменения написаны в последнем абзаце.
Если в кратце я добавил поддержку профиля llvm 13-14, оригинальная версия патча работала с профилем 12 версии, она собирала профиль, но при конвертации сырого профиля выскакивала ошибка т.к. формат профиля отличался.
После того как компания Google выпустила набор патчей для PGO оптимизации, мною была добавлена поддержка LLVM 13 и LLVM 14, т.к. в них менялся формат профиля и с оригинальными патчами clang его не понимает. Также файл профиля и сброса были перенесены из debugfs в proc для устранения проблем с включённым kernel_lockdown (man kernel_lockdown) в ядре Linux, который не даёт прочесть профиль. Данное изменение позволять профилировать ядро с включёнными системами безопасности ядра, без их отключения на этапе загрузки. Дополнительную информацию вы можете найти в файле Documentation/dev-tools/pgo.rst после применения патча ядра.
Я думаю это произошло из-за линковки стаба rt llvm необходимого для профилирования, и в начале каждой функции встраивался ассемблерный код, который вызывал этот стаб, в коде могли быть ассемблерные вставки, или слишком большой код и inline вставки, которые компилятор чудным образом оптимизировал, как помню это была очень тяжелая функция со сложным ветвлением, и происходил сбой. Потом эта проблема исчезла из ядра. Но я запечатлил ее, чтобы потом показать. В переписке к патчу ядра это тоже упоминалось, что не каждую функцию можно просто так профилировать. Ядро обычно все ошибки сразу сообщает, на край ядро обкатывается на qemu. Я пока ловил баг с AMD Secure Memory Encryption (SME) support, ядро успешно запускалось в qemu, долго не мог понять в чем причина, ни кернел паник, ни дампов ядра, просто ядро зависало на самом раннем этапе загрузки.
Что будет у меня не факт, что будет у вас. Что именно вы предлагаете замерить?
Замеры должны делать вы сами, все экспериментальные методы так и помечены в ядре, как экспериментальные. Т.е. вы их используете на свой страх и риск, и сами решаете нужно это вам или нет.
Вы делаете замеры на своей нагрузке и смотрите дает это вам выигрыш с вашей нагрузкой или нет.
Самомодификация это полиморфный код, антивирусы на него будут реагировать. Анализ ресурсоемкая задача, поэтому выигрыш от производительности будет съедать ее деградация от анализа. Плюс самомодификация тоже тяжеловесная задача, возьмите к примеру LTO оптимизацию и сравните насколько она увеличивает время линковки. Да банально возьмите упаковщик PE и сравните насколько медленее стала программа. И как вы можете заметить сами время компиляции на порядок дольше чем запуск самой программы. Что вы написали уже есть, и называет JIT-компиляция, правда она не везде применима. У любого метода есть плюсы и свои ограничения, нет ничего идеального в этом мире, везде используют компромиссы.
По ядру Linux нет, все зависит от правильно собранного PGO профиля и нагрузки. Но в интернете есть бенчмарки очень большого количества программного обеспечения, так же бенчмарки есть в исходниках языков программирования где используется PGO оптимизация при сборке. Не говоря о том, что большая часть сложного софта сейчас собирают с PGO оптимизацией. Думаю создатели PGO оптимизации и компании производители программного обеспечения не дураки. Ну а если ..., то ждем от вас доказательств и пруфы. Ваша же статья по ссылке касается больше вас самих. Поэтому применять или нет, это вопрос только к вам. Мое дело только рассказать и открыть новые горизонты читателям.
igrblkv у нас EMS хоть не идеально работает, но особых проблем нет, у нас там вполне приличный курьер, и дядька этот делает свою работу на совесть, с ним общался не раз, он работает уже больше 10 лет.
Tim06ka так CDEK итак цены поднял, если мне надо отправить относительное не большое и не дорогое, то у меня в приоритете сейчас почта россии. Для крупного и дорогого другие компании. Что-то дорогое отправлять лоукостом типа CDEK(хотя он уже не совсем лоукост) это по моему безответственность. Лучше переплатить за надежность и удобство. Нет денег на рентген, то пусть собак купят, взрывчатку, наркотики они находят не плохо. Для поиска радиоактивного могут купить обычный дозиметр мкс-01са1м. Правда уже сейчас в метро и много где стоят портальные детекторы ионизирующего излучения и они быстрее поймают человека.
Нет, и не буду делать. Это не благодарное дело, я проходил уже это, делал форк пакетов Arch Linux. Выхлоп и отдача от этого 0, забирает кучу личного времени, и деньги на хостинг файлов.
Про "поделие" вы конечно завернули. Wayland давно уже готов к использованию. Насчет инпут лага у меня есть, что вам ответить, процитирую автора sway:
X11 сложнее в реализации, с кучей расширений и багов, отсюда он использует больше ресурсов, Wayland же более легкий и современный протокол. Самое главное в Wayland нет разрывов и статеров, цена тому задержка не превышающая 1 кадр, что на 240гц мониторе вы даже не заметите, при этом будет более плавная картинка, в шутеры играть со статерами ужасно, и я проходил это в X11. Задержку можно уменьшить включив VRR, который сейчас используют большинство мониторов. По личному опыту играть в Apex в X11 c Proton очень сложно, дикие статеры, картинка скачет, 240гц ощущаются как 60гц, все реагирует с заметным запозданием. При этом в Sway у меня плавная картинка, и все отзывчиво на команды от мыши и клавиатуры. Потому, что кроме vsync инпут лаг вносит кучу компонентов в системе. И есть вполне объективные способы проверить, что стало лучше, есть бенчмарки AIM. Например в Apex чем ниже инпут лаг тем легче контролить спрей в точку т.к. игра быстрее реагирует на мышь. Если есть инпут лаг, то спрей контролить сложнее, это очень заметно в такой игре как Apex. Плюс например в Overwatch 2 можно запустить VAXTA и сравнить результаты на Widow и Soldier 76, точность вырастает, и можно трекать более мелкие движения и больше попадать в голову. Я сравнивал Windows, Gamescope(запуск как DE без прослойки из композитора), KDE X11 и инпут лаг в Sway не хуже. Ну а если у вас монитор 60гц, то это не про игру в шутеры, нормальных результатов там не добиться с 60гц, можно забыть про инпут лаг и играть, что-то казуальное.
Вы статью не читали? Там есть ссылки на MR! Только многие MR вы увидите только в следующем dev релизе или в Wine 10.
Делают только его перебазирование, но это старая версия Fsync.
Сравните файлы https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/server/fsync.c
https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/dlls/ntdll/unix/fsync.c
А если вам лень, то сравните просто server protocols и поищите строки fsync https://github.com/ValveSoftware/wine/blob/7e4f2dd4c74d5721b59e0340ac31beeda3c7578c/server/protocol.def
В Wine-tkg старая версия FSync патча. Я переносил вручную, обновленную версию из Proton, там больше функций синхронизации она поддерживает.
dxvkиvkd3d-protonнет смысла собирать используя левый репозиторий, просто клонируетеdxvkиvkd3d-protonи собираете, месу да в ручную собираю, но со своими патчами, про один из патчей я написал во второй части статьи. Кастомные ядра кривые, у меня свое ядро, плюс многие оптимизации про которые пишут в интернете таковыми не являются, например меня порадовала безграмотность специалистов из убунты, которые не понимают, что делают, и приписывают параметрам ядра из статьи ниже Low Latency, когда там почти все параметры заставляют экономить энергопотребление, пропуская работу некоторых функций ядра, что полезно например для ноутбуков и никаким Low Latency там не пахнет, и Latency увеличивается от этих параметров. https://www.phoronix.com/news/Ubuntu-Low-Lat-Generic-KernelОтсюда доверяй, но проверяй! Изучайте сами параметры ядра, тестируйте, и не копируйте чужие ошибки.
Вот мой скрипт сборки
dxvkиvkd3d-proton: https://pastebin.com/6qQBwbjrСамое главное почему писалась статья, ни официальный Proton, ни GE не умеют работать нативно в Wayland! И скорее всего поддержку Wayland не завезут даже в Proton 9 из-за отсутствия некоторого функционала в Wine Wayland, и будет он добавлен только в Wine 10 в следующем году. А мне же удалось запустить игры Steam, и с помощью самописного патча добавить Raw Input в Wine Wayland. С учетом, что все переходят на Wayland, а я на Wayland уже несколько лет, то этот опыт будет полезен другим людям.
Proton не стабилен из грязных специфичных хаков для определенных игр. Эти хаки грязнее чем патчи из Wine-Staging. Отсюда вы их чаще всего никогда не увидите в основном Wine. Отсюда могут быть разные ошибки, и не стабильная работа в некоторых играх. Моя задача была получить лучший результат в шутерах, в которые я играю.
Wine 9.0 из дистрибутивов не стабилен и содержит ошибки. Мною же ошибки были пофиксены с помощью патчей. В дистрибутивах обычно есть только Esync т.к. применяют патчи Wine-Staging, но нет FSync и темболее NtSync. Чем лучше FSync и NtSync вы можете загуглить в интернете.
Лучше поддержка Native Wayland чем в Wine 9.0.
У меня FPS плюс минус такой же, но зато инпут лаг заметно ниже, меньше пропусков кадров и статеров, особенно это заметно в игре Apex Legends. При этом результат на 240гц мониторе, лучше чем в Windows, или X11 c Proton. На удивление игры имеют лучшую производительность в Wine чем в Windows. Про специфику протона написано во второй части статьи, она выйдет в пятницу.
Очень часто люди спрашивают, как запустить Steam игры в Wine c Native Wayland. Ставят Steam в Wine, и это не работает. Я один из первых кто еще в декабре смог запустить Steam игры в Wine Wayland.
Объяснить специфику ручной сборки Wine и Proton. Официальный протон собирается в контейнере и скрипты сборки сложны для изучения новичками не знакомыми с Proton.
Для удобства сравнения результатов можете использовать KDiff3 или Kompare.
Если в кратце я добавил поддержку профиля llvm 13-14, оригинальная версия патча работала с профилем 12 версии, она собирала профиль, но при конвертации сырого профиля выскакивала ошибка т.к. формат профиля отличался.
Замеры должны делать вы сами, все экспериментальные методы так и помечены в ядре, как экспериментальные. Т.е. вы их используете на свой страх и риск, и сами решаете нужно это вам или нет.
Вы делаете замеры на своей нагрузке и смотрите дает это вам выигрыш с вашей нагрузкой или нет.
www.phoronix.com/news/GCC-12-PGO-TR-3990X-AMD