chromium does not accelerate video without following this procedure: https://code.google.com/p/chromium/wiki/LinuxHWVideoDecode Can we have that set up behind a USE flag?
"Hardware acceleration of video decode on linux is unsupported in Chrome for user-facing builds. During development (targeting other platforms) it can be useful to be able to trigger the code-paths used on HW-accelerated platforms (such as CrOS and win7) in a linux-based development environment."
(In reply to Jeroen Roovers from comment #1) > "Hardware acceleration of video decode on linux is unsupported in Chrome for > user-facing > builds. During development (targeting other platforms) it can be useful to > be able to > trigger the code-paths used on HW-accelerated platforms (such as CrOS and > win7) in a > linux-based development environment." I think it would make sense to include a "you get to keep the pieces" warning if the flag is selected. However, if somebody is willing to do the work to implement this I don't see why we shouldn't allow it. If people find bugs and fix them it only helps the upstream project, and other Gentoo users.
Just wanted to say that I kludged together a chromium build based on the HOWTO cited by OP and so far it's working well on my ~amd64 x11-drivers/xf86-video-ati workstation. It was just as a one-off experiment: I simply wedged stuff into the build-tree between ebuild phases... I didn't even bother to take notes. But, the resulting chromium has noticeably less jank. It's not nearly as smooth as chrome-Windows, but it's definitely* noticeably improved compared to what I'm used to. I was also pleasantly surprised to discover that it took very little work to do, because most of the requirements discussed in the HOWTO already coincide with how Gentoo's ebuilds do things already. In a nutshell, I think the only things missing are a few library dependencies which should be satisfied by something like: RDEPEND+="vdpau? ( x11-libs/libva[vdpau] )" and a couple (iirc, literally just two) trivial patches to remove the upstream behavior of making a ChomeOS build a prerequisite to gpu acceleration enablement (technically I'm pretty sure the HOWTO is telling us to request a chromeos build from the build-system, which, I decided was too kludgy and error-prone an idea even for a one-off experiment), with one exception: Despite the HOWTO's advice to use "--no-sandbox" at runtime, when invoking chromium, it wasn't required to get acceleration up and running. On my system it seems that acceleration is indeed happening even when I keep the sandbox enabled. Either way, chromium uses GPU acceleration, and periodically makes incomprehensible complaints onto stderr, although the precise complaints do seem to vary as a function of whether or not I pass --no-sandbox... I'll try to whip up an ebuild encapsulating whatever
(In reply to Gregory Turner from comment #3) > ... the resulting chromium has noticeably less jank. It's not nearly as > smooth as chrome-Windows, but it's definitely* noticeably improved compared > to what I'm used to. * I tweaked the necessary run-time settings, and double-checked in the appropriate places: and, yes, before you ask, the gpu acceleration was really and truly active in the browser. Anyhow, Mr. Imaginary-Tough-Question-Askey-Dude, since you're so damn smart, you should know that my having seen real accelerated chromium in no way disconfirms the hypothesis that my perception of reduced jank was attributable to placebo effect or confirmation bias, so nyaaah!
(In reply to Gregory Turner from comment #3) > I'll try to whip up an ebuild encapsulating whatever ... I can remember.
A bit of a status update... Thinking about this from a perspective of a proxy maintainer (as opposed to just a dude throwing patches over the wall via this bug) is a bit overwhelming. First, there are several orthogonal features, such as vaapi-accelerated video decoding, v4l2-accelerated video encoding, and gpu-accelerated-render-compositing, etc., that we can try to add frobs for if we want. Second, consider the many dimensions of support that currently or potentially arise in Gentoo within the www-client/chromium package slot: o Per platform: Does code exist to enable a given feature for a given platform? o Per slot: Does that code exist in stable, beta, and canary versions? o Time Scary or no, I have been working on some patches, for the 44.0.2403.xx (::beta) ebuilds. They don't compile yet, but I seem to be making some kind of progress. Can't say what I have so far is beautiful but much of the ugliness is seemingly driven by my personal ignorance of the chrome build system; with some effort can probably be eliminated or refactored to be less ugly. No promises but there is at least a chance something useful will come out of it.
Thank you for your efforts Gregory.
Haven't been messing with this too much as I've been hoping to get another chromium bug, #547630, sorted out first. However, I did want to document, both for myself and anyone else wanting to look into this, that much inspiration can be had looking at ubuntu's gpu-accelerated chromium ppa: http://bazaar.launchpad.net/~saiarcot895/chromium-browser/chromium-browser.wily.beta/files/head:/debian/patches/ The only problem with stealing those patches is they largely work by hard-coding behaviors whereas I think the correct equivalent in Gentoo would be to patch the .gyp infrastructure to make changes to the build configurable at build-time via gyp frobs -- in other words, we are sort-of "forced" to proceed as if we were designing our patches for upstream.
New link to docs is https://chromium.googlesource.com/chromium/src/+/master/docs/linux_hw_video_decode.md This seems completely unsupported and requires --no-sandbox . Also, chromeos=1 is somewhat hacky for a desktop build. Is it really feasible to try doing this in main tree ebuild at this time? It might be more suitable for one's custom builds or possibly an overlay.
