L1T Hello!
So i’ve been kinda annoyed at mangohud for quite a while! As it’s a fork of the Vulkan overlay with supposed FEATURES far so far so faaaaaaaar beyond the measly mesa version. Which is flat out just wrong.
Tired and knowing that mesa’s Gallium_hud has already been done far better, way way back. I decided to add them BOTH. To test them, side by side. Mangohud basically looks amazing, the problem would be that it’s supposed to have all, if not even MORE features than the mesa version. As it’s actually maintained and improved upon…
Now i’m just an enthusiast. Don’t come here swinging at me, i’m just saying when people fork something they better at least SOME if not ALL of the already known, used and documented features. Environment Variables — The Mesa 3D Graphics Library latest documentation
The side-by-side test i made. Is with mangohud, configured almost fully, with known modern config (goverlay, config) vs flat out gallium_hud variables. The amount of left out parameters, metrics and what-not of mangohud is mind-boggingly annoying to someone who’d like too see more than simple numbers of fps, wattage and the likes of it.
There is a lot lot lot LOT more going on and NO Not only devs are allowed to see pixels rendered and so forth. Some if not most MAY be more interesting to devs. But that’s besides the point. On linux we want to see what’s going on and a cheap knockoff like mangohud, isn’t going to do the trick for me personally by removing important variables.
NOTE: I’m not a dev as such! The settings could still be there somewhere or other stuff i have no idea about! Feel free to correct me if i’m wrong 
But hey if someone feels the time was wasted then i’m sorry! At least the graphs looked cool right? 
Test will be added after upscaling processing is done server-side by yt.
3 Likes
I think this tool is really cool for checking out the details of what is going on in your game. I don’t really understand it, but I can see how much space there is for me to learn stuff about gaming graphics.
You do you!
Just as an alternative perspective, also a linux gamer, I’d rather NOT be bogged down with even these simple things. I’m just trying to play the game.
If I experience performance issues, these basic details are enough for me to determine there’s no thermal throttling.
If I want to upgrade hardware because thermals aren’t the issue, these basic details are enough for me to determine a CPU or GPU or storage upgrade for the games I actually play.
Basically, a nice GUI is a more important feature to me than this other stuff. Using the tool that has a checkbox to integrate with Steam / Lutris makes it an easy choice.
1 Like
Can’t say i understand every single gallium_hud variable / setting. Although there are many i know what mean, alone from a former benchmarking perspective. As do many other people.
I don’t dislike mangohud as such, i mean it has what could be considered the utmost-necessary. But as it is a fork, it should still allow more settings to be visible. In the gui aswell, that’s what gui’s are for.
Gui’s are not meant to be restrictive, just because it has a prettier ui. That’s probably also one of the reasons people stick to terminal only. It makes very much sense, but why can’t we just have both? It’s not like that much extra work, because it’s already there.
1 Like
Update >
New mangohud & gallium_hud config.
Mangohud config updated several times as to fit a 4k+ use-case and some other settings. Gallium_hud config now probably works on any display, as i’ve only used the x-axis as in the documentation. Can upload both configs, if anyone else wishes to use them…
Added about 15+ more settings to gallium_hud to display more info, also upscaled the gallium-ui, fixed refresh parameters. It now updates in a 0.5 sec instead of every 1-2 sec (can be changed) and it now has almost every single parameter documented in the gallium-help pages. Although running on the default pipe (can be changed)
Worth noting: Again i’m not a dev, i may know some settings and such. But not every single gallium setting, therefore the config is not set as a potential dev may would. Tried to make it, as less shitty as possible by chaining some of the parameters together, so that they are not 20 lines apart etc.
A 20min 4K side-by-side test with gallium_hud and mangohud will be added to this thread later at some point.
The gallium_hud variables can be configured to such an extent that it display immense data of what’s going on behind-the-hood and to have seen and followed that data even for a short while, is astonishing to say the least.
It displays a lot of the millions if not more data flowing through the gpu, rendering, shadowing, pixels rendered etc etc, the list goes on and on. One thing is to be immersed in a 3D experience, to the point of losing ones senses or whatever, another things is to have all that data displayed on the monitor and then some more. Because it’s not even ONLY displaying data rendered! Lost rendering, lost samples, sample sizes and the list freaking still continues! 
Update
Test video has been processed and is now available to watch without distortion
Another update
Now included both gallium_hud & mangohud side-by-side but this time scaled so gallium_hud’s own cpu, fps and gpu load values works. Both mangohud & gallium_hud configs will be uploaded at some point at a later time. If and when it’s fine tuned properly, followed by some easy-to-use documentation.
Further fine tuning config on gallium_hud and can be used as single string of commands in the launcher or in terminal. It’s now a 1406 characters long command 
With or without mangohud included. Looks like this in 4k side-by-side
small changes / updates
Replacing SSR with RS, as main x.org grabber. As jpeg-turbo is way way more effective at higher resolutions, less so with 3d acceleration but even with that OBS and the like of programs on linux, is no-where near as effective overall in general. When and if jpeg-turbo using programs gets tweaked enough, surely will lay the entire blob that obs is to dirt. Including every other program relying on the same method of recording. Obs-blob is basically just a gui for ffmpeg anyway, and blah blah In Linus Torvalds voice: Obs-Studio F** Y**!.*
OBS-like programs and obs itself does also not display frames aswell without proprietary blobbed versions using qcksync or hevc and et cetera…
TL;DR jpeg-turbo codec records frames at about 30 frames which is fine, as it USES less than a quarter of the cpu-power required for an equivalent like obs and other screen-grabbers, including at super high resolutions over 3860p where it’s not even possible to record anything with obs as bu-hu u need 247 cpu cores.
Here comes the best part, if u ask devs meuhhh u need 3645 cores cpu to record! blah blah. No u dont, RS can record whatever resolution u want with cores u don’t even own, using the same explanation. Of course this is justa rant, all credits to devs of jpeg-turbo, gallium_hud, mangohud, replay-sorcery.
Here’s what a 3084p looks like with High settings, recorded with ReplaySorcery.
Also Jpeg-turbo uses /tmp for temporary recording and release, amazing stuff when mixed together with an ssd, or even better nvme speeds. As it actually utilizes the hardware. Yeah it uses the memory for that, which is just amazing. As the encoder is used when all images are already recorded. Mathematical beauty in that for sure. As it also makes use of much lower-end hardware and puts it up there to compete with every other screen grabber. (Including proprietary ones, very much so)
Ob-blob does 0 of that and points to your cpu cores lol.
Point being, why smash your computer through frames frame-by-frame the much harder way, when it can simply be stored and processed when it’s done? Anyway it’s not the only open source project thats amazing, it’s definetly one of them though.
Can’t leave out, gallium_hud though, so here is one with RS,MHUD & GHUD combined 
And another one with 6K 150%+ amped / scaled to deliver above 9K.
Clearly, the gpu is hardware-locked to certain resolutions which is super annoying, getting only 20-30% gpu accelerated utilization on some titles above resolutions that surpass 2160p
Double or even tripple the amount of allowed gpu rendering performance in such a case to get an actual theoretical estimate of actual performance (non-hardware-locked performance)
Small update, Regarding ReplaySorcery…
It dishes out frames in about 30fps and it gets even better when paired with an ssd or nvme, too add to that, a pci-nvme could also be used to leverage even better frame-capture and thereby recording, very likely also to lessen lost numbers of frames and thereby providing a better end result of ReplaySorcery.
So ssd , ssd-nvme, pci-nvme and even a ramdisc could be used… Using a ramdisk either software or hardware based could break possible speed barriers or requirements as ReplaySorcery only uses it for storage anyway and processes those frames much later with the cpu.
