Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

MangoHud, a new open source Vulkan overlay layer for gaming on Linux

By - | Views: 70,762

Today, the first official release of MangoHud went out, a new open source Vulkan overlay layer for gaming on Linux. This enables you to get a HUD on your games with fancy details like FPS and Frame Timings, GPU and CPU utilization, GPU and CPU temperature reporting and more.

Originally a fork of the Mesa drivers "with the overlay files modified to produce the hud", it's now an entirely new project separate from Mesa and it works across different GPUs including NVIDIA. Their intention is to be an alternative to the Mesa overlay and the DXVK HUD and they've certainly got my vote as it works great!

Pictured: MangoHud (top left) with Jupiter Hell on my Manjaro/NVIDIA system.

It also has logging capabilities, so it can be useful for some benchmarking too. Allowing you to start and stop the logging with the tap of a button to record things like FPS, CPU & GPU utilization. I can see all sorts of uses for a handy open source project like this.

What I also appreciate is how easy it is to use. Once installed, all you have to do is add this as a launch option for a game on Steam for example:

MANGOHUD=1 %command%

Impressive stuff, I was looking for something exactly like this not long ago and came up completely short. Will definitely be keeping an eye on this.

You can find MangoHud on GitHub.

Article taken from GamingOnLinux.com.
26 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
42 comments
Page: «3/5»
  Go to:

Redface Feb 5, 2020
Quoting: dvd
Quoting: Alm888
Quoting: ShmerlHow much drag is there?

/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
/usr/share/bug/mesa-vulkan-drivers
/usr/share/bug/mesa-vulkan-drivers/control
/usr/share/bug/mesa-vulkan-drivers/script
/usr/share/doc/mesa-vulkan-drivers
/usr/share/doc/mesa-vulkan-drivers/changelog.Debian.gz
/usr/share/doc/mesa-vulkan-drivers/copyright
/usr/share/lintian/overrides/mesa-vulkan-drivers
/usr/share/vulkan/icd.d/intel_icd.x86_64.json
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json


That is for starters. And then the package dependency hell kicks in and this all goes downhill. Fast.

Remember, before libGLVND we could not even have two OpenGL implementations installed at once, so installing Mesa was not an option.

IMO, the less dependencies a project has the better. And Mesa here is clearly redundant. Of course, I think it would be better if the original "Mesa Vulkan Overlay" project was untied from the Mesa in the first place.

Offtopic: There are lots of problems with Mesa. It being critical system component and thus "frozen in stone" in the Ubuntu LTS releases for two years for many people is the most prominent. And in order to not be stuck with hugely outdated software Ubuntu users resort to hacks like untested unstable repositories (due to NIH syndrome Canonical® calls them "PPA"s) thus throwing the whole idea of stable supported system out the window. :)

I may be mistaken, but i think binary blobs are not officially part of ubuntu, so the blame's on nvidia.
Quoting: dvd
Quoting: Alm888
Quoting: ShmerlHow much drag is there?

/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
/usr/share/bug/mesa-vulkan-drivers
/usr/share/bug/mesa-vulkan-drivers/control
/usr/share/bug/mesa-vulkan-drivers/script
/usr/share/doc/mesa-vulkan-drivers
/usr/share/doc/mesa-vulkan-drivers/changelog.Debian.gz
/usr/share/doc/mesa-vulkan-drivers/copyright
/usr/share/lintian/overrides/mesa-vulkan-drivers
/usr/share/vulkan/icd.d/intel_icd.x86_64.json
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json


That is for starters. And then the package dependency hell kicks in and this all goes downhill. Fast.

Remember, before libGLVND we could not even have two OpenGL implementations installed at once, so installing Mesa was not an option.

IMO, the less dependencies a project has the better. And Mesa here is clearly redundant. Of course, I think it would be better if the original "Mesa Vulkan Overlay" project was untied from the Mesa in the first place.

Offtopic: There are lots of problems with Mesa. It being critical system component and thus "frozen in stone" in the Ubuntu LTS releases for two years for many people is the most prominent. And in order to not be stuck with hugely outdated software Ubuntu users resort to hacks like untested unstable repositories (due to NIH syndrome Canonical® calls them "PPA"s) thus throwing the whole idea of stable supported system out the window. :)

