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

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


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!


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

Blender – even on old laptops a graphics card increases rendering performance

My present experiments with Blender on my old laptop take considerable time to render- especially animations. So, I got interested in whether rendering on the laptop’s old Nvidia card, a GT 645M, would make a difference in comparison to rendering on the available 8 hyperthreaded cores of the CPU. The laptop’s CPU is an old one, too, namely an i7-3632QM. The laptop’s operative system is Opensuse Leap 15.3. The system uses Optimus technology. To switch between the Nvidia card and the Intel graphics I invoke Suse’s Prime Select application on KDE.

I got a factor of 2 up to 5.2 faster rendering on the GPU in comparison to the CPU. The difference depends on multiple factors. The number of CPU cores used is an important one.

How to activate GPU rendering in Blender?

Basically three things are required: (1) A working recent Nvidia driver (with compute components) for your graphics card. (2) A certain setting in Blender’s preferences. (3) A setting for the Cycles renderer.

Regarding the CUDA toolkit I quote from Blender’s documentation

Normally users do not need to install the CUDA toolkit as Blender comes with precompiled kernels.

With respect to required Blender settings one has to choose a CUDA capable device via the menu point “Preferences >> System”:

You may also select both the GPU and the CPU. Then rendering will be done both on the GPU and the CPU. My graphics card unfortunately only understands a low level of CUDA instructions. The Nvidia driver I used is of version 470.103.01, installed via Opensuse’s Nvidia community repository:

In addition, you must set an option for the Cycles renderer:

With all these settings I got a factor of 2 up to > 6 faster rendering on the GPU in comparison to a CPU with multiple cores.

The difference in performance, of course, depends on

  • the number of threads used on the CPU with 8 (hyperthreaded) cores available to the Linux OS
  • tiling – more precisely the “tile size” – in case of the GPU and the CPU

All other render options with the exception of “Fast G” were kept constant during the experiments.

Scene Setup

To give the Blender’s Cylces renderer something to do I set up a scene with the following elements:

  • a mountain-like landscape (via the A.N.T Landscape Add-On) with a sub-dividion of 256 to 128 – plus subdivision modifier (Catmull-Clark, render level 2, limit surface quality 3) – plus simple procedural texture with some noise and bumps
  • a plane with an “ocean” modifier (no repetition, waves + noisy bump texture for the normal to simulate waves)
  • a world with a sky texture of the Nishita type ( blue sky by much oxygen, some dust and a sun just above the horizon)

The scene looked like

The central red rectangle marks the camera perspective and the area to be rendered. With 80 samples and a resolution of 1200×600 we get:

The hardest part for the renderer is the reflection on the water (Ocean with wave and texture). Also the “landscape” requires some time. The Nishita world (i.e. the sky with the sun), however, is rendered pretty fast.

Required time for rendering on multiple CPU cores

I used 40 samples to render – no denoising, progressive multi-jitter, 0 minimum bounces.
Other settings can be found here:

The number of threads, the tile size and the use of the Fast CI approximation were varied.
The resolution was chosen to be 1200×600 px.

All data below were measured on a flatpak installation of Blender 3.1.2 on Opensuse Leap 15.3.

tile size threads Fast GI time
64 2 no 82.24
128 2 no 81.13
256 2 no 81.01
32 4 no 45.63
64 4 no 43.73
128 4 no 43.47
256 4 no 43.21
512 4 no 44.06
128 8 no 31.25
256 8 no 31.04
256 8 yes 26.52
512 8 no 31.22

A tile size of 256×256 seems to provide an optimum regarding rendering performance. In my experience this depends heavily on the scene and the chosen image resolution.

“Fast GI” gives you a slight, but noticeable improvement. The differences in the rendered picture could only be seen in relatively tiny details of my special test case. It may be different for other scenes and illumination.

Note: With 8 CPU cores activated my laptop was stressed regarding CPU temperature: It went up to 81° Celsius.

Required time for rendering on the mobile GPU

Below are the time consumption data for rendering on the mobile Nvidia GPU 645M:

tile size Fast GI time
64 no 18.3
128 no 16.47
256 no 15.56
512 no 15.41
1024 no 15.39
1200 no 15.21
1200 yes 12.80

Bigger tile sizes improve the GPU rendering performance! This may be different for rendering on a CPU, especially for small scenes. There you have to find an optimum for the tile size. Again, we see an effect of Fast GI.

Note: The temperature of the mobile graphics card never rose above 58° Celsius. I measured this whilst rendering a much bigger image of 4800×2400 px. I therefore think that the temperature stress Blender rendering exerts on the GPU is relatively smaller in comparison to the heat stress on a CPU.

Required time for rendering both on the CUDA capable mobile GPU and the CPU

As the CPU is CUDA capable one can activate CUDA based rendering on the CPU in addition to the GPU in the “preferences” settings. With 4 CPU cores this brings you down to around 11 secs, with 8 cores down to 10 secs.

tile size threads Fast GI time
64 4 no 11.01
128 8 no 10.08


Even on an old laptop with Optimus technology it is worthwhile to use a CUDA capable Nvidia graphics card for Cycles based rendering in Blender experiments. The rise in temperature was relatively low in my case. The gain in performance may range from a factor 2 to 5 depending on how many CPU cores you can invoke without overheating your laptop.

