MangoHud: A Vulkan and OpenGL Overlay for FPS, Temperatures and CPU/GPU Load

What MangoHud draws over a running game

MangoHud is a Vulkan and OpenGL overlay for monitoring FPS, temperatures, CPU/GPU load and more, according to its README. The overlay renders inside the game's own frame rather than in a separate window, so the numbers appear on top of the scene without a second application competing for the display. The README's example asset shows a standard performance readout with frametimes, which is the shape most users see first: a compact block of text in a corner of the screen.

The intended audience is Linux users who want to know how a game is performing while they are playing it. That includes people tuning graphics settings, people comparing a game across drivers or Proton versions, and people who simply want to confirm that a frame rate cap or vsync setting is doing what they expected. Because the overlay is per-application, it does not require a background daemon to be running while you play, and it does not collect data unless you ask it to log.

The project is written in C and licensed under MIT. It is not archived, and the last push to the default branch was on 2026-09-16.

How MangoHud hooks Vulkan and OpenGL without patching the game

The mechanism is a library that the game loads at startup. In normal usage the README describes launching a program through the mangohud wrapper, which sets up the environment so the overlay library is injected into the process. The game continues to call its normal Vulkan or OpenGL entry points; MangoHud intercepts enough of them to know when a frame begins and ends, and draws its own content into that frame.

That design explains several things a reader will notice. First, the overlay is per-process, so a game launched without the wrapper gets no overlay at all. Second, because interception happens at the graphics API level, the set of metrics available depends on the GPU vendor and driver rather than on MangoHud alone; the README carries a metrics-support table by GPU vendor and driver for exactly this reason. Third, the build has separate switches for the pieces that talk to hardware and to the desktop: the meson options include with_nvml for NVIDIA GPU metrics on Wayland and with_xnvctrl for NVIDIA metrics on older GPUs, with_x11 and with_wayland for keybinds, and with_dbus for the media features.

Configuration is read from environment variables. The README names MANGOHUD_CONFIG, MANGOHUD_CONFIGFILE and MANGOHUD_PRESETSFILE as the three that control the HUD, so a per-game setting can be supplied on the command line or through a file without editing anything global.

Installing MangoHud from a package or from source

The fastest path on a supported distribution is the packaged build. On Debian 11 (Bullseye) or later, Ubuntu 21.10 (Impish) or later, and distributions derived from them, the README gives a single apt command. Debian additionally offers a 32-bit package; the README states that the 32-bit package is not available on Ubuntu.

sudo apt install mangohud

After installation, run a game through the wrapper. The README's normal usage section is the reference for the wrapper's name and its arguments; the pattern is that the wrapper takes the command you would have run and runs it with the overlay loaded.

Arch-based distributions have mangohud and lib32-mangohud in the extra and multilib repositories, with mangohud-git and lib32-mangohud-git on the AUR. The README notes that the git packages can help when the HUD does not activate with stable releases from pacman, which is worth remembering before filing a bug. Fedora, Solus, openSUSE and Flatpak are also listed as pre-packaged options.

If no package fits, building from source starts with a recursive clone, because the repository has submodules.

git clone --recurse-submodules https://github.com/flightlessmango/MangoHud.git
cd MangoHud

Then meson and ninja install it, defaulting to /usr/local. The repository also contains a build.sh script that can install dependencies on Ubuntu-based, Arch-based, Fedora-based and openSUSE-based systems, and that installs into ./build/release.

meson build
ninja -C build install

./build.sh build
./build.sh install

The README also documents an uninstall path through the same script, and a clean target that removes the build folder. For a 32-bit build on a 64-bit distribution, the README shows setting CC and CXX to the -m32 variants and pointing PKG_CONFIG_PATH at the 32-bit pkgconfig directories, with a libdir appropriate to the distribution (lib32 on Arch, lib/i386-linux-gnu on Debian-based systems).

FPS logging, mangoplot and the limits of the overlay

An overlay that only displays numbers is hard to compare across sessions, so MangoHud can log frames. The README describes two destinations for that data: upload to FlightlessMango.com for online visualization, or render it locally with mangoplot. The mangoplot option is on by default in the meson build, which tells you the project treats local analysis as part of the normal install rather than an extra.

