AMD Catalyst 14.12 dla systemów Linux

A no nic. Po prostu zamiast używać generowania peczek, wybierasz opcje instalacji i bangla.

Te sterowniki używają VA_API, a nie VDPAU.

Niby tak. Ale u mnie na Firefox ten flash 11.2 na VAAPI zachowuje się jakby go nie było czyli tylko software rendering – czyli jak bez obsługi VAAPI. Co ciekawe, już od jakieś czasu jest trik na XVBA –> vaapi –> vdpau + akceleracja flash. Nie wiem tylko czy działa na tym nowym catalyst 14.12 z nową implementacją vaapi?
O tym ext73 mówiłeś?
Jeśli tak, to podziedziel się jak to zrobiłeś :D

Niestety nie jest tak różowo jak mi sie na początku wydawało … na teraz udało mi się jedynie aktywować tak wsparcie dla H264 – vide:

ext73@ext73-X370:~$ vdpauinfo
display: :0 screen: 0
[VS] Software VDPAU backend library initialized
libva info: VA-API version 0.35.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0
API version: 1
Information string: OpenGL/VAAPI/libswscale backend for VDPAU

Video surface:

name width height types
——————————————-
420 1920 1080 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
422 1920 1080 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
444 1920 1080 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name level macbs width height
——————————————-
H264_BASELINE 51 16384 2048 2048
H264_MAIN 51 16384 2048 2048
H264_HIGH 51 16384 2048 2048

Output surface:

name width height nat types
—————————————————-
B8G8R8A8 16384 16384 y
R8G8B8A8 16384 16384 y
R10G10B10A2 16384 16384 y
B10G10R10A2 16384 16384 y
A8 16384 16384 y

Bitmap surface:

name width height
——————————
B8G8R8A8 16384 16384
R8G8B8A8 16384 16384
R10G10B10A2 16384 16384
B10G10R10A2 16384 16384
A8 16384 16384

Video mixer:

feature name sup
————————————
DEINTERLACE_TEMPORAL –
DEINTERLACE_TEMPORAL_SPATIAL –
INVERSE_TELECINE –
NOISE_REDUCTION –
SHARPNESS –
LUMA_KEY –
HIGH QUALITY SCALING – L1 –
HIGH QUALITY SCALING – L2 –
HIGH QUALITY SCALING – L3 –
HIGH QUALITY SCALING – L4 –
HIGH QUALITY SCALING – L5 –
HIGH QUALITY SCALING – L6 –
HIGH QUALITY SCALING – L7 –
HIGH QUALITY SCALING – L8 –
HIGH QUALITY SCALING – L9 –

parameter name sup min max
—————————————————–
VIDEO_SURFACE_WIDTH –
VIDEO_SURFACE_HEIGHT –
CHROMA_TYPE –
LAYERS –

attribute name sup min max
—————————————————–
BACKGROUND_COLOR –
CSC_MATRIX –
NOISE_REDUCTION_LEVEL –
SHARPNESS_LEVEL –
LUMA_KEY_MIN_LUMA –
LUMA_KEY_MAX_LUMA –

Wystarczy zainstalować libvdpau-va-gl i programy korzystające z vdpau korzystają z vaapi (wywołania vdpau są przesyłane do sterownika vaapi).
Wcześniejsze sterowniki obsługiwały xvba tylko, przez co łańcuszek był dłuższy, bo z rozwiązania Nvidii VDPAU trzeba było przejść na rozwiązanie Intela VAAPI (libvdpau-va-gl), a z rozwiązania Intela trzeba było przejść na rozwiązanie AMD czyli XvBA (libva-xvba-driver), które wspierał sterownik. Obecnie narzut się mocno zmniejszył przez wsparcie VAAPI.

Ta historia przypomina mi stary obrazek z grafem serwerów dźwięku na Linuksie.
Teraz jeszcze NV dorzuciła do pieca tworząc nową bibliotekę od encodowania video. Na szczęście w ffmpeg już się z nią uporali.

Ja myślałem, że jeśli ma być jakiś wrapper na te wszystkie libki to powinien być OpenMAX.

Nvidia nic nie dorzuciła NVENC podobnie jak VDPAU to ich natywne API, bezpośrednie dla sterowników, jednak zarówno NVENC jak i VDPAU mogą robić za backend dla OpenMAX IL (jeśli chodzi o ścisłość, to NVENC powstało właśnie dla Tegry pod Androidem, aby być backendem dla OpenMAX IL, a dopiero teraz wydano to dla desktopów).

Z OpenMAX jest taki problem, że nie ma dobrej implementacji tego API (Google pod Androidem też daleko do zgodności i pełnego wsparcia), więc na desktopie mało kogo interesuje obecnie czy są sterowniki, a aplikacje olewają OpenMAX, bo obecnie praktycznie to go nie ma (i tak od wielu, wielu lat). Jasne, że OpenMAX jest najlepszym wyborem i super byłoby gdyby był on nie tylko na mobilkach czy konsolach, ale i desktopach od Linuksa przez Maca do Windowsa, ale w obecnym stanie to wolę działające kilka api (z możliwością podpięcia jako backend innego) niż niedziałające API.

Takich sytuacji jest wiele, jak przykładowo po co nam Mir/Wayland z różnymi api skoro można by mieć po prostu dwie implementacje OpenWF i nie ważne którą wybierzesz wszystkie programy i tak będą działać.

Aha.
Czyli jak wyjdzie Mantle to też nie będzie problemu ;?
Lepiej, żeby była jakaś wydajna i _działająca_ biblioteka dla AMD ;-)

Tak. Mantle to taka sama różnica jak przykładowo rozszerzenia Nvidii do OpenGL sprawiające, że jest lepszy niż Mantle (i są już w sterownikach)… przykładowo dopiero co wydany NV_Command_List, które Joshua Barczak trafnie podsumował:
„Why is NV_Command_List not named NV_Entirely_Different_API?”
http://www.slideshare.net/tlorach/opengl-nvidia-commandlistapproaching-zerodriveroverhead
Ofc z Mantle jest taki problem, że jest to api jeszcze w powijakach i przypuszczam, że na Linuksa nigdy nie zostanie wydane, a i na Windowsa szybko zostanie porzucone. Powodem ofc nie jest ofc DirectX 12, a OpenGL Next, a nad tym API pracują osoby, które przyniosły przełom w API zarówno z AMD jak i Nvidii, a pełna jego rozszerzalność o specyficzna dla sprzętu możliwości (jak OpenGL, gdzie rozszerzenie może wymienić dosłownie wszystko – przykładowo AMD miało pomysł, aby Mantle zaimplementować jako rozszerzenie OpenGL, bo ofc się da, ale tam to wymieniłoby dosłownie wszystko) Mantle traci jakikolwiek sens istnienia (api jednego producenta, które jest gorsze niż otwarte wspólne api nie będzie nigdzie wspierane)..