Void-packages: Build Option Request: VAAPI

[dm17]

As requested here: https://github.com/void-linux/void-packages/pull/5219#issuecomment-643661306

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