LINUX.ORG.RU
решено Форум — Development  

libvdpau-va-gl

 , , ,


33

20

https://github.com/i-rinat/libvdpau-va-gl/releases

В двух словах, это VDPAU драйвер, который использует OpenGL для рисования и VA-API для декодирования видео.

VDPAU это открытый интерфейс, который подразумевает единую точку входа (libvdpau) и подключаемые драйверы; API не замкнуто накоротко на nVidia. Выбор конкретного драйвера осуществляется либо через переменную окружения VDPAU_DRIVER, либо спрашивается у X-сервера. Если так или иначе получить имя не удалось, считается, что оно есть «nvidia». Драйвер представляет собой разделяемую библиотеку с именем вида libvdpau_<drivername>.so.1. Программы линкуются с libvdpau, а она в свою очередь загружает нужный драйвер.

Чтобы использовать, нужно собрать, положить библиотеку в директорию, где её сможет найти компоновщик, и добавить в окружение переменную VDPAU_DRIVER=va_gl. Проверить, что драйвер работает, можно запустив vdpauinfo. А vainfo покажет, работает ли драйвер VA-API.

На видеокартах AMD по чудаковатым причинам происходят падения внутри XCloseDisplay. Чтобы обойти проблему, нужно в переменную VDPAU_QUIRKS добавить строку XCloseDisplay. Элементы в VDPAU_QUIRKS перечисляются через запятую, слитно, без пробелов и служат для тонкой настройки поведения драйвера. Кроме XCloseDisplay, есть ещё параметр ShowWatermark, включающий отображение строки va_gl в правом нижнем углу. Полный список можно найти в README.md.

Начиная с версии 2.99.908 xf86-video-intel сообщает переходнику libvdpau.so имя VDPAU драйвера. Символьных ссылок
libvdpau_i965.so.1 → libvdpau_va_gl.so.1
libvdpau_i915.so.1 → libvdpau_va_gl.so.1
достаточно для загрузки, и необходимости в использовании VDPAU_DRIVER больше нет.

★★★★★

Последнее исправление: i-rinat (всего исправлений: 12)

 ← 1 2 3 4 5 6 7 8 →
Ответ на: комментарий от i-rinat

нет, не нормальны. наша зона отвественности libAMDXbBA.so.1.0 + libAMDXbBAW.so. У нас такое поведение есть 100% баг. За это по мордасам дают.

Касательно падения - я написал челам, которые это дело пилят(xorg-часть не наша, мы туда даже патчи вносить не можем). У меня таки дошли руки до этого бага, но положа руку на серцо, я, перерывши все исходники хorg и папки drivers/2d у нас, могу сказать, что тут нечто by-design.

Это может быть и в полный рост баг иксов. Ибо xdl_xs113_DestroyWindow и прочие xdl_xs113_ - это переходник для XServer1.13(XS133). Внутри просто киляется окно. Вообще, внутри fglrx ничего криминального не делают.

Есть мнение, что иксы просто говно.

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

видите-ли, когда я там увидел хаки с указателями на функции между Screen* и Drawable*, мне очень грустно стало там разбираться. Бараны, которые думают, что Х11 рулит они просто бараны.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

нет, не нормальны.

Я аналогично запустил valgrind против intel'овского драйвера и узрел там аналогичные записи-в-память-которая-никогда-не-выделялась, которые тем не менее не баг. В драйвере intel выделяется буфер в устройстве, потом он мапится в пользовательское адресное пространство. valgrind, естественно, запись туда воспринимает как баг. Могу предположить, что в fglrx происходит что-то подобное.

Ибо xdl_xs113_DestroyWindow

Эх, а символов-то нам не дают.

За это по мордасам дают.

Valgrind (или аналог) у вас используют?

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

я писал отдельное dri, и для него дрова для радеона. в радеоне нечему выделяться в памяти видяхи. там есть dummy page(любой запрос, не попавший в system_aperture идет в MMU, оттуда если попал в bus_aperture, идет в pci_e, иначе если попал в vram aperture, идет в vram, иначе похеру, все идет в dummy page). и еще есть scratch page. но это всё в ведре. ничего наружу торчать не должно. Я во всяком случае не вижу где что-либо может торчать.

Это баг 100%.

Ибо xdl_xs113_DestroyWindow

Эх, а символов-то нам не дают.

да я пока даже не смотрел вглубь, руки не доходили. это чисто предположение, потому что общая часть одна, а иксов много, значит должны быть переходники. 113 очень похоже на версию.

