Opensuse Leap 15.5 – installation of CUDA 12.3 for Machine Learning

Working with Machine Learning and Deep Neural Networks not only requires GPU drivers, but in case of Nvidia GPUs also the installation of CUDA and cuDNN. This process is always a bit tricky as additional environment variables have to be set for IPython-based Jupyterlab or classic Jupyter Notebook. On an Opensuse system one must in addition take care of the right settings in /etc/alternatives.

I have described the necessary steps in a post at ““.

I hope this helps people who want to use Leap 15.5 for Machine Learning with Nvidia GPUs, Keras/Tensorflow 2 and Jupyterlab.

Important addendum 01/27/2024:
Although the combination of CUDA 12.3, cuDNN 8.9.7, Tensorflow 2.15 and Nvidia drivers 545.29.06 works regarding AI-models, there is another major problem:
Nvidia’s driver 545.29.06 is buggy – at least for Leap 15.5, KDE/Plasma with multiple screens. The bug affects Suspend-to-RAM. Suspend-to-RAM seems to work in the suspend phase, and the system also comes up afterward in a seemingly proper state of your KDE/Plasma interface (on your screens).

However, the problems begin when you want to change to another virtual screen via Ctrl-Alt-Fx. You wait and wait and wait … The same for changing the run-level or systemd target state or when you want to shut the system down. This makes Suspend-to-RAM with driver 545.29.06 impossible to use.

If you have a working older Nvidia driver (e.g. a stable 535 version) do not change to 545.29.06. Unfortunately, it is a mess on a multiscreen Leap 15.5 system to return to an older driver version. The Nvidia community repository does not offer you a choice. (Why by the way ????). Downloading an older proprietary driver from Nvidia and trying to install it afterward on a console terminal (after having stopped X11 or Wayland) did not work in my case – the screens displaying the terminal changed their resolution and froze afterward. So, you may have to completely uninstall the present driver 545 completely, go back to standard VGA and then try to install an older driver via Nvidias install mechanism. As I said: It is a mess …


Combining Jupyterlab, QtAgg, Matplotlib and PyQt

For a variety of reasons I have recently started to study options to write PyQt applications which are directly started from a Python3 notebook in Jupyterlab and are displayed on the Linux desktop.

Without blocking further code execution in other notebook cells and without compromising interactivity both of the notebook and the Qt windows.

Due to the support of QtAgg you do not need any blocking “app.exec_()” statements. You just construct your PyQt windows (with Qt-widgets and integrated Matplotlib figures) and afterward show them on your Linux desktop.

In addition it is rather easy to move activities, objects, methods to background threads controlled by QThread-objects. Worker objects in such threads can communicate with Qt windows and widgets in the foreground via signals, which end up in a thread-safe and serialized way in the Qt event-loop in the main thread. From there they are picked up and handled by callbacks.

I found this a fascinating way on a Linux system with a KDE desktop to use Python in Jupyterlab to create full-fledged Qt-applications and run them under the control of Jupyterlab.

People who are interested find more information in the sister-blog

See the posts

Using PyQt with QtAgg in Jupyterlab – I – a first simple example
Using PyQt with QtAgg in Jupyterlab – II – excursion on threads, signals and events
Using PyQt with QtAgg in Jupyterlab – III – a simple pattern for background threads
Using PyQt with QtAgg in Jupyterlab – IV – simple PyQt and MPL application with background worker and receiver threads