Please describe your issue in as much detail as possible:
When Steam is running over a long period of time (i.e., multiple days), the Xorg process accumulates multiple gigabytes of VRAM over time. It doesn't matter if Steam is running in foreground or as systray only.
This behavior leads to games having VRAM starvation issues like stuttering, periods of low FPS with fluctuating frame times, high PCIe bandwidth usage, and ultimately games crash to desktop eventually.
Here's a snapshot of nvidia-smi when the issue exists:
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.54.03 Driver Version: 535.54.03 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| 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 RTX 3080 Ti Off | 00000000:01:00.0 On | N/A |
| 74% 64C P0 196W / 370W | 11937MiB / 12288MiB | 44% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 1824 G /usr/libexec/Xorg 3698MiB |
| 0 N/A N/A 2486 G /usr/bin/kwin_x11 5MiB |
| 0 N/A N/A 2505 G /usr/bin/plasmashell 4MiB |
| 0 N/A N/A 3648 G ...local/share/Steam/ubuntu12_32/steam 8MiB |
| 0 N/A N/A 3654 G ...re/Steam/ubuntu12_64/steamwebhelper 10MiB |
| 0 N/A N/A 5361 G ...ding,RawDraw,WebRTCPipeWireCapturer 109MiB |
| 0 N/A N/A 2513172 G ...,WinRetrieveSuggestionsOnlyOnDemand 54MiB |
| 0 N/A N/A 2518848 C+G ...ous-odyssey-64\EliteDangerous64.exe 7823MiB |
+---------------------------------------------------------------------------------------+
Elite Dangerous is struggling to allocate the needed VRAM, resulting in drops to 10 fps lower when close to suns, then going back up to 90 fps as soon as shadow casting of the sun is no longer rendering in the cockpit. This effect gets worse over time but shadow casting is the first showing the problem, later it affects rendering of stations and planets, too. Usually, the game crashes to desktop before any worse effects can be observed.
Xorg memory allocation persists no matter which application I close until I quit the Steam client itself (3698MiB vs 538MiB):
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.54.03 Driver Version: 535.54.03 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| 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 RTX 3080 Ti Off | 00000000:01:00.0 On | N/A |
| 0% 50C P5 42W / 370W | 1085MiB / 12288MiB | 20% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 1824 G /usr/libexec/Xorg 538MiB |
| 0 N/A N/A 2486 G /usr/bin/kwin_x11 132MiB |
| 0 N/A N/A 2505 G /usr/bin/plasmashell 4MiB |
| 0 N/A N/A 5361 G ...ding,RawDraw,WebRTCPipeWireCapturer 236MiB |
| 0 N/A N/A 2513172 G ...,WinRetrieveSuggestionsOnlyOnDemand 56MiB |
+---------------------------------------------------------------------------------------+
Starting the Steam client again slowly increases VRAM usage again, here's what it looks like after a few hours:
| 0 N/A N/A 1824 G /usr/libexec/Xorg 1457MiB |
It doesn't matter if GPU acceleration for Steam GUI is enabled or disabled. It seems to allocate VRAM resources no matter what, it doesn't even look like the acceleration setting makes a difference at all: VRAM allocation behaves the same, rendering speed is the same (subjectively).
Steps for reproducing this issue:
Use NVIDIA on Xorg with kwin (not sure if kwin matters)
Take note of nvidia-smi VRAM usage before starting the client
Run the client and let it run for many hours
Compare nvidia-smi VRAM usage
Quit the client and compare nvidia-smi VRAM usage again
Your system information
Please describe your issue in as much detail as possible:
When Steam is running over a long period of time (i.e., multiple days), the Xorg process accumulates multiple gigabytes of VRAM over time. It doesn't matter if Steam is running in foreground or as systray only.
This behavior leads to games having VRAM starvation issues like stuttering, periods of low FPS with fluctuating frame times, high PCIe bandwidth usage, and ultimately games crash to desktop eventually.
Here's a snapshot of nvidia-smi when the issue exists:
Elite Dangerous is struggling to allocate the needed VRAM, resulting in drops to 10 fps lower when close to suns, then going back up to 90 fps as soon as shadow casting of the sun is no longer rendering in the cockpit. This effect gets worse over time but shadow casting is the first showing the problem, later it affects rendering of stations and planets, too. Usually, the game crashes to desktop before any worse effects can be observed.
Xorg memory allocation persists no matter which application I close until I quit the Steam client itself (3698MiB vs 538MiB):
Starting the Steam client again slowly increases VRAM usage again, here's what it looks like after a few hours:
It doesn't matter if GPU acceleration for Steam GUI is enabled or disabled. It seems to allocate VRAM resources no matter what, it doesn't even look like the acceleration setting makes a difference at all: VRAM allocation behaves the same, rendering speed is the same (subjectively).
Steps for reproducing this issue: