1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems

Facebook RSS Twitter Twitter Google Plus

Phoronix Test Suite

OpenBenchmarking Benchmarking Platform
Phoromatic Test Orchestration

Ubuntu Will Not Enable Open-Source VDPAU Support


Published on 18 February 2014 12:09 PM EST
Written by Michael Larabel in Ubuntu

This morning I wrote about Mesa 10.1 likely going into Ubuntu 14.04 LTS, but if you were hoping this means Ubuntu will enable VDPAU driver support for open-source hardware-accelerated video decoding, that improvement to video playback isn't going to happen with the official Ubuntu Mesa/Gallium3D driver packages.

A Phoronix reader has sent in an IRC log today where Ubuntu VDPAU support was asked about and Maarten Lankhorst of Canonical responded. While the VDPAU state tracker inside Gallium3D has stabilized greatly and can be used by the Nouveau driver as well as the R600/RadeonSI Gallium3D drivers, it will not be enabled. The Video Decode and Presentation API for Unix is widely supported by Linux multimedia software for offloading the video acceleration of popular video formats onto the GPU. This works really well in the open-source world with the AMD Radeon Linux driver stack since last year when they provided open-source support for UVD, the AMD Unified Video Decoder block found on most modern Radeon GPUs.

Having VDPAU support available "out of the box" would be a big win for open-source Linux GPU driver users since the playback experience is a lot better, since it can allow HD video playback with ultra low-end hardware and it ends up being a smooth and great experience. VDPAU is also provided by NVIDIA's binary Linux graphics driver that's found in the Ubuntu package archive. Unfortunately, Canonical will not be enabling this feature for the open-source drivers.

Enabling the VDPAU support in Mesa comes down to a configure switch at build-time and it's that easy. However, Canonical's apparent reason for not having this support is due to extra space the VDPAU support takes up on the disk. Apparently building in the support to Mesa adds around 8MB to the package size and so they don't want this officially in Ubuntu. Those wanting Mesa/Gallium3D VDPAU support will be left to using external sources like the Oibaf PPA or building Mesa themselves.

