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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
I'd prefer developers improving Mesa HUD instead of forking and then not upstreaming things.
Logging capabilities were taken straight from the Mesa HUD for the reference. It had it all along.
And Mesa HUD (i.e. Vulkan overlay) works for all Vulkan drivers as well, including Nvidia.
Last edited by Shmerl on 4 February 2020 at 11:23 pm UTC
Logging capabilities were taken straight from the Mesa HUD for the reference. It had it all along.
And Mesa HUD (i.e. Vulkan overlay) works for all Vulkan drivers as well, including Nvidia.
Last edited by Shmerl on 4 February 2020 at 11:23 pm UTC
5 Likes, Who?
I'd prefer developers improving Mesa HUD instead of forking and then not upstreaming things.
I believe this is FlightlessMango's HUD? He modified DXVK_HUD and added stuff to it originally, but I believe the stuff he added wasn't of interest to the upstream project. I agree with you, its better to see this work go upstream but sometimes this work is rejected for whatever reason.
3 Likes, Who?
I'd prefer developers improving Mesa HUD instead of forking and then not upstreaming things.A HUD like this not being tied to drivers is a good thing. Faster updates for starters, easier to install across any distro and so on. Many reasons why as a standalone project it can be a big benefit.
Logging capabilities were taken straight from the Mesa HUD for the reference. It had it all along.
And Mesa HUD (i.e. Vulkan overlay) works for all Vulkan drivers as well, including Nvidia.
10 Likes, Who?
I don't see why it can't be developed at its own pace, and upstreamed at the same time, unless for some reason it can't be accepted back.
3 Likes, Who?
I don't see why it can't be developed at its own pace, and upstreamed at the same time, unless for some reason it can't be accepted back.nVidia users do not use Mesa, so bundling the utility with it would mean needless drag in the system.
0 Likes
I don't see why it can't be developed at its own pace, and upstreamed at the same time, unless for some reason it can't be accepted back.nVidia users do not use Mesa, so bundling the utility with it would mean needless drag in the system.
How much drag is there?
.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libVkLayer_MESA_overlay.so
/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
/usr/share
/usr/share/bug
/usr/share/bug/mesa-vulkan-drivers
/usr/share/bug/mesa-vulkan-drivers/control
/usr/share/bug/mesa-vulkan-drivers/script
/usr/share/doc
/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
/usr/share/lintian/overrides
/usr/share/lintian/overrides/mesa-vulkan-drivers
/usr/share/vulkan
/usr/share/vulkan/explicit_layer.d
/usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
/usr/share/vulkan/icd.d
/usr/share/vulkan/icd.d/intel_icd.x86_64.json
/usr/share/vulkan/icd.d/radeon_icd.x86_64.json
1 Likes, Who?
How 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.jsonThat 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. :)
1 Likes, Who?
That's a problem with Ubuntu, not with Mesa. No one is forcing you to use a distro with outdated graphics support. And if you are so inclined to use it instead of a distro which keeps such things up to date, you'll figure out how to work around such kind of issues.
Personally, I don't recommend Ubuntu for gaming.
Last edited by Shmerl on 5 February 2020 at 6:51 am UTC
Personally, I don't recommend Ubuntu for gaming.
Last edited by Shmerl on 5 February 2020 at 6:51 am UTC
5 Likes, Who?
I'd prefer developers improving Mesa HUD instead of forking and then not upstreaming things.
Logging capabilities were taken straight from the Mesa HUD for the reference. It had it all along.
And Mesa HUD (i.e. Vulkan overlay) works for all Vulkan drivers as well, including Nvidia.
At first I didn't make this project for the community, I made it to help myself with my benchmarking videos. However, now that more people are interested in it and find it useful for themselves it has become a community project. As such, upstreaming most changes would be pointless as they are geared towards ease of use in regards to gaming. Most changes are not in line with what Mesa is going for with their hud, for example displaying debugging/low level Vulkan information.
The Mesa overlay did have logging capabilities but were not really in line with how I wanted to use it (for example uploading/parsing on flightlessmango.com for benchmarks), so it has been rewritten, not simply copied and pasted.
12 Likes, Who?
Looks good. Now if it supported OpenGL also, we would have a tool that would work across all Linux Games.
0 Likes
How to run with a game in steam? Does not help:
MANGOHUD=1 %command%
Or is it necessary first? MANGOHUD_CONFIG
MANGOHUD=1 %command%
Or is it necessary first? MANGOHUD_CONFIG
0 Likes
How to run with a game in steam? Does not help:MANGOHUD=1 %command% worked fine for me if installed correctly.
MANGOHUD=1 %command%
Or is it necessary first? MANGOHUD_CONFIG
1 Likes, Who?
MANGOHUD=1 %command% worked fine for me if installed correctly.Still needed lib32-mangohud
But still does not work in some games. For example, in Doom 2016, it flickers in the menu, but in the game it is not visible at all.
Last edited by ikiruto on 5 February 2020 at 10:01 am UTC
0 Likes
Perkeleen_Vittupää Feb 5, 2020
It's the small details that often decide Linux adoption for surprisingly many! 
That being said, i wonder if there could be a snap package for MangoHud later on?
That being said, i wonder if there could be a snap package for MangoHud later on?
2 Likes, Who?
How 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.
1 Likes, Who?
Looks good. Now if it supported OpenGL also, we would have a tool that would work across all Linux Games.
Unlike Vulkan, OpenGL doesn't have layers concept, so it can't.
4 Likes, Who?
How 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. :)
Mesa 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
PPA 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
Restricting users to only get offcial packages would be more like "NIH"
1 Likes, Who?
Patreon
PayPal
See more from me