Chromium Build Discussion

[RobRich999]

Discussion regarding Chromium builds and related topics.

[RobRich999]

@Alex313031 Windows AVX is thankfully one of the easiest edits to set SIMD level. In the WIndows build config:

//chromium/src/build/config/win/BUILD.gn

Simply search for -msse3 and replace with -mavx. Clang will propagate the -mavx flag to lld for LTO, so do not worry about an ldflag for AVX. Default SIMD levels aside, the default x86-64 instruction model in LLVM is actually Intel Sandy Bridge, which already includes modelling for AVX instructions when using -mavx.

If you are cross building under Linux for Windows, you need to do the same in the compiler config as well, just like if you were natively doing a Linux build. The reason is libc++ pulls its build config from there.

//chromium/src/build/config/compiler/BUILD.gn

Make sure you disable AVX in the tflite config. It will not build successfully with AVX and above.

//chromium/src/third_party/tflite/BUILD.gn

Add the following cflags to the tflite config for a x86-64 build:

"-march=x86-64",
"-msse3",
"-mno-avx",
"-mno-avx2",
"-mno-fma",

---

I have updated the Widevine args. Windows builds just pushed. The Bitmovin demo works.

https://bitmovin.com/demos/drm

Awaiting a reroll of Linux builds after a Polly config update. Sadly nothing new there, which is one of the reasons I tend to tell people trying Polly to use a very basic Polly config to start.

---

I have a new Ryzen 8C/16T notebook on order. I would not be surprised if it turns out (much) faster for building Chromium than my two old 32-core Opteron systems.

[Rusenche]

Hello

1. Why do not you target your efforts to build full portable versions (all files to be stored only in the current directory)?!

2. Why do not you focus your attention and efforts to build sufficiently protected chromium as a Ungoogled?!

I tried Win-32 folder in the archive you've uploaded to the repository here. It turned out to be x64. I started chromium version 97 and the account folder is created in "\AppData\Local" - which for me is totally unacceptable.

[RobRich999]

My personal interest is optimizing Chromium performance. I do not care much about portable releases, and I have no personal interest in ungoogled patches. Long story short, ya'll get the same builds I use. ;)

---

Straight copy-and-paste from chrome://version in the current Win32 zip archive:

https://github.com/RobRich999/Chromium_Clang/releases/download/v97.0.4670.0-r931446-win32-sse3/chrome.zip

Chromium 97.0.4670.0 (Official Build) (32-bit)
Revision b112428b14eb9a6a78dcf880b2c17236ecaad8a4-refs/heads/main@{#931446}

That said, you might have snagged the Win32 build that was up for awhile yesterday, and it might have been packaged or pushed incorrectly. Happens occasionally. Anyway, it was already well outdated when pushed, so I went ahead and simply removed it to be sure.

---

Jerry (woolyss) has a server-side script to generate portable releases (using crlauncher) of submitted builds. You might look into that if interested:

https://chromium.woolyss.com/

[Rusenche]

Exactly from his site I came with a link to your repository. ;)

In my opinion, the browser should not be as fast as secure, so I think there is a need to fight for the privacy of browsers, not speed. Without a doubt, the developers of Chrome make them cumbersome enough, taking up a lot of memory and so on.

Confidential browsers remain on the fingers of one hand.

And from this point of view - I have no interest in any speed optimizations, as long as the browser is not permeable to telemetry.. In other words, if it's not a Marmaduke - end with Ungoogled. How and why - because not everyone has the knowledge to compile to do it themselves for each new version.

Lastly, I use Chrlauncher, but there is simply no collision of Chromium privacy developments. Only Marmaduke is relied upon, he at least quickly compiled and published them for download, while Elostone stopped publishing new versions of Windows.

Because I'm looking for a sure, protective browser as the Ungoogled is for now. If your developments for new versions were what I'm looking for ... but alas - they are not. ;)

It is a pity that the trend is such - to regress for consumers and withdrawing them to confidentiality, withdrawing freedoms.

[Alex313031]

Thanks as always!! Also how does one contact Jerry. I made a comment but I don't think he will see or do anything. Things are incorrect. Carl's (who makes Bromite) builds for android need to show that they have all codecs, and marmaduke needs to be reverted from all codecs+ to all codecs, because H.265 hasn't worked for a while now. He was only using build flags, which make the browser REPORT mime handling of HEVC, but won't actually play it, as he has not actually modified the proper header files like Nik used to do. However, doing this on my end failed on linux, I'm not sure if it is windows specific. I'm also going to notify Marmaduke. Also, I'm starting to build often enough that I would like to see if he would consider posting my builds for linux.

