LINUX.ORG.RU

Firefox VA-API/X11 (заброшен; смержили другую реализацию)

 , , ,


4

9

Проект по добавлению VA-API/X11 в Firefox. Заброшен.
Текущее состояние на 3 июля 2020: (комментарий).

Текст от 25 марта 2020:
Атипичная простуда в очередной раз всех напугала и напомнила, что люди не вечные, причём часто внезапно. Было бы жаль совсем потерять результаты работы, поэтому выкладываю текущий вариант патча к Firefox с поддержкой VA-API под иксами.

Это ещё не готовый к мержу патч, всё держится на честном слове. Из текущих проблем:

  • если не подкрутить настройки, ест больше ватт, чем полностью программное декодирование;
  • с WebRender видео не видно; возможно роняет контент-процесс;
  • с layers-opengl нет видео, если не включить gfx.use-glx-texture-from-pixmap;
  • истерично переаллоцирует X11-пиксмапы, если под layers-opengl переключиться на другую вкладку.

Чтобы под layers-basic экономия от декодирования вообще имела смысл, нужно включить gfx.xrender.enabled. Без XRender чтение картинки обратно в память CPU ест больше энергии, чем просто декодирование сразу на CPU.

До рабочего варианта ещё далеко. Но если кто-то захочет собрать и потестить, ссылка внизу. Патчсет базируется на 74.0. Оригинальный репозиторий был в Mercurial, и файлы .gitignore там где-то игнорят нужное для сборки, поэтому не факт, что код как есть соберётся. Если так оно и есть, должно помочь использование релизных исходников от 74.0 с последующим накладыванием патча.

Для VP9 Firefox предпочитает ffvpx, особую сборку ffmpeg, которую таскает с собой. Чтобы VP9 декодировать через системный ffmpeg с поддержкой VA-API, нужно выключить media.ffvpx.enabled.


https://github.com/i-rinat/firefox/compare/master...vaapi

★★★★★

Ответ на: комментарий от i-rinat

Мое почтение. Есть вопрос. У вас какой то бэкграунд в этой области имеется? Интересно, на любительском уровне возможно изучить кишки отрисовки браузера? Что примерно надо знать, какие библиотеки и апи, чтоб разобраться как это все работает? Чем занимаетесь на основной работе?

unstable-case ()
Ответ на: комментарий от unstable-case

Интересно, на любительском уровне возможно изучить кишки отрисовки браузера?

Чтобы вот так прям сесть и всё детально изучить, то нет. Не верю, что возможно стать специалистом по всему. Если интересует какой-то конкретный аспект, то да, вполне возможно. Это же всё люди делали, причём они старались упростить понимание кода.

Что примерно надо знать, какие библиотеки и апи, чтоб разобраться как это все работает?

Да там всё просто. Видишь вызов функций из библиотеки — читаешь про эту библиотеку. И так далее, пока всё не станет ясно.

Чем занимаетесь на основной работе?

Пишу код, ищу ошибки в коде, исправляю код.

i-rinat ★★★★★ ()
Ответ на: комментарий от Shadow

а чо было причиной

Читать данные обратно в память CPU, потом там масштабировать и снова писать в память GPU это дорого. Собственно, оно и сейчас так есть, для basic, потому что там есть резервный код, который занимается копированием в память CPU. У остальных режимов такого резервного кода нет, и если нужные фичи не включены, картинки просто не будет.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

Выросла ли производительность в этом релизе? Вернее - стала ли ниже нагрузка на CPU?

Не проверял, но не думаю, что станет лучше. В коде, который я добавил, почти что нет дополнительной нагрузки на CPU, если нужные фичи в about:config включены. Поэтому чтобы что-то улучшить, придётся приличную часть движка перелопачивать. Ещё не факт, что улучшения вообще возможны.

Сейчас основная проблема — отловить и исправить баги, которые всплывают, когда включаешь аппаратное декодирование.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

