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_MSVSHASH=' 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 https://github.com/RobRich999/Chromium_Clang/issues/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.

[Alex313031]

Ooo, I didn't know that. How did you find out what exactly is_official_build does? I will still probably keep them in my args.gn anyway because I like to keep track of what I have explicitly set, because I sometimes turn off is_ofiicial_build and do a component build for quick testing. And the thinlto thing sucks, does this mean that google chrome is built without thinlto? Also, what about enable_debugallocation = false enable_iterator_debugging = false enable_resource_allowlist_generation = false Does it do anything to set these with is_official_build enabled?

[RobRich999]

Those three are set to false as well, at least as just checked against one of my recent is_official_build builds.

You can setup a default build with a blank args.gn and run "gn args out/default --list > args.txt" (change default to your build dir if needed) to get a list of default build args. You can do similar with an args.gn just setting is_official_build = true and running the same args list command on that build, then compare the differences.

---

Looking back a few posts, it appears I posted about gn args out/default --list regarding build targets. That is just args. To get targets, inside a build directory try running the "ninja -t targets all" command to get a list of what targets ninja can build.

For example:

ninja -t targets all | grep chrome/installer/linux: chrome/installer/linux:beta: phony chrome/installer/linux:beta_deb: phony chrome/installer/linux:beta_rpm: phony chrome/installer/linux:calculate_deb_dependencies: phony chrome/installer/linux:calculate_rpm_dependencies: phony chrome/installer/linux:common_packaging_files: phony chrome/installer/linux:deb_packaging_files: phony chrome/installer/linux:installer_deps: phony chrome/installer/linux:linux: phony chrome/installer/linux: phony chrome/installer/linux:merge_deb_dependencies: phony chrome/installer/linux:merge_rpm_dependencies: phony chrome/installer/linux:rpm_packaging_files: phony chrome/installer/linux:save_build_info: phony chrome/installer/linux:stable: phony chrome/installer/linux:stable_deb: phony chrome/installer/linux:stable_rpm: phony chrome/installer/linux:strip_chrome_binary: phony chrome/installer/linux:swiftshader_libs: phony chrome/installer/linux:theme_files: phony chrome/installer/linux:unstable: phony chrome/installer/linux:unstable_deb: phony chrome/installer/linux:unstable_rpm: phony/

---

Google Chrome is built with ThinLTO on various platforms, but AFAIK, currently the LTO codegen by default is set to -O0.

Even setting thin_lto_enable_optimizations = true only gets LTO codegen at -O2 for the primary binaries, like chrome.exe and chrome.dll on Windows. Project devs use the split LTO approach to save build time.

Take a look at the thinlto_optimize_default and thinlto_optimize_max headings in the compiler config:

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

I prefer running LTO optimizations on all applicable build targets. I suggest setting all lto_opt_level lines to at least 2; though I typically use 3 for my builds.

[Alex313031]

That's what I resorted to to compare the is_official_build, it's just like dang I'm not reading ALL of that lol. And thats what I've been doing to list ninja build targets, It's just that I'd like a list of the main ones and when running without grep it emits ~200 lines of targets.

And I've already been using everything you mentioned in compiler flags a while ago, i,e. lto_opt_level, import_instr_limit, cflags = [ "-O2" ], -mavx. I didn't know that thinlto could be set to anything higher than 2. What are the available numbers and what is the difference between them?? I guess until you respond I'll go ahead and use 3.

Also, I modified the linux installer to include ui_resources_100_percent.pak, shell_resources.pak, content_shell.pak, and content_shell. It's currently a seperate package in debian and ubuntu, but I find it useful for tests and can be used with chromedriver. If you want a looksie look in my Thorium repo.

Also, something you may want to do, I've gotten 97 working on distros as old as debian 9 and ubuntu 16.04 by using enable_distro_version_check = false and compiling chrome_sandbox. My usual build goes like 'autoninja -j8 -C out/thorium chrome chrome_sandbox chromedriver content_shell -d stats -d explain' The sandbox is needed for old distros, and the bypassing version check doesn't bypass dependency checks, but bypasses checking for the newer versions of them. This is because chrome will still run with older libnss and libc for example, it just doesn't like to.

Lastly, do you know if Jerry's busy or something because it's been over a week now and he hasn't emailed me back after saying lemme know when the builds are ready for the linux subsection.

[RobRich999]

Pipe the gn lists to two different files, then do a diff comparison. ;)

http://www.technicaloverload.com/compare-two-files-using-notepad/ https://winmerge.org/?lang=en https://wiki.archlinux.org/title/List_of_applications/Utilities#Comparison,_diff,_merge

I too enable_distro_version_check = false because I build with a later distro than officially supported. The project tends to favor LTS distros, while I prefer staying up to date with Ubuntu.... well. more like a modified Kubuntu, but anyway. ;)

Clang codegen and LTO codegen take similar opt levels. -O2 is considered generally more stable and with less binary bloat, but -O3 can be tried for both if desired. The issue is -O3 tends to ignore code bloat limitations when optimizing, but we have PGO profiles to guide optimizations, which can help cut some of the bloat. The result (with PGO) is a little larger binaries due to additional optimizations. YMMV on actual performance differences.

I tend to suggest -O2 across the board for those wanting the least amount of the frustration with broken builds, but -O3 for both Clang and LTO codegen has proven generally okay for building Chromium for quite awhile now (in my experience). That said, the performance difference tends to be trivial for most components, plus -O3 can take slightly longer to build.

Technically Clang codegen with take one "higher" level with -Ofast, but that is really just -O3 with various "unsafe" math optimizations applied. I suggest not bothering with it for Chromium, and in fact components like ffmpeg will complain if trying to build with it.

BTW, clang-cl used for Windows builds will not natively accept "/O3" since clang-cl maintains compatibility with MSVC cl.exe flags. You can workaround it by passing -O3 into the underlying clang driver instead. For example, replace:

cflags = [ "/O2" ] + common_optimize_on_cflags + [ "/Oi" ]

....with:

cflags = [ "-Xclang", "-O3", ] + common_optimize_on_cflags + [ "/Oi" ]

Jerry is sometimes away from the site due to work, vacation, etc. He was on vacation awhile back. Not sure right now.

[Alex313031]

OML why didn't I think of that. Duh. I already have a nice diff viewer so yeah I'll do that. Thanks for that info. Am currently compiling the latest thorium with lto set to 3 and cflags set to 2. EDIT: Completed!

Speaking of which, I've done a complete overhaul. I've included many patches from Ubuntu and Bromite, and modified the installer to include content_shell and needed .pak files, as well as patching it to not reject unstripped ELF's or RPATH binaries (i.e. for content_shell and to use is_component_ffmpeg = true to build libffmpeg.so) Chromium strings is also updated for windows, mac (future possible usage), and chromiumos. And the readme is much better. In particular, you might want to use the font rendering patch, which affects all linux distros. I didn't label which files map to which patches, but you'll just want to copy the contents of the v8 directory. I prefer not making branches, just directly patching files, and use the trunk.sh script I made to revert everything and update/sync to trunk, so the folder v8 can just be copied in place over //chromium/src/v8/ https://github.com/Alex313031/Thorium/tree/main/v8

EDIT: Octane 2.0 score of 29151 vs. 280102 for previous thorium build vs. 22531 on vanilla debian buster chromium 90.0.4430.212 & HTML5 score of 530 for both compared to debian chromium's 524.

[Paukan777]

Can anyone provide manual how to properly get source for chromium stable? Tried to checkout version 95.0.4638.54 using this manual https://stackoverflow.com/questions/47087970/how-to-checkout-and-build-specific-chromium-tag-branch-without-download-the-full/47093174#47093174 but after I as usually run "gn gen out/mybuild" there's no targets named "chrome/installer/linux:unstable_deb" or "chrome/installer/linux:stable_deb" (nothing related to linux installer at all) What I do wrong?

[Paukan777]

Upd: there's no "chrome/installer/linux:unstable_deb" target even after I completely reinstall depot_tools and sources. Looks like depot_tools is broken now?

Upd: solved by manually creating "out/mybuild" and placing args.gn in it before running "gn gen out/mybuild". Looks like enable_linux_installer is not set by default anymore.

P.S. build.py now builds extremely buggy clang 14.0 so I switched to manually installed 13.0 via clang_base_path

[Alex313031]

@Paukan777 When I build release builds, I follow https://www.chromium.org/developers/how-tos/get-the-code/working-with-release-branches, with minor caveats (explicitly running runhooks and undoing with git checkout -f origin/main rather than master). Namely

1. git rebase-update
2. gclient sync --with_branch_heads --with_tags
3. git fetch --tags
4. git show-ref --tags
5. Then picking the latest stable which can be found by going to https://chromium.woolyss.com/
6. Then making a branch with git checkout -b $yourbranchname tags/95.0.4638.69 (current stable release)
7. Then AGAIN run gclient sync --with_branch_heads --with_tags
8. Then explicitly run gclient runhooks
9. The build as normal and run the stable .deb ninja target. Also using autoninja rather than ninja is preferred.

I too searched how to build stable releases, but following others guides has led to problems, whereas following that official chromium doc has never caused me problems. To get back to trunk and delete your branch when your done building, I run

1. git branch -D $yourbranchname
2. git checkout -f origin/main
3. gclient sync --with_branch_heads --with_tags Thats it!

Also remember if you delete and recreate or update/downgrade depot_tools, to also delete the .vpython_cipd_cache/ .vpython-root/ in your home folder (assuming depot_tools is in $HOME), and then recreate these by running gclient runhooks again in your chromium checkout. And remember if you downgrade depot_tools which downloads clang, export DEPOT_TOOLS_UPDATE=0 to prevent auto-updating which is done anytime gclient sync is called.

[Paukan777]

@Alex313031 thanks very much!

I still have a question - how do you compare performance of different builds? I use https://chromium.github.io/octane/
Can I rely on its results or you know more accurate benchmarks? E.g. to measure combined js + rendering performance.

[RobRich999]

Octane 2.0 is fine for JavaScript benchmarking.

I tend to use Basemark Web 3.0 when doing a quick benchmark comparison test. It covers multiple aspects, though it leans a little heavy on WebGL benchmarking IMO.

https://web.basemark.com/

The BrowserBench.org benchmarks are used by various browser projects for routine performance testing.

https://browserbench.org/

[Alex313031]

@Paukan777 I say at the bottom of https://github.com/RobRich999/Chromium_Clang/issues/26#issuecomment-951987009 that I use Octane 2.0, same as what you just commented. And those other two that @RobRich999 mentioned are also fine benchmarking tools. @RobRich999 https://web.basemark.com/ IS WebGL heavy, which is why I specifically used it to test gpu performance after using the flags '--enable-native-gpu-memory-buffers --num-raster-threads=4 --gpu-rasterization-msaa-sample-count=8 --webgl-msaa-sample-count=8' to run the GPU Process as hard as possible. Using those flags, I got some really nice visuals at https://playcanv.as/e/p/44MRmJRU/ and https://akirodic.com/p/jellyfish/ and http://flower.302chanwoo.com/interactive/ (all three are really good examples of what WebGL can do and highly recommended to visit), however my GTX 970 was at 70-80% usage with VRAM as high as 600Mb on AfterTheFlood.

Also, to test HTML5 Standard adherence, you can test any browser at https://html5test.com/ In a note related to GPU stuff, WebGPU, the proposed successor to WebGL that fizzled out, is being brought back as WebGPU 2.0 and can be enabled in Chromium 93 and up by enabling chrome://flags/#enable-unsafe-webgpu

[Paukan777]

@Alex313031 I got crash on startup with --enable-native-gpu-memory-buffers using both my build and @RobRich999's one Tested on Intel HD 530 (i915) and Radeon 7900 (amdgpu) with latest mesa from kisak-mesa repo.

[Alex313031]

It used to be a chrome://flag flag, but was removed because it doesn't work in many cases. On my rig, it only works with the proprietary nvidia drivers, and on another machine, wont work on windows with an old AMD HD6450. It's really YMMV, but it doesn't make as large of a performance benefit as changing --num-raster-threads (values can be 1-4, and shouldn't be higher than the number of logical CPU cores on your system). Enabling those MSAA flags really depends on what your GPU is capable of.

[Alex313031]

@RobRich999 Do you know how to use the goma service. Im building my latest ChromiumOS, which has codecs, full linux firmware/module deployment, and added packages like iotop, sysstat, htop, and sl. Doing this though requires building chromium from source, along with the rest of the os and added packages, which is taking in excess of 300GB, and over 8 hours on my machine and I would really like some CPU help from googles servers because this is just ridiculous even for chromiumos. Also, do you have any interest in ChromiumOS, or just chromium, and if not, would you ever consider trying it out?

[char101]

Hi,

Is it possible to also build for 32 bit with avx/avx2 optimization? I had repeatedly tested and 32 bit vs 64 bit chrome and the 64 bit build always consume significantly more memory. Since chrome itself is already memory hungry, 32 bit build with avx/avx2 optimization could provide memory/perfomance balance for newer processors.

[Paukan777]

32-bit builds are usually slower, as modern compiles aimed to optimize 64-bit code while 32-bit support is a kind of abandonware, but if memory footprint is your main issue - you can try. Just change ALL occurences of -msse3 to -mavx in your //chromium/src/build/config/compiler/BUILD.gn and use target_cpu="x86" in args.gn

[Alex313031]

In my testing this fails, but that was a while ago, and I think it's a combination of 32 bit builds only being supported on x86 anymore, and the fact that there are no 32bit only processors with avx, so compilation flag propogation just doesn't go to all targets. However, if @Paukan777 managed to get it working, try it out. @char101 why are you trying to produce an AVX 32 bit build in the first place (note this is not me criticizing, just curious) Also, if you need any help or pointers, feel free to talk here, or talk to me at Alex313031@gmail.com, or talk to @RobRich999

[char101]

Thanks @Paukan777 and @Alex313031 for your comments.

Sorry I wasn't trying to compile chrome but was asking if @RobRich999 would add 32 bit avx to his builds, since 32 bit build has the benefit of smaller memory usage.

Since most processors nowadays are 64 bit, I think 32 bit with avx means 32 bit emulation but with access to avx instructions.

As for why 32 bit, if you are only opening 10s tabs it does not matter whether it is 32 bit or 64 bit chrome (in fact I would prefer using 64 bit chrome in that case), but if you are opening 100s of tabs then it makes a lot of difference in terms of memory usage.

[Paukan777]

@char101 opening 100 tabs is a bad idea. Use bookmarks instead ^) Modern chromium has a cool sidebar for bookmarks )

[char101]

Thanks for the suggestion but I know what I am doing.

Also speaking about the sidebar, I'm more interested if Google will allow addons to put content in it, that way we can have something like tree style tab in chrome. Although it is Google, we never know if they will someday kill that feature.

[Alex313031]

@char101 For reducing memory usage (I also regularly have 400+ tabs open spread across many windows), append --process-per-site as a cmdline flag.

Also, @RobRich999 and @Paukan777 I found two args.gn flags worth changing. I looked them up and chromium docs said they should be set the way they are below for official builds, yet by default even with is_official_build = true set they are not. I found them by doing a search about what official build does, and then comparing it my diff between arg lists that @RobRich999 proposed I do (which I did). Anyway, set >

dcheck_always_on = false exclude_unwind_tables = true

Unwind tables are really only useful for android debugging, and dcheck is turned off for most things with official build set to true, but not all, and adding the 1st flag ensures all dchecks are off.

[RobRich999]

@Alex313031 Goma will require you being an active project developer. It is a Google resource, particularly for employees, so a huge YMMV on ever obtaining access.

That is probably the top reason most of us independent builders are running our own build boxes. The only reason my old Opteron systems still suffice, at least marginally, are them having lots of cores available for parallel compilation and ThinLTO.

I have built Chromium on even quad-core systems, though it is not my idea of "fun." It was more tolerable with the Jumbo unity build process, but sadly that was dropped years ago due to ongoing code maintenance concerns.

https://chromium.googlesource.com/chromium/src.git/+/65.0.3283.0/docs/jumbo.md

@char101 Running 32-bit software on a 64-bit system affords no real benefit other maybe binary code size. An x86-64 proc likely is zero extending most 32-bit ops to full register space anyway, and if not, it could run into partial-register stalls. You might as well running the 64-bit code for performance.

Accordingly, I have no plans to offer a 32-bit AVX build at this time. I am considering dropping 32-bit builds in the near- to mid-term anyway, as I have no immediate use for them myself.

[char101]

@char101 For reducing memory usage (I also regularly have 400+ tabs open spread across many windows), append --process-per-site as a cmdline flag.

Thanks, I have used that flag before but it wasn't very stable. Maybe I'll check it again. Currently I use Auto Tab Discard but even with most of the tab in discarded state, chrome still consume a lot of memory and also have high idle CPU usage.

@char101 Running 32-bit software on a 64-bit system affords no real benefit other maybe binary code size.

It also matters on the runtime memory size. The logic is like this: rendering a website uses dynamic memory which is located in the heap, allocating memory in the heap use pointers, a pointer in 64 bit application is double of that in 32 bit application, chrome uses a lot of pointers.

[Paukan777]

I have (maybe a dumb) question about memory usage. Windows uses .dll for most of chromium code and small-sized .exe as "wrapper". So, a lot of chromium processes uses one shared copy of "bloatware".

In Linux there's a big, uh, freaking statically linked binary which is cloned in memory many times, wasting valuable RAM. Can I build Linux version like Windows one - a small executable and big .so for engine itself?

[Alex313031]

@char101 I use that flag on every release I do as well as Robs, and debians/ubuntus/arch's default chromium, with no problems at all.

@Paukan777 The way linux does it is actually more performant, although it does use slightly more memory. There is no easy way around this besides doing a component build, but that has horrible performance and takes up two times the disk space. Unless you wanna do some heavy source code modification, telling individual components whether they should be linked or not. You could do this with just libblink_common.so, libblink_controller.so, and libblink_core.so by themselves, which would mitigate some of this, but also make blink slower, which is the core rendering engine soooo.