Page 2 of 2
Posted: Thu Feb 06, 2025 7:26 am
by M1buKy0sh1r0
NeddySeagoon,
in my case it is detected as:
This may did the trick on the apple m1 only.
Posted: Thu Feb 06, 2025 9:23 pm
by NeddySeagoon
M1buKy0sh1r0,
True.
There is no change on a Pi5
Posted: Fri Feb 14, 2025 6:49 am
by hardhat
The Chromium situation is worse on older ARMv8 processors. My board lacks SVE, SME, i8mm, and dotprod. If I were to enable arm_use_neon (for some reason this is not respected for CPU features in the ebuild) and therefore I have to do the following:
- libyuv_use_sme = false
- libyuv_use_sve = false
- LIBYUV_DISABLE_NEON_DOTPROD=1
- stop libaom, libgav1, and libdav1d from building
- libvpx fails here because I can't stop it from building at all
The accomodation for CPU flags in recent Chromium seems to be whack and halfassed.
Some of the bundled libraries are all hardcoded to expect later ARM revisions. There is no arm_use_neon_dotprod nor arm_use_sve, etc.
For example, libdav1d's preconfigured define headers expect v8.6 and newer.
Because they are headers we have to sed patch them if we are expected to make them bend to our will.
This bullshit is to be expected but it's sad that they neglect their older userbase.
So in the end I have to do arm_use_neon=false, and I don't even know if I'll run into any errors-- yet.
What happened to system-libvpx and system-av1 on Chromium, by the way? Those flags are now dead gone.
Posted: Fri Feb 14, 2025 2:39 pm
by Hu
I have not discussed any of this post with the people who maintain Chromium in Gentoo.
As I read the
gentoo.git history for
www-client/chromium, chromium-117.0.5938.149.ebuild had support for USE=system-av1, but newer ebuilds do not. Presumably, this means that newer releases cannot work with the system version without more downstream effort than the Gentoo maintainer was willing to volunteer. It might be the case that this flag would come back if the upstream Chromium developers made it easier for Gentoo to switch to the system version.
I also found
www-client/chromium unmask system-av1 ?, where a (now retired) Gentoo developer stated:
[bug=909343#c1]Stephan Hartmann[/bug] wrote:Chromium uses internal API of libaom. Bundled ffmpeg has modifications required for compiling Chromium.
From this, I would infer that there is more work - maybe much more work - involved than merely deleting the bundled copy and passing some flags to point to the system version.
Posted: Sat Feb 15, 2025 1:53 am
by hardhat
That was exactly what I suspected... alas.
Also: only one wasted day later did I realize that arm_use_neon is not exposed to build configuration. D'oh!
At some point I will try to come up with an idea how to patch this stuff properly, but for now I'm going to stick with Firefox.
Posted: Sat Feb 15, 2025 12:09 pm
by NeddySeagoon
hardhat,
neon on 32 bit arm and neon on 64 bit arm are completely different things.
That's a mess.
There has been some discussion about splitting CPU_FLAGS_ARM= into two, so CPU_FLAGS_ARM64= applied to aarch64 and CPU_FLAGS_ARM was for 32 bit only.
Nothing has happened yet.
Both neons would still be different.
Posted: Wed Mar 19, 2025 8:18 pm
by NeddySeagoon
There is a horrible hacky patch in
www-client/chromium-133.0.6943.27 build fails with ld.lld: error: undefined symbol: __arm_tpidr2_save that changes libyuv's CPU feature detection from one value of wrong to a different value of wrong that works on a Pi5,
It may point the way to similar hacky patches to support other arm64 feature sets.
Posted: Tue Jul 08, 2025 10:42 pm
by Kangie
Hi,
The real issue here is the use of '-march' in CFLAGS in your chromium build. This whole "unbundle toolchain" is barely supported upstream, and for some reason libyuv (when built in chromium, it seems fine if built standalone...) does not strip '-march' when it is building units that have specific '-march' requirements (as in this case, where it's building a library that uses runtime detection to determine whether to enable a path containing these instructions).
In the short term Neddy's patch is probably fine, or an env which does not set '-march' options for Chromium until this is resolved.
I would subscribe to the bug for updates; I need to find time to do some more diagnosis and submit an upstream bug.
Posted: Wed Jul 09, 2025 7:09 pm
by NeddySeagoon
Kangie
-march or -mcpu makes Chromium break. I gave up setting -march on arm64 when the Pi3 was new as breakage was quite common. -mcpu was UK.
I use
Code: Select all
# Chromium at least, is broken with -march or -mcpu
# Unset it on a per package basis
# COMMON_FLAGS="-mcpu=cortex-a76+crc+crypto -O2 -pipe -mtune=cortex-a76 -mbranch-protection=standard"
CFLAGS="-O2 -pipe -mtune=cortex-a76 -mbranch-protection=standard"
CXXFLAGS="-O2 -pipe -mtune=cortex-a76 -mbranch-protection=standard"
and
without the libyuv patch now.
I think
is a hangover from jumping the gun on the /23.0/ profile before the arm64 version was ready.
Posted: Fri Sep 26, 2025 2:10 am
by Kangie
Revisiting this: you're correct.
There are several components within chromium that build CPU-optimised units and then use runtime detection to select a codepath. Unfortunately the Chromium build system always puts custom
_after_ any unit-specific compiler flags (which is normally desirable), but in this case is causing issues.
Some, like
have handy toggles that we
could wire up to
and disable features we don't want to compile. Unfortunately others (like
don't have any toggles and I really don't think upstream care enough about it. I also note that somehow this works on amd64 (because the "floor" is higher?), but would fail exactly the same way there.
I'm honestly leaning towards filtering out
on aarch64 at this point. It's the best solution in terms of user-experience, and as we've been able to identify here Upstream are already optimising taking advantage of CPU instructions / features in areas like media decoding (automatically) where it makes sense to do so.