Strange NVIDIA Application Profiles
devnull May 20, 2018
For anyone who doesn't know, these are the defaults their driver uses when it detects certain software. Some how we accept this now whereas in the past it would be considered cheating especially in benchmarks (3dmark and NVIDIA.. google it). But that is for another time...

Looking through what little source of their drivers is released you'll find their defaults. Because including it in nvidia-settings is apparently too obvious(?).. Which brings me to the point of this, I expected settings for games and some software, but was quite surprised to see entries for window managers, gnome-shell, etc. Quite bizzare is the rules they are applying _disable_ GSYNC [1].

Is there something I'm missing here? I have hardware that does GSYNC yet their own profile settings force it off. From what I gather of older threads this was to address perceived interactivity especially with the mouse... That's great but it also affects things I use every day. Webbrowser, terminal, etc
Simple test shows 60Hz for example

The HUD on my monitors confirm a higher refresh (165Hz) which is kinda pointless if applications aren't utilizing it.

There used to be a weird quirk/hack in mate where you could enable a benchmark mode within either mate or xfce. It threw up an fps counter of its own but more importantly ran the WM uncapped. For the life of me I can't find it any more though.

[1] - NVIDIA-Linux-x86_64-396.24/nvidia-application-profiles-396.24-rc
nox May 20, 2018
You are wondering why they disable gsync outside of games?
To my knowledge it absolutely isn't designed for normal non-gaming use at all.
devnull May 20, 2018
I am and why not? :) Open to suggestions for dealing with tearing while still getting better then 60fps.
Xpander May 20, 2018
forcecompositionpipline deals with tearing. it introduces small bit of input lag though.
if you have high refresh monitor like i do (144hz one), you don't actually need anything against tearing, its barely noticable anyway at that high refresh rate. Check your DE/WM compositor, it might be just forcing it to 60hz. I have MATE desktop and my desktop is nicely 144hz, i can confirm that with moving my mouse to my other monitor which is 60hz, the difference is night and day :)
devnull May 20, 2018
Bah. Had a longer reply, got logged out. Poof.

Problem is although I'm pushing 165hz, some applications aren't coming anywhere near that. Doesn't appear related to frame render time either which is rather annoying.
devnull May 23, 2018
Update: Played with this quite a bit, X and or the nvidia drivers are quite picky about what order GL calls are issued in. There's certainly something that stinks at least wrt vsync. May be yet another thing related to clock speed and power save *shrug*. Short version is GL_Flush and GL_Finish can perform very badly. Not really surprised I guess considering the documentation I could find online was really inconsistent.

Testing now with kwin. No, not full KDE. Difference is quite remarkable. Though it appears Chormium and Google Capatch do not play well (weird image corruption).
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.