LINUX.ORG.RU

Linux Mint 21.1, Firefox из репозиториев, высокая нагрузка на CPU при просмотре видео

 


1

1

Доброе утро.

Подскажите пожалуйста по такому вопросу.

Mint Cinamon 21.1 core i3, 8 озу

Так же пробовал редакции Mate и Xfce, и некоторые другие дистрибутивы, но везде ситуация аналогичная.

При открытой одной вкладке в Firefox 108.1, при воспроизведении видео в 720 и ниже, идет нагрузка цп 50-60%, при перемотке доходит до 100%

Под windows аналогичная ситуация потребляет лишь примерно 10% цп

Есть ли возможность как то настроить линукс для меньшей прожорливости?

https://ibb.co/rbM7kgD

Перемещено hobbit из general

Ответ на: комментарий от johnsmith

Базово firefox собирается с использованием CLANG, при этом, кмк, подключение аппаратного ускорения видео ложится на LLVM и получается порой не очень. У меня если при этом оставить в настройках firefox галку на «использовать аппаратное ускорение» firefox начинает сильно глючить.

Но если его собрать с помощью GCC (у меня gentoo), то никаких глюков нет и аппаратное ускорение работает отлично. Советую попробовать собрать его с GCC.

Еще, конечно, есть вариант, что кодек того видео не поддерживается твоей видяхой…

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

soomrack спасибо, но собрать я точно не смогу, опыта немного больше 0. Я пробовал и вкл. и откл. аппаратное ускорение эффекта если чес то вообще никакого. В общем буду пробовать просто качать видосы. Tartube в роде как получилось запустить, но не получилось русифицировать, но думаю в процессе разберусь. Возможно нужно по перебирать другие браузеры в поисках подходящих параметров.

johnsmith
() автор топика
Ответ на: комментарий от soomrack

А разве оно не будет дополнительной прослойкой между софтом и железом, транслируя код виртуалки в код для железа через DRI?

Это же просто компилятор, никаких прослоек.

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

Неужели так сложно потратить 30 секунд и почитать википедию, чтобы понять как примерно это работает?

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

LLVM можно использовать в качестве JIT-движка (в FF, насколько мне известно, ничего такого нет), но это не имеет абсолютно никакого отношения к компиляции проекта с помощью clang. Можно использовать LLVM JIT и собираться gcc, и наоборот.

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

Ну так читаю, и там есть разные варианты, а для такого комбайна, как firefox, не очень понятно, что скомпилится в машинный код, а что в промежуточное представление, особенно касательно графики (про которую ТС и спросил).

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

PS:

а clang я не люблю вот за такие фокусы:

#include <iostream>

int main() {
    std::cout << "Hello World!" << std::endl;
    while(1){};
}

void unreacheable() {
    std::cout << "Hello World!" << std::endl;
}

clang++ –Wall –O2 1.cxx

./a.out
Hello World!
Hello World!
Segmentation fault
clang version 15.0.7
soomrack ★★★★★
()
Ответ на: комментарий от arax

Всё, ничего llvm специфичного там нет.

Вроде, да, но касательно графики мне это пока непонятно.

Надо будет собраться и покопаться в документации и примерах для LLVM, сайт у них хороший, информативный.

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

касательно графики мне это пока непонятно

Тут есть два реалистичных варианта:
1) Тебе это просто показалось
2) Ты при сборке с llvm использовал кривой ebuild, либо сам напихал лишних параметров

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

Ну черт его знает.

Подытожа все что я выше писал:

Я предпочитаю gcc vs clang, например, потому что пример выше меня приводит в недоумение, а собирать я все предпочитаю с оптимизаций (без нее тот пример работает нормально у clang), потому что оптимизация нужна, да и у llvm это одна из нескольких ее ключевых фич.

Если результат несколько отличается от ожидаемого, то стоит попробовать собрать проект другим компилятором. Это то, что я советовал ТС.

Мой коммент про LLVM как прослойку – чушь, в том смысле, что gcc для FF заменит только clang в фронтенде для LLVM, и от влияния LLVM на FF это не избавит (да и в принципе это невозможно, FF сильно завязан на LLVM).

LLVM создает промежуточный уровень абстракции, при компиляции, который может дать прирост скорости, а может и наоборот, – с этим мне надо поразбираться, когда будет свободное время, чтобы понять предметно, что там к чему, посравнивать разный код… Я LLVM детально не смотрел, и вообще до этого треда думал, что это low level VIRTUAL machine, т.е. JIT (вот надо было так назвать, что потом пришлось везде отказываться от названия и говорить, что это больше не аббривиатура!).

Фронтенды GCC и CLANG могут генерировать разный код для LLVM, соответственно, они могут по разному цеплять (или не цеплять) графику, в частности, кодеки. Имеет смысл пробовать собрать другим, если что-то не заработало, что я и посоветовал ТС.

Проблемы ТС скорее всего в сборке с отсутсвующими кодеками и без поддержки VA-API или какая там у него карта… Т.е. пересобрать все равно надо.

Мой личный опыт со стабильным ебилдом FF 102.10.0 на gentoo говорит, что если собрать используя gcc, а не clang, то включение аппаратного ускорения не приводит к поломке отрисовки его окна и ряду других неприятных эффектов, которые я вижу с clang (Nvidia 3060, xorg, Fluxbox).

И надо заканчивать писать в технические разделы в подпитии, а то начинаешь говорить ради говорения, и быстро сваливаешься в утверждения, которые на первый взгляд кажутся разумными, но по факту это просто додумки, фантазии… :)

Ну и спасибо за то, что простимулировал меня посмотреть на LLVM дальше названия, которое к тому же уже изменилось (т.е. это больше не low level virtual machine)… Ликбез это хорошо, особенно в отношении хрен знает почему и как сложившихся убеждений!

soomrack ★★★★★
()