The State Of Vulkan Rendering In Chromium 84: Say Goodbye To All VRAM, RAM and Swap, Chromium Will Eat It All
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"
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 and select 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 cryptowat.ch 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()"
July 22nd, 2020
Lies And Deceit
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 radeontop, htop, top and similar tools tell you the truth about what is actually going on inside your computer.
, and so on and you select . 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.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.
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" |
459 | 209M | 514 | 1550M | |
Unity Web 2018 | 48662 | 240M | 48961 | 544M | ||
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" |
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 [511052.441765] 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 and 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"
Enable comment auto-refresher
Aviallon
Anonymous (aa8fc88b20)
Permalink |