Those of you who don't live under a rock will have learned by now that AMD has published VDPAU code to use the Radeon UVD engine for accelerated video decode with the free/open source drivers.
In case you want to give it a try, mesa-9.2_pre20130404 has been added (under package.mask) to the portage tree for your convenience. Additionally you will need a patched kernel and new firmware.
grab the 10 patches from the dri-devel mailing list thread (recommended) [UPDATE]I put the patches into a tarball and attached to Gentoo bug 466042[/UPDATE]. For kernel 3.8 I have collected the necessary patches here, but be warned that kernel 3.8 is not officially supported. It works on my Radeon 6870, YMMV.
The new firmware files are
radeon/RV710_uvd.bin: Radeon 4350-4670, 4770.
radeon/RV770_uvd.bin: Not useful at this time. Maybe later for 4200, 4730, 4830-4890.
radeon/CYPRESS_uvd.bin: Evergreen cards.
radeon/SUMO_uvd.bin: Northern Islands cards and Zacate/Llano APUs.
radeon/TAHITI_uvd.bin: Southern Islands cards and Trinity APUs.
If you have any questions or problems setting up UVD on Gentoo, stop by #gentoo-desktop on freenode IRC.
In case you want to give it a try, mesa-9.2_pre20130404 has been added (under package.mask) to the portage tree for your convenience. Additionally you will need a patched kernel and new firmware.
Kernel
For kernel 3.9,Firmware
The firmware is part of radeon-ucode-20130402, but has not yet reached the linux-firmware tree. If you require other firmware from the linux-firmware package, remove the radeon files from the savedconfig file and build the package with USE="savedconfig" to allow installation together with radeon-ucode. [UPDATE]linux-firmware-20130421 now contains the UVD firmware, too.[/UPDATE]The new firmware files are
radeon/RV710_uvd.bin: Radeon 4350-4670, 4770.
radeon/RV770_uvd.bin: Not useful at this time. Maybe later for 4200, 4730, 4830-4890.
radeon/CYPRESS_uvd.bin: Evergreen cards.
radeon/SUMO_uvd.bin: Northern Islands cards and Zacate/Llano APUs.
radeon/TAHITI_uvd.bin: Southern Islands cards and Trinity APUs.
Testing it
If your kernel is properly patched and finds the correct firmware, you will see this message at boot:
[drm] UVD initialized successfully.If mesa was correctly built with VDPAU support, vdpauinfo will list the following codecs:
Decoder capabilities: name level macbs width height ------------------------------------------- MPEG1 16 1048576 16384 16384 MPEG2_SIMPLE 16 1048576 16384 16384 MPEG2_MAIN 16 1048576 16384 16384 H264_BASELINE 16 9216 2048 1152 H264_MAIN 16 9216 2048 1152 H264_HIGH 16 9216 2048 1152 VC1_SIMPLE 16 9216 2048 1152 VC1_MAIN 16 9216 2048 1152 VC1_ADVANCED 16 9216 2048 1152 MPEG4_PART2_SP 16 9216 2048 1152 MPEG4_PART2_ASP 16 9216 2048 1152If mplayer and its dependencies were correctly built with VDPAU support, running it with "-vc ffh264vdpau," parameter will output something like the following when playing back a H.264 file:
VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU accelerationTo make mplayer use acceleration by default, uncomment the [vo.vdpau] section in /etc/mplayer/mplayer.conf
Gallium3D Head-up display
Another cool new feature is the Gallium3D HUD (link via Phoronix), which can be enabled with the GALLIUM_HUD environment variable. This supposedly works with all the Gallium drivers (i915g, radeon, nouveau, llvmpipe). |
| An example screenshot of Supertuxkart using GALLIUM_HUD="cpu0+cpu1+cpu2:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,pixels-rendered" |
If you have any questions or problems setting up UVD on Gentoo, stop by #gentoo-desktop on freenode IRC.
25 comments:
So, what kernel did you actually build this on? Since the patches from the mailing list don't apply properly to either 3.9-rcX.
And your 3.8 patchset applies (with some offsets though) - but doesn't compile properly because of evergreen_dma_is_lockup being undefined.
What about releasing one patch vs vanilla 3.8.6 or similar?
One patch was mistakenly reversed, this is fixed in v2 tarball now.
Hi
I could not apply your patches cleanly neither to 3.9 nor to 3.8. So I've just rebuilt from dev's git repo -
http://cgit.freedesktop.org/~deathsimple/linux/?h=uvd-3.9 (uvd-3.9 branch)
Together with mesa-9.2_pre20130404 it works.
Thanks for a small howto.
Success with gentoo, kernel-3.8.6, mesa-9.2_pre20130404, (libX11-1.5.0), xorg-xserver-1.13.1
in kernel log, [drm] i see UVD as you told.
xbmc 12.1 decodes without glitches x264, mpeg2 streams; but freezes (only xbmc) in some cases when i stop playing.
in kernel log there's no trace of failures about UVD. my arch is a Dual Core E2140@1.4Ghz, 2GB ram, SATA2 disk.
Cpu level about 4% when playing.
Probably the freezes about xbmc are due to the fact that on xbmc they are playing a lot with vdpau on nvidia.
Same experience as dimitri in regard to XBMC vdpau playback (xbmc-9999 here).
SMPlayer seems to work nicely with "Output driver" set to vdpau. However, if "Freetype support" is checked, then playback becomes very slow. No such problem with xv.
Dammit, at this rate I'm gonna look like an imbecile since I was telling everyone it would take about 10 years before AMD FLOSSers got working and supported H.264 hardware decoding. Oh well, at least it still requires patching not yet released kernel and by the look of things will take at least 3-4 more years to support the Hi10p profile and H.265 looks to be set to hit the world next year along with 4k resolution (that's 4xFullHD in pixels) and I hear the combo seems to be taxing even on current high-end PCs. At least Ffmpeg/libav will give us working software decoder that will work before the AMD/mesa guys have heard of it.
I retry some tests with vlc (i assume it's compiled with vdpau). i don't know how much mplayer with vdpau is stable.
* when loading a video, xbmc stops at "Creating Demuxer"
bye
According to my memory MPlayer was the first to adopt VDPAU with everyone else either being all anti-nVidia and siding with Intel's VA-API like VLC or waiting for Xv-whatever-AMD-planned which was a stillbirth years after the other two.
Anyway, for best VDPAU experience you should probably try media-video/mplayer2 or media-video/mpv. Both trace back to MPlayer but it seems that most of action takes place in MPlayer and mpv..
dear.
3 days ago i've done some tests.
only some h264 streams are going ok.
but for a lot of other streams the windows outs trash and the kernel give me this errors:
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
radeon 0000:04:00.0: r600_check_texture_resource:1551 tex pitch (384, 0x100, 1) invalid id
i'm using a clone of 3.9 kernel from deathsimple repo on cgit.freedesktop.org
there's some news about?
regards.
Sorry, but this is not the correct place to report problems other than setup issues. These should be directed to the radeon folks.
Is there any way to get a patch
(without using git) that actually
applies cleanly to a _current_ kernel?
I'm really looking forward to uvd support ;)
Thanks in advance
If by current kernel you mean 3.8, get v2 tarball from http://dev.gentoo.org/~chithanh/radeon-uvd/
If you mean 3.9, the patches are attached to https://bugs.gentoo.org/show_bug.cgi?id=466042
kernel 3.8 does not work anymore with mesa-9.2_pre20130427. Can you make a new 3.8 patchset with the latest changes (as you did for 3.9 on https://bugs.gentoo.org/show_bug.cgi?id=466042)?
Thanks in advance.
No, making the latest patches apply to 3.8 is too much work for too little gain.
Either upgrade to kernel 3.9 or stay with kernel 3.8 and mesa-9.2_pre20130404.
Hi Ci Thanh,
i've updated to 0427 mesa (the kernel is taken from a snapshot of the freekernel git of 3.9 of konig).
but vdpauinfo detects only mpeg1 and mpeg2 decoding.
bye
If you see only MPEG2 in vdpauinfo it means that there is a mismatch between kernel and mesa code.
The uvd-3.9 branch is obsolete, either use the patches from bug 466042 with vanilla kernel, or airlied's drm-next.
ok. i've updated the kernel checking out a snapshot from airlied one.
it's great for mpeg2 and h264 streams (hd-ready only, even with xbmc). but not with h264 hd-full streams. mplayer2 told me that i've a slow pc, and xbmc freezes (and i've to kill it).
i premit that i'm testing it with my hd4550, but it's working better than fglrx drivers.
bye.
dimitri
dimitri giardina, do you even need hardware accelerated decoding? Modern threaded ffh264 is very capable and fast as long as you have at least 2 GHz Core 2 Duo or better for FullHD while HD can be handled by 1.5 GHz Core 2 Duo if not less. And threaded decoding was merged in ffmpeg upstream at least a year or even two ago while libav had it a good year or two before ffmpeg.
Doing decoding in the hardware isn't always the best option. For example, handing new formats such as H.264 Hi10p (that's High profile 10 bits per pixel) can only be done in software until upgraded hardware is released right on time for introduction of 4K H.265 or later and it's generally agreed that software decoders can better handle corrupt or invalid bitstreams.
The MA785 chipset (HD4200)
http://www.avsforum.com/t/1163214/the-official-gigabyte-ga-ma785gm-us2h-amd-785g-chipset-motherboard-thread
supported by the patches
Is the MA785G (HD4200)
I tried the patches with 3.9.1, but don't see the UVD string, as described. Maybe the chipset is not supported, yet ?
No. HD4200 is not supported at this time.
sys-kernel/gentoo-sources-3.9.1 now contains the UVD patches.
This may be a double post, had a minor slip up when I posted...
I receive this error attempting to compile sys-kernel/gentoo-sources-3.9.1:
make[4]: *** No rule to make target `drivers/gpu/drm/radeon/radeon_uvd.o', needed by `drivers/gpu/drm/radeon/radeon.o'. Stop.
I have an RS880 (HD4250) apparently unsupported chipset. Under external firmware blobs I have "radeon/R600_rlc.bin" entered. Any way to prevent this error if UVD isn't available to me?
Thanks in advance.
Yes that was a small patching issue in gentoo-sources, which is fixed now. emerge --sync again in an hour or so, and the problem should go away.
H.264 Hi10p actually means 10 bits per primary (R, G and B) rather than pixel. Per pixel it's often called RGB30, I think.
Got it working, kernel 3.10.1-gentoo with mesa-9.2_pre20130619 on a Radeon HD 7340.
Playback via mplayer is working fine, although the hardware decoder is somewhat picky about corrupted or invalid files that pass software decoding quite fine.
Post a Comment