The first real limitation is metric availability. MangoHud can only show what the driver exposes, and the README's metrics-support-by-vendor-and-driver table is the authoritative list. On an NVIDIA GPU, the build options with_nvml and with_xnvctrl gate those metrics, and the README notes with_xnvctrl is needed on older GPUs. A user who builds with -Dwith_xnvctrl=disabled, or who runs on a driver that exposes nothing, will get frame timing and not much else.

The second limitation is scope. MangoHud measures the frame as the application presents it. It does not attribute time to individual draw calls, shader compilations or driver internals, so it cannot answer why a frame is slow, only that it is. For that question you need a GPU profiler, not an overlay.

The third is platform. The README's installation sections cover Arch, Debian, Ubuntu, Fedora, Solus, openSUSE and Flatpak, all Linux. There is no Windows installation path in the README, and the build files that mention mingw are not accompanied by a documented Windows workflow.

MangoHud compared with the Steam overlay and with GPU vendor tools

The nearest everyday alternative is the Steam in-game overlay's performance display, which shows a frame rate counter inside Steam's own rendering path. The difference in approach is where the measurement comes from. Steam's counter is tied to Steam, so it appears for games launched through Steam and not for a game started from a terminal, a standalone launcher, or a native OpenGL application outside Steam. MangoHud sits at the graphics API level, so any Vulkan or OpenGL process launched through its wrapper can be measured, including non-Steam games and emulators.

The second alternative is a GPU vendor tool or a general system monitor, which reports clocks, temperatures and utilization for the whole machine. Those tools are better when the question is about the system rather than about one game, and they keep working when no game is running. They are worse at correlating a number with a specific frame, because they sample on their own schedule instead of per frame. MangoHud's frametime output is per frame by construction.

Neither comparison is a clear win. If you only play Steam games and only want a frame counter, the Steam overlay is already there and requires no install. MangoHud earns its place when you want frametimes, when you want the same overlay across Steam, Heroic, Prism and standalone binaries, or when you want to log a session and plot it afterward with mangoplot.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-09-16, five days before the publication date of this article, so the project is being changed on an ongoing basis. Recent releases are v0.8.4 on 2026-05-27, v0.8.3 on 2026-04-24, and v0.8.3-rc2 on 2026-04-21, which shows a release cadence measured in weeks to a couple of months rather than years.

The upgrade cost depends on how you installed it. A distribution package moves with the distribution, and the README explicitly mentions that the AUR git packages can resolve cases where the HUD does not activate with stable releases, which implies that at least some users track git to stay ahead of that class of problem. A source build is manual: re-run meson and ninja after pulling, and if a build that previously worked starts failing, the README's suggested first step is the clean target, which removes the build directory and clears subprojects. Because the project uses submodules, a plain git pull without --recurse-submodules can leave you building against stale dependencies.

The licence is MIT. In practical terms that is a permissive licence that allows use, modification and redistribution with the licence text preserved, but the repository's LICENSE file is the actual terms and this article is not legal advice. One licence-adjacent detail worth noting for packagers: the build depends on yaml-cpp, libcap, sd-bus and other system libraries, so a redistributed binary inherits whatever those licences require.

Editorial conclusion

MangoHud fits Linux users who want an in-game readout of FPS, frametimes, temperatures and CPU/GPU load without launching a separate monitoring application, and it is a reasonable default on Arch, Debian, Ubuntu, Fedora and Flatpak where packages exist. It is the wrong tool if you are gaming on Windows, if you need a profiler that attributes time to individual draw calls, or if you want a long-running system monitor rather than a per-game overlay. Before adopting it, verify that your distribution ships a package for your architecture, that the 32-bit variant exists if you run 32-bit games, and which metrics your GPU vendor and driver actually expose, because the README's metrics table is the only reliable answer to that last question.

Frequently asked questions

Official sources

1. flightlessmango/MangoHud on GitHub
2. License: MIT
3. Project website
4. README
5. Releases