Video-Performance mit Radeon und Mesa auf FreeBSD besser als auf Linux?

C

cabriofahrer

Well-Known Member
Eigentlich wollte ich nur mal endlich den Linux-Steam-Client auprobieren und installierte dazu auf einem alten Rechner mit einem AMD Athlon(tm) 64 Processor 3500+ (2211.37-MHz K8-class CPU) und einer ATI Radeon HD 4850 Fedora Linux 25.
Dabei habe ich auch Kodi installiert und mal einen Film von einem Addon angespielt mit sehr hoher Auflösung. Wenn man bei Kodi die o-Taste drückt, bekommt man Informationen zum Video-Format und zur Prozessorbelastung, ob Hardwarebeschleunigung genutzt wird, etc. Obwohl auf Fedora das Paket für vdpau für ati installiert war und auch die Ausgabe (weiß nicht mehr, ob es vdpauinfo oder so war) das bestätigt hat, lief der Film auf Kodi ohne Hardwarebeschleunigung. Die Prozessorbelastung war immer sehr hoch bei fast 100% und wenig darunter, ab und zu vielleicht ein leichtes Ruckeln.

So weit, so gut. Auf dem gleichen Rechner mit FreeBSD 11, wo es für ati sowieso kein vdpau gibt (hoffentlich irgendwann), lief der gleiche Film zwar auch mit einer Prozessorbelastung von nahezu 100%, aber doch merklich öfter weiter unterhalb (77-98%) und es war absolut ruckelfrei.

Kann das sein, dass die unbeschleunigte Videowiedergabe bei FreeBSD mit jeweils MESA-Treibern doch geringfügig besser ist als bei Linux?

(Ach so, und letztendlich hing der Linux-Steam-Client, auch nach mehreren Aufrufen, und war daher überhaupt nicht benutzbar).
 
Hier für FreeBSD: multimedia/libvdpau und hier das multimedia/vdpauinfo.

Radeon möchte aber wohl VA-API haben: multimedia/gstreamer1-vaapi. Beim Paket multimedia/libva ist auch das Info Werkzeug vainfo dabei.

Für Nvidia gibt es dann wiederum einen Wrapper, um VA-API auf Nvidia Grafikhardware nutzen zu können: multimedia/libva-vdpau-driver.
So sieht das dann aus:
Code: 
vainfo

libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/va/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG4Simple            : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
      VAProfileH264Baseline           : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

Während es bei vdpauinfo so aussieht:
vdpauinfo

display: :0 screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library 375.20 Tue Nov 15 16:15:11 PST 2016

Video surface:

name width height types
-------------------------------------------
420 4096 4096 NV12 YV12
422 4096 4096 UYVY YUYV

Decoder capabilities:

name level macbs width height
----------------------------------------------------
MPEG1 0 65536 4080 4080
MPEG2_SIMPLE 3 65536 4080 4080
MPEG2_MAIN 3 65536 4080 4080
H264_BASELINE 41 65536 4096 4096
H264_MAIN 41 65536 4096 4096
H264_HIGH 41 65536 4096 4096
VC1_SIMPLE 1 8190 2048 2048
VC1_MAIN 2 8190 2048 2048
VC1_ADVANCED 4 8190 2048 2048
MPEG4_PART2_SP 3 8192 2048 2048
MPEG4_PART2_ASP 5 8192 2048 2048
DIVX4_QMOBILE 0 8192 2048 2048
DIVX4_MOBILE 0 8192 2048 2048
DIVX4_HOME_THEATER 0 8192 2048 2048
DIVX4_HD_1080P 0 8192 2048 2048
DIVX5_QMOBILE 0 8192 2048 2048
DIVX5_MOBILE 0 8192 2048 2048
DIVX5_HOME_THEATER 0 8192 2048 2048
DIVX5_HD_1080P 0 8192 2048 2048
H264_CONSTRAINED_BASELINE 41 65536 4096 4096
H264_EXTENDED 41 65536 4096 4096
H264_PROGRESSIVE_HIGH 41 65536 4096 4096
H264_CONSTRAINED_HIGH 41 65536 4096 4096
H264_HIGH_444_PREDICTIVE 41 65536 4096 4096
HEVC_MAIN --- not supported ---
HEVC_MAIN_10 --- not supported ---
HEVC_MAIN_STILL --- not supported ---
HEVC_MAIN_12 --- not supported ---
HEVC_MAIN_444 --- not supported ---

