New mesa features for the adventurous: Radeon UVD and Gallium3D HUD

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.


For kernel 3.9, 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 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  1152
If 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 acceleration
To 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.


Anonymous said...

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?

Unknown said...

One patch was mistakenly reversed, this is fixed in v2 tarball now.

Anonymous said...

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.

dimitri giardina said...

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.

sayap said...

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.

Anonymous said...

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.

dimitri giardina said...

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"


Anonymous said...

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

dimitri giardina said...


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?


Unknown said...

Sorry, but this is not the correct place to report problems other than setup issues. These should be directed to the radeon folks.

boris64 said...

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

Unknown said...

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

Anonymous said...

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.

Unknown said...

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.

dimitri giardina said...

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.


Unknown said...

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.

dimitri giardina said...

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.


Anonymous said...

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.

Unknown said...

The MA785 chipset (HD4200)
supported by the patches

Unknown said...

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 ?

Unknown said...

No. HD4200 is not supported at this time.

sys-kernel/gentoo-sources-3.9.1 now contains the UVD patches.

Anonymous said...

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.

Unknown said...

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.

Anonymous said...

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.

A. Vollmerhaus said...

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.