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