Which Chromium flavors to build on Hydra?

[primeos]

Currently we only build the following package on Hydra:

• chromium (on both nixos-unstable and nixos-stable)

But since the build times are very high, it might make sense to add additional popular flavors.

Potential candidates (+ combinations):

• [x] ungoogled-chromium: Pretty popular and IIRC already includes the VA-API patches by default
  • Depends on https://github.com/NixOS/nixpkgs/pull/76082 (actually there are multiple PRs)
• [x] VA-API: With the VA-API patches
  • Implementation: Built by default, can be enabled in the wrapper via enableVaapi = true;
  • Would be great if we could enable these patches (actually only one small patch) by default
  • Last time it was disabled due to issues with the radeon driver (at least on some AMD GPUs)
  • I can confirm this issues with my HD 6950, but VA is only enabled with if I use --ignore-gpu-blacklist - i.e. if the blacklist is good enough it might be fine. -> Would be great if we could apply the patches but VA is disabled by default (independent of the GPU).
  • Very useful for laptops! Basically required e.g. for/beyond 1080p@60Hz on YouTube and Google Stadia.
• chromium-widevine: Shouldn't require a rebuild (TODO: verify)
• chromium-ozone: For native Wayland support
  • Alternative: https://github.com/colemickens/nixpkgs-chromium
  • Might soon be the default (finally):
  • 2019: Chromium's Ozone Wayland Back-End Is Now Considered Beta, Aiming To Ship Next Year
  • 2020: Chrome Is Reaching The Point Of Good X11 + Wayland Support In Same Build

Unlikely candidates:

• chromiumBeta, chromiumDev: Our support should focus on the stable channel.

Testing: chromium should always work, other flavors should be provided on a best effort basis (or have a dedicated maintainer).

Ideally we'd have at most two different flavors to keep it manageable and avoid unnecessary Hydra overhead.

What other distributions do: TODO, see e.g. https://repology.org/projects/?search=chromium Additional resources:

• https://chromium.googlesource.com/chromium/src/+/master/docs/gpu/vaapi.md#VaAPI-on-Linux
  • Suggests that at least --ignore-gpu-blacklist is always required
• https://chromium.googlesource.com/chromium/src.git/+/master/docs/ozone_overview.md
• ...

Status: WIP, please add feedback, suggestions, general thoughts, etc.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/would-it-be-possible-to-provide-binary-cache-for-chromium-vaapi/6229/2

[dR3b]

Please that would be a very good improvement. It would have a positive effect on the battery. On my Intel NUC it takes over 16 hours to compile... I'd be delighted.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixos-unstable-hasnt-been-updated-in-a-while/6584/13

[primeos]

There's now a draft for chromium-vaapi: https://github.com/NixOS/nixpkgs/pull/85076 But IMO (and as already discussed in that PR) chromium-vaapi isn't really worth the overhead (building + maintaining). Therefore I'm more in favor of enabling VA-API by default (vs. an additional package)

As an alternative I considered adding chromium-experimental with Ozone + VA-API (and possibly additional features). I'd prefer that approach, but unfortunately that works less reliable and seems not ready for Nixpkgs yet (e.g. it required custom patches or a Nixpkgs package for minigbm when I tested it with M80).

Back to enabling VA-API by default: One issue is that Chromium seems to lacks a more fine grained control than ignore-gpu-blacklist (which ignores all entries - not just VA-API - which is mainly important as some users might already use that flag for other purposes). Another issue is that VA-API causes some overhead to maintain (e.g. M81 required two additional patches: https://github.com/NixOS/nixpkgs/commit/b533f103452d5f39dace33a1b76ff88ac8f0f21f) and might break as it is not officially supported. Therefore I'd suggest that we try to enable it by default as an experimental feature, but disable it again if it causes too many problems. It is important to note that VA-API was already enabled once by default and that didn't work out. However, I think if we discuss this first, run some tests before enabling it, and don't backport it to stable right away we should be able to merge such a change without causing too many problems at once (which would require reverting that change).

E.g. one interesting possibility to look into would be to enable disable-accelerated-video-decode and disable-accelerated-video-encode by default. If that works as expected this shouldn't break any existing setups, even with ignore-gpu-blacklist.

[misuzu]

E.g. one interesting possibility to look into would be to enable disable-accelerated-video-decode and disable-accelerated-video-encode by default. If that works as expected this shouldn't break any existing setups, even with ignore-gpu-blacklis

How about this:

chromium-vaapi = callPackage ../applications/networking/browsers/chromium ((config.chromium or {}) // { useVaapi = true; });
chromium = chromium-vaapi.override { commandLineArgs = "--disable-accelerated-video-decode --disable-accelerated-video-encode"; };

chromium-vaapi and chromium should only have different wrappers so no rebuilds required!

[stale[bot]]

I marked this as stale due to inactivity. → More info

[primeos]

The situation has significantly improved since I opened this issue and (IMO) we can close it now :tada:

We currently build the following on Hydra:

• chromium: With VA-API and Ozone support now :)
• ungoogled-chromium (should also support VA-API and Ozone)