Bug 1264499 - unclear how to enable radeon support
Summary: unclear how to enable radeon support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libva-vdpau-driver
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nicolas Chauvet (kwizart)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-18 15:28 UTC by Oliver Henshaw
Modified: 2015-11-02 04:24 UTC (History)
2 users (show)

Fixed In Version: libva-vdpau-driver-0.7.4-12.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-01 02:44:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Oliver Henshaw 2015-09-18 15:28:37 UTC
Description of problem:

As I understand it, I need vaapi for hardware accelerated html5 video in firefox. And gstreamer in general has better vaapi support than vdpau support, I think? In order to get this working on radeon (r600) hardware I have to jump through a few hoops that aren't well documented, at least not on fedora.


At first I thought that installing libva-vdpau-driver would be enough, but:

$ vainfo 
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/r600_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

but based on ubuntu bug reports and https://wiki.archlinux.org/index.php/ATI#Enabling_video_acceleration I see that I should do:

$ LIBVA_DRIVER_NAME=vdpau vainfo 
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib64/dri/vdpau_drv_video.so
libva info: Found init function __vaDriverInit_0_36
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.36 (libva 1.4.1)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Baseline           : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

(Though I haven't actually tested playback yet)

Seems that although I don't need to set VDPAU_DRIVER the autodetection fails for the vaapi wrapper.

Would it be possible to add a note to the README about setting LIBVA_DRIVER_NAME on radeon devices? Or perhaps add symlinks for the various radeon families as is done for nvidia_drv_video.so and s3g_drv_video.so?


Version-Release number of selected component (if applicable):

libva-1.4.1-1.fc21.x86_64
libva-utils-1.4.1-1.fc21.x86_64
mesa-vdpau-drivers-10.4.7-1.20150323.fc21.x86_64
libva-vdpau-driver-0.7.4-10.fc21.x86_64
libvdpau-1.1-1.fc21.x86_64

Comment 1 Oliver Henshaw 2015-09-18 15:49:37 UTC
See also bug #1244559.

Comment 2 Oliver Henshaw 2015-09-18 16:01:02 UTC
and ubuntu/debian have been using symlinks for nouveau/radeonsi/r600 for a while - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757370

Comment 3 Nicolas Chauvet (kwizart) 2015-09-23 21:16:26 UTC
IIRC some time ago, they was some plans to have some radeon native vaapi backends (maybe in mesa). The problem is that libva doesn't seems to be fair when, despite using a driver name with a vaapi backend available, the hardware actually doesn't support any acceleration (this often lead to crash).

I will give a try later with one hardware I have using r600.

Can you experiment any improvements using a vaapi enabled player over non-accelerated video ? (using either totem/gstreamer or vlc) ?

Comment 4 Oliver Henshaw 2015-09-25 20:25:13 UTC
Yes, there's a definite improvement in CPU usage when using the vdpau vaapi backend. And the gallium backend gives fairly similar results.

This is an AMD E-350 processor (so quite weak) with an 1680x1050 screen, playing a 1080p video.

gstreamer (gst-launch-1.0 playbin):

non-accel:                      118% gst-launch-1.0 + 12% Xorg.bin
accel(LIBVA_DRIVER_NAME=vdpau)   11% gst-launch-1.0 +  6% Xorg.bin

mplayer:

non-accel:                          81% mplayer + 13% Xorg.bin
accel (vo=vdpau, vc=ffh264vdpau)  0-11% mplayer + 11% Xorg.bin

So vaapi does about as well as vdpau at reducing the cpu load to tolerable levels. Note that although the cpu can handle unaccelerated HD video in video players, it can't in flash (and firefox html5 video looks like it will be a similar story)

Comment 5 Fedora Update System 2015-10-08 20:39:09 UTC
libva-vdpau-driver-0.7.4-12.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-e3f4fa5b19

Comment 6 Fedora Update System 2015-10-09 13:54:41 UTC
libva-vdpau-driver-0.7.4-12.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update libva-vdpau-driver'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-e3f4fa5b19

Comment 7 monkeyboyted 2015-10-28 04:26:52 UTC
vainfo 
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Issue is still presistant on Fedora 23. The symlink workaround works


sudo ln -s /usr/lib/dri/vdpau_drv_video.so /usr/lib/dri/radeonsi_drv_video.so

sudo ln -s /usr/lib64/dri/vdpau_drv_video.so /usr/lib64/dri/radeonsi_drv_video.so

 vainfo 
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_37
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.1)
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
      VAProfileVC1Advanced            :	VAEntrypointVLD

Comment 8 monkeyboyted 2015-10-29 02:40:52 UTC
scratch that. It does not seem to work. I guess I have to wait until all the rpmfusion libraries are release to see if it work well or not.

Comment 9 Nicolas Chauvet (kwizart) 2015-10-29 08:06:25 UTC
This package might be obsoleted by mesa
https://bugzilla.redhat.com/show_bug.cgi?id=1271842

Basically, you should use the mesa gallium_drv_video.so backend instead.
Can you report that it works for you (with radeonsi) ? I've tested with radeon (and still have an issue with nouveau on f22 but need to test with f23).

Comment 10 Fedora Update System 2015-11-01 02:44:05 UTC
libva-vdpau-driver-0.7.4-12.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 11 monkeyboyted 2015-11-02 04:24:33 UTC
I am just confused on the proper procedure on how to test if vaapi work on my computer. When I wrote my post, not all the libraries has been push through fedora. 

I tried this command 

gst-launch-0.10 -vv filesrc location="Louis_CK_OhMyGod_EXT_HD1280.mp4" ! decodebin ! x264enc ! vaapidecode ! vaapisink 

it gave something like this WARNING: erroneous pipeline: no element "x264enc"

I guess this happens when I do not have enough experience with the tool


Now, that fedora 23 has been push to stable. It seems to be working. 

[00007f2e3161cb08] avcodec decoder: Using mesa gallium vaapi for hardware decoding.


Note You need to log in before you can comment on or make changes to this bug.