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.
JUST
LOVE
THIS !
Awesome work !!!!!
Quoting: flightlessmangoHow to run with a game in steam? Does not help:
MANGOHUD=1 %command%
Or is it necessary first? MANGOHUD_CONFIG
Quoting: ikirutoMANGOHUD=1 %command% worked fine for me if installed correctly.Quoting: flightlessmangoHow to run with a game in steam? Does not help:
MANGOHUD=1 %command%
Or is it necessary first? MANGOHUD_CONFIG
Quoting: Liam DaweMANGOHUD=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
Quoting: Alm888Quoting: 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: XpanderLooks 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.
Quoting: Alm888Quoting: 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. :)
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"
See more from me