Also I cannot for the life of me get cross building to work!! I would really like that so I don't have to boot into windows.
I have compiled on win 7 (yes you can despite them saying you cant by changing some OS version checking stuff and copying some files from a win 10 VS install), 10, and 11, and following the instructions at https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/win_cross.md, however after packaging the nonredistributable stuff using 'python package_from_installed.py 2019 -w 10.0.xxxx.xx' it always fails after copying over to linux machine and running 'export DEPOT_TOOLS_WIN_TOOLCHAIN_BASE_URL=<path/to/sdk/zip/file>
export GYP_MSVS_HASH_=' This happens after me trying on all those windows versions, using the newest as well as trying older sdk versions, and this happens on ubunutu bionic and debian buster. So how are YOU cross building successfully.

How are you making your zips. I have been opting to manually copy everything to /home/alex/bin, and running my own build artifact cleanup script, and making my own .desktop file in ~/.local/share/applications, but would like it to auto make it into a zip.

Lastly, where did you find info on downloading the PGO profile, the setup and mini_installer targets, i.e. how does one list all the available targets for ninja/autoninja. These are notably absent from chromium documentation. Also I attached my script and .desktop file (modeled after debian's) for shits and giggles if you or anyone else finds it useful. I also included a .desktop file to run the content shell if you compile blink_tests, as well as a folder (for content shell) and single .svg (for chromium) to copy to /usr/share/icons/hicolor/scalable for both desktop files.
chromium-dev.zip

[RobRich999]

Jerry's email address: https://info.woolyss.com/
Jerry's github: https://github.com/woolyss

---

On Windows with VS2019, WinSDK 19041, and Python3 installed to default directories. Go to:

/depot_tools/win_toolchain

And run:

python3 package_from_installed.py 2019 --noarm -w 10.0.19041.0

Your choice on ARM support. I do not have it installed in my WinSDK config, as I do not target Windows builds for aarch64.

WinSDK 10.0.22000.0 might work as well. I know the script can package a toolchain from testing earlier this week, but I have not actually tried cross building with 10.0.22000.0, yet.

The script will assemble and spit out of the needed SDK files in a zip archive. For example:

476813973f.zip

Copy that to somewhere on your Linux box. I have mine in /home/robrich/vs2019.

So the first part would be redirecting the Windows toolchain URL to a local directory:

export DEPOT_TOOLS_WIN_TOOLCHAIN_BASE_URL="/home/robrich/vs2019"

Next is overriding the default toolchain hash by setting the hash for the generated archive file.

export GYP_MSVS_HASH_3bda71a11e=476813973f

Having to find and override the hardcoded hash is kind of annoying, but it does not change often. It is currently 3bda71a11e and can be found in the //chromium/build/vs_toolchain.py script file.

Make sure you have target_os = ['android', 'win'] in your //chromium/.gclient config.

Now when you export those values, running gclient sync should pickup the toolchain change.

Alternatively, you can manually do the same from the //chromium/src directory if desired:

python build/vs_toolchain.py update --force

Add target_os = "win" to your builds.args and proceed as usual with your build process.

---

There are various ways about obtaining PGO data. I just manually run the PGO script to fetch it.

python tools/update_pgo_profiles.py --target=linux update --gs-url-base=chromium-optimization-profiles/pgo_profiles
python tools/update_pgo_profiles.py --target=win64 update --gs-url-base=chromium-optimization-profiles/pgo_profiles
python tools/update_pgo_profiles.py --target=win32 update --gs-url-base=chromium-optimization-profiles/pgo_profiles
python tools/update_pgo_profiles.py --target=mac update --gs-url-base=chromium-optimization-profiles/pgo_profiles

There is no 32-bit PGO data for Linux builds. There might be a 32-bit x86 Linux AFDO sample profile generated by the ChromiumOS project, but I have not looked lately. AFAIK, I have never even done a Chromium 32-bit Linux build.

---

There are various installer and packaging scripts under the //chromium/src/chrome/installer/ directory.

You might have to skim the scripts to get ideas. For example, here is how to do a deb package when building:

ninja -C out/release "chrome/installer/linux:unstable_deb"

You probably would want to clean up the Google Chrome stuff if doing a deb package. Remove the lines below remove_udev_symlinks in the following files:

//chromium/src/chrome/installer/linux/debian/postinst
//chromium/src/chrome/installer/linux/debian/postrm

---

You can extract Chromium from the deb if desired. For example, something like this:

ar x chromium-browser-unstable_97.0.4670.0-1_amd64.deb

The data.tar.xz archive has the files you want; already in their recommended directory layout.

BTW, in theory, you might be able to even use alien to convert the deb package to various other package formats. Never tried it here, though.

---

For a list of what ninja targets, try:

gn args out/release --list > targets.txt

The large list of targets are piped to the text file, though I am not sure installer targets are listed. Been awhile.

[Alex313031]

Thank you. I know about the different pgo datasets, but where did you find your information, like where is it in the documentation.
I already use gn args out/release --list but that only lists available gn arguments, not all the possible targets.
And I was asking how you make your .zips for linux and windows, like how do you get rid of all the other build artifacts so the zip only has what it needs to run and isn't 4+Gb.
I have tried alien on an ubuntu chromium package and it works well.

On cross building, that is EXACTLY what I've been doing and it still fails, but havent tried 'python build/vs_toolchain.py update --force' so I'll try that. If it still fails ill post the error output here.
Also thanks for making a discussion, tis noice broski.

[Paukan777]

Answering to #23

You said -avx encodes both AVX and SSE3 in VEX, but I found that -avx2 does same thing. Dump screenshot attached (built with -avx2 -march=skylake). As you see, vmovups used instead of movups while using 128- and 256-bit registers close enough to each other. And so on. I guess clang is smart enough to encode instructions to minimize penalties.

There's another dump snippet of same binary, instructions are not VEX encoded. But there's no mixing with ymm registers so there will be no penalty. Compiler decided to use "old-style" encoding.

So, don't underestimate compiler, I think there's a reason to use benchmarks to decide if avx2 builds are better.

[RobRich999]

You are overthinking it. Naturally -mavx2 would do the same thing. Why wouldn't it? It includes AVX. Just as if you set -mavx512, and you get AVX and AVX2 as well. All of them enable VEX encoding.

The second screenshot does not include mixing of XMM and YMM instructions, which is what we are discussing here. Throw some AVX code in there, then see what potentially happens. Now think about Chromium. Several components have CPU dispatch, which can cause mixed encodings, as LLVM is building part of the code at -msss3 and the dispatched code at -mavx, -mavx2, etc. LLVM is not going to optimize the -msse3 code for VEX encoding using the default x86-64 processor target.

If you want an AVX2 build of Chromium, do it. ;) Going a little further back, I used to target Haswell and tune for Skylake. I did not want to pull in any instructions from Skylake or later, as I was pushing public builds for larger consumption, but I did want to target my primary Kaby Lake system with instruction tuning.

