Some days ago I wanted to perform some Blender experiments on my laptop. Before I had upgraded most of the installed Leap 15.3 packages installed. Afterwards I thought this was a good opportunity to bring my flatpak based installation of Blender up to date, too.

A flatpack installation of Blender had been necessary since I had changed the laptop’s OS to Opensuse Leap 15.3. Reason: Opensuse did and does not offer any current version of Blender in its official repositories for Leap 15.3 (which in itself is a shame). (I have not yet checked whether the situation has changed with Leap 15.4.)

Blender’s present version available for flatpack is 3.3.1. I had Blender version 3.1 installed. So, I upgraded to version 3.3.1. However, this upgrade step for Blender alone did not work. (In contrast to a snap upgrade).

The problem

The sequence of commands I used to perform the update was:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak update org.blender.Blender  
flatpak list

The second command brought Blender V3.3.1 to my disk. However, when I tried to start my new Blender with

flatpak run org.blender.Blender &

the system complained about a not working GLX and GL installation.

But, actually my KDE desktop was running on the laptop’s Nvidia card. The laptop has an Optimus configuration. I use Opensuse Prime to switch between the Intel i915 driver for the graphics card integrated in the processor and the Nvidia driver for the dedicated graphics card. And Nvidia was running definitively.

The cause of the failure and its solution

Flatpack requires the right interface for the Nvidia card AND the presently active GLX-environment to start OpenGL applications.

A “flatpack list” showed me that I had an “app” “nvidia-470-141-01” running.

Name                    Application ID                                   Version    Branch   Installation
Blender                 org.blender.Blender                              3.3.1      stable   system
Codecs                  org.blender.Blender.Codecs                                  stable   system
Freedesktop Platform    org.freedesktop.Platform                         21.08.16   21.08    system
Mesa                    org.freedesktop.Platform.GL.default              21.3.9     21.08    system
nvidia-470-141-01       org.freedesktop.Platform.GL.nvidia-470-141-01               1.4      system
Intel                   org.freedesktop.Platform.VAAPI.Intel                        21.08    system
ffmpeg-full             org.freedesktop.Platform.ffmpeg-full                        21.08    system
openh264                org.freedesktop.Platform.openh264                2.1.0      2.0      system

A quick view to the nvidia-settings and YaST showed me, however, that the drivers and other components installed on Leap 15.3 were of version “nvidia-470-141-03”.

Then I tried

mytux:~ # flatpak install flathub org.freedesktop.Platform.GL.nvidia-470-141
Looking for matches…
Similar refs found for ‘org.freedesktop.Platform.GL.nvidia-470-141’ in remote ‘flathub’ (system):

   1) runtime/org.freedesktop.Platform.GL.nvidia-470-94/x86_64/1.4
   2) runtime/org.freedesktop.Platform.GL.nvidia-470-141-03/x86_64/1.4
   3) runtime/org.freedesktop.Platform.GL.nvidia-470-141-10/x86_64/1.4
   4) runtime/org.freedesktop.Platform.GL.nvidia-470-74/x86_64/1.4
   5) runtime/org.freedesktop.Platform.GL.nvidia-430-14/x86_64/1.4
   6) runtime/org.freedesktop.Platform.GL.nvidia-390-141/x86_64/1.4

Which do you want to use (0 to abort)? [0-6]: 2

This command offered me a list to select the required subversion from. In my case option 2 was the appropriate one.

And indeed after the installation I could start my new Blender version again.

By the way: Flatpak allows for multiple versions to be installed at the same time. Like:

Name                 Application ID                                Version  Branch Installation
Blender              org.blender.Blender                           3.3.1    stable system
Codecs               org.blender.Blender.Codecs                             stable system
Freedesktop Platform org.freedesktop.Platform                      21.08.16 21.08  system
Mesa                 org.freedesktop.Platform.GL.default           21.3.9   21.08  system
nvidia-470-141-03    org.freedesktop.Platform.GL.nvidia-470-141-03          1.4    system
nvidia-470-141-10    org.freedesktop.Platform.GL.nvidia-470-141-10          1.4    system
Intel                org.freedesktop.Platform.VAAPI.Intel                   21.08  system
ffmpeg-full          org.freedesktop.Platform.ffmpeg-full                   21.08  system
openh264             org.freedesktop.Platform.openh264             2.1.0    2.0    system

Conclusion

Your flatpack installation must provide a version of the ‘org.freedesktop.Platform.GL.nvidia-xxx-nnn-mm’ packet which matches the present Nvidia driver installation on your Linux operative system.
Do not forget to upgrade flatpak packets for NVidia after having upgraded Nvidia drivers on your Linux OS!

Links

https://github.com/flathub/ org.blender.Blender/ issues/97
Replacing unstable Blender 2.82 on Leap 15.3 with flatpak or snap based Blender 3.1

The problem

First I started to copy with the help of KDE’s Dolphin. The transfer rates were really bad – something about 5 MB/s. Would have had to wait for hours.

Then I tried with just a standard cp-command. The rates rose to something like 20 MB/s to 25 MB/s. But this was not a reasonable transfer rate either.

A workaround

A search on the Internet then gave me the following two commands

mytux:~ # echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
mytux:~ # echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes

Note that setting values on these system parameters automatically sets the standard values of

mytux:~ # cat /proc/sys/vm/dirty_ratio 20 mytux:~ # cat /proc/sys/vm/dirty_background_ratio 10

to zero! And vice versa. You either have to use dirty_bytes and dirty_background_bytes OR the related ratio-parameters!

The effect of the above settings was remarkable: The total transfer rate (i.e. reading from one disk and writing to another; both on the same controller) rose to 130 MB/s. Still far away from theoretical rates. But something I could live with.
It would be worth to experiment more with the size of the parameters, but I was satisfied regarding my specific problem.

Conclusion

An efficient data transfer on Linux systems between two external USB-3 disks may require system parameter settings by the user.
I admit: The whole thing left me baffled. For discussions and hints please refer to the Internet. It seems that the whole performance reduction is worst for users who have a lot of RAM. And the problem exists since 2014. Unbelievable!

Linux-Blog – Dr. Mönchmeyer / anracon – Augsburg

Linux, LAMP, Python – praxisnaher Einsatz im Alltag – Ein Blog für Linux-Anwender

Tag Archives: Linux

Flatpak and Blender after system updates – update the flatpak Nvidia packet to match your drivers

The problem

The cause of the failure and its solution

Conclusion

Links

Opensuse Leap, dolphin and abysmal slow data transfer between two external USB 3 disks

The problem

A workaround

Conclusion

Links