Closed ventureoo closed 2 years ago
Думаю для dlss нужно дождаться релиза proton-ge-custom на стабильном wine. Глянул обновление было вчера. По возможности постараюсь перепроверить исправление проблем и доработать раздел
С кастомными ядрами интересный момент... я провёл , пока что, поверхностное сравнение стокового ядра с xanmod и у меня в ashes if singularity получился результат не в пользу кастомного, но результат очень поверхностный и без выборки. Возможно все дело было в том, что xanmod базировался ещё на 5.15, а не 5.16
@ventureoo в кастомные ядра возможно стоит добавить информацию на счет планировщиков и как их выбирать при сборке, если я правильно помню, то также думаю стоит добавить информацию о kernel timer frequency.
@dewdpol Да, по планировщикам много информации придется перерабатывать. Во-первых, мы долгое время в ARU рекомендовали использовать MuQSS, ибо по нашим тестам он давал лучшие задержки при достаточно хорошем FPS в играх. Но к сожалению его поддержка и разработка прекращена. Последнее патчи что я находил были на версию 5.14. Но понятно что никто тянуть лямку дальше не станет. uPDS похоже тоже окончательно умер. Не смотря на то, что его вроде как тянул мейнтейнер linux-tkg, последняя версия в которой его можно применить это 5.11. Из более менее "мейнстримных" планировщиков в живых остались только PDS и BMQ. Оба предоставляются на выбор в linux-lqx, хотя по умолчанию отдается предпочтение PDS. Первый мы с @Almarus когда-то тестировали и он нам в свое время не понравился, но судя по моим последним замерам он уже стал выдавать хорошие результаты и его можно использовать, впрочем таких низких задержек как в MuQSS я получить так и не смог. BMQ я до сих пор никак не тестировал, поэтому ничего про него сказать не могу. А вот новых планровщиков появилось вагон и маленькая тележка: https://github.com/hamadmarri/cacule-cpu-scheduler, https://github.com/hamadmarri/TT-CPU-Scheduler, https://github.com/hamadmarri/Baby-CPU-Scheduler (все три от одного разработчика кстати), https://github.com/firelzrd/bore-scheduler. Их и надо затестить.
Попрошу всех теперь отказаться от использования
:bash:`code block`
для встраивания части кода прямо в текст. Вместо этого используйте два обратных апострофа до и после текста который должен находится в блоке кода. Например:
``code block``
@dewdpol
См. https://github.com/ventureoo/ARU/commit/7e42d238e6ffc4c70d45070d676b78f4530dae61
@ventureoo нужна помощь в переформатировании?
@ventureoo нужна помощь в переформатировании?
Нет, спасибо.
@ventureoo на счёт ядер: необходимо добавить информацию о таких ядрах как: linux-ck, linux-clear, linux-mptcp, linux-pf, linux-rt, linux-vfio? Ядра типа linux-libre, linux-aufs думаю, что смысла не имеют, поскольку один лишен проприетарных драйверов, а второй заявлен для docker. Также не знаю на счёт linux-mainline, linux-next-gut и linux-git, думаю эти тоже спорные.
Если перечисленные ядра те, что нужны могу попробовать заняться для начала оформлением базовой информации, а потом взависимости от доступного времени
@dewdpol Проблема всех ядер указанными вами выше в том, что они как правило улучшают что-то одно, а нам нужно чтобы улучшения были в совокупности и работали хорошо.
linux-ck
Поддержка патчей автором брошена и обновляться они не будут. Но их поддержку взял на себя автор Xanmod. То есть, все патчи CK сейчас есть в Xanmod. https://github.com/xanmod/linux-patches/tree/master/linux-5.15.y-xanmod/ck-hrtimer Будь там обновленный планировщик MuQSS я бы подумал, но так не вижу смысла.
linux-clear
Все патчи clearlinux уже давно растасканы по другим ядрам. Они есть и в lqx, и в Xanmod, в linux-tkg, и даже, если мне память не изменяет, есть и в Zen.
linux-mptcp
Я не слышал о таком ядре, но судя по тому что я увидел - он базируется на ветке ядра 4.19 и содержит только сетевые улучшения. Не вижу смысла его добавлять.
linux-pf
Достойное упоминания ядро, только вот многие что там уже есть тоже давно есть и в других ядрах. Если тестирования покажут что он имеет какое-то преимущество - лишним не будет.
linux-rt
Realtime патч есть в linux-xanmod-rt и недавно появился в linux-tkg (Тут стоит только упомянуть опцию _preempt_rt
)
linux-vfio
Аналогично с linux-clear. ACS патч есть в linux-zen, linux-lqx, linux-xanmod, linux-tkg (Нужно включить параметр _acs_override)
Лично я сейчас заинтересован ядром linux-cachy, ибо он имеет расширенный выбор планировщика, да и само ядро по моим ощущениям показывает себя очень хорошо.
Итак, похоже kwin-lowlatency снова стал сиротой, так что нам придется искать другое решение позволяющие сделать отвязку композитора от полноэкранных окон. https://github.com/tildearrow/kwin-lowlatency/commit/8e9c640c85ef0f060a7b2d138e07e072f73706be
Здравствуйте. Я знаю, что моя идея возможно не совсем в тему, но как насчёт добавления пункта про браузеры? К примеру в раздел useful-programs. Суть его в сравнении скорости браузеров и собственно отношению их жручести к функционалу. Добавить туда и достаточно малоизвестные проекты, вроде falkon. Думаю, если даже если идея покажеться нормальной, то успеть до 28 числа не очень выйдет. Если что, я могу протестировать браузеры со скринами, как пример того, как они работают на слабом пк(очень слабом).
@Atmosphelen Я не против, у меня самого возникала идея сделать раздел про браузеры чтобы описать включение аппаратного ускорения декодирования видео. Думаю такая информация больше подходит для раздела "Первые шаги" и выбора ПО. То, что можем не успеть к следующему выпуску - ничего страшного, в конце концов веб версия ARU у нас получает всегда самые новые изменения.
В основном нужно смотреть на потребление памяти и скорость загрузки страниц. С последним правда сложно делать замеры, возможно есть какие-то бенчмарки которые позволяют это делать.
@ventureoo отвязка композитора от полноэкранных окон? Если я правильно понимаю, то выключить композитинг у полноэкранных окон можно и без kwin-lowlatency, если об этом речь, насколько помню возможно даже в автоматическом режиме, но нужно проверить
@dewdpol Нет, KWin по умолчанию не делает отвязки композитора от полноэкранных окон, по крайне мере для X11 сессий. У него есть опция блокировки композитинга другими приложениями, но это совершенно не то. Только для Wayland начиная с версии 5.22 у него есть такая возможность.
linux-rt
Realtime патч есть в linux-xanmod-rt и недавно появился в linux-tkg (Тут стоит только упомянуть опцию
_preempt_rt
)
Смысл-то от rt, если из-за него в играх FPS меньше ? А на сколько я помню: "Чем выше ФПС -- тем меньше задержки". А от бесмысленного RT ФПС всегда меньше и из этого следует, что больше задержки P.S. у меня монитор 165герц и я не ощущаю никаких задержик, но более меньший ФПС уже даёт по глазам
Починил переключатель версий в веб версии. Извините за задержку.
@KuKuRuZ1337 ARU не нацелен только на оптимизацию под игрушки. RT патч на декстопах используется людьми которые хотят свести задержки звука к минимуму.
Тестировал в последнее время TT планировщик, и получил очень плохие результаты. Лично пока не могу никому его порекомендовать, по крайне мере для игр. В третьем ведьмаке я получал постоянные статеры и микро-фризы, нагрузка на процессор тоже постоянно скакала. Пробовал его и с linux-xanmod-tt и c linux-cachyos-tt. Результат был один и тот же. Настройка sudo sysctl kernel.sched_tt_balancer_opt=2
улучшила ситуацию, однако он по прежнему хуже чем CFS и PDS.
Я немного удивлен, но похоже что дефолтный планировщик CFS с последними версиями ядра довольно сильно улучшили, да настолько что для меня он теперь ЛУЧШЕ чем PDS. Хотелось бы сделать тесты на этот счёт, да и возможно это просто так работают твики liqorix (zen) ядра.
@ventureoo я читал, что относительно недавно дефолтный планировщик улучшали, то ли в 5,15, то ли чуть раньше.
Убрал упоминания MuQSS и uPDS, т.к, как и писал выше, их поддержка полностью прекращена. Для linux-tkg заменил упоминание MuQSS на CacULE. Если честно я сомневаюсь, что он также хорош как и MuQSS, но больше альтернатив я не вижу. Baby-Scheduler о котором я упоминал выше более также не поддерживается, а TT Scheduler дает скверные результаты в играх. Поэтому пока что я остановился на таком наборе: PDS, BMQ, CFS, т.к. они наиболее проверенны временем.
Сколько должен устанавливаться wine-tkg-git ? У меня уже 1 ч 20 м. собираетсяэ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self \ -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value \ -Wno-format -Wformat-overflow -Wnonnull -mcx16 -Wformat -O2 -ftree-vectorize -march=native ccache x86_64-w64-mingw32-gcc -c -o dlls/wbemprox/qualifier.cross.o ../wine-mirror-git/dlls/wbemprox/qualifier.c -Idlls/wbemprox \ -I../wine-mirror-git/dlls/wbemprox -Iinclude -I../wine-mirror-git/include \ -I../wine-mirror-git/include/msvcrt -DWINESRC -D_UCRT -D__WINE_PE_BUILD -Wall \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self \ -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value \ -Wno-format -Wformat-overflow -Wnonnull -mcx16 -Wformat -O2 -ftree-vectorize -march=native
@Organarh В зависимости от процессора. Как правило часа полтора-два.
Что-ж, к сожалению этот месяц прошел не так продуктивно как я бы хотел, но надеюсь что следующий выпуск пройдет плодотворнее.
Все запланированные изменения которые не были выполнены в этом выпуске перейдут в новый.
Используйте эту тему для предложения новых изменений которые могут войти в следующий выпуск. Текущий же план таков:
На этом пока все. Пишите свои предложения ниже.