Skipper Linux x64 consuming huge amounts of VRAM using mutter-x11-frames

Question

I've noticed that Skipper is consuming huge amounts of VRAM when open for several hours with the following config:

• Skipper AppImage Linux
• Ubuntu 23.04 with GNOME 44
• X11
• 2560x1440@165Hz@100%

Output of nvidia-smi - you can clearly see mutter-x11-frames consuming >3GB VRAM

Thu May 11 16:54:57 2023       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.105.17   Driver Version: 525.105.17   CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+
| 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 ...  Off  | 00000000:01:00.0  On |                  N/A |
| N/A   53C    P0    34W / 115W |   5197MiB / 16384MiB |      3%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      7922      G   /usr/lib/xorg/Xorg               1006MiB |
|    0   N/A  N/A      8177      G   /usr/bin/gnome-shell              258MiB |
|    0   N/A  N/A      8194      G   ...libexec/mutter-x11-frames     3380MiB |
|    0   N/A  N/A      8565      G   .../usr/bin/telegram-desktop       57MiB |
|    0   N/A  N/A      9345      G   ...veSuggestionsOnlyOnDemand       79MiB |
|    0   N/A  N/A      9403      G   ...RendererForSitePerProcess       35MiB |
|    0   N/A  N/A     10826      G   ...993402366275824947,131072       74MiB |
|    0   N/A  N/A     11110      G   ...b/thunderbird/thunderbird      171MiB |
|    0   N/A  N/A     12386      G   ...features=BackForwardCache       63MiB |
|    0   N/A  N/A     39624      G   /usr/bin/nautilus                  11MiB |
|    0   N/A  N/A     49680      G   ...RendererForSitePerProcess       28MiB |
|    0   N/A  N/A    165800      G   /usr/bin/gjs                       24MiB |
+-----------------------------------------------------------------------------+

Comments

Thank you for the report. Unfortunately, this seems to be probably a GNOME-dependent issue.

We're compiling Skipper on Ubuntu, so we can declare full compatibility with Ubuntu-like systems as noted in Skipper docs.

We will try it under Ubuntu if we will see a similar issue, but we're using Skipper without exit for several days/weeks on our computers only with sleeping computers and we don't see such issues on our dev computers.

I'm not sure what are differences between x11 on Ubuntu and Gnome,so maybe some incompatibility in X11 or Qt libraries on Gnome vs Ubuntu.

---

Hello and thank you for your reply.
It's great news and I'll be happy to test it out when it's ready ;-)
Meanwhile, could you please confirm if you're using Wayland on Ubuntu?

---

We're using the Qt framework for GUI on Ubuntu compiled with Wayland support, so I believe the Wayland is used if possible.

---

I see, thank you. And I believe that is what's causing problems. Unfortunately, there are many issues with Wayland for Nvidia GPUs, so I've had to go to X11. Would it be possible in the future to introduce also the support for X11?

---

I think the app should support both modes already. And it's only about configuring some environments to use x11.

You can try to check what platforms are offered to you on Gnome based on this post:

https://bbs.archlinux.org/viewtopic.php?id=266967

try to set QTQPAPLATFORM to wayland/xcb to see what is working.

---

check also this one:

https://stackoverflow.com/questions/71143549/is-it-safe-to-force-qt-qpa-platform-xcb-on-linux-desktop

---

env QT_QPA_PLATFORM=wayland ./Skipper
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

I'm going to test with xcb today and will update the ticket correspondingly

---

If you're receiving this error this means that only xcb is available on your system and probably xcb is automatically used.

---

That is a logical deduction. However, that means that this is the issue that is causing VRAM leak, in my opinion. How can we work around this?
Wayland on NVIDIA is unusable, as reported by many users on Canonical Launchpad, including myself.

---

Unfortunately for now I'm not able to tell you what is causing this issue. It can be some inefficiency in the Qt library itself or some compatibility issue on your computer.

I'm not fully aware of how Nvidia drivers as the same as mutter-x11-frames working with Qt.

Isn't possible that this mutter-x11-frames process is shared across multiple processes for example?

Anyway, unfortunately, there is not much more that we can do. We're not working with Nvidia drivers directly, we're using Qt libraries for GUI access, and the model is generated/drawn on Canvas also via Qt.

I would like to fix it and help you more, but for now, I'm not sure how.

---

Thanks a lot for your replies.
I understand your position, obviously. So I will try to debug the issue more and will let you know of my findings.
I've arrived at the conclusion of Skipper causing the VRAM leak as the leak only occurs after I've launched Skipper and left it open for several hours.

---

Thanks for understanding. Unfortunately, it's a such complex and probably not directly related bug that we're not able to easily fix it :-(.

You can try to keep Skipper open without opened model vs opened, etc. To check what exactly is causing the error.

Also, you can try to close all models (projects) and keep Skipper open only on the welcome screen if VRAM consumption will be lowered.