Build Option Request: VAAPI

[dm17]

As requested here: #5219 (comment)

I'm wondering if we can get hardware acceleration for modern AMD GPUs in chromium (build_options_default)? It seems pretty common & very useful.
Thanks!

[Logarithmus]

I'm coming from Arch Linux and it has been having binary packages for chromium-vaapi for years! In AUR, of course. Void
doesn't have AUR analog. So I guess there's no reason to avoid building chromium with VA-API support. People who doesn't like it can always disable it in chrome://flags.

[dm17]

@Logarithmus Right! Perhaps we can both suggest the same for the Firefox pkg...

[Johnnynator]

It was disabled by default, not because it might be unwanted by some people, but because it was broken on some configurations. And shipping broken defaults is bad.

[Logarithmus]

It was disabled by default, not because it might be unwanted by some people, but because it was broken on some configurations. And shipping broken defaults is bad.

The best solution to suit everyone is to build chromium with VAAPI support, but with "Hardware video acceleration" disabled in chrome://flags. So the majority of users who want to enjoy smooth video playback without excess CPU usage and heating could just flip one flag in settings instead of rebuilding for about 8 hours wasting electricity and their time, or trying to somehow repack pacman or dpkg packages.

[dm17]

So the majority of users who want to enjoy smooth video playback without excess CPU usage and heating c