[RobRich999]

@Alex313031 The Windows zip archives are just reformats and recompresses of the chrome.7z archive generated when building the mini_installer. ;) I started doing the zip archives to appease a few people that complained about installing 7z or similar to use the files.

The only thing I do on Linux is generated debs, which can be unarchived if desired. The ungoogled project apparently generates a portable Linux config, but I have not bothered really looking into their process.

---

BTW, make sure you are building without any debug symbols. I do not think symbols are pulled into chrome.7z anyway, but it has been a long time since bothering with them, so just covering the bases here.

[RobRich999]

Before I forget, about documentation, AFAIK it simply does not exist for some features. I have picked up lots of build processes over the years through crbug.com reports. git changes, looking at project buildbots, skimming the source, etc.

[Alex313031]

@RobRich999 Oh lawd this is half of what I've had to do to learn about building chromium, you'd think PGO and build targets would be documented. Only chrome, chromedriver, blink_tests, and content_shell are well documented. And about the windows archives ah that makes sense, does the installer or build process use its own p7zip or lzma/lib7zip, and yeah duh you don't make linux archives. If you ever do make linux zips check out my cleanup script as I mentioned, it's only meant for linux anyway. For making a portable I have a bash script called cr and a .desktop file and all it really does is this > '--user-data-dir=../.profile --no-default-browser-check --allow-outdated-plugins --disable-logging --disable-breakpad' I use this because I use debians chromium which is sadly I think going to remain stuck on M90 for buster, but mostly use mine, and I want them to run independently of each other with my own builds not touching the system outside of its dir, this is all that is needed on linux to make a portable install.