1619523

Этот баг «запачкали» требованием перехода на EGL и dma-buf. Хотя переход на EGL это, в принципе, хорошая идея, но все боятся, что на приличной доле инсталляций переход всё сломает. Приоритет P5 это фактически путёвка на свалку.

Вопрос я запостил. Надеюсь, к чему-нибудь придём.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от SkyMaverick

Они, видимо, не против. Мол, если кто-то сделает, OK. Но сейчас патчи для EGL/X11 ждут, пока не закончится переезд WebGL в отдельный процесс. Я даже не знаю, ревьювил их вообще кто-то или нет.

Потом ещё непонятно, как будет происходить переход на EGL. Если так же осторожно, как и выкатывать OpenGL- и WebRender- композиторы, то это затянется надолго. Если быстро и решительно, будет весело, потому что у пользователей старых линуксов наверняка будут поломки и фризы. А эти пользователи самые громкие, хоть их и очень мало.

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

Мда. Ну хотя бы радует, что наконец-то обратили внимание и что-то собираются делать спустя несколько лет. И вообще собираются, судя по тому, что все уже мысленно X-ы похоронили.

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

Я уже потратил много сил на ковыряние в коде, и просто так из-за одного сообщения бросать наработки жалко. Но если там реально реализуют поддержку до того уровня, что меня устраивает, какой смысл продолжать-то?

А если прям надо сейчас, то берёшь патч, накладываешь и собираешь. На basic-композиторе вполне неплохо работало.

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

А если EGL/GL ES тормоз но есть специализированный чип с поддержкой vaapi? (и там внутри dmabufs, поэтому zero-copy)? Это вполне себе частое явление, да и на ПК с увеличением разрешений выгоднее подрубать аппаратную акселерацию а не EGL.

slapin ★★★★★ ()
Ответ на: комментарий от i-rinat

Почитал баг, ничего они не сделают. У них кто-то очень упоролся по wayland’у и просто считает остальное конкурирующим. Это сейчас почти везде так, кто-то видать хорошо платит в разные места. dmabuf + GLX это хорошо и правильно и работать будет везде, только нужна поддержка аппаратного синка на буфере (это надо проверить, но почему ему не работать?). В худшем случае будет тиринг, и надо будет чуть еще поковыряться, возможно понадобится дабл-буферинг.

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

А команда мозилы знает о патче?

Нет, я всё ещё ковыряю его. Готового варианта для мержа нет, поэтому не выкладывал.

Может им предоставить код?

Может быть.

i-rinat ★★★★★ ()

Скорее всего, нет. В нерелизных сборках по умолчанию включается WebRender, а для него пока не всё готово. Поэтому пока реорганизовывал патчи, добавил явные условия включения. И теперь аппаратное декодирование включается только если:

  • используется basic композитор;
  • включена настройка media.ffmpeg.vaapi.enabled;
  • включена настройка gfx.xrender.enabled.

Все три условия обязательны. Используемый композитор можно посмотреть на about:support, поле Compositing.

С OpenGL и WebRender есть некоторые проблемы: при некоторых условиях при завершении контент-процесса он падает или зависает. Там дело не в декодировании, а в обработке X11 Pixmap в этих композиторах. Но результат всё равно неприятный, так что пока выключено.

А, да. Проблемы проявляются от использования последнего патча, где кроме всего прочего включается gfx.use-glx-texture-from-pixmap. Если эту настройку выключить, то падать больше не должно.

i-rinat ★★★★★ ()
Ответ на: комментарий от unstable-case

XRender это одно из расширений X11. Там больше инструментов для рисования. Среди всего есть поддержка альфа-канала. Если разрешить Cairo использовать XRender, некоторые задачи едят меньше CPU, вынося работу на GPU.

i-rinat ★★★★★ ()
Ответ на: комментарий от annerleen

ЧЯДНТ?