Exactly... No reason to disable modern hardware from being useful on Linux just for some edge cases that are easily worked around (I'll assume such edge cases exist on faith, despite the lack of reference).

[Duncaen]

It was disabled because people couldn't even start chromium to disable the flag...

[dm17]

It was disabled because people couldn't even start chromium to disable the flag...

Can't you run chromium with flags? This seems like hurting the many for the few, which I figured was not a Void approach... Considering everyone already has that approach in Ubuntu et al.

[Logarithmus]

It was disabled because people couldn't even start chromium to disable the flag...

You can specify flags using command line switches:
https://peter.sh/experiments/chromium-command-line-switches/

--disable-accelerated-video-decode

[Duncaen]

There is no need to discuss this, we decided to disable it because it made a lot of trouble.

If someone thinks its good to enable, they need to do the testing and make sure each version works.

Edit: The flag didn't work and it crashed very early with specific setups.

[Logarithmus]

There is no need to discuss this, we decided to disable it because it made a lot of trouble.

If someone thinks its good to enable, they need to do the testing and make sure each version works.

Edit: The flag didn't work and it crashed very early with specific setups.

Please, can you provide more info on this? What were those "specific configurations"?
If you mean old GPU's, then it's unlikely the case: I have 2012 year laptop as my daily driver. It has AMD Radeon HD 7670M graphics adapter and dual core i3 CPU. And this GPU works flawlessly for decoding H264 with VAAPI, as well as with VDPAU. Without hardware acceleration, my CPU starts to heat up and the fan becomes louder. So as a person with older hardware, I'm pro-VAAPI person.

[Duncaen]

It broke all the time for different reasons, videos didn't work on new AMD hardware then the last time when I disabled it, it just crashed early with intel graphics.

I don't care if there are people who are "pro-VAAPI" as long as they don't do the work like testing on different setups and make sure everything works. There is a reason why this is not enabled by default and why chrome doesn't ship with it in linux builds.

[dm17]

It broke all the time for different reasons, videos didn't work on new AMD hardware then the last time when I disabled it, it just crashed early with intel graphics.

I don't care if there are people who are "pro-VAAPI" as long as they don't do the work like testing on different setups and make sure everything works. There is a reason why this is not enabled by default and why chrome doesn't ship with it in linux builds.

OK... Well sounds like there's a bug in Chrome if the flags to launch without it don't actually work, right?

[Logarithmus]

It broke all the time for different reasons, videos didn't work on new AMD hardware then the last time when I disabled it, it just crashed early with intel graphics.

I don't care if there are people who are "pro-VAAPI" as long as they don't do the work like testing on different setups and make sure everything works. There is a reason why this is not enabled by default and why chrome doesn't ship with it in linux builds.

What do you think about making separate package, like ungoogled-chromium-vaapi?
Me and some another guy plan to make one. Will it be pushed into the repo?

[dm17]

It broke all the time for different reasons, videos didn't work on new AMD hardware then the last time when I disabled it, it just crashed early with intel graphics.
I don't care if there are people who are "pro-VAAPI" as long as they don't do the work like testing on different setups and make sure everything works. There is a reason why this is not enabled by default and why chrome doesn't ship with it in linux builds.

What do you think about making separate package, like ungoogled-chromium-vaapi?
Me and some another guy plan to make one. Will it be pushed into the repo?

@Logarithmus
We'll just follow this... Which seems to clarify the quality requirements:
https://github.com/void-linux/void-packages/blob/master/Manual.md#quality_requirements

[Duncaen]

What do you think about making separate package, like ungoogled-chromium-vaapi?
Me and some another guy plan to make one. Will it be pushed into the repo?

Chromium alone is already a big maintenance burden and regularly blocks the build server for 9+ hours.
So I don't think there is a high chance to get it into the repository because of limited resources, there are already package requests for ungoogled-chromium that were closed/rejected.

https://github.com/void-linux/void-packages/issues?q=is%3Aissue+ungoogled-chromium+is%3Aclosed

[Johnnynator]

The problem is, that chromium right now takes 12h on the builders. This is also the reason I have not merged any of my Electron PR's yet. It just blocks the builders too long.

[dm17]

So there's a general problem in Void having more packages because the amount of money / resources Void has for CPU cycles? We can open another thread for this idea if you think it is valid: perhaps there's a way to have building done in a verified way on dev computers (or maybe there'd be no way to verify that)?

[Duncaen]

This is specific to chromium/blink/webkit being that big and resource intensive.
And I don't think there is going to be an exception to manually add packages to the repositories that are being build automatically.
But there is nothing stopping someone from hosting their own repository and signing packages with their own keys.

[dm17]

This is specific to chromium/blink/webkit being that big and resource intensive.
And I don't think there is going to be an exception to manually add packages to the repositories that are being build automatically.
But there is nothing stopping someone from hosting their own repository and signing packages with their own keys.

Ok. I'll ask the ungoogled-chromium dev if we can build some of the components once for use in both chromium & ungoogled-chromium.

@Duncaen Also, I'm new to xbps... Any idea if it needs to build each component from scratch each time, as these devs are claiming a good pkg manager should be able to avoid: https://lobste.rs/s/iri1te/chromium_has_compilation_time_problem

[Duncaen]

Its the build system and not the package manager, xbps-src currently cleans up builds after finishing packages so incremental builds are not supported.

Also even if this would be supported I don't think we would have the resources to store objects for each package to allow incremental builds.
Which is probably also going to break with a lot of build systems that rebuild stuff based on mtime instead of hashing inputs.

[dm17]

Its the build system and not the package manager, xbps-src currently cleans up builds after finishing packages so incremental builds are not supported.

Also even if this would be supported I don't think we would have the resources to store objects for each package to allow incremental builds.
Which is probably also going to break with a lot of build systems that rebuild stuff based on mtime instead of hashing inputs.

Incremental builds would be sweet. @Logarithmus and I will try to help with that in a month or so.
Looks like here is a starting place for us:

1. https://www.chromium.org/chromium-os/build/faq#TOC-How-do-I-test-that-my-change-does-not-break-an-incremental-build-
2. http://neugierig.org/software/chromium/notes/2011/02/ninja.html
3. https://randomascii.wordpress.com/2020/03/30/big-project-build-times-chromium/

If we get it working, then perhaps other Void packages could make use of the code.

[Logarithmus]

So there's a general problem in Void having more packages because the amount of money / resources Void has for CPU cycles? We can open another thread for this idea if you think it is valid: perhaps there's a way to have building done in a verified way on dev computers (or maybe there'd be no way to verify that)?

I've heard of verified builds before... I think I should investigate this topic further.

[Logarithmus]

What do you think about making separate package, like ungoogled-chromium-vaapi?
Me and some another guy plan to make one. Will it be pushed into the repo?

Chromium alone is already a big maintenance burden and regularly blocks the build server for 9+ hours.
So I don't think there is a high chance to get it into the repository because of limited resources, there are already package requests for ungoogled-chromium that were closed/rejected.

https://github.com/void-linux/void-packages/issues?q=is%3Aissue+ungoogled-chromium+is%3Aclosed

If you lack of processing power, maybe we just need to pay for more powerful server? I'm sure there are people who can donate for the servers, including me. Also using volunteer's processing power, in Rosetta@home's fashion, seems reasonable. But then the issue of trust stands on.

[dm17]

What do you think about making separate package, like ungoogled-chromium-vaapi?
Me and some another guy plan to make one. Will it be pushed into the repo?

Chromium alone is already a big maintenance burden and regularly blocks the build server for 9+ hours.
So I don't think there is a high chance to get it into the repository because of limited resources, there are already package requests for ungoogled-chromium that were closed/rejected.
https://github.com/void-linux/void-packages/issues?q=is%3Aissue+ungoogled-chromium+is%3Aclosed

If you lack of processing power, maybe we just need to pay for more powerful server? I'm sure there are people who can donate for the servers, including me. Also using volunteer's processing power, in Rosetta@home's fashion, seems reasonable. But then the issue of trust stands on.

If we could figure out incremental builds, then I think that would be more important - since the build time would be much less and therefore people would be more willing to update the pkg (plus it might work similarly for other long compile-time pkgs).

[ericonr]

This is fixed on current chromium packages.

[dm17]

This is fixed on current chromium packages.

Have you verified it using the method of looking in about:media-internals?
I tried many times and I still see the non-hardware-accelerated codec being used for Vimeo & YouTube videos (VpxVideoDecoder).

[ericonr]

As far as I know, the VAAPI build option is no longer required in any way. If the hw accel isn't working correctly / being detected, that's a separate issue.

[dm17]

As far as I know, the VAAPI build option is no longer required in any way. If the hw accel isn't working correctly / being detected, that's a separate issue.

Such a pain to debug chromium. Perhaps Void should consider replacing chromium with its own custom build of ungoogled-chromium... Wouldn't that be truer to the FOSS message anyway (considering how much tracking comes with chromium)?

[Logarithmus]

This is fixed on current chromium packages.

Have you verified it using the method of looking in about:media-internals?
I tried many times and I still see the non-hardware-accelerated codec being used for Vimeo & YouTube videos (VpxVideoDecoder).

@dm17 Just install enhanced-h264ify chromium extension, block everything except h264 and it will work like a charm (if you use Xorg, not Wayland). For Nvidia there's https://github.com/xtknight/vdpau-va-driver-vp9

[dm17]

This is fixed on current chromium packages.

Have you verified it using the method of looking in about:media-internals?
I tried many times and I still see the non-hardware-accelerated codec being used for Vimeo & YouTube videos (VpxVideoDecoder).

@dm17 Just install enhanced-h264ify chromium extension, block everything except h264 and it will work like a charm (if you use Xorg, not Wayland). For Nvidia there's https://github.com/xtknight/vdpau-va-driver-vp9

I use Xorg. I did try this extension, but it did not change the fact:
"If it says FFmpegVideoDecoder or VpxVideoDecoder, accelerated video decoding is not working"
https://www.linuxuprising.com/2018/08/how-to-enable-hardware-accelerated.html

about:media-internals:

"Failed to initialize DecryptingVideoDecoder"
"Failed to initialize MojoVideoDecoder"
"Failed to initialize VpxVideoDecoder"
"Failed to initialize Dav1dVideoDecoder"
kIsVideoDecryptingDemuxerStream | false
kVideoDecoderName | "FFmpegVideoDecoder"

[Logarithmus]

@dm17 what GPU do you have? Did you read this: https://wiki.archlinux.org/index.php/Hardware_video_acceleration ? 21 января 2021 г. 2:19:00 GMT+03:00, dm17 <notifications@github.com> пишет:

…

> > > This is fixed on current chromium packages. > > > > > > Have you verified it using the method of looking in about:media-internals? > > I tried many times and I still see the non-hardware-accelerated codec being used for Vimeo & YouTube videos (VpxVideoDecoder). > > @dm17 Just install **enhanced-h264ify** chromium extension, block everything except h264 and it will work like a charm (if you use Xorg, not Wayland). For Nvidia there's https://github.com/xtknight/vdpau-va-driver-vp9 I use Xorg. I did try this extension, but it did not change the fact: "If it says FFmpegVideoDecoder or VpxVideoDecoder, accelerated video decoding is not working" https://www.linuxuprising.com/2018/08/how-to-enable-hardware-accelerated.html about:media-internals: ``` "Failed to initialize DecryptingVideoDecoder" "Failed to initialize MojoVideoDecoder" "Failed to initialize VpxVideoDecoder" "Failed to initialize Dav1dVideoDecoder" kIsVideoDecryptingDemuxerStream | false kVideoDecoderName | "FFmpegVideoDecoder" ```

[dm17]

@Logarithmus Yes, read that. I have Polaris 20 (an AMD card with some of the best support in Linux).

[Duncaen]

Such a pain to debug chromium. Perhaps Void should consider replacing chromium with its own custom build of ungoogled-chromium... Wouldn't that be truer to the FOSS message anyway (considering how much tracking comes with chromium)?

How does this in any way make any sense to you, how would that reduce any work instead of adding more work?
Chromium is FOSS, chromium is the maintained browser, its FOSS there is not more or less FOSS.
Stop spamming us with ungoogled chromium stuff, I've had enough of it, we said no not once but in multiple different threads and you have to accept it.