So is there anything else on build targets, bc idk how you're getting a list of those from gn args out/Default --list.
Also another three flags I would recommend is this. pffft was introduced in M93 but would fail with avx for a long time but as of M97 it works and is better and faster than ffmpeg for webaudio, which is increasingly being used for WebRTC and video chatting.
To learn about what pffft is > https://github.com/marton78/pffft#:~:text=PFFFT%20is%20a%20fork%20of,few%20other%20signal%20processing%20functions
rtc_use_h264 = true
use_webaudio_ffmpeg = false
use_webaudio_pffft = true
First keeps h264 webrtc from bugging out with pffft if the content is H.264_main3.0 or higher, I.E. 1080p or higher., and the 2nd one is needed because unlike most flags which are smart about disabling incompatible ones it wont disable the ffmpeg one when pffft is set and errors during building without it explicitly disabled.

Also, are you using is_official_build, if not (and even if you are because there's not good documentation on what is_official_build actually changes, so I'm not sure if it sets these.) you can set these to further remove debugging stuff (reduction of about 40mb when I ran du -h in my out dir after running cleanup script.)
enable_debugallocation = false
enable_iterator_debugging = false
enable_resource_allowlist_generation = false

A last flags thing is that webui is increasingly being used in chromium and chromium os so this is worthwhile to set but in my testing increases build time by 10 mins (but again im on a FX-8370), probably not an issue for you. . If you wanna know more > https://chromium.googlesource.com/chromium/src/+/HEAD/docs/webui_explainer.md
optimize_webui = true

Did you try out my chromium-dev-editor, it doesn't matter if you didn't but if you did how did it run on win 10 avx. One known bug that I can't seem to figure out is that the menu items wont respond to clicks and you gotta use the arrow keys. I majority of it is programmed in dart and idk much about it. Most everything besides updating the icon, about section, and .crx manifest did just took a bajillion google searches and stackoverflow lol.

Lastly, since you shared your args.gn, I'll share mine, which attempt to make an "as much like google chrome in features and performance" build as possible. Some of the things in there wouldn't be there without your help so cudos.

google_api_key = ""
google_default_client_id = ""
google_default_client_secret = ""
is_official_build = true
is_debug = false
enable_debugallocation = false
enable_iterator_debugging = false
enable_resource_allowlist_generation = false
is_component_build = false
symbol_level = 0
enable_nacl = true
optimize_webui = true
use_lld = true
blink_symbol_level=0
enable_precompiled_headers = false
media_use_ffmpeg = true
media_use_libvpx = true
proprietary_codecs = true
ffmpeg_branding = "Chrome"
enable_ffmpeg_video_decoders = true
is_component_ffmpeg = true
use_webaudio_ffmpeg = false
use_webaudio_pffft = true
use_vaapi = true
use_vr_assets_component = true
enable_widevine = true
bundle_widevine_cdm = false
enable_media_drm_storage = true
enable_media_overlay = true
enable_hangout_services_extension = true
rtc_use_h264 = true
enable_vr = true
enable_platform_hevc = true
enable_platform_ac3_eac3_audio = true
enable_platform_dolby_vision = true
enable_platform_mpeg_h_audio = true
enable_mse_mpeg2ts_stream_parser = true
enable_platform_encrypted_hevc = true
use_thin_lto = true
thin_lto_enable_optimizations = true
chrome_pgo_phase = 2
pgo_data_path = "/home/alex/chromium/src/chrome/build/pgo_profiles/chrome-linux-main-1634428778-a43eab9dd5ad60bddb027ec878634f6b1e31bee3.profdata"

[Alex313031]

Oh shit I put my api keys!! how do I delete a comment???

[Alex313031]

Nvm figured it out, and I just edited it.

[RobRich999]

A step furhter, outright disable PDB creaetion by searching //chromium/src/build/config/compiler/BUILD.gn for config("no_symbols") and below set /DEBUG:NONE for Windows builds.

Just doing a very quick skim right now. ;) I will try to comment on the other inquiries later today or maybe tomorrow.

[Paukan777]

Several components have CPU dispatch, which can cause mixed encodings, as LLVM is building part of the code at -msss3 and the dispatched code at -mavx, -mavx2, etc. LLVM is not going to optimize the -msse3 code for VEX encoding using the default x86-64 processor target.

Then why not to build ALL the code with -mavx2 not only dispatched to globally avoid SSE3 code?

[RobRich999]

Because building globally with -mavx accomplishes the same in regards to SSE3 code. Plus code dispatch for AVX2, AVX512, etc. still is honored where present in whatever components.

The reality is we are talking a project where the bulk of the core code is actually scalar anyway. ;)

Also, as I have noted elsewhere, AVX2 was my most annoying build to maintain due to breakages. I was not building it natively, which made it all that more "fun"* when something inevitably broke. I might eventually return AVX2 builds. In the meantime, if someone else wants to maintain an AVX2 or whatever build, then I will try to answer build questions as possible.

*Hobbies are supposed to be interesting and fun IMO. When a hobby is no longer either, then it becomes time to reevaluate one's efforts. Admittedly, I have done Chromium builds for so many years now that I am pretty much burnt out on the project; and have been for quite a long time now. It is a big part of why my build intervals have declined in recent times.

[Paukan777]

Woow, just tried to build current version, gclient runhooks now requires python 3.10, and depot_tools still contains 3.8 ))

[Paukan777]

*Hobbies are supposed to be interesting and fun IMO. When a hobby is no longer either, then it becomes time to reevaluate one's efforts. Admittedly, I have done Chromium builds for so many years now that I am pretty much burnt out on the project; and have been for quite a long time now. It is a big part of why my build intervals have declined in recent times.

Maybe it's time to publish a complete howto with as much explainations as possible, so people like me and others will able to make their own "it works for me" builds. Maybe someone will then maintain them or will create own repo.

[Alex313031]

@RobRich999 I'm sorry to hear that mate. Also jerry fixed carls by adding all codecs and changes marmadukes from allcodecs+ to allcodecs at my request, and he has accepted my thorium builds for the linux subsection!! He also accepted my chromium os builds but I need to find a place to put them as I dont think github will allow the 6.8gb apiece disk image files.
Did you decide to use any of the flags I mentioned? And thanks for the PDB thing, I was already using the flag to disable but changing that completely removes it.
@Paukan777 I saw that, however I fixed it by completely clobbering chromium/src, depot_tools AND (this is important) .vpython-root and .vpython_cipd_cache which can be found in your home folder. After starting completely fresh chromium builds like normal and runhooks is fine. .vpython-root stores multiple python binaries that run independently of the system, and sometimes depot_tools doesn't like to runhooks if a newer python is needed because runhooks is needed to install the newer version, stupid I know.

[Alex313031]

Also @RobRich999 Whats your build system i.e cpu, ram, gpu. os, os version.

[Alex313031]

@Paukan777 I would be willing to publish an in depth how-to to my github if you want.

[Alex313031]

I am proud to announce the first actual release of Thorium, which will be put on chromium.woolyss.com right underneath yours @RobRich999 as soon as Jerry reads his email today.
https://github.com/Alex313031/Thorium
Release is in .deb format and is at 97.0.4674.0

Also uploaded is linux-chromeos, where it runs the whole system UI in an X11 window. Jerry said he might add that to the chromiumos subsection.
https://github.com/Alex313031/ChromeOS-Linux

Also uploaded is full ChromiumOS x86_64 builds with x264, module, and full linux firmware support. If someone here wants a tutorial on API keys to allow sign in on ChromiumOS OR to enable sync on chromium (or any other chromium based browser for that matter), I can provide them sparingly upon request.
https://github.com/Alex313031/ChromiumOS

[RobRich999]

@Alex313031 Congrats! :)

Windows 10 build box
2x Opteron 6378 (32 cores)
64GB ECC DDR3
Crucial 256GB SSD (os drive)
2x Micron 1TB SSDs (enterprise class)
Radeon RX460 graphics

Kubuntu build box
2x Opteron 6380 (32 cores)
64GB ECC DDR3
2TB Seagate SSHD hybrid drive
32GB Intel Optane SSD drive
Geforce 730 GT graphics

I just obtained a new Ryzen 5700u 8c/16t notebook. I might get around to setting up a dev environment on it.

[RobRich999]

@Alex313031 It does not hurt to set them, but several of your builds args already match their default settings, at least with is_official_build = true enabled. ;) A few examples:

rtc_use_h264 = true
use_webaudio_ffmpeg = false
use_webaudio_pffft = true
optimize_webui = true

I do use is_official_build = true for building. Primarily it turns off component and debug building. It also turns off ThinLTO optimizations (for now) due to binary bloat, but we turn the optimizations back on with the other ThinLTO build args anyway, so no concern there.

[d3-X-t3r]

Hi @RobRich999, would it be possible to get an AVX512 or znver4 build for Linux please?

[RobRich999]

Updated Linux builds and diffs.

Quick FYI. My current Linux diffs include the following Vulkan on Wayland patch.

https://chromium-review.googlesource.com/c/chromium/src/+/5568860/3/ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc

Vulkan and VAAPI are working (generally) okay with AMDGPU and RADV via Mesa 24.1.4 here.

chrome --use-angle=vulkan --enable-features=Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,VaapiVideoEncoder,UseMultiPlaneFormatForHardwareVideo,UseMultiPlaneFormatForSoftwareVideo --disable-gpu-memory-buffer-video-frames

It is not actually needed, but I am using --disable-gpu-memory-buffer-video-frames as a workaround for the GPU log being spammed with YUV_420_BIPLANAR messages during video playback. YMMV.

BTW and FWIW, while I target Debian and similar, I test and use my Linux builds mostly on CachyOS these days. The usual deb installer package can be unarchived (two levels deep including data.tar.xz) to whatever directory if desired.

---

@d3-X-t3r I have added a Linux AVX512 build for now. YMMV, as I do not have an AVX512 system for testing at the moment.

https://github.com/RobRich999/Chromium_Clang/releases/tag/v129.0.6614.0-r1331996-linux64-deb-avx512

---

@ms178 Thanks for the testing. Could be revision related, but anyway, I am going back to mixed O2/O3. Linux builds tonight. Windows builds might be tomorrow.

---

@Andarwinux Thanks for the testing.

[RobRich999]

Followup. Removed my comment about possible YT and similar streaming media issues. It was related to a pipewire graph from earlier that I still had loaded in the background. Exiting qpwgraph resolved the issue.

[RobRich999]

Time to start cleaning up marches, instructions etc. Previously I as looking to set more like fine-grained absolutely baselines for AVX/AVX2 support, but some LLVM tuning was updated awhile back and seems okay for our purposes now.

Chromium devs have determined SIMDs levels are not cumulative, but they are not setting -march=. We are setting various -march= configs, so we can skip all the extra SIMD and instruction options for those unless needed for extras.

On Windows we use /arch: where possible without conflicts, and that sets corresponding -march= as well. When not setting either of those we will have to continue passing the SIMD and instruction options along with -mtune= to replicate whatever x86-64-v version level we are targeting.

I already started cleanup of the Linux diffs, including migrating to x86-64v version levels, though I still need to purge the extra SIMD and instruction options as applicable. No real difference since -march= supersedes, so I probably will wait to my next round of Linux builds for further updates there.

I am cleaning up Windows diffs right now. Taking the above in consideration, the Win build configs for AVX/AVX2 still need the -mtune= and/or options set due to command-line configuration conflicts in sub-projects.

---

Windows AVX2 and diff updated. More to follow.

---

I have decided to pretty much target x86-64-v(2/3/4) levels with corresponding instructions and tuning.

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td

Accordingly, I made a slight instruction support tweak for the WinAVX2 diff. I am going to redo that build as well just to cover my bases.

---

Windows AVX512 build and diff updated.

https://github.com/RobRich999/Chromium_Clang/releases/tag/v129.0.6617.0-r1332867-win64-avx512

---

Windows AVX2 build updated; again. ;)

---

Windows AVX build and diff updated.

[RobRich999]

,After some instability reports at woolyss.com, I am pulling back instructions for Windows AVX/AVX2 builds back to previous known working configs for now. I am taking the cautious approach until further evaluation.

If it is instruction related, the following were the added overlaps with WinAVX and WinAVX2 builds.

"-mcx16", "-mcrc32", "-mpopcnt",

x86-64-v2 and higher supports those, but Chromium does not natively build with them enabled across the codebase, so any related issues are likely unknown at this time.

Also note software H265 is not patched for this round of Windows builds. There have been some changes. I poked at a couple of more obvious changes but perhaps not enough, as it is not proceeding past the first frame when streaming.

