NVIDIA/Tips and tricks
Fixing terminal resolution
Transitioning from nouveau may cause your startup terminal to display at a lower resolution.
For GRUB, see GRUB/Tips and tricks#Setting the framebuffer resolution for details. [1] [2]
For systemd-boot, set console-mode
in esp/loader/loader.conf
. See systemd-boot#Loader configuration for details.
For rEFInd, set use_graphics_for +,linux
in esp/EFI/refind/refind.conf
.[3] A small caveat is that this will hide the kernel parameters from being shown during boot.
Using TV-out
X with a TV (DFP) as the only display
The X server falls back to CRT-0 if no monitor is automatically detected. This can be a problem when using a DVI connected TV as the main display, and X is started while the TV is turned off or otherwise disconnected.
To force NVIDIA to use DFP, store a copy of the EDID somewhere in the filesystem so that X can parse the file instead of reading EDID from the TV/DFP.
To acquire the EDID, start nvidia-settings. It will show some information in tree format, ignore the rest of the settings for now and select the GPU (the corresponding entry should be titled "GPU-0" or similar), click the DFP
section (again, DFP-0
or similar), click on the Acquire Edid
Button and store it somewhere, for example, /etc/X11/dfp0.edid
.
If in the front-end mouse and keyboard are not attached, the EDID can be acquired using only the command line. Run an X server with enough verbosity to print out the EDID block:
$ startx -- -logverbose 6
After the X Server has finished initializing, close it and your log file will probably be in /var/log/Xorg.0.log
. Extract the EDID block using nvidia-xconfig:
$ nvidia-xconfig --extract-edids-from-file=/var/log/Xorg.0.log --extract-edids-output-file=/etc/X11/dfp0.bin
Edit xorg.conf
by adding to the Device
section:
Option "ConnectedMonitor" "DFP" Option "CustomEDID" "DFP-0:/etc/X11/dfp0.bin"
The ConnectedMonitor
option forces the driver to recognize the DFP as if it were connected. The CustomEDID
provides EDID data for the device, meaning that it will start up just as if the TV/DFP was connected during X the process.
This way, one can automatically start a display manager at boot time and still have a working and properly configured X screen by the time the TV gets powered on.
If the above changes did not work, in the xorg.conf
under Device
section you can try to remove the Option "ConnectedMonitor" "DFP"
and add the following lines:
Option "ModeValidation" "NoDFPNativeResolutionCheck" Option "ConnectedMonitor" "DFP-0"
The NoDFPNativeResolutionCheck
prevents NVIDIA driver from disabling all the modes that do not fit in the native resolution.
Headless (no monitor) resolution
In headless mode, resolution falls back to 640x480, which is used by VNC or Steam Link. To start in a higher resolution e.g. 1920x1080, specify a Virtual
entry under the Screen
subsection in xorg.conf
:
Section "Screen" [...] SubSection "Display" Depth 24 Virtual 1920 1080 EndSubSection EndSection
Check the power source
The NVIDIA X.org driver can also be used to detect the GPU's current source of power. To see the current power source, check the 'GPUPowerSource' read-only parameter (0 - AC, 1 - battery):
$ nvidia-settings -q GPUPowerSource -t
1
Listening to ACPI events
NVIDIA drivers automatically try to connect to the acpid daemon and listen to ACPI events such as battery power, docking, some hotkeys, etc. If connection fails, X.org will output the following warning:
~/.local/share/xorg/Xorg.0.log
NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon NVIDIA(0): may not be running or the "AcpidSocketPath" X NVIDIA(0): configuration option may not be set correctly. When the NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will NVIDIA(0): try to use it to receive ACPI event notifications. For NVIDIA(0): details, please see the "ConnectToAcpid" and NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X NVIDIA(0): Config Options in the README.
While completely harmless, you may get rid of this message by disabling the ConnectToAcpid
option in your /etc/X11/xorg.conf.d/20-nvidia.conf
:
Section "Device" ... Driver "nvidia" Option "ConnectToAcpid" "0" ... EndSection
If you are on laptop, it might be a good idea to install and enable the acpid daemon instead.
Displaying GPU temperature in the shell
There are three methods to query the GPU temperature. nvidia-settings requires that you are using X, nvidia-smi or nvclock do not. Also note that nvclock currently does not work with newer NVIDIA cards such as GeForce 200 series cards as well as embedded GPUs such as the Zotac IONITX's 8800GS.
nvidia-settings
To display the GPU temp in the shell, use nvidia-settings as follows:
$ nvidia-settings -q gpucoretemp
Attribute 'GPUCoreTemp' (hostname:0[gpu:0]): 49. 'GPUCoreTemp' is an integer attribute. 'GPUCoreTemp' is a read-only attribute. 'GPUCoreTemp' can use the following target types: GPU.
The GPU temps of this board is 49 °C.
In order to get just the temperature for use in utilities such as rrdtool or conky:
$ nvidia-settings -q gpucoretemp -t
49
nvidia-smi
Use nvidia-smi which can read temps directly from the GPU without the need to use X at all, e.g. when running Wayland or on a headless server.
To display the GPU temperature in the shell, use nvidia-smi:
$ nvidia-smi
Wed Feb 28 14:27:35 2024 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce GTX 1660 Ti Off | 00000000:01:00.0 On | N/A | | 0% 49C P8 9W / 120W | 138MiB / 6144MiB | 2% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | 0 N/A N/A 223179 G weston 120MiB | +-----------------------------------------------------------------------------------------+
Only for temperature:
$ nvidia-smi -q -d TEMPERATURE
==============NVSMI LOG============== Timestamp : Wed Feb 28 14:27:35 2024 Driver Version : 550.54.14 CUDA Version : 12.4 Attached GPUs : 1 GPU 00000000:01:00.0 Temperature GPU Current Temp : 49 C GPU T.Limit Temp : N/A GPU Shutdown Temp : 95 C GPU Slowdown Temp : 92 C GPU Max Operating Temp : 90 C GPU Target Temperature : 83 C Memory Current Temp : N/A Memory Max Operating Temp : N/A
In order to get just the temperature for use in utilities such as rrdtool or conky:
$ nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader,nounits
49
nvclock
Install the nvclockAUR package.
There can be significant differences between the temperatures reported by nvclock and nvidia-settings/nv-control. According to this post by the author (thunderbird) of nvclock, the nvclock values should be more accurate.
Overclocking and cooling
Enabling overclocking
- Overclocking settings cannot be applied if the Xorg server is running in rootless mode. Consider running Xorg as root.
- Enabling DRM kernel mode setting may cause overclocking to become unavailable, regardless of the Coolbits value.
Overclocking is controlled via Coolbits option in the Device
section, which enables various unsupported features:
Option "Coolbits" "value"
# nvidia-xconfig --cool-bits=value
The Coolbits value is the sum of its component bits in the binary numeral system. The component bits are:
1
(bit 0) - Enables overclocking of older (pre-Fermi) cores on the Clock Frequencies page in nvidia-settings.2
(bit 1) - When this bit is set, the driver will "attempt to initialize SLI when using GPUs with different amounts of video memory".4
(bit 2) - Enables manual configuration of GPU fan speed on the Thermal Monitor page in nvidia-settings.8
(bit 3) - Enables overclocking on the PowerMizer page in nvidia-settings. Available since version 337.12 for the Fermi architecture and newer.[4]16
(bit 4) - Enables overvoltage using nvidia-settings CLI options. Available since version 346.16 for the Fermi architecture and newer.[5]
To enable multiple features, add the Coolbits values together. For example, to enable overclocking and overvoltage of Fermi cores, set Option "Coolbits" "24"
.
The documentation of Coolbits can be found in /usr/share/doc/nvidia/html/xconfigoptions.html
and here.
Setting static 2D/3D clocks
Use kernel module parameters to enable PowerMizer at its maximum performance level (VSync will not work without this):
/etc/modprobe.d/nvidia.conf
options nvidia NVreg_RegistryDwords="PerfLevelSrc=0x2222"
Lowering GPU Boost Clocks
With Ampere (NV170/GAXXX) GPUs and later, clock boost works in a different way, and maximum clocks are set to the highest supported limit at boot. If that is what you want, then no further configuration is necessary.
The drawback is the lower power efficiency. As the clocks go up, increased voltage is needed for stability, resulting in a nonlinear increase in power consumption, heating, and fan noise. Lowering the boost clock limit will thus increase efficiency.
Boost clock limits can be changed using nvidia-smi, running as root:
- List supported clock rates:
$ nvidia-smi -q -d SUPPORTED_CLOCKS
- Set GPU boost clock limit to 1695 MHz:
# nvidia-smi --lock-gpu-clocks=0,1695 --mode=1
- Set Memory boost clock limit to 5001 MHz:
# nvidia-smi --lock-memory-clocks=0,5001
To optimize for efficiency, use nvidia-smi to check the GPU utilization while running your favorite game. VSync should be on. Lowering the boost clock limit will increase GPU utilization, because a slower GPU will use more time to render each frame. Best efficiency is achieved with the lowest clocks that do not cause the stutter that results when the utilization hits 100%. Then, each frame can be rendered just quickly enough to keep up with the refresh rate.
As an example, using the above settings instead of default on an RTX 3090 Ti, while playing Hitman 3 at 4K@60, reduces power consumption by 30%, temperature from 75 to 63 degrees, and fan speed from 73% to 57%.
Saving overclocking settings
Typically, clock and voltage offsets inserted in the nvidia-settings interface are not saved, being lost after a reboot. Fortunately, there are tools that offer an interface for overclocking under the proprietary driver, able to save the user's overclocking preferences and automatically applying them on boot. Some of them are:
- gweAUR - graphical, applies settings on desktop session start
- nvclockAUR and systemd-nvclock-unitAUR - graphical, applies settings on system boot
- nvocAUR - text based, profiles are configuration files in
/etc/nvoc.d/
, applies settings on desktop session start
Otherwise, GPUGraphicsClockOffset
and GPUMemoryTransferRateOffset
attributes can be set in the command-line interface of nvidia-settings on startup. For example:
$ nvidia-settings -a "GPUGraphicsClockOffset[performance_level]=offset" $ nvidia-settings -a "GPUMemoryTransferRateOffset[performance_level]=offset"
Where performance_level
is the number of the highest performance level. If there are multiple GPUs on the machine, the GPU ID should be specified: [gpu:gpu_id]GPUGraphicsClockOffset[performance_level]=offset
.
Custom TDP Limit
Modern NVIDIA graphics cards throttle frequency to stay in their TDP and temperature limits. To increase performance it is possible to change the TDP limit, which will result in higher temperatures and higher power consumption.
For example, to set the power limit to 160.30W:
# nvidia-smi -pl 160.30
To set the power limit on boot (without driver persistence):
/etc/systemd/system/nvidia-tdp.timer
[Unit] Description=Set NVIDIA power limit on boot [Timer] OnBootSec=5 [Install] WantedBy=timers.target
/etc/systemd/system/nvidia-tdp.service
[Unit] Description=Set NVIDIA power limit [Service] Type=oneshot ExecStart=/usr/bin/nvidia-smi -pl 160.30
Now enable the nvidia-tdp.timer
.
Set fan speed at login
You can adjust the fan speed on your graphics card with nvidia-settings' console interface. First ensure that your Xorg configuration has enabled the bit 2 in the Coolbits option.
Place the following line in your xinitrc file to adjust the fan when you launch Xorg. Replace n
with the fan speed percentage you want to set.
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=n"
You can also configure a second GPU by incrementing the GPU and fan number.
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=n" \ -a "[gpu:1]/GPUFanControlState=1" -a [fan:1]/GPUTargetFanSpeed=n" &
If you use a login manager such as GDM or SDDM, you can create a desktop entry file to process this setting. Create ~/.config/autostart/nvidia-fan-speed.desktop
and place this text inside it. Again, change n
to the speed percentage you want.
[Desktop Entry] Type=Application Exec=nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=n" X-GNOME-Autostart-enabled=true Name=nvidia-fan-speed
To make it possible to adjust the fanspeed of more than one graphics card, run:
$ nvidia-xconfig --enable-all-gpus $ nvidia-xconfig --cool-bits=4
Kernel module parameters
Some options can be set as kernel module parameters, a full list can be obtained by running modinfo nvidia
or looking at nv-reg.h
. See Gentoo:NVidia/nvidia-drivers#Kernel module parameters as well.
For example, enabling the following will enable the PAT feature [7], which affects how memory is allocated. PAT was first introduced in Pentium III [8] and is supported by most newer CPUs (see wikipedia:Page attribute table#Processors). If your system can support this feature, it should improve performance.
/etc/modprobe.d/nvidia.conf
options nvidia NVreg_UsePageAttributeTable=1
On some notebooks, to enable any NVIDIA settings tweaking you must include this option, otherwise it responds with "Setting applications clocks is not supported" etc.
/etc/modprobe.d/nvidia.conf
options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
Preserve video memory after suspend
By default the NVIDIA Linux drivers save and restore only essential video memory allocations on system suspend and resume. Quoting NVIDIA:
- The resulting loss of video memory contents is partially compensated for by the user-space NVIDIA drivers, and by some applications, but can lead to failures such as rendering corruption and application crashes upon exit from power management cycles.
The "still experimental" interface enables saving all video memory (given enough space on disk or RAM).
To save and restore all video memory contents, NVreg_PreserveVideoMemoryAllocations=1
kernel module parameter for the nvidia
kernel module needs to be set. While NVIDIA does not set this by default, Arch Linux does for the supported drivers.
You also need to have the services nvidia-suspend.service
, nvidia-hibernate.service
, and nvidia-resume.service
enabled. Arch Linux enables them by default on supported drivers, as per upstream requirements.
See NVIDIA's documentation for more details.
- As per Kernel module#Using files in /etc/modprobe.d/, you will need to regenerate the initramfs if using early KMS.
- The video memory contents are by upstream default saved to
/tmp
, which is a tmpfs. NVIDIA recommends using an other filesystem to achieve the best performance. This is also required if the size is not sufficient for the amount of memory. Arch Linux thus setsnvidia.NVreg_TemporaryFilePath=/var/tmp
by default on supported drivers. - The chosen file system containing the file needs to support unnamed temporary files (e.g. ext4 or XFS) and have sufficient capacity for storing the video memory allocations (i.e. at least 5 percent more than the sum of the memory capacities of all NVIDIA GPUs). Use the command
nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits
to list the memory capacities of all GPUs in the system. - While
nvidia-resume.service
is marked as required by NVIDIA, it can be optional, as its functionality is also provided by a systemd-sleep(8) hook (/usr/lib/systemd/system-sleep/nvidia
) and the latter is invoked automatically. Note that GDM with Wayland however explicitly requiresnvidia-resume.service
to be enabled.
Driver persistence
NVIDIA has a daemon that can be optionally run at boot. In a standard single-GPU X desktop environment the persistence daemon is not needed and can actually create issues [9]. See the Driver Persistence section of the NVIDIA documentation for more details.
To start the persistence daemon at boot, enable the nvidia-persistenced.service
. For manual usage see the upstream documentation.
Forcing YCbCr with 4:2:0 subsampling
If you are facing limitations of older output standards that can still be mitigated by using YUV 4:2:0, the NVIDIA driver has an undocumented X11 option to enforce that:
Option "ForceYUV420" "True"
This will allow higher resolutions or refresh rates but have detrimental impact on the image quality.