I may be mistaken, but i think binary blobs are not officially part of ubuntu, so the blame's on nvidia.
That comment was about Mesa not nvidia. Ubuntu distributes nvidia drivers via their restricted archive, so it is an optin, but I would say it can be said to be an optional part of the distribution, they warn they can not properly support due to the closed source.

And just as for Mesa, just only since last summer, newer versions also coem as SRU now, just with a few months delay. 18.04 has 430 and 435 now with 440 just uploaded to proposed, so in normal updates in a few days.https://bugs.launchpad.net/ubuntu/bionic/+source/nvidia-graphics-drivers-340/+bug/1854485 It is not the new version released yesterday, but 440.44 which was released a while ago.
Redface Feb 5, 2020
If the Mesa overlay is independent of the graphics driver then it probably could be built as a stand-alone package for the various distributions, to not conflict but work with whatever Mesa or Nvidia driver are installed. I still think it is a good idea to have competition if they have different goals and ways to implement them.
Alm888 Feb 5, 2020
Quoting: dvdI may be mistaken, but i think binary blobs are not officially part of ubuntu, so the blame's on nvidia.
Nope. nVidia updates its drivers frequently enough.
The fact that Canonical thinks it is OK to not provide adequate drivers to 60% of the userbase has nothing to do with nVidia. Besides, there is always "Linux Mint", fixing this little issue. :)
Quoting: RedfaceMesa is not "frozen in stone" for the current LTS release, it gets SRU (Stable Release Updates, see https://wiki.ubuntu.com/StableReleaseUpdates) 18.04 and 19.10 have now Mesa 19.2.8 released in December 2019 https://packages.ubuntu.com/source/bionic-updates/mesa and https://changelogs.ubuntu.com/changelogs/pool/main/m/mesa/mesa_19.2.8-0ubuntu0~18.04.1/changelog
Hm, it seems that is true. So, at least Mesa is not completely stuck. This leaves the question about frequency of updates, however.
Quoting: RedfacePPA is short for Personal Package Archive https://en.wikipedia.org/wiki/Ubuntu#Package_Archives
What is NIH about having a mechanism to "Using a Personal Package Archive (PPA), you can distribute software and updates directly to Ubuntu users. Create your source package, upload it and Launchpad will build binaries and then host them in your own apt repository. " from https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA
Oh, excuse me. Maybe I've used the wrong term. "Unnecessary Multiplication of Instances" would be more fitting. Here at Fedora we do not call 3rd-party repositories like "RPM Fusion" some fancy names (and I believe, SUSE branch don't do it either). Even "Debian GNU/Linux" doesn't do that! So "PPA" is strictly Ubuntu-specific.
Quoting: RedfaceRestricting users to only get offcial packages would be more like "NIH"
Now, that would be dumb, won't it? After all, if someone wants to install a 3rd-party application, she/he can just manually force-insert it into the system by simply copying the files into system directories and creating symlinks. Or by compiling from "tarballs". Preventing this will require complete stripping any administrative rights from users. I doubt many distros do it (maybe some government/army custom built super-secured ones do this, however).
BrazilianGamer Feb 5, 2020
A M A Z I N G
Redface Feb 5, 2020
Quoting: Alm888Nope. nVidia updates its drivers frequently enough.
The fact that Canonical thinks it is OK to not provide adequate drivers to 60% of the userbase has nothing to do with nVidia. Besides, there is always "Linux Mint", fixing this little issue. :)
Mint does get its nvidia drivers straight from Ubuntu, from a Mint VM I have:
[ apt policy nvidia-driver-435
nvidia-driver-435:
  Installed: (none)
  Candidate: 435.21-0ubuntu0.18.04.2
  Version table:
     435.21-0ubuntu0.18.04.2 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages

Ubuntu, and thus also mint has currently ,besides some legacy drivers like 390 and older, 430 and 435, and 440 is in proposed now coming into normal updates in a couple of days if the testing goes ok.

So most users do not need a PPA for nvidia drivers, unless they have a very recent GPU or want some new features straight away.

Quoting: Alm888Hm, it seems that is true. So, at least Mesa is not completely stuck. This leaves the question about frequency of updates, however.
Check the changelog I provided.

Quoting: Alm888Here at Fedora we do not call 3rd-party repositories like "RPM Fusion" some fancy names (and I believe, SUSE branch don't do it either). Even "Debian GNU/Linux" doesn't do that! So "PPA" is strictly Ubuntu-specific.
So PPA is a fancy name and RPM Fusion is not
Yes PPA is a Ubuntu and derivates specific term, which also was mentioned in the wiki page I linked.
TheRiddick Feb 6, 2020
Allot of the MESA updates are sort of unstable and in beta phase. It makes good progress but at the same time is dragged behind by terrible display backends like X.org or even the forever slow to process Wayland. (in saying that the windows AMD driver is in somewhat bad shape, they need to make it open-source and just unify with Linux driver!)

Anyone who regularly flips between Linux and Windows will fully understand the serious limitations of Linux desktop back-ends and drivers.
I was using Arch Plasma5 setup last week for a good 6months, back on windows10 (had to reinstall the stupid thing due to broken MS update) and its quite clear how far ahead windows still is for a general gamer ease of use.

I'm only using windows10 for testing and some Bethesda gaming, both of which I can get running under Linux but with no freesync (via gsync, due to flickers), and a 30% performance hit which is a KILLER at 4k.
Also there is a significant disk access penalty but that COULD be related to using NTFS under Linux (I have it configured the best I can). But I suspect the disk access performance issue is also related to WINE(via proton) somewhat.

Hate me all you want, I HATE Microsoft and Windows, but can't deny the fact they have gaming Desktop with ALL the bells and whistles down packed damn well. (minus their terrible semi-forced update system and how it sometimes can brick your install.....lol)


Last edited by TheRiddick on 6 February 2020 at 12:11 am UTC
Shmerl Feb 6, 2020
I wouldn't say Windows packs gaming desktop well. It's just good at hiding problems, until they hit you. And when they do, Windows users are more lost than Linux ones.


Last edited by Shmerl on 6 February 2020 at 5:10 am UTC
Phlebiac Feb 6, 2020
Quoting: Alm888Here at Fedora we do not call 3rd-party repositories like "RPM Fusion" some fancy names

Well, we do have "Cool Other Package Repo"
https://fedoraproject.org/wiki/Category:Copr
Phlebiac Feb 6, 2020
Quoting: TheRiddickwindows AMD driver is in somewhat bad shape

Just got a new Windows box at work; the damn AMD drivers do a hard reset whenever I use Flash (unfortunately, there are some websites that still require it, even though the browsers are doing everything they can to make it hard to use it). The boss had issues with webcam software, so he changed his for an Nvidia card - I might be next, if I can't find a stable driver version.

Quoting: TheRiddickAlso there is a significant disk access penalty but that COULD be related to using NTFS under Linux

Bad move, NTFS is total garbage compared to every Linux-native file system. Just look at any of the I/O benchmarks on Phoronix (Windows native vs Linux native).
TheRiddick Feb 6, 2020
Quoting: ShmerlWindows users are more lost than Linux ones.

I think that would be in rather niche situations however. Linux has the advantage of lots of open source drivers and hack in patches yourself, unless your stuck with nvidia drivers, pretty much a dictatorship there.

Quoting: PhlebiacBad move, NTFS is total garbage compared to every Linux-native file system. Just look at any of the I/O benchmarks on Phoronix (Windows native vs Linux native).

Performance wise, NTFS is pretty damn fast under windows, its just under Linux where its still pretty terrible (but functions). You might get 1/6th the performance with NTFS under Linux vs Windows.

I use it for cross-platform testing, but am considering moving to EXT4 and just using a paragon license. AND NO I REFUSE to use BTRFS, its amazingly slow, as proven continuously with benchmarks and comparisons! Until someone can FIX btrfs to not be slow pos fs, I aren't using it!


Last edited by TheRiddick on 6 February 2020 at 7:05 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.