[ms178]

I just want to share an observation, with the Windows AVX2 build, I've noticed that the installation of my plugins (ublock Origin Lite; enhanced-h264ify and I dont care about cookies) are to blame for around 20% performance loss in speedometer v3 vs the build without these plugins installed.

[RobRich999]

@ms178 That is pretty common for Chromium plugins.

I disable extensions for my local benchmark testing.

---

Previous Linux AVX512 builds are not pulling in 512-bit instructions. I can run the current public build on my AVX2 system. ;)

I was tweaking the LTO config to hopefully pass -march=x86-64-v4 for the core browser binaries, but it appears the CFLAGS are not being propagated for whatever reason(s).

Accordingly, I will have to discontinue Linux AVX512 for now.

[Andarwinux]

Maybe consider using a sh wrapper to pass CFLAGS, which is a common hack I use when cross-compile.

[RobRich999]

@Andarwinux Chromium has a somewhat complex compiler build configuration.

https://chromium.googlesource.com/chromium/src/+/main/build/config/compiler/BUILD.gn

Plus there are more config files for PGO, Windows, etc.

Chromium with LTO optimization builds according to two configs. I was passing different -march= depending upon the specific target. The regular thinlto_optimize_default, which includes various binaries run during building, was set for x86-64-v3. The thinlto_optimize_max comprises the core browser binaries, which are not run (unless testing is enabled), thus I was passing x86-64-v4 there. That is not viable with the existing parsing of CFLAGs.

I might can add some conditionals elsewhere, but the far easier (for my sanity) solution is to simply build on a x86-64-v4 system. I do not have one at the moment. Most of my builds are done on an AVX2-class 4x Intel Xeon E7-8890 v4 (96c/192t) server. ;)

https://www.intel.com/content/www/us/en/products/sku/93790/intel-xeon-processor-e78890-v4-60m-cache-2-20-ghz/specifications.html

I could build Linux AVX512 in a compatible cloud instance, but that is more aggravation.... and money.

---

Windows AVX512 is possible via cross-compile from Linux because optimizations can be set specifically for the Windows binaries. :)

https://chromium.googlesource.com/chromium/src/+/main/build/config/win/BUILD.gn

[d3-X-t3r]

@RobRich999 Do you have a PKGBUILD that I could use to build the AVX512 version on my (znver4) box? I'm on CachyOS as well.

[RobRich999]

@d3-X-t3r My build box runs Ubuntu Server. I just extract the build deb archive (a couple of layers deep) to run the Chromium binaries from an arbitrary directory on CachyOS. ;)

I only run CachyOS on my daily notebook. Most other Linux systems here are either Kubuntu or MintOS.

For now you would have to setup a Chromium build environment, apply patches, tweak a couple of -march= statements in the build config, then build the browser. It is not exactly a fun process to start from nothing to end up with a working build.

I might be able to toss together a PKGBUILD script at some point, but admittedly, it is not very high on my priority list right now.

[boyedarat]

@RobRich999 can we have a Win64 AVX512 build?
Thanks!

[hrzhu]

Playing Bilibili video, like this one crashes the tab on latest Linux build(129.0.6652). It happens to every videos on Bilibili. It works fine on Windows build and old Linux build(128.0.6580). Can anyone confirm the issue?

[RobRich999]

@boyedarat Getting around to Windows build updates tonight. Hopefully in an hour or few; or perhaps tomorrow.

@hrzhu Confirmed. Possibly just a revision issue. I need to roll Linux v130 builds anyway. Might be a day or two.

---

General FYI. If hitting a ffmpeg build error related to pointers, try rolling back ../third_party/ffmpeg before (or maybe just revert) this revision:

https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/ae639da286e6b99393d03f87baa6badbdc63730a

The changes were pulled for H.264 but not HEVC. I just did a rollback to the parent revision for now instead of (yet) analyzing a diff to hopefully generate a patch.

[RobRich999]

@hrzhu Rolled Linux v130 locally. Still happening at default settings using AV1, though forcing H.264 seems to be okay. Hmmm.

Before I go on a wild goose chase here, I suggest filing a Chromium project bug report to see if anyone else is encountering the issue in general.

https://issues.chromium.org/issues

[RobRich999]

Linux builds updated.

[gz83]