Output surface:

name width height nat types
----------------------------------------------------
B8G8R8A8 16384 16384 y Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8
R10G10B10A2 16384 16384 y Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8

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 y
DEINTERLACE_TEMPORAL_SPATIAL y
INVERSE_TELECINE y
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY y
HIGH QUALITY SCALING - L1 y
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 y 1 4096
VIDEO_SURFACE_HEIGHT y 1 4096
CHROMA_TYPE y
LAYERS y 0 4

attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y
 
Azazyel schrieb:
Sofern es die Hardware unterstützt, nimmt Fedora 25 Wayland statt X11. Kann es sein, dass du Wayland mit laufender X11-Emulation mit nativem X11 vergleichst?
Zum Vergrößern anklicken....

Das weiß ich natürlich nicht. Dafür sind meine Linux-Kenntnisse zu spärlich. Da aber auch das eigentliche Ziel der Fedora-Installation verfehlt wurde (Linux-Steam-Client), bleibt für mich natürlich wiedermal die Bestätigung, dass ich FreeBSD viel besser finde. Im Übrigen frage ich mich dann aber auch, warum Fedora out-of-the-box X11 emulieren sollte?

Fusselbär schrieb:
Radeon möchte aber wohl VA-API haben: multimedia/gstreamer1-vaapi. Beim Paket multimedia/libva ist auch das Info Werkzeug vainfo dabei.
Zum Vergrößern anklicken....

WOW, heißt das, dass man damit jetzt unter FreeBSD Hardwarebeschleunigung auf Ati-Karten bekommt?
 
foxit schrieb:
Bist du sicher, dass das nötig ist? VPDAU ist doch eine Entwicklung von Nvidia.VA-API von Intel.
Zum Vergrößern anklicken....
Nötig ist es wohl nicht unbedingt auch noch VA-API Unterstützung für Nvidia zu installieren. Andererseits frisst es auch kein Brot. Selbst wenn man die Pakete für VA-API Unterstützung selbst compiliert ist das blitzschnell erledigt. Die sind nicht groß.

cabriofahrer schrieb:
WOW, heißt das, dass man damit jetzt unter FreeBSD Hardwarebeschleunigung auf Ati-Karten bekommt?
Zum Vergrößern anklicken....
Dafür ist ja das VA-API Info Werkzeug vainfo da, um das nachzuschauen. Ich habe keine Radeon Grafik.

Schaut man aber mal in die Mailingliste, so scheint es bei Radeon Grafik wie unmittelbar vor dem großen Durchbruch auszusehen. So etwa wie bei HURD, nächstes Jahr, *Daumendrück*. :)
https://lists.freebsd.org/pipermail/freebsd-x11/2016-December/018422.html
 
Hm, trotz multimedia/gstreamer1-vaapi leider keine Hardwarebeschleunigung auf meinem ATI-Chip, es gehört wohl noch mehr dazu, siehe Anmerkung 1 in
https://wiki.freebsd.org/Graphics

Code: 
Notes:

    Radeon video cards:
        AGP cards not supported before FreeBSD 10-CURRENT
        Features not yet working/implemented:
            Hardware-assisted video decoding

            Audio over HDMI or DisplayPort
            Multiple cards sharing output connectors
            Power management

Das hat aber glaube ich nichts zu tun mit dem, was @Fusselbär als Quelle angegeben hat, da geht es eher um Wayland. Wie sind also die Perspektiven für Hardwaredekodierung, wenn die sagen "not yet working/implemented"?

derOliver schrieb:
Na weil erst wenige Anwendungen auf Wayland portiert wurden und X Anwendungen unter Wayland nicht laufen.
Zum Vergrößern anklicken....

Danke für diese Erklärung, da habe ich nun wieder etwas Neues erfahren. Dabei kommt mir aber ein Video auf youtube in Erinnerung mit dem Titel "Linux sucks", anscheinend ein selbstkritischer Vortrag von Linuxern, in dem die Frage aufgeworfen wird, warum Wayland, wenn xorg immernoch so gut funktioniert oder auch bemängelt wird, dass der meiste Arbeitsaufwand für Linux darin besteht, ständig zehntausende Pakete für unterschiedliche Distributionen zu kompilieren...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben