The State Of Vulkan Rendering In Chromium 84: Say Goodbye To All VRAM, RAM and Swap, Chromium Will Eat It All

From LinuxReviews
Jump to navigationJump to search

The Chromium web browser and other web browsers based on it got Vulkan rendering support late last year. The result of enabling it on GNU/Linux machines resulted in disaster when it became available in Chromium 79. It has gotten better five versions and half a year later but it is still very far from being perfect. You can enable it in recent Chromium versions and use it for normal web browsing but there are some big caveats you should be aware of and consider before you turn the Vulkan rendering switch on. Chromium can and will eat all your GPU RAM, all your system RAM and go after swap partitions for good measure if Vulkan is enabled.

written by 林慧 (Wai Lin) 2020-07-23 - last edited 2020-08-03. © CC BY

Chromium 84 running the Unity 2018 web browser benchmark on GNU/Linux with Vulkan enabled and a MangoHud overlay showing incriminating information about the computer.

The Vulkan graphics API is a multi-platform low-level API for computer graphics. It was recently described by mpv developer wm4 as:

"Vulkan sure is bad. I can't think of anything good about it, other than "is not GL". For some reason vulkan.h may even pull in xrandr headers"

wm4 in #mpv-devel July 22nd, 2020

Recent Chromium versions can take advantage of the Vulkan API and use it to do web page rendering if you manually tell it to do so. You can type chrome://flags into the address bar and search for Vulkan and select Enable if you want to try it. It works and it will no longer turn the web browser window into some kind of modern art if you resize it. You may find that you have no immediate issues using Chromium after you have turned Vulkan rendering on. It may appear to work just fine for some time. That initial calm is deceiving. You will eventually discover that there is a dark and sinister side to Chromium's Vulkan renderer..

On the sunny side, synthetic performance tests do indicate that Vulkan rendering translates to a nice, mostly initial, performance boost. It is not huge and it does not apply everything you may want to do in web browser and you may not notice it - but it's there. Vulkan rendering beats OpenGL rendering in all the benchmarks as long as you start with a fresh clean browser process when you run each benchmark.

Chromium Ate My GPU Memory, My System Memory And Went After Swap For Dessert

First, lets address the primary reason why you may want to stay ten feet or more away from Chromium's shiny Vulkan rendering support: Chromium can easily allocate and fill all available GPU memory, all available system RAM and all swap partitions and keep that memory locked until it is closed, killed or crashed. This can be demonstrated by starting Chromium and opening two web browser tabs - as long as one of them has a lot of graphical elements made in JavaScript. The other tab can be blank or any other site. Switching between tabs is enough to fill all available memory.

Keep an eye on the VRAM and RAM numbers:

Use the little square button in the lower right corner to make the video full-screen. You can increase the resolution from the low 360p default if you want to.

Our loyal readers have donated a whopping 0.155 LTC crypto currenty to LUydW49vBvUrcyLsGc1YfHW8v3jSqZKChq during the 16 years this website has existed. They have also donated a whopping 50 of those BAT tokens the Brave Web Browser gives users of that browser as rewards for viewing advertisements that are sent using the systems notification system (libnotify on GNU/Linux). The can be used to learn that a BAT is worth $0.264 (COINBASE-PRO:BAT-USDC) and a LTC is worth $43.77 (COINBASE-PRO:LTC-USD). 0.155*43.77+50*0.264 works out to about $20 in the SpeedCrunch calculator.

Opening a JavaScript-based graphical chart web page like COINBASE-PRO:BAT-USDC or COINBASE-PRO:LTC-USD and a blank tabs and switching between those tabs will increase the amount of GPU memory used each time the focus goes from one tab to another until all available GPU memory is used. Chromium will then move on to system memory and eventually fill that too. That is, of course, not enough for Chromium so Chromium will happily move on to filling any and all swap partitions once all the GPU and system memory have been filled with who knows what.

"manual memory management, the bane of OOP programmers

of course it takes some C++ shitmess to forget to call free()"

mpv developer Niklas Haas on Chromium and memory management
July 22nd, 2020

Lies And Deceit

Chromium 84 with Vulkan Ate My GPU Memory.jpg
Chromium's task manager says it is using 28 MiB GPU memory showing a blank window. radeontop showed 120 MiB before Chromium was started. After running the Basemark 3.0 benchmark in Chromium and closing that tab radeontop reveals that 1537 MiB GPU memory is actually still (ab)used by Chromium. There is a slight difference between 28 MiB and 1.5 GiB.

Chromium has a built-in task manager that can be opened by pressing ⇧ Shift+esc. This task manager can show how much GPU memory is used if you right-click the top bar with Task, Memory footprint and so on and you select GPU memory. That task manager will not show that Chromium has eaten all your graphics card memory and your system memory and some of your swap too when you have surfed the web for a while or ran a benchmark or have flipped back and forth and back and forth between two problematic tabs time and time again. radeontop, htop, top and similar tools tell you the truth about what is actually going on inside your computer.

Chromium is either blissfully unaware of how much memory it is eating when Vulkan rendering is enabled or outright lying in a desperate attempt to cover up just how extremely bad it really is.

The Good News: Vulkan Is Faster (In Theory)

Rendering with Vulkan is faster until you inevitably run out of GPU memory. That will make performance drop and it will fall like a rock when the machine starts swapping. However, there is an initial performance boost when you start with a fresh newly opened browser. This would translate to real-world performance benefits if Chromium didn't leak memory like crazy when Vulkan is enabled.

Chromium 84 on a Athlon II x3
Radeon HD 7850 2 GB GPU, 1080p
OpenGL Vulkan
Benchmark chrome://flags Score VRAM used(*) Score VRAM used(*)
Basemark 3.0

"Override software rendering list"

466.61 207M 497.4 1177M
Unity Web 2018 47683 199M 48044 500M
Basemark 3.0

"Override software rendering list"
"GPU rasterization"
"Out of process rasterization"

459 209M 514 1550M
Unity Web 2018 48662 240M 48961 544M
Chromium 84 on a Ryzen 2600
Radeon RX 470 8 GB, 1440p
OpenGL Vulkan
Benchmark chrome://flags Score VRAM used(*) Score VRAM used(*)
Basemark 3.0

"Override software rendering list"

1087.37 350M 1046 7664M
Unity Web 2018 104926 502M 108067 1140M
Basemark 3.0

"Override software rendering list"
"GPU rasterization"
"Out of process rasterization"

1036,95 386M 1172,3 6937M
Unity Web 2018 105532 503M 107324 1185M
(*) The VRAM used refers to the amount of graphics card memory held by Chromium after the benchmarks are finished and the tab used to run the benchmark has been closed.

The good news, if you can call it that, is that Chromium consistently performs better when the Vulkan renderer is enabled as along as you start with a fresh web browser window. It is not possible run the Basemark 3.0 benchmark three times in a row and get a result for comparision. The Basemark 3.0 benchmark figures for GPU memory held after the above benchmarks have finished should tell you why: Chromium has to fall back to eating system memory when it is holding on to 7664M graphics memory for no reason and it wants just as much or more in addition to what it already swallowed and it will eventually run out of that too. The result is that repeated tests of Basemark 3.0 fail because the Linux kernels out of memory reaper kills Chromium half-way through the test:

[511052.428906] Out of memory: Killed process 596206 (chromium-freewo) total-vm:5196084kB, anon-rss:199036kB, file-rss:0kB, shmem-rss:21456kB, UID:1000 pgtables:2148kB oom_score_adj:300
oom_reaper: reaped process 596206 (chromium-freewo), now anon-rss:0kB, file-rss:0kB, shmem-rss:21544kB

It is additionally interesting to note that the chrome://flags options "GPU rasterization" and "Out of process rasterization" have an impact on both performance and GPU memory use. Enabling these options will increase GPU memory usage and either decrease or increase actual performance depending on the machine.

Stay Clear (For Now)

Enabling Vulkan GPU rendering in Chromium on GNU/Linux is, as it stands today, a very bad idea. It will make Chromium eat any and all RAM, VRAM and swap sooner or later.

There could be a performance benefit down the line if the Chromium developers manage to plug all the insane memory leaks in the Vulkan rendering engine. We will check again and see if the situation has improved in 6 months. Perhaps it will be safe to enable Vulkan rendering in Chromium by Christmas. It could, of course, also be that this is simply how Vulkan is supposed to work.

"Isn't that how vulkan works? It allows applications to steal all your GPU memory because it was made for games, assuming exclusive access to all hardware resources"

wm4 in #mpv-devel July 22nd, 2020
(0 votes)



13 months ago
Score 0++

It seems your are very confused about what Vulkan, Mantle, Metal, OpenGL, DirectX 11 and DirectX 12 are. They are all graphic APIs. - Metal is Apple's proprietary graphic API, and the only one they support since they deprecated OpenGL on their platform. - OpenGL is a cross-platform graphic API supported by virtually all GPUs since at least 2005. It has several versions, and nowadays, a frequent requirement is OpenGL 3.0+. It is GPU vendor agnostic, like almost all graphic APIs - DirectX 8/9/10/11/12 are Microsoft proprietary APIs, with DirectX 12 having major changes in how the drivers handles the draw calls so that systems with several cores can make better use of the GPU (among other things). It is supported by AMD, Nvidia, Intel _at least_. - Vulkan, formerly known as Mantle, is a cross-platform API originally developped by AMD, but whose developpement was transfered to the Khronos Group (who is also responsible for OpenGL). It has the same advantages as DirectX 12, while also being cross-platform. It is supported by a broad range of GPU vendors, including AMD (since ~2010), Nvidia (since ~2012?), Intel since the Intel HD Graphics 4000.

I skipped some details to be concise, but that is a good summary of the graphics APIs available right now.

Anonymous (aa8fc88b20)

20 days ago
Score 0

- This is all on the Vulkan renderer in Chrome, not on Vulkan itself.

- wm4 is obviously salty about something, it would be best to refrain from quoting them. An API cannot, by itself, contribute in such a manner to the noted problems with Chrome.

In fact, Vulkan is a great API. Considerably better than OpenGL. Which is just an aging dinosaur of an API that is not up to dealing with modern hardware in any efficient manner. Now, DX12 would be an interesting alternative to Vulkan, since, like Vulkan, it is designed to scale better with modern hardware (increasing core count, to name but one thing). But, well... we're talking about Linux. So, either Vulkan or bust. OpenGL simply will NOT do. It HAS to be replaced. And, personally, I'd much rather see it be replaced by Vulkan than by some proprietary nonsense, wouldn't you?

So, yeah... blame the Chrome developers, who apparently are incompetent. Don't blame Vulkan. Because, without it, the Linux desktop experience will be dead by 2030, tops.
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.