niedziela, 1 września 2013

Akceleracja wideo - otwarte sterowniki AMD

Otwarte sterowniki dla kart AMD Radeon już od dłuższego czasu obsługują akcelerację wideo z wykorzystaniem dedykowanej jednostki UVD. Współpraca z programami odbywa się przez popularną bibliotekę VDPAU i obejmuje zarówno akcelerację wyświetlania jak i dekodowania wideo.

Uruchomienie akceleracji jest łatwe, wystarczy mieć aktualną wersję sterowników z włączonym wsparciem VDPAU. Użytkownicy Ubuntu wystarczy, że dodadzą repozytoria ppa:oibaf/graphics-drivers i zainstalują pakiet libg3dvl-mesa.

Po tym wszystkim można zapytać nasz ulubiony odtwarzacz, czyli w moim przypadku mplayer2, o wsparcie VDPAU.

Dekodowanie:
mplayer -vc help | grep vdpau 
ffmpeg12vdpau ffmpeg working FFmpeg MPEG-1/2 (VDPAU) [mpegvideo_vdpau] 
ffwmv3vdpau ffmpeg problems FFmpeg WMV3/WMV9 (VDPAU) [wmv3_vdpau] 
ffvc1vdpau ffmpeg problems FFmpeg WVC1 (VDPAU) [vc1_vdpau] 
ffh264vdpau ffmpeg working FFmpeg H.264 (VDPAU) [h264_vdpau] 
ffodivxvdpau ffmpeg working FFmpeg MPEG-4,DIVX-4/5 (VDPAU) [mpeg4_vdpau] 
 
Wyświetlanie:
mplayer -vo help | grep vdpau 
vdpau VDPAU with X11

Jak to działa w praktyce? 

Testowym filmem niech będzie Bick Buck Bunny w 1920x1080 i 24 klatkach na sekundę:

mplayer -vc ffh264vdpau big_buck_bunny_1080p_h264.mov

Można sprawdzić czy UVD jest rzeczywiście używane:
sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
uvd    vclk: 70000 dclk: 56000
power level 0    sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0


Podczas odtwarzania poczciwy Athlon II 240 był tylko obciążony przez mplayera2 w 4-5%, pracując na 800 MHz. Całą robotę załatwiał Radeon HD 6670, którego temperatura wzrosła z 35 na 40 stopni C.

Notka poboczna: Układ ma włączony nowy system zarządzania energią dostępny od jądra 3.11 i zwykle pracuje w zakresie 35 (pulpit 2D) do 47 st. C (intensywne gry 3D). Bez niego temperatury wynosiły 47-52 stopni. Więcej informacji tutaj. Testy wydajności w grach można za to znaleźć tutaj.


Dla porównania poniżej znajduje się zrzut podczas odtwarzania bez użycia UVD. Obciążenie procesora przekracza 40% i dzieje się to przy taktowaniu 2,8 GHz.

 

Dodatkowym testem był trailer Incepcji (1920x800) zapisany w 48 klatkach na sekundę. I tutaj nie było problemów z odtwarzaniem, a obciążenie CPU nie przekraczało 5%. Bez UVD wzrostało ono do 60 - 90%.

 

Problemy?

Podczas odtwarzania napisów końcowych Bick Buck Bunny (zawartość ekranu przesuwa się z dołu w górę) zauważyłem artefakty w dolnej części okna. Również wznowienie odtwarzania po zatrzymaniu filmu potrafi czasami zamrozić obraz na kilka sekund. Dekodery oznaczone jako "problematyczne",  jak VC-1, zwykle powodują błędy w wyświetlaniu.

Pełną listę dekoderów można sprawdzić również używając narzędzia vdpauinfo:

Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                 0  9216  2048  1152
MPEG2_SIMPLE          3  9216  2048  1152
MPEG2_MAIN            3  9216  2048  1152
H264_BASELINE        41  9216  2048  1152
H264_MAIN            41  9216  2048  1152
H264_HIGH            41  9216  2048  1152
VC1_SIMPLE            1  9216  2048  1152
VC1_MAIN              2  9216  2048  1152
VC1_ADVANCED          4  9216  2048  1152
MPEG4_PART2_SP        3  9216  2048  1152
MPEG4_PART2_ASP       5  9216  2048  1152


Oczywiście użycie VDPAU da się ustawić też w SMPlayerze zaznaczać wybrane w ustawieniach programu:

 

Duchy piszą kod AMD dla Linuksa

Czytałem ostatnio raport opisujący wkład deweloperów i firm ich zatrudniających w Linuksa 3.11. Zestawienie można znaleźć na stronach LWN.net.

Nie zaskoczyły mnie wysokie pozycje RedHata, który od niepamiętnych czasów wkłada wiele sił w rozwój jądra, czy przeogromnego (ponad 100 000 pracowników) Intela. Zaskoczyła mnie wysoka pozycja AMD (zaledwie 10 000 pracowników).

Jeszcze niedawno czytałem newsa  AMD rezygnuje z Linuksa na desktopie, na rzecz serwerów:
Kilka dni temu świat obiegła szokująca wiadomość, ponieważ AMD zamknęło centrum badawcze Operating System Research Center, w którym pracowało 25 deweloperów Open Source. 
(...)
Po ostatnich kiepskich miesiącach i utracie sporej liczby deweloperów, związanych bezpośrednio z Linuksem, AMD postanowiło skupić się głównie na sektorze biznesowym, a dokładniej serwery.
(...)
Pytanie jest zatem proste - co teraz poczną obecni i przyszli użytkownicy platform, opartych o procesory i chipsety firmy AMD? Pozostaje domniemywać, iż jedynym ratunkiem będzie zmiana na Intela, który obecnie jest jedyną firmą, tak mocno wspierającą zarówno desktop, jak i serwery.
Według podsumowania LWN.net AMD jest na 11 miejscu pod względem wprowadzonych zmian i na 3 (wyprzedzając m. in. wymienionego wyżej Intela) pod względem liczby zmienionych linii kodu.  Kto napisał ten kod? Duchy czy krasnoludki?

Sprawa zamknięcie OSRC też nie jest taka prosta i  nie oznaczała końca wsparcia Linuksa. Mike Silverman z AMD opisał ją tak:
As announced during our last financial earnings results on October 18th 2012, AMD is restructuring its business and building a more efficient operating model. As consequence and as part of a global reduction in workforce, AMD GmbH is closing its operations in Dresden, including its Operating System Research Center (OSRC) as part of a full site closure at this location. We will continue to support the Linux kernel, and the software development work happening at the OSRC is being consolidated and will be performed at other AMD locations.
Mamy do czynienia więc ze zwykłą restrukturyzacją i działania wykonywane w OSRC zostały przeniesione do innych ośrodków, a nie zaprzestane.

Nie jest też prawdą, że AMD przestaje wspierać desktopy. Wystarczy spojrzeć na wcześniej przytaczane podsumowanie. Najbardziej aktywny pracownik AMD, Alex Deucher, zajmuje się układami graficznymi, które obecnie mają znaczenie tylko na desktopach i w notebookach. Alex znajduje się na trzecim miejscu biorąc pod uwagę zarówno liczbę zmian jak i linii kodu.

Tendencja powinna zostać utrzymana w przyszłości, wystarczy spojrzeć na zmiany w DRM Linuksa 3.12.
Obejmują one zarówno serwerowe APU "Berlin" (ciekawostka: poźniej pojawi "Warsaw") jak i układy graficzne "Canary Islands/Sea Islands", które zostaną dopiero wprowadzone do produkcji. Zresztą, w przypadku AMD wszystko idzie w kierunku unifikacji. Czy to PC-ty, czy serwery czy konsole (PS4/XO), architektura jest podobna: APU, HSA, hUMA. Szczególnie, gdy mówimy o Linuksie, tutaj kod współdzielą nawet urządzenia mobilne z superkomputerami z listy TOP500.

 Polecam zapamiętać tę listę z LWN.net:

Most active 3.11 employers
By changesets
(None)9769.1%
Intel9709.1%
Red Hat9118.5%
Linaro8908.3%
Samsung4854.5%
(Unknown)4834.5%
IBM4183.9%
Vision Engraving Systems3333.1%
Texas Instruments3193.0%
SUSE3102.9%
AMD2812.6%
Renesas Electronics2652.5%
Outreach Program for Women2302.1%
Google2242.1%
Freescale1511.4%
Oracle1371.3%
ARM1351.3%
Cisco1321.2%
By lines changed
(None)30799631.9%
Linux Foundation939299.7%
AMD577456.0%
Red Hat526795.5%
Intel408684.2%
Texas Instruments288193.0%
Qualcomm262152.7%
Renesas Electronics240842.5%
Samsung234132.4%
Linaro206492.1%
(Unknown)173621.8%
IBM173371.8%
AbsoluteValue Systems168721.7%
Nokia168471.7%
Mellanox168411.7%
Vision Engraving Systems122681.3%
Outreach Program for Women114991.2%
SUSE102791.1%
Obejmuje ona firmy, które wspierają Linuksa. Linuksa, a nie tylko swoje produkty na Linuksie. Greg Kroah-Hartman w pliku stable_api_nonsense.txt opisał prawa rządzące Linuksem:
So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do?  Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.

Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .)  If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place.  This ensures that your driver is always buildable, and works over time, with very little effort on your part.

Może robię się monotematyczny, ale otwarty kod i kod wprowadzony bezpośrednio do jądra to cholernie ważna rzecz. I nie ma tu u mnie pobudek ideologicznych, są wyłącznie praktyczne.