Без понятия. У тебя в about:support что написано в пункте Compositing? media.ffmpeg.vaapi.enabled и gfx.xrender.enabled включены?

Я пока что вставил проверки, которые требуют Basic композитор и включенные опции в about:config. Без них код даже не пытается VA-API использовать.

Есть ли загрузка аппаратного декодера, можно посмотреть в выводе intel_gpu_top.

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

Без понятия. У тебя в about:support что написано в пункте Compositing? media.ffmpeg.vaapi.enabled и gfx.xrender.enabled включены?

Compositing: Basic
media.ffmpeg.vaapi.enabled и gfx.xrender.enabled = true
в консольном выхлопе при открытии видео

VA-API version 1.4.0
libva info: va_getDriverName() returns 0


буду очень благодарен, если подскажешь, как собрать Firefox 75 с этими патчами (не Nightly)

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

libva info: va_getDriverName() returns 0

Если после этой строчки ничего нет, что-то не так с VA-API драйвером. Там дальше должно быть что-то вроде

libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0

Команда vainfo работает?

если подскажешь, как собрать Firefox 75 с этими патчами

Там солидная часть основного патча задевает код, который очень сильно менялся между 75 и текущим Nightly. Я патчи постоянно ребейзил, когда происходили изменения, и там было относительно просто. Двинуться назад разом очень тяжело, и я не осилю без пересоздания патча заново. А это во много раз тяжелее, чем вот это объяснение написать.

Если в результате обсуждений выяснится, что принимать патчи точно не будут, а всё к этому идёт, займусь портированием под релизные версии Firefox.

i-rinat ★★★★★ ()

Убрал ограничения на использование VA-API, чтобы использовалось вообще всегда, даже когда это не имеет смысла или не будет работать. Добавил в код printf’ов, чтобы в прямо в stderr вываливать тип используемого композитора и значения релевантных настроек из конфига. Последний патч в ветке — экспериментальный, где собраны недоделанные части. Остальные — более или менее доделанные.

i-rinat ★★★★★ ()

Да, там остался один патч, который ещё не попал в mozilla-central. Видимо, либо завтра, либо на следующей неделе попадёт. Сейчас можно либо руками запатчить (удалить вызов IsWaylandDisplay() из gfxPlatformGtk::UseDMABufVideoTextures()), либо подождать, пока ночную сборку с вошедшими патчами соберут.

Я попробовал, оно работает. Есть огрехи, но, наверное, решаемые.

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

Наверное лучше что они пошли своим путем. Потому что прямо сейчас под вендой Firefox на твитче жрет ровно в 2 раза больше VideoRAM по сравнению с любым Chromium-based браузером (в среднем 400 мб против 200мб). Подозреваю что на линуксе все точно самое.

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

спасибо что придал ускорение этому вопросу

Мне было бы лестно, будь это так. Но там всё было немного по-другому. Где-то с месяц назад Robert Mader допилил патч для переключения с GLX на EGL. Потом этот месяц патч мариновался, потому что сильно перепиливали контексты WebGL, и было не до него. Вчера патч всё-таки влили, и фактически всё заработало само, потому что код, который написан под EGL/Wayland работает под EGL/X11 без изменений. Патчи, которые вливали потом, большей частью просто убирали проверки на IsWaylandDisplay().

Хотя там вроде подхватили идею измерять потребление связки CPU+GPU в Ваттах. Вот про это я могу сказать, что с моего пинка. Однако оно, скорее всего, так идеей и останется.

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

А, вот вижу теперь - тут уже и до меня всё сделали и сказали.

Спасибо, i-rinat!

Хотя там вроде подхватили идею измерять потребление связки CPU+GPU в Ваттах.

Вроде старые процы и GPU такое вообще не репортят?

fam15h_power-pci-00c4
Adapter: PCI adapter
power1:       44.37 W  (crit =  95.06 W)

но насколько оно калиброванное непонятно .....

Andrew-R ★★★ ()