@hrzhu Rolled Linux v130 locally. Still happening at default settings using AV1, though forcing H.264 seems to be okay. Hmmm.

Before I go on a wild goose chase here, I suggest filing a Chromium project bug report to see if anyone else is encountering the issue in general.

https://issues.chromium.org/issues

Hi robrich, I compiled version 130 with your patch, and I had the same problem as hrzhu, but when I reverted the changes to the two BUILD.gn files and recompiled, the crash no longer occurred.

So I suspect the crash is related to some parameters in BUILD.gn.

@Alex313031

[RobRich999]

@gz83 Thanks for the followup. The prominent suspect would be "-fstrict-vtable-pointers" IMO. I was trying to potentially improve devirtualization, but I have had some issues with -fstrict-vtable-pointers in the past.

I will try to get around to updated Linux builds in the next day or few.

[RobRich999]

BTW, while I am here, a copy-and-paste of a recent post of mine in the woolyss comments.

Ad-block extension? What needed extension?

https://www.youtube.com/watch?v=wLcdN-ElF4s

Mostly just playing here. It is not 100% filtering by any stretch, but as for now, it is a whopping two lines of browser source code modifications to get working. Hmmm.

[gz83]

@gz83 Thanks for the followup. The prominent suspect would be "-fstrict-vtable-pointers" IMO. I was trying to potentially improve devirtualization, but I have had some issues with -fstrict-vtable-pointers in the past.

I will try to get around to updated Linux builds in the next day or few.

After testing, this parameter is indeed the culprit

@RobRich999

[RobRich999]

@gz83 Excellent. I am rolling Linux builds at the moment, too.

[RobRich999]

Encountered a somewhat flaky Linux AVX2 build during basic testing. Fun.

I suspect perhaps extra instructions pulled in with x86-64-v3 versus me manually defining a subset of SIMD and other instructions.

I will try to revisit the situation tomorrow or over the weekend.

[boyedarat]

@boyedarat Getting around to Windows build updates tonight. Hopefully in an hour or few; or perhaps tomorrow.

@hrzhu Confirmed. Possibly just a revision issue. I need to roll Linux v130 builds anyway. Might be a day or two.

General FYI. If hitting a ffmpeg build error related to pointers, try rolling back ../third_party/ffmpeg before (or maybe just revert) this revision:

https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/ae639da286e6b99393d03f87baa6badbdc63730a

The changes were pulled for H.264 but not HEVC. I just did a rollback to the parent revision for now instead of (yet) analyzing a diff to hopefully generate a patch.

Thanks a lot @RobRich999 . Working great so far.
Appreciate all the hard work you put into this for us folks!

[RobRich999]

The ffmpeg HVEC pointer issues have been resolved in the Chromium third-party repo.

---

I am doing Linux builds right now. AVX2 is already pushed.

Optimizations in the Linux diffs have been cleaned up. I am dropping the machine function splitter for now, so we can drop lots basic block options, go back to the default configuration for stripping binaries, and reduce binary sizes.

---

@hrzhu The linked AV1 video now plays. :)

[boyedarat]

Hi @RobRich999, can we have updated builds for Win64 AVX512?
Thanks a bunch!

[RobRich999]

@boyedarat Builds updated, including Win64 AVX512.

[lilacluster611]

My dream is you make AVX512 win64 build with patches from ungoogled chromium.
I'm using generic ungoogled chromium build, I wish I could use one with your optimizations.

[Andarwinux]

AVX512 ungoogled chromium would be cool, but that means no more live at HEAD.

As an alternative, you might consider the ungoogled chromium built with PGO+LTO by macchrome.

[RobRich999]

Apologies on the extended build cycle delay here. Tropical weather systems among other things, plus I had to sort out a network issue with my build server.

I am pushing Linux build updates right now, I will try to get Windows builds done later today.

Note H265 software decoding is not enabled due to various changes in ffmpeg. I poked at it for awhile, but I ended up moving on to getting builds done. H265 hardware decoding is working okay in my quick testing of the feature.

Also YMMV on VAAPI hardware encoding assuming that is even a concern for anyone. It is not being detected on my primary Linux notebook at the moment, regardless of the usual source edit and even the CLI options tried (so far).

[RobRich999]

Various Windows builds updated. Same issue regarding H265 software support. H265 hardware should be okay, but it is not testable for Windows under VM on my Linux notebook, so YMMV.