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

Ubuntu Will Not Enable Open-Source VDPAU Support

Ubuntu

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

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

Latest Linux Hardware Reviews
  1. Overclocking The AMD AM1 Athlon & Sempron APUs
  2. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  3. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
  4. AMD Athlon 5350 APU On Linux
Latest Linux Articles
  1. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  2. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  3. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
  4. DDR3 Memory Scaling Performance With AMD's Athlon 5350
Latest Linux News
  1. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  2. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  3. Red Hat Releases Its RHEL 7 Release Candidate
  4. New Features Coming To Xubuntu 14.04 LTS
  5. NVIDIA Officially Releases CUDA 6
  6. Google Releases An AutoFDO Converter For Perf In LLVM
  7. Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation
  8. Star Citizen Will Be Coming To Linux
  9. Ubuntu 14.10 Convergence To Focus On Replacing Core Apps
  10. The Results Of Optimizing Radeon's VRAM Behavior
  11. Kernel Developers Discuss Improving Kernel Configurations
  12. Apple, LLVM Developers Figure Out Their 64-Bit ARM Approach
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. New tool for undervolt/overclock AMD K8L and K10 processors
  5. How to enable opengl 3.3 on r9 270?
  6. R290x sound problems
  7. radeon-profile: tool for changing profiles and monitoring some GPU parameters
  8. Torvalds Is Unconvinced By LTO'ing A Linux Kernel