пока я подозреваю обращение к окну после освобождения(т.е. внутри блоба окно убили, а потом от него обновили (это ниже блоба по стеку)

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

Это баг 100%.

Да, теперь верю, это уже явно: 

==12439== Thread 1:
==12439== Invalid read of size 4
==12439==    at 0x684D8E0: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439==  Address 0x444c650 is 48 bytes inside a block of size 56 free'd
==12439==    at 0x402750C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12439==    by 0x684970D: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439== 
==12439== Invalid read of size 4
==12439==    at 0x684D8E7: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439==  Address 0x444c638 is 24 bytes inside a block of size 56 free'd
==12439==    at 0x402750C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12439==    by 0x684970D: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439== 
==12439== Invalid read of size 4
==12439==    at 0x684DF6B: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439==  Address 0x444c63c is 28 bytes inside a block of size 56 free'd
==12439==    at 0x402750C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12439==    by 0x684970D: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439== 
==12439== Invalid read of size 4
==12439==    at 0x684DF78: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)
==12439==  Address 0x444c628 is 8 bytes inside a block of size 56 free'd
==12439==    at 0x402750C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12439==    by 0x684970D: ??? (in /usr/lib/i386-linux-gnu/dri/fglrx_dri.so)

Хотя, вообще-то, это может быть и у меня.

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

Поставил KDE (4.8, в debian wheezy), падение иксов так и не смог воспроизвести. (До меня тут внезапно дошло, что версии иксов у нас разные, у меня 1.12.4).

Иногда комп намертво зависает, даже на Alt-SysRq не реагирует. Эти зависания удручают, конечно.

Баг со скроллом на youtube'е воспроизвёлся на AMD, но я так и не понял, где он. Похоже на то что отрицательные смещения внезапно становятся положительными. То есть если прямоугольник с флешплеером уезжает за границы окна, этот баг проявляется. Имеют значение границы окна браузера как приложения, но не границы области отображения. На intel такого нет, и скролится нормально.

Мне не до конца понятно, как вообще плагин рисует. Судя по XGetGeometry, vdpau-драйверу передаётся отдельное окно. Оно никуда не двигается, только меняет размер при изменении области отображения. Видимо, его содержимое потом копируется в вывод браузера.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от ckotinko 
ArchLinux /home/behem0th/AUR/X11/mesa-git :( $ X -version
InitConnectionLimits: MaxClients = 256

X.Org X Server 1.13.3
Release Date: 2013-03-07
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.7.3-1-ARCH i686 
Current Operating System: Linux ArchLinux 3.7.3-1-ARCH #1 SMP PREEMPT Sat Jan 19 09:55:29 MSK 2013 i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=b92cca27-60d7-4851-ba51-2306cd4e3a79 ro nomodeset quiet
Build Date: 20 April 2013  03:01:25PM
 
Current version of pixman: 0.28.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

Говорят с версией 1.14 каталист не работает, так что не обновлялся.

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

Оно никуда не двигается
Видимо, его содержимое потом копируется

откуда они наркоманов-кодеров набрали

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

Рендерится в одном процессе, отображается в другом. Тут нет выбора - только копировать. Только вот где в этих тоннах кода firefox'а это происходит?

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

Кстати, вопрос. У fglrx для ядра поставляется блоб и сорцы прослойки, которая обеспечивает совместимость с текущим ABI ядра. А DDX драйвер поставляется цельным, и поэтому завязанным на конкретное ABI DDX. Почему бы не делать так же, как с ядерной частью? Если прослойка тривиальная, это позволит оперативно её патчить для запуска на более новых версиях иксов.

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

ну она как бы так и есть но пишут её как и катаглист китайцы, это маленький, но очень гордый народ, у них по легендам 100000 лет истории с императорами и драконами, поэтому возникают ньюансы.

ckotinko ☆☆☆
()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от Kadi

ну не считая того, что с субтитрами он начинает сильно процессор нагружать

Выяснил причину тормозов с субтитрами: для каждого глифа (а ещё обводки глифа и тени глифа) создаётся новая крошечная BitmapSurface. На коротком куске у меня образовалось из 459 штук. Соответственно, на каждую заводится текстура. Вроде в mplayer2 с этим получше.

i-rinat ★★★★★
() автор топика

Вот, опакетил: http://yadi.sk/d/syFxoB304fCIC Для убунты 13.04 64-битной. Как номер версии использую год, месяц, число, в которые скачал копию исходников с гита. Если надо для других дистров/разрядностей - сделаю.

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

Если не сложно, а можно исходники (т.е. содержимое каталога debian), хочу для 12.04 себе собрать.

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

http://yadi.sk/d/C0zRnwKC4fEIC Я просто компилировал либу, в отдельном каталоге создавал всё, что надо для опакечивания, запихивал либы в подкаталог lib/ внутри этого каталога, потом собирал командой dpkg -b ./libvdpau-va-gl ./libvdpau-va-gl-2013.05.04-raring-amd64.deb

Знаю. нетехнологично, надо бы по-хорошему рулзы писать. Но лень сейчас. Потом осилю. Как осилю - выложу, если надо будет.

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

Вот, опакетил

Отлично, спасибо.

С обязательными зависимостями странная ситуация: их нет. Они разве автоматически не добавляются dh_shlibdeps? Там точно должны появиться libva-glx1, libva1, libvdpau1, libglib2.0-0 и прочие.

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

Сорри, ступил. Мог бы сам догааться. Добавил.

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

меня пока отвлекли багом на оффтоп-8ку

В задницу баги восьмерки.
Я сейчас вот под седьмой виндой сижу (к родителям приехал домой) - последнюю версию драйвера (не бету) получилось на 7770 раза с 4 только поставить. Иначе BSOD при загрузке системы и все.

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

Дев-пакедж

Это вообще не нужно. libvdpau_va_gl.so.1 предназначена для использования только libvdpau.so.1. Последняя подгружает первую прозрачно для приложения. Поэтому толку от внутренних заголовков нет.

Кстати, может кгда допишу рулзы(скорей после сессии) - в апстрим примешь? Чтоб народ сразу мог скачав сорцы опакетить их.

Дилемма. С одной стороны, это упрощает сборку и дальнейшее использование. С другой стороны, держать специфичные для конкретного дистрибутива файлы рядом с исходниками не правильно. Может лучше держать в отдельном репозитории?

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

для каких это видеокарт?

Для intel и AMD. На AMD работает через xvba-va-driver. Иногда, в хорошую погоду :)

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

