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

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.

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.

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.

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.

I 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. :)

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

Hm, it seems that is true. So, at least Mesa is not completely stuck. This leaves the question about frequency of updates, however.

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

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.

Restricting 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).

A M A Z I N G

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. :)

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.

Hm, 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.

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.

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.

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

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

Here 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

windows 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.

Also 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).

Windows 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.

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).

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

Here 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

Nah. That's server-side infrastructure for creating/maintaining repositories. From user's perspective it is still enabled via ordinary "/etc/yum.repos.d/*.repo" config files.

Performance wise, NTFS is pretty damn fast under windows

Definitely not my experience, but for general desktop use / gaming I guess it's fine.

considering moving to EXT4 and just using a paragon license.

I've been hoping Phoronix would do some benchmarks (even asked once), but he never has.

AND NO I REFUSE to use BTRFS, its amazingly slow, as proven continuously with benchmarks and comparisons!

:D

Vote for inclusion in the repository:
https://aur.archlinux.org/packages/mangohud

I've been hoping Phoronix would do some benchmarks (even asked once), but he never has.

There are benchmarks comparing NTFS EXT4 BTRFS XFS on phoronix site. There may be some windows10 based benchmarks but I can't recall.

I just tried MANGOHUD with Grim Dawn on Steam. Works like a charm, looks much cleaner than DXVK_HUD. I like that you can toggle it on and off with F12, although minor annoyance I've had to change the screenshot binding in steam.
Nice work! =)

Here 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

Nah. That's server-side infrastructure for creating/maintaining repositories. From user's perspective it is still enabled via ordinary "/etc/yum.repos.d/*.repo" config files.

Same as PPAs are config files under /etc/apt/sources.list.d on Ubuntu, and a key added just like with Copr. Does it bother you that there are graphical and commandline frontends for it so that users do not have to know about the config files?

Reading through https://fedoraproject.org/wiki/Category:Copr and https://help.launchpad.net/Packaging/PPA?action=show&redirect=PPA it is really the same concept just implemented differently off course.

How to enable this with lutris for other non steam games ?

How to enable this with lutris for other non steam games ?

If you got it installed system wide, it should be as simple as adding the environment variable under system options tab as MANGOHUD   1

Have people actually used this or are people talking about how cool it is and then moving on?

It doesn't seem to work for me at all. I'm reluctant to open an issue on the GitHub repo because I'm curious if other people are having issues with it first.

The install instructions on the readme don't work and installing it via the release file doesn't appear to do anything.

Can folks confirm that it is working and maybe provide some screenshots?

Have people actually used this or are people talking about how cool it is and then moving on?

It doesn't seem to work for me at all. I'm reluctant to open an issue on the GitHub repo because I'm curious if other people are having issues with it first.

The install instructions on the readme don't work and installing it via the release file doesn't appear to do anything.

Can folks confirm that it is working and maybe provide some screenshots?

The article screenshot is literally me using it. Download, extract, cd into the folder, install, done. Then add it as a launch option for a Vulkan game or DXVK. Works great for me.