Meanwhile, Red Hat's Adam Jackson was also in the IRC room and he wrote, "I should see about getting the vdpau drivers onto our live image though, 8.5M isn't _that_ bad." So we may end up seeing VDPAU driver support out-of-the-box in future Fedora Linux releases while it won't be in Ubuntu over being conservative with the disk image size. The next release of Fedora, version 21 due out in H2'2014, is also aiming for great open-source OpenCL support, another feature not to be found in Ubuntu 14.04 LTS.
15:13 [ zgreg] mlankhorst, do you know what the situation with vdpau is on ubuntu?
15:14 [ mlankhorst] zgreg: disabled, for now
15:14 [ zgreg] mlankhorst: I know. why is it still disabled?
15:14 [ mlankhorst] too big to download
15:15 [ zgreg] what?
15:15 [ mlankhorst] as long as we don't have a size reduction in mesa I'm only going to enable egl and opengl
15:16 [ zgreg] it doesn't need to be shipped on the live cds, but it would be great to have it available as an additional package
15:16 [ zgreg] at the moment people have to jump through various hoops to get vdpau and that sucks
15:17 [ mlankhorst] various hoops = 'install this package from a ppa' :P
15:17 [ zgreg] wouldn't that be a reasonable compromise
15:18 [ zgreg] mlankhorst: yes, but ppas are inofficial, and might introduce bugs. some people only want to use the official repos.
15:18 [ mlankhorst] and if they want something that's officially supported they won't use vdpau :P
15:19 [ xexaxo] zgreg: you can please some people most of the time, or most people some of the time :\
15:19 [ zgreg] sorry, but these excuses are horrible...
15:19 [ mlankhorst] ok I'll be more clear, as it stands I won't officially support vdpau
15:19 [ xexaxo] mlankhorst: do you guys build egl-static ?
15:19 [ mlankhorst] xexaxo: unfortunately, not sure what it adds on top of normal egl, though
15:20 [ zgreg] I'd say egl is less important than vdpau for desktop users :p
15:21 [ xexaxo] mlankhorst: openvg (if it still works), and another duplication of gallium/aux + each gallium driver (~2.5MiB for hw and ~1.5MiB for swrast)
15:21 [ mlankhorst] I don't think debian/ubuntu enables openvg
15:21 [ xexaxo] the numbers are from the drivers alone, gallium/aux is ~1.8M
15:22 [ mlankhorst] xexaxo: but yeah the duplication is really annoying and I want that fixed, your approach looks nice though
15:23 [+ajax] why would you build swrast vdpau
15:24 [ xexaxo] ajax: if that's meant for me - as a roc that the xlib codepaths work with the pipification of vdpau
15:24 [ xexaxo] *POC
15:24 [+ajax] hardware decelerated video decoding
15:25 [+ajax] xexaxo: as a developer that might make sense, as a distro it's pretty useless
15:27 [+ajax] i should see about getting the vdpau drivers onto our live image though, 8.5M isn't _that_ bad
15:28 [+ajax] vg's completely useless though
15:28 [+ajax] also: if y'all really wanted smaller drivers you'd stop writing them in C++
15:29 [ mlankhorst] ajax: yeah not going to happen, but duplicating them many times is a baaad idea
15:34 [+ajax] just for size, or do you have a functionality bug in mind?
15:35 [ zgreg] what happened to the "megadrivers" project?
15:49 [ mlankhorst] zgreg: well xexaxo had a nice patch to use pipe loader everywhere
15:53 [ xexaxo] *almost everywhere
15:54 [ xexaxo] and on top of that work we can get the megadrivers in gallium
15:54 [ xexaxo] as the initial idea of having them dri only did not sound too appealing imho
15:55 [ cand] it would be nice to have some backwards compatibility though (w/ older X servers)
15:55 [ mlankhorst] xexaxo: mostly, there are some conflicts
15:56 [ mlankhorst] xexaxo: src/mesa/x86/rtasm is an old version of what's in gallium, and going to break really badly if you link everything in one big blob :P
16:01 [ xexaxo] mlankhorst: one step at a time, first have one for classic and gallium and then - when we cleanup some of the duplication it can go
16:02 [ xexaxo] currently we have three "hash_table" implementations, and a handful of other fun stuff
16:03 [ xexaxo] hmm is the GLX_MESA_query_renderer spec still considered. Seems like dri3 does not have any support for it - nor anything outside of dri2/intel for that matter
16:03 [ mlankhorst] xexaxo: yeah but those duplicate symbols would prevent it linking in a single place
16:05 [ xexaxo] mlankhorst: I'm aware of that, I did have some very nasty "link it all" experiments

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Articles & Reviews
  1. AMD Radeon R9 290 OpenGL On Ubuntu 15.04: Catalyst vs. RadeonSI Gallium3D
  2. Ubuntu 15.04 Offers Faster OpenGL For AMD Radeon GPUs On Open-Source
  3. Ubuntu 15.04 Brings Some Graphics Performance Improvements For Intel Haswell
  4. Sub-$20 802.11n USB WiFi Adapter That's Linux Friendly
  5. The Lenovo T450s Is Working Beautifully With Linux
  6. Linux 4.0 SSD EXT4 / Btrfs / XFS / F2FS Benchmarks
Latest Linux News
  1. GTX 750 Maxwell Acceleration Starts Working On Nouveau With Linux 4.1
  2. Reasons To Make A PTS/OB Test Profile For Your Software
  3. Vivaldi TP3 Browser Adds Native Window Support On Linux
  4. A Brief Update On Fwupd For Linux Firmware Updating Of Devices
  5. Upgrading To KDE Plasma 5.3 On Kubuntu 15.04
  6. Ubuntu 15.10 Plans Being Discussed Next Week
  7. KDE Plasma 5.3 Released: Expands On Widgets, Bluetooth, PM
  8. Making It Easier To Deploy CUDA On Fedora
  9. GCC 4.9.2 vs. GCC 5 Benchmarks On An Intel Xeon Haswell
  10. Intel Haswell/Broadwell Power Use On Linux Still Moving Lower
Most Viewed News This Week
  1. Ubuntu's Desktop-Next Switching From .DEBs To Snappy
  2. Systemd Kills Off Shutdownd
  3. KDBUS Still Hasn't Been Pulled, Might Not Land For Linux 4.1
  4. My Favorite Computer Desk Of The Past Decade For Less Than $100
  5. The Many Features Of The Linux 4.1 Kernel
  6. AMD Open-Sources "Addrlib" From Catalyst
  7. Qt Creator 3.4 Brings C++ Programming Improvements & More
  8. Debian 8.0 Jessie Is Ready For Release This Weekend