AMD Catalyst 14.12 dla systemów Linux

AMD Catalyst 14.12 dla systemów Linux

przez -
15 786
AMD Catalyst
AMD ogłosiło wydanie sterowników graficznych Catalyst 14.12 dla systemów Linux. Dodano obsługę OpenCL 2.0, które wymaga 64 bitowego systemu operacyjnego i kompatybilnej karty graficznej AMD Radeon serii R. Pojawiło się wsparcie dekodowanie VAAPI (H264, VC1, MPEG2, MPEG4). Wspierane są aktualnie systemy Ubuntu 12.04, Ubuntu 14.04, Ubuntu 14.10, Red Hat Enterprise Linux 6.5, Red Hat Enterprise Linux 7.0, SUSE Linux Enterprise 11 SP3, SUSE Linux Enterprise 12, OpenSUSE 13.1.

  • grewest

    Co z open suse 13.2 ?

    • DamonLinuxPoland

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

  • hm testuje od wczoraj … ładnie video działa na vdpau – w tym flash i webm/vp9 … ale chyba mają jakieś “wycieki” na ramie – Xorg puchnie jak “ta lala” … momentami dochodzi do 1.9 GB … a raz miałem 2.8 GB na serwer Xorg !! sprawdźcie … muszę pobadać głębiej i zgłosić błędy. Ogólnie super … ale znowu musiałem w moim buildzie [jutro udostępnię] dostosowywać do kerneli wyższych niż 3.16.x, włączyć IOMMU dla CPU intela, etc … oczywiście mój build moduł kernela dopasowuje idealnie do instalowanej platformy ;). Na teraz wole jednak zmodowane przeze mnie 14.41 ;)

    http://a.disquscdn.com/uploads/mediaembed/images/1519/4747/original.jpg

    http://a.disquscdn.com/uploads/mediaembed/images/1519/4749/original.jpg

    • Roman

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

    • DamonLinuxPoland

      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 –

    • pijaczek

      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.

    • Roman

      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.

    • pijaczek

      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ć.

    • Roman

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

    • pijaczek

      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)..