Можно. Заведёшь отдельную ветвь, - на твоё усмотрение, в общем. Кстати: как, планируешь нумерацию версий вводить какую-то?

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

нумерацию версий

Да, 1.0, когда все функции доделаю. Правда сейчас затормозилось — mplayer и flash работают, так что острая необходимость отпала. Но я планирую довести до внятного состояния, включая тесты и доки.

i-rinat ★★★★★
() автор топика
4 июля 2013 г.
Ответ на: комментарий от Behem0th

Есть шанс что этот патч попадет в апстрим?

Gwenole Beauchesne (автор xvba-va-driver) таки ответил. Оказалось, что так было сделано специально, иначе что-то там падало на вызове XCloseDisplay() (как и сейчас). Особого желания включать патч в xvba-va-driver я не заметил. Похоже, ему сейчас вообще кодить xbva-va-driver неудобно, так что шанс на включение исчезающе мал. Ещё он высказал идею, что было здорово определить, в какой версии fglrx баг поправили. Не думаю, правда, что у меня выдастся возможность это проверить в ближайшем будущем.

Имеет смысл потестить, не наблюдается ли с патчем падений mplayer'а и gstreamer-vaapi и заслать патч в дистибутивный багтрекер.

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

не наблюдается ли с патчем падений mplayer'а и gstreamer-vaapi

У меня либа пересобраная с этим патчем стоит все это время. Обычный мплеер не падает, гстриммер не тестировал. Слать патч в багтрекер ради пакета с 10 голосами в ауре не вижу смысла. Да и английский я не знаю, так бы уже давно в вики дописал про либу.:-(

Behem0th ★★★★★
()

Поставил тег v0.1.0. Изменений практически нет (мелкие исправления в системе сборки, fix для компиляции с новой libva 1.2.1). Прошло уже много времени, а ничего не меняется. Пусть это будет версия 0.1.0.

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

ни предлагать же саппорту качать гигабайты нелегального

Петухозаконодательство во всей красе.

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

Так ведь там же сабы. А читать намного проще чем писать.

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

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

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

А в компании нет планов по отказу от блоба в пользу опенсорс решения на никс системах? Я понимаю что ты не в силах озвучивать официальную политику компании, может хоть слухи ходят? Или у тебя полное неразглашение?

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

Как они, в своём уме, могут заменить, пусть и кривой, но драйвер на опенсорсную заглушку. Ты, amd-хейтер, хочешь чтоб они людям такую свинью подсунули?

anonymous
()
29 сентября 2013 г.

Отличная работа! Установил, работает. Решил написать фич-риквест:

zenitur@zenithar:~/libvdpau-va-gl-master/build> su
Пароль:
zenithar:/home/zenitur/libvdpau-va-gl-master/build # make install
[100%] Built target vdpau_va_gl
Linking C shared library CMakeFiles/CMakeRelink.dir/libvdpau_va_gl.so
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/lib/vdpau/libvdpau_va_gl.so.1
-- Installing: /usr/lib/vdpau/libvdpau_va_gl.so
zenithar:/home/zenitur/libvdpau-va-gl-master/build # exit
exit
zenitur@zenithar:~/libvdpau-va-gl-master/build> VDPAU_DRIVER=va_gl firefox
Failed to open VDPAU backend libvdpau_va_gl.so: невозможно открыть разделяемый объектный файл: Нет такого файла или каталога

Переместил из /usr/lib/vdpau в /usr/lib64/vdpau и всё заработало! В RPM-based библиотеки там. Кстати, нашёл SRPM,но ещё не пробовал.

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

Переместил из /usr/lib/vdpau в /usr/lib64/vdpau и всё заработало!

https://github.com/i-rinat/libvdpau-va-gl/issues/19

Я не могу «осчастливить» всех. Если сделать установку в lib64, это поломает работу в Debian, если не делать — в Fedora (64-bit). А вообще, если в неком дистрибутиве изменили libvdpau и она больше не смотрит в /usr/lib/vdpau, это недосмотр мейтейнеров этого дистрибутива. Так делать не стоило.

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

А нафига эти костыли? Мэйнтейнер пусть при опакечивании заботится об этом.

Behem0th ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 →
Development