{"id":16154843,"url":"https://github.com/ventureoo/nvidia-tweaks","last_synced_at":"2025-04-05T17:03:41.668Z","repository":{"id":46264087,"uuid":"446479474","full_name":"ventureoo/nvidia-tweaks","owner":"ventureoo","description":"A collection of tweaks and improvements to the proprietary NVIDIA driver (Linux)","archived":false,"fork":false,"pushed_at":"2025-01-31T12:21:29.000Z","size":90,"stargazers_count":125,"open_issues_count":1,"forks_count":8,"subscribers_count":8,"default_branch":"main","last_synced_at":"2025-03-29T16:03:28.570Z","etag":null,"topics":["driver","linux","nvidia"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ventureoo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-01-10T15:32:35.000Z","updated_at":"2025-03-28T15:48:19.000Z","dependencies_parsed_at":"2024-01-19T14:41:46.701Z","dependency_job_id":"9aead6ed-0323-43a5-83c5-df8352290982","html_url":"https://github.com/ventureoo/nvidia-tweaks","commit_stats":{"total_commits":56,"total_committers":4,"mean_commits":14.0,"dds":0.5357142857142857,"last_synced_commit":"3a054fbad32f7b6d85ab73aac0ae8c3b5bd0ca52"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ventureoo%2Fnvidia-tweaks","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ventureoo%2Fnvidia-tweaks/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ventureoo%2Fnvidia-tweaks/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ventureoo%2Fnvidia-tweaks/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ventureoo","download_url":"https://codeload.github.com/ventureoo/nvidia-tweaks/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247369953,"owners_count":20927928,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["driver","linux","nvidia"],"created_at":"2024-10-10T01:19:03.222Z","updated_at":"2025-04-05T17:03:41.634Z","avatar_url":"https://github.com/ventureoo.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# nvidia-tweaks\n\n## Description\n\nnvidia-tweaks is a set of tweaks and workarounds for the Linux version of the\nclosed NVIDIA driver. It will allow you to fix some problems related to the\ndriver and can potentially improve performance (Read about the driver module\noptions).\n\nIn other words, this project doesn't contain anything you can't do yourself,\nbut just simplifies the process and stores a lot of information.\n\n## Installation\n\nFirst of all, you must have the NVIDIA driver itself installed and loaded in\norder for this tweak kit to work. Without it, no further action is meaningful.\n\nAnd yes, **please ONLY install the NVIDIA driver using the package manager of\nyour distribution!** Installing it manually from the official NVIDIA website\nmay make it more difficult to maintain and impossible to update.\n\nSpecific instructions on how to install the driver can be found here:\n\nhttps://github.com/lutris/docs/blob/master/InstallingDrivers.md\n\n### Arch-based systems (AUR)\n\n\n\u003e [!WARNING]\n\u003e The AUR package was removed for the following reasons:\n\u003e\n\u003e I am discontinuing maintenance of this package and recommend that everyone remove it from their system. Most of the “tweaks” that are provided within this package are already part of the nvidia-utils package upstream, so you no longer need the following things because you get them with the nvidia-utils package:\n\u003e\n\u003e - Enabling nvidia-drm.modeset=1 and nvidia-drm.fbdev=1 in nvidia.conf. This is now enabled by default in nvidia-utils as a patch and ensures Wayland/PRIME configurations work properly. For users of “older” driver branches like nvidia-390xx-dkms and nvidia-470xx-dkms this is still relevant, but since these versions do not fully support Wayland sessions, enabling nvidia-drm.modeset=1 for them is only relevant for running PRIME configurations. Contact the maintainers of these packages to have them enable this by default, as it is quite useful for laptops.\n\u003e - Using udev 60-nvidia.rules. I've been doing the work of upstreaming some of these rules in nvidia-utils: https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/merge_requests/9, so you don't need to worry about them anymore, only if you're not using the nvidia-390xx-dkms and nvidia-470xx-dkms packages. Again, contact the maintainers of those packages if you want them to sync with changes in the nvidia-utils package upstream. The rest of the rules regarding power management remain relevant only for Turing generation mobile GPUs. Be warned that RTD3 does NOT work with open source versions of driver modules (nvidia-open-dkms) on Turing generation.\n\u003e -  The power schemes provided by _powermizer_scheme no longer work with newer driver versions because NVIDIA broke them starting with the 530 driver: https://forums.developer.nvidia.com/t/kernel-module-option-nvreg-registrydwords-for-powermizerenable-doesnt-work-on-530-41-03/247610. Not sure about _override_max_perf.\n\u003e -  Hooks for mkinitcpio are no longer needed, as they are now automatically run by mkinitcpio itself when installing any kernel modules:\n\u003e\n\u003e https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_requests/392\n\u003e\n\u003e https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_requests/256\n\u003e\n\u003e For those who installed this package for the benefit of nvidia-patch, please refer to the nvidia-patch package (https://aur.archlinux.org/packages/nvidia-patch). The remaining Nvidia module parameters such as NVreg_UsePageAttributeTable=1 and NVreg_InitializeSystemMemoryAllocations=0 are still valid and you can set them yourself in `/etc/modprobe.d/nvidia.conf. I will also still maintain the rest of the theoretical material in the GitHub repository.\n\n\n### Other distros\n\nThere are no packages for other distributions yet. However, you can manually\ncopy all necessary configuration files:\n\n```\ngit clone https://www.github.com/ventureoo/nvidia-tweaks.git\ncd nvidia-tweaks\nsudo cp nvidia-tweaks.conf /etc/modprobe.d/nvidia-tweaks.conf\nsudo cp 60-nvidia.rules /etc/udev/rules.d/\n```\n\nThe keylase nvidia-patch requires a separate installation. You can read about\nit on the project site: https://github.com/keylase/nvidia-patch\n\n## So, how does it work?\n\nFirst, we configure the kernel modules of the NVIDIA driver (`nvidia.conf`).\nThe thing is that by default, not all parameters are enabled in the driver\nmodule. Including the following things we need to change:\n\n- NVreg_UsePageAttributeTable=1 (Default 0) - Activating the better memory\n  management method (PAT). The PAT method creates a partition type table at a\n  specific address mapped inside the register and utilizes the memory\n  architecture and instruction set more efficiently and faster. If your system\n  can support this feature, it should improve CPU performance. To check if your\n  processor is supported by PAT, use the command: `grep -E '^flags.+ pat( |$)'\n  /proc/cpuinfo`. If the output of the command was not empty, then all is OK\n  (98% of modern processors today have PAT support).\n\n  See also:\n  \n  https://bbs.archlinux.org/viewtopic.php?id=242007,\n  https://old.reddit.com/r/linux_gaming/comments/9wjpkz/poor_gaming_performance_is_this_a_cpu_or_gpu/\n\n- NVreg_InitializeSystemMemoryAllocations (Default 1) - Disables clearing\n  system memory allocation before using it for the GPU.\n\n  Potentially improves performance, but at the cost of increased security\n  risks. Write `options nvidia NVreg_InitializeSystemMemoryAllocations=1` in\n  `/etc/modprobe.d/nvidia.conf`, if you want to return the default value.\n\n  **Note**: It is possible to use more VRAM (?)\n\n- ``nvidia_drm.modeset=1`` - enables modesetting support for the NVIDIA driver.\n  Critical for Wayland support and proper PRIME Offload operation. **Be sure to\n  enable**.\n\n- ``nvidia_drm.fbdev=1`` - enables hardware framebuffer support. Allows to use\n  native display resolution in tty. This option has no effect on PRIME laptops,\n  as the framebuffer is handled by the integrated graphics. ~~This parameter is\n  marked as experimental, so bugs may occur.~~ After 570.xx, this parameter is\n  enabled by default and is no longer experimental.\n\nThen we install udev rules from negative17\n(https://github.com/negativo17/nvidia-kmod-common/blob/master/60-nvidia.rules).\nThese udev rules are required for node presence and runtime PM and fixes\nproblems with raytracing in vkd3d\n(https://github.com/HansKristian-Work/vkd3d-proton/issues/711,\nhttps://github.com/HansKristian-Work/vkd3d-proton/issues/902).\n\n**Note**: The driver packages in Arch Linux already have these rules by default\n(See:\nhttps://github.com/archlinux/svntogit-packages/commit/3c0985a523c8795a483f3c63d177508717603b65).\nBut for other distributions this may still be necessary. Also, the packages for\nArch appear to have an incomplete set of rules, so installing them may still be\nuseful.\n\nThere are also tweaks as an option:\n\n- Installing the nvidia-patch from keylase\n  - This patch removes restriction on maximum number of simultaneous NVENC\n    video encoding sessions imposed by Nvidia to consumer-grade GPUs. You can\n    read more about it here: https://github.com/keylase/nvidia-patch\n  - As an alternative, there is [nvlax](https://github.com/illnyang/nvlax).\n    Unlike nvidia-patch, it can be used for any driver version.\n- Power Setup (PowerMizer)\n\u003e [!WARNING]\n\u003e PowerMizer options doesn't work anymore after 530.41.03 update. You can only use these parameters on driver versions lower than 530, that is, on the 470.xx and 390.xx legacy branches.\n\u003e Read more here: https://forums.developer.nvidia.com/t/kernel-module-option-nvreg-registrydwords-for-powermizerenable-doesnt-work-on-530-41-03/247610\n  - Another kernel module parameter of the `RegistryDwords` driver allows you\n    to configure the GPU power supply. To be more precise, configure the driver\n    power manager - PowerMizer.\n  - PowerMizer has three levels of performance:\n    - 1 (0x1 bit) - Maximum performance\n    - 2 (0x2 bit) - Balance between performance and power saving\n    - 3 (0x3 bit) - Powersaving\n  - PowerMizer also has two frequency management strategies:\n    - Adaptive strategy (Frequencies change depending on the load on the GPU)\n    - Static strategy (Frequencies are fixed at strictly one of the performance levels described above)\n  - Power saving is set separately for AC and battery (if you have one). That\n    is, you can select separately one frequency management strategy for the\n    battery, and separately for AC. Also if a static strategy has been selected\n    for any of the power supplies, you can set its specific performance level\n    through their respective flags `PowerMizerDefault` (battery) and\n    `PowerMizerDefaultAC` (AC).\n\n  - All PowerMizer settings are specified with a semicolon as part of the\n    `NVreg_RegistryDwords` kernel module parameter. For example:\n    `NVreg_RegistryDwords=\"PowerMizerEnable=0x1;PerfLevelSrc=0x2222;PowerMizerDefault=0x3;PowerMizerDefaultAC=0x1\"`\n    - is set Static strategy with maximum performance for AC operation and\n    maximum power savings for the battery.\n  - For convenience, the AUR package has a ready-made set of PowerMizer tuning\n    diagrams. You can apply them by setting the desired one in the PKGBUILD\n    `_powermizer_scheme=value` parameter. See PKGBUILD for a description of\n    possible values.\n  - For other distributions you have to manually edit\n    `/etc/modprobe.d/nvidia.conf` and the `NVreg_RegistryDwords` parameter. \n  - See also: https://wins911.blogspot.com/2012/06/etcx11xorg.html\n\n- Force maximum performance (For laptops only)\n  - `OverrideMaxPerf` flag for `NVreg_RegistryDwords` parameter enforces\n    applying a certain performance level while activating some GPU overclocking\n    possibilities, such as controlling GPU fan speed via nvidia-settings.\n  - The flag takes values in bits only. For example:\n    `NVreg_RegistryDwords=\"OverrideMaxPerf=0x1\"` - Forces of maximum\n    performance on any power source.\n  - **Works only for laptops.**\n  \nAll of the optional tweaks mentioned above should be applied according to your\npreferences. For a package from the AUR, they are applied through the\ncorresponding options in PKGBUILD. For other distributions this will probably\nrequire editing `/etc/modprobe.d/nvidia-tweaks.conf` and adding the appropriate\nparameters.\n\n## Some tips from me\n\n### Do not use the Force Composition Pipeline to eliminate with tearing\n\nThere are two ways to deal with tearing in Linux: \n\n1) Use a compositor with properly working Vsync frame synchronization\n(something all working environments are trying to do at the moment)\n2) Use driver options that allow you to fix it (like the Force (Full)\nComposition Pipeline).\n\nSome people advise doing the second way. Personally, I don't agree with that.\nYes, the Force Composition Pipeline does fix the tearing, but you do pay some\noverhead. Namely, you get the input lag problem, since this option contributes\nto a massive increase in latency everywhere you can. This is especially\nsensitive for places like games, because that is where the difference is best\nfelt. In addition, it also causes problems with resetting the frequencies of\nyour GPU. It is verified that the Force Composition Pipeline increases the idle\ntime for the driver to change its level of performance (See\nhttps://forums.developer.nvidia.com/t/if-you-have-gpu-clock-boost-problems-please-try-gl-experimentalperfstrategy-1/71762/14).\nAnother issue in the latest driver versions is that\nForceFullCompositionPipeline breaks VK_KHR_present_wait, which affects many\ngames (See: https://github.com/ValveSoftware/Proton/issues/6869).\n\nSo I recommend everyone to use the first way whenever possible. At the moment,\nall modern DEs and consequently the composers attached to them are good at\nsolving this issue. Particularly GNOME and since version 5.21 of Plasma no\nlonger have any problems (the main thing is to switch the rendering backend to\nOpenGL). However, for all less modern environments such as Xfce and Mate, and\nof course all window managers, the problem is still relevant. In this case it\nis necessary to perform an installation of a separate compositor like Picom.\nNow it is good enough, the most important thing is to add it to the autostart\nwith the following options to start it:\n\n``picom --backend glx --vsync``\n\nFor Xfce, you must get rid of the problematic default compositor before using\nPicom:\n\n``xfce-query -c xfwm4 -p /general/use_compositing -s false``\n\nP.S. All of the above only makes sense for the X11 sessions. Wayland implies\nthe use of compositing as a built-in feature.\n\n## Do not use the nvidia-settings or nvidia-xconfig utilities to generate xorg.conf\n\nNote, the author strongly discourages setting up your monitors and saving the\n``xorg.conf`` config via nvidia-settings or nvidia-xconfig. This is primarily\nbecause it is simply not necessary. Modern versions of the X server perform\nautoconfiguration and working monitors detection themselves, besides most DEs\nin their settings already allow you to set the required display refresh rate\nand layout for external monitors, overriding all changes made in the xorg.conf\nfile, which is static and cannot be adjusted to changes in your hardware\nconfiguration (for example, connecting a second monitor on the fly will cause\nproblems, as it isn't specified in xorg.conf, and autodetection in the presence\nof a configuration file. The nvidia-settings options are also limited in\nconfigurations with hybrid graphics (PRIME) or Wayland sessions.\n\nMore details on the issues that can arise when using nvidia-settings as a\nconfigurator for Xorg can be found here:\n\nhttps://unix.stackexchange.com/questions/697517/how-to-correlate-xorg-conf-config-for-nvidia-gpu-with-xrandr-detected-screens/697553#697553\n\nIf, however, you are a user of tiling window managers (WM), where there are no\nconvenient out-of-the-box customization tools, the author recommends that you\nuse tools such as xrandr and [picom](https://github.com/yshui/picom).\n\n## Wayland + NVIDIA\n\nCurrently, starting with driver branch 515 and higher, NVIDIA has support for\nGBM API, which made it possible to run Sway and wlroots-like window managers,\nand also significantly improved Wayland sessions in GNOME/KDE Plasma.\n\nMost of the flickering and artifact issues on Nvidia have been fixed with the\nintroduction of Explicit sync [1], which has been supported in the Nvidia\ndriver since branch 555, so it is strictly recommended to use the latest\nversion of driver on Wayland. Note that support for explicit sync on the\ncompositor side was added in KDE Plasma 6.1 and GNOME 46.2, sway 1.10 or anoter\nwlroots-based compositor that using at least wlroots 0.18.\n\nI would also like to point out that GNOME Wayland and Plasma Wayland are now\nworking at a pretty good level, it's not perfect, but progress is significant.\nFor gamers I would also recommend using the native Wayland driver in Wine, this\nachieves less lag input and avoids Xwayland issues. So, here's a set of\nenvironment variables to help you on NVIDIA using Wayland:\n\n```\nSDL_VIDEODRIVER=wayland # Can break some native games\nQT_QPA_PLATFORM=\"wayland;xcb\" # Only for Qt 5 apps\nMOZ_DBUS_REMOTE=1 # For shared clipboard with Xwayland apps\nGBM_BACKEND=nvidia-drm\nWLR_NO_HARDWARE_CURSORS=1\n_JAVA_AWT_WM_NONREPARENTING=1\n```\n\nIt is best to place these variables in ``/etc/environment`` for greater\nreliability. This should also work regardless of the shell or distribution\nused. Not all of them are useful if you are not using the wlroots-based window\nmanager. I would also recommend you to avoid Chromium (without\nOzon)/Electron-based applications, as they can all be very unstable in Wayland\non NVIDIA. ~~Browsers on QtWebEngine such as qutebrowser unfortunately do not\nwork either.~~ QtWebEngine works if you use ``QT_QUICK_BACKEND=software``\nenvironment variable.\n\nIf you do not have a Wayland session to choose from in GDM, then include the\n``NVreg_PreserveVideoMemoryAllocations=1`` parameter to the ones we already\ndescribed above.\n\n```\n  sudo systemctl enable nvidia-resume.service nvidia-suspend.service nvidia-hibernate.service\n```\n\nThis will also allow you to avoid some sleeping issues on Wayland.\n\n\u003e [!CAUTION]\n\u003e  On laptops with PRIME enabling ``NVreg_PreserveVideoMemoryAllocations=1``\n\u003e  may cause issues with sleep. Therefore it is recommended to use it only on\n\u003e  desktop PCs.\n\n[1] - https://github.com/NVIDIA/egl-wayland/pull/104\n\n## Environment variables\n\nThe NVIDIA driver has some specific environment variables. I will not list the\ntechnical specifics of how they work, I will just tell you about the effect\nthey can have, more details you will learn if you follow the links:\n\n``__GL_THREADED_OPTIMIZATIONS=1`` (Off by default) - Enable multi-threaded\nOpenGL processing. The analog of Mesa's ``mesa_glthread`` variable.\nUse selectively for native games/applications, because sometimes it can cause\nperformance regression [1], [2]. Some games may not run with this variable at\nall (e.g. some native parts of Metro). Note that for some applications this\nenvironment variable is already used in the default NVIDIA profile supplied\nwith the driver (``/usr/share/nvidia/nvidia-application-profiles-525.78.01-rc``\nfor example).\n\n\u003e [!WARNING]\n\u003e Gamescope crashes when this variable is used:\n\u003e https://github.com/ValveSoftware/gamescope/issues/526#issuecomment-1733739097\n\n[1] - https://www.phoronix.com/review/nvidia_threaded_opts (a very old benchmark)\n\n[2] - https://www.phoronix.com/review/nvidia-t2015-optimizations\n\n``__GL_MaxFramesAllowed=1`` (Default value is 2?) - Roughly speaking, it sets\nthe type of frame buffering by the driver. You can specify \"3\" (Triple\nbuffering) for more FPS or better performance in applications/games with VSync.\nI recommend to try \"1\". It can noticeably decrease FPS value in games, but in\nreturn you will get better rendering delays and real physical response, because\nthe frame will be displayed to you immediately on the screen without\nunnecessary processing steps. This hack was used in some compositors to improve\nlatency [1][2][3][4].\n\n[1] - https://github.com/yshui/picom/pull/641\n\n[2] - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1269\n\n[3] - https://forums.developer.nvidia.com/t/how-to-turn-on-low-latency-mode-max-pre-render-frames-on-linux/108353\n\n[4] - https://phabricator.kde.org/D19867\n\n``__GL_YIELD=\"USLEEP\"`` (Unset by default) - Pretty specific parameter with\nseveral possible values. Most interestingly, the ``USLEEP`` value can\npotentially reduce latency and CPU load [1][2]. More information can be found\nin the driver documentation:\nhttps://download.nvidia.com/XFree86/Linux-x86_64/525.78.01/README/openglenvvariables.html\n\n[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925528\n\n[2] - https://aweirdimagination.net/2020/05/24/100-cpu-usage-in-games-with-nvidia-linux-drivers/\n\n**Note:** I'm not entirely sure how relevant this variable is right now.\n\n``__GL_SHADER_DISK_CACHE_SKIP_CLEANUP=1`` - disables OpenGL/Vulkan shader cache\nlimit (``~/.cache/nvidia`` by default).  Recommended for modern games and DXVK\n2.0+, where the cache can reach more than a gigabyte. \n\n\u003e [!WARNING]\n\u003e I strongly advise against specifying the above environment variables for the\n\u003e whole system. Please specify them for specific applications/games with\n\u003e nvidia-settings or using Lutris/Steam.\n\n## GSP firmware\n\n**NOTE:** Starting with version 555.42.02, the use of GSP firmware is enabled\nby default on GPUs where it is supported. In open source versions of the NVIDIA\ndriver modules, GSP is always used and you cannot disable it.\n\nGSP (GPU System Processor) - this is a special chip which is present on NVIDIA\nvideo cards starting from Turing and above, which offloads GPU initialization\nand control tasks, which are usually performed on CPU. This should improve\nperformance and reduce the load on the CPU.\n\nSome users report issues when using GSP, such as minor performance drops. You\ncan disable GSP using the ``NVreg_EnableGpuFirmware=0`` option by adding it to\nthe ``/etc/modprobe.d/nvidia.conf`` config.  Note that this parameter works\nonly for closed driver modules.\n\nSee also:\n\nhttps://www.techpowerup.com/291088/nvidia-unlocks-gpu-system-processor-gsp-for-improved-system-performance\n\nhttps://download.nvidia.com/XFree86/Linux-x86_64/530.41.03/README/gsp.html\n\n## Resizable Bar\n\nStarting with version 530.30.02 NVIDIA introduced support for the Resizeble\nBar. Previously, we already had a third-party patch for this (see the patches\ndirectory), but it also required to patch for kernel. Although this change was\nnot documented for some reason, we now have the ``NVreg_EnableResizableBar``\nprameter which is disabled by default. Keep in mind that for Resize Bar to work\nproperly, you not only need a GPU that supports it (it is officially supported\nsince Ampere), but also an compatible motherboard.\n\nTo make sure that your GPU actually supports this, go to nvidia-settings,\nselect your GPU, and look in the ``Resizable Bar`` column. If it says \"Yes\",\nthat's all right and you can use the kernel parameter specified above:\n``NVreg_EnableResizableBar=1``.\n\n(P.S. For some reason, the ``Resizable Bar`` column is not shown in\nnvidia-settings in the Wayland session)\n\n## Partial unlocking of TDP limit on laptops with Ampere GPUs and higher\n\nUnfortunately on new driver versions it is not possible to set the TDP limit\nmanually via nvidia-smi. But for users of laptops with Ampere generation GPUs\n(RTX 30xx) and higher, there is a workaround that partially solves the issue by\nslightly increasing the TDP limit. For this purpose, you just need to enable\nthe ``nvidia-powerd`` service, which enables Dynamic Boost technology:\n\n```\n sudo systemctl enable nvidia-powerd\n```\n\nFor example on a laptop with a 3050 Mobile this allows you to raise dynamically\n(i.e. depending on system load) the TDP limit from 35W to 40W, without\nsignificant temperature changes.\n\nNote that Dynamic Boost technology only works when the laptop is running on AC\npower and also affects CPU performance by changing the maximum frequency.\n\nSee more:\n\nhttps://download.nvidia.com/XFree86/Linux-x86_64/565.57.01/README/dynamicboost.html\n\n## Firejail + NVIDIA\n\nFor 3D acceleration to work properly via NVIDIA GPU inside Firejail starting\nwith the 550.xx driver and above, you need to add the following lines to your\n``~/.config/firejail/globals.local``:\n\n```\nnoblacklist /sys/module\nwhitelist /sys/module/nvidia*\nread-only /sys/module/nvidia*\n```\n\n## Low-latency frame presentation mode\n\nStarting with the 570.xx driver, the NVIDIA driver has a so-called low-latency\ndisplay mode, which allows you to get latency close to the vblank value. You\ncan enable this mode by adding ``NVreg_RegistryDwords=RMIntrLockingMode=1`` to\nyour modprobe configuration for the nvidia module. Note that this is\nexperimental and may have potential issues.\n\n## Hybrid graphics (NVIDIA Optimus)\n\nAll sorts of fun :)\n\nFirst, let's understand what hybrid graphics are (Of course, technical details\nare not something everyone wants to go into, but it is necessary for further\nunderstanding).  Hybrid graphics is a hardware configuration in which you have\ntwo graphics cards that can work in tandem with each other. This approach is\nmainly found in laptops where you have integrated graphics (iGPU) of your CPU,\nand discrete graphics (dGPU). The main advantage is that integrated graphics\nshould (but not necessarily) only be used for low-profile tasks, such as\nsurfing the Internet, watching videos, etc. And discrete graphics are used for\nhigh-performance things like gaming, editing, 3D modeling, and so on.\nConsequently, if two GPUs share \"big\" and \"small\" tasks, then if we have only\n\"small\" tasks running at the moment, we don't need to use our dGPU, so it can\nsimply be disabled (as if asleep), thereby significantly reducing power\nconsumption. This way when our dGPU is needed again (we run an application\nusing it), it will wake up and start working.\n\nIt sounds good on paper, as it allows modern laptops to balance low power\nconsumption while leaving the ability to engage high-performance graphics, but\nin practice there are a lot of problems. Obvious problem No. 1, which lies in\nconcept: Which GPU will do the output to screen? There are several variations\nhere:\n\n1. (MUXless) The most common case is when the integrated graphics completely\n   control your (at least) internal display. This leads to the fact that\n   firstly: you can not completly turn off iGPU, because it is responsible for\n   output on internal display. Secondly, and more terribly, dGPU can't output\n   anything directly to the screen, forcing the iGPU to be used as a buffer to\n   which rendered frames for displaying on the screen go. As it turned out in\n   practice, this is the source of most problems. Because there is an overhead\n   of copying frames from dGPU to iGPU, and also iGPU and dGPU can be\n   controlled by different drivers, which may not want to be friends with each\n   other at all (hello Linux).\n\n2. (MUXed) The best case (which of course is less common) is when you have a\n   special multiplexer - MUX. The MUX, is controlling for which GPU will\n   display the image on the screen. We will not go into the details of its\n   work, but simply say that with it both GPUs can now directly output an\n   image. Unfortunately, laptops with MUX are much rarer and usually more\n   expensive.\n\n3. (MUXed) There is also another option in which you already have two MUX. One\n   MUX controls the output on the built-in screen, the second MUX controls the\n   image output on the external display (ports).\n\nFor a better understanding, take a look at this picture.\n\n![hyrbid-graphics](https://github.com/ventureoo/nvidia-tweaks/assets/92667539/2332379d-56c8-4771-b6d4-a1fa0060efaf)\n\nNow that we have understood the concept, we can look at how it works in Linux\nnow.\n\nPRIME is a unifying technology for working with different sets of hybrid\ngraphics in Linux, like NVIDIA Optimus/AMD Dynamic Switchable Graphics. PRIME\nOffload is an implementation of the idea of moving the execution of render from\none GPU to another in Linux. PRIME support in a closed NVIDIA driver actually\nstarted only with the 435.17 driver. So if you are a user of the outdated 390xx\nor even 340xx driver branches, PRIME will not work for you. Note that I also\nstrongly discourage you from using outdated ways to handle hybrid graphics,\nsuch as nvidia-xrun or Bumblebee. They are obsolete and unsupported (Bumblebee\nhas not been updated for over 8 years), run solely on hacks and have low\nperformance. At the same time the Nouveau driver supports PRIME Offload, which\ncan be an alternative for older dGPUs.\n\nSo, the good news about PRIME Offload is that you should already have it\nworking out of the box (yes, manual configuration of xorg.conf is not required\non the latest driver versions, since many options are already enabled by\ndefault), under two conditions:\n\n1. All NVIDIA driver modules are properly installed and loaded. Most of the\n   problems with PRIME occur here because some people don't know that their\n   dGPU is not properly serviced. On a desktop PC, the modules leak to a black\n   screen at boot time, but on laptops it will just cause your system to rely\n   entirely on the iGPU. So trying to use PRIME Offload will result in an\n   error. You can check that all modules are loaded with ``lsmod | grep\n   nvidia`` and also with ``lspci -k``. One of the common reasons why NVIDIA\n   modules may not boot is that Secure Boot is enabled in your UEFI, so it is\n   recommended to disable it (or to sign modules and kernel, but this is beyond\n   the scope of this guide).\n\n2. You have the option ``nvidia-drm.modeset=1`` enabled. This is also **very\n   important** because even if you have the driver properly installed and\n   working, without this option PRIME and some other features (such as Wayland,\n   DMA-BUFs) simply will not work. See previous instructions to enable this\n   option.\n\n3. Don't use DDX drivers like ``xf86-video-intel`` and ``xf86-video-amdgpu``.\n   ``xf86-video-intel`` is an obsolete driver that can cause many issues and\n   glitches in rendering your desktop. ``xf86-video-amdgpu``, although it's\n   actively maintained, doesn't support PRIME Synchronization technology\n   (https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/11),\n   which can cause tearing on laptops. Instead it is better to use the built-in\n   DDX driver modesetting which requires no further setup, you just need to\n   uninstall the old DDX drivers from system then modesetting started using.\n\nTo check that PRIME Offload is working properly, you need to use the following\nset of environment variables:\n\n```\n# If the glxinfo command is not found, install mesa-utils\n__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep vendor\n```\n\nIn the last two, the dGPU driver is set as the OpenGL/Vulkan provider used,\nrespectively.\n\nIf the output of the command indicates to you mention of your NVIDIA card,\nand without specifying the environment variables an integrated graphics, then\neverything is fine. This means you have the Reserve PRIME mode set up and\nworking correctly.\n\nNote that the above environment variables can be replaced by the ``prime-run``\ncommand in Arch-based distributions. Essentially ``prime-run`` is just a wrapper\nscript over these variables, but it is much more convenient to write prime-run\nthan a large set of environment variables.\n\nAlso note that on most systems running Vulkan applications and games that use\nVulkan via DXVK/vkd3d-proton by default will cause your dGPU to be used. You\ncan check this by running ``vkcube`` without any variables.\n\nIf not, you will probably have to specify the use of PRIME Offload either in\nthe Lutris settings (in the \"Global options\" section) or specify above\nvariables in the Steam game \"Properties\", remembering to add the ``%command%``\ndelimiter at the end, for example:\n\n```\nprime-run %command%\n```\n\nOr (if you're not on the Arch-based system):\n\n```\n__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia %command%\n```\n\nPlease note that some features of discrete graphics in this mode are somewhat\nreduced. So, you will not be able to configure your monitors via\nnvidia-settings as it was indicated in the previous section, because iGPU are\nresponsible for connecting and maintaining internal display (only if you have a\nMUXless laptop) and external monitors. The possibility of overclocking and\nmanual power management of a dGPU is also excluded.\n\nBut the main issue with PRIME is the performance of external monitors. The\nthing is, as stated in the beginning, main display of laptop is controlled by\niGPU. But external ports can be controlled by either dGPU or iGPU depending on\nyour laptop. In case they are controlled by the iGPU, you may be fine. But if\ndGPU is used to control the external display, then problems begin.\n\nYour external monitor may be artfect, or very slow. It's worth noting that this\nisn't really an Nvidia driver issue, but also in compositors, as they aren't\nvery good at handling these situations, since the implication is that you only\nhave one GPU to manage all the displays. When multiple displays are handled by\ndifferent GPUs the compositor doesn't always know what to do.\n\nSome people recommend using dGPU as the default GPU in this case, but I'm not\nreally in favor of this solution as it kills your laptop's power savings and on\nMUXless configurations still causes frames to be copied to the iGPU.\n\nMy advice is to just wait for modern compositors to fix these issues. Some work\nis already being done on this in GNOME and KDE:\n\nhttps://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304\n\nhttps://bugs.kde.org/show_bug.cgi?id=452219\n\nIn Plasma 6, this issue will probably already be fixed by using the latest 550\ndriver and EGL_ANDROID_native_fence_fd extension in KWin (its support added by\nNvidia since 545).\n\nGnome users should switch to using version 46.1+ where this has been fixed.\n\n### System hangs when using 550 driver\n\nIf you notice system hangs when using driver 550 and above, try switching to\nusing open NVIDIA modules. This is a known issue, see here:\nhttps://forums.developer.nvidia.com/t/series-550-freezes-laptop/284772/168\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fventureoo%2Fnvidia-tweaks","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fventureoo%2Fnvidia-tweaks","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fventureoo%2Fnvidia-tweaks/lists"}