Ceterum censeo: The worst living fascist and war criminal today, who must be isolated, denazified and imprisoned, is the Putler.


Blender – complexity inside spherical and concave cylindrical mirrors – VI – first experiment with a half-sphere

I had some fun yesterday with a first experiment I did in Blender with a fully reflective concave half-sphere. This is a further step in this series about the construction of some special reflecting surfaces in Blender for virtual optical experiments.

Blender – complexity inside spherical and concave cylindrical mirrors – I – some impressions
Blender – complexity inside spherical and concave cylindrical mirrors – II – a step towards the S-curve
Blender – complexity inside spherical and concave cylindrical mirrors – III – a second step towards the S-curve
Blender – complexity inside spherical and concave cylindrical mirrors – IV – reflective images of a Blender variant of Mr Kapoor’s S-curve
Blender – complexity inside spherical and concave cylindrical mirrors – V – a video of S-curve reflections

One of the most spectacular effect in a NASA movie about a real half-sphere (see the first post of this series) is the virtual finger that seems to come out of the sphere when the physicist moved his own finger towards the center. I thought this might be a nice Blender experiment on a free day with bad weather outside. The finger had to be replaced by a small lengthy NURBS based cylinder in Blender. The main objective was to find some cylinder-like figure coming out of a half-sphere built in Blender. But as I was playing around I shot some additional images of the half-sphere from different positions to verify the appearance of ring-like patterns at the outer edges of the half-sphere, too.

Building the half-sphere

I created the half-sphere for this experiment as a mesh with 64×64 faces, which I cut into two parts afterwards. I added the “subdivision modifier” at the end to get a smooth surface. But, probably, you could also have started with a high resolution Nurb sphere. I have not yet tested which methods results in faster rendering. Reflectivity was achieved by setting the material to be fully metallic without any roughness. The base color of the material was set to pure white.

Scene setting

The geometrical setup I choose for this post is the following:

The image above reflects my first camera perspective. What we want to see from this perspective is a mirrored pattern of the cylinder-like (Nurbs) object – appearing in front of the background mirror-surface and opposite of the real object. Such an appearance would of course just be an illusion, but is the result of simple optics. The light rays reaching the camera stem of course from the inner surface of the half sphere. Note that the cylinder is placed on the central symmetry axis of the half-sphere. We later give it a metallic red surface. Note also that the Nurb’s cylinder is an open figure at both ends and not a solid one. So, we will get some tiny reflection patterns on the inside of the cylinders, too.

The small sphere is placed off the symmetry axis to show a different reflection effect. I gave it a green color. A few light sources have been placed at various positions.

As a background I chose again a kind of dusk with a “sun” just above the horizon. This gives us a distinct contrast rich orange-yellow horizontal stripe, which will later help us to identify multiple reflections inside the half-sphere. Remember that we should get an inner part of the half-sphere showing a sharp ring-like edge marking the border-line where the first double reflection occurs. Other ring-like shapes, which a camera positioned on the central symmetry axis and looking towards the half-sphere’s center should “see”, appear in the outer areas of the half-sphere. The distance between these ring like structures should systematically become smaller.

At the bottom of the half-sphere I have also added an extended reflective plane. This helps us later to watch different reflection patterns coming from two different angles towards the camera. The half sphere is placed a bit above the ground level, i.e. above the plane. This leads to incomplete rings resulting from multiple reflections of the horizon line.

Result for a camera position above and sideways of the cylinder close to the half-sphere

From the perspective shown above we get the following rendered image:

So, indeed we see an artificial cylindrical “figure” coming out of the inner part of the half sphere opposite the real red cylinder. In addition, the sharply edged inner area of the half-sphere is clearly visible – here a bit distorted as our camera is placed off the central axis. At the top of the half-sphere the effects of multiple reflections stemming from the horizontal line can clearly be seen. The green sphere leads to a reflection pattern which already appeared at the concave side of the S-curve (see the previous posts).

Changed camera perspective high above the central symmetry axis

In a second experiment I placed the camera above the central axis at quite a distance away from the half-sphere and relatively high in z-direction. A yellow and somewhat extended light source has been added to get one more reflection pattern.

We clearly see the expected ring like structures due to multiple reflections at the upper edge of the half sphere. It seems that the basic optics works well in Blender. Something which is unrealistic in the images I create is the lossless reflection; in reality reflective patterns would get a bit weaker in intensity with every reflection.

Camera perspective from a position on the central symmetry axis

If we put the camera down to the central axis, the green sphere to the same height and switch off the yellow light sources we get the following result:

A bit off the symmetry axis

Let us eventually get the camera a bit offside the symmetry axis and move the green sphere into a position closer to, but not onto the main axis. Then we get the following picture:


As we expected after our experience with the S-curve we get interesting reflection patterns from a mirroring half-sphere. We showed that Blender reproduces a pattern where a figure seems to grow out of the half-sphere when we move an elongated body into the sphere along the main symmetry axis. We also saw a strong dependency of the reflection patterns on the position of the camera. So, all is well prepared for more experiments.
And, again, a basic lesson is: Some things appear bigger than they are, because we look at a bloated image instead of the real thing. If only things were that easy in politics, too.

Ceterum censeo: The worst living fascist and war criminal today, who must be isolated, denazified and imprisoned, is the Putler.