I switched to Ubuntu Linux for the time being

First, I like Clear Linux a lot. It’s the swupd tool that made me leave Clear Linux. The tool is not yet mindful of the NVIDIA proprietary driver installation. So I watched a few updates on a newly installed Clear Linux. I witnessed swupd taking approximately 10 GB of disk space i.e. du -sh /var/lib/swupd from 120 MB before running the update. That seems awfully high, IMO.

Ubuntu 20.04.4 was released recently and thought to give that a try. Then, I began the journey getting the pieces together for enabling hardware acceleration using NVIDIA graphics. I finished the project today. Both the NVDEC-enabled and VDPAU-enabled VA-API drivers work well. They can co-exist with little effort.

1 Like

Looking at your scripts, I notice that VAAPI takes the most effort, how come?

There are two reasons:

The meson binary 0.53.2 on Ubuntu is less than 0.58.0. Upon closer inspection, the requirement is so able to understand the meson.add_devenv directive inside the meson.build file. The block is used by the developer, but not required to build and install the driver. So I remove the block from the meson.build file. I chose this path versus adding another script to build a recent meson binary.

The 2nd reason is a build dependency package libgstreamer-plugins-bad1.0-dev has opencv and additional sub-dependencies (i.e. 182 additional packages, > 500MB) which are not required to build the NVDEC-enabled VA-API driver.

The libgstreamer-plugins-bad1.0-dev package is used if already installed. Otherwise, I prefer to download the “deb” package instead and update the dependency list so as not to install 181 additional packages > 500MB. Afterwards, the modified libgstreamer-plugins-bad1.0-dev package is uninstalled.

In the end, the Ubuntu OS is not bloated with unnecessary packages simply to build the two VA-API drivers. That was the intent.

1 Like

Thanks for explaining in detail.

I know there are some VA-API issues with KdenLive, Openshot, Shotcut.

Maybe this can clear up things for more projects that rely on it.

Thanks for making the ffmpeg build repository! So simple to use, flawless istallation, where I’d failed with other attempts, and is delivering hardware accelerated video in Firefox on my T495.

I do agree that the massive “bundles” add unnecessary bloat.

I often search swupd for a package only to find it’s only available in an huge bundle that installs literal gigabytes of garbage, like the entire Xfce desktop where I needed a 10MB utility app.

Seems like a very strange way of doing things.

they are able to make bundles optional. you can skip the optional bundles with sudo swupd bundle-add --skip-optional and you can remove them without removing the parent packages. i just dont understand why many unnecessary bundles are listed as hard dependencies of others

1 Like

Wait, so not sure if I understand this correctly, but swupd simply is not compatible with the NVIDIA’s drivers? And when it tries to update it starts using an insane amount of space?
I ask this because I currently use CL on a old netbook from 2014 (Celeron N2808, 4GB RAM) and works like a charm, I was planning to use this on my main desktop in the future which has a GTX 1060, it means that CL doesn’t play nice with NVIDIA’s drivers then?

1 Like

I use Clear Fraction · GitHub and don’t need to build anything, just install it with one swupd command.

:rofl::joy::sweat_smile: Swupd don’t care and shouldn’t about drivers at all.

That’s what I think as well, but, you know…

That claim about swupd… IF I’m getting this right, he says that swupd basically doesn’t “like” the NVIDIA’s propietary drivers, “bugs” itself out, and starts using insane amounts of storage for updates, or something on those lines. I didn’t really understand if that’s the case 'cause it doesn’t make much sense to me, but if it’s true and it’s what I believe it is, then it’s indeed a problem…

EDIT: Unless he just means that swupd doesn’t recognises the NVIDIA’s drivers, which in that case is not that bad, one should update the drivers manually and that’s it.
In case that the swupd update is something unrelated to the NVIDIA’s stuff, then I don’t thing that insane amount of storage usage has happened to me yet, it’s just that I got confused since he used the word “so” and I connected the problems one with each other hehe.

EDIT2: Nope, just checked my swupd folder and it seems normal, the “manifest” folder is growing up with each update it would seem, but it weights around 250MB for me, so I don’t even bother.

It’s funny fake without any real arguments. Swupd doesn’t handle (or hate!!!11) nvidia drivers just 'cause don’t care about third-party software, man stateless for details.

swupd clean --all will remove the garbage. Probably, you can even move the swupd state to /tmp, update, clean, then move back.

Ah, yes, you are right about that, forgot that swupd only takes care of the bundles you install through it, but doesn’t actually touch anything that’s outside swupd since it’s considered “user stuff” if I’m not wrong, swupd only manages system stuff, and user things are strictly separated, bundles installed by swupd becomes a “system part” and such it’s managed by swupd. (In fact, I just realized that swupd means SoftwareUpdate lol).

Basically then, it means that the NVIDIA’s drivers are just considered user configuration and because of that, swupd doesn’t intervene at all with it. In other words… it just works fine then, and as expected.
OP probably tried to say that he was bothered that swupd didn’t handle NVIDIA’s updates, but considering that it’s user-managed, then the behavior is correct and not a flaw. I got confused by his connection to the “so I saw some updates” thinking it was related to NVIDIA’s stuff and thought for an instant that the NVIDIA’s drivers somehow made CL go nuts lol.

Also yeah, I have saw some commands in terminal to clean swupd stuff, but didn’t bother since it’s used for cache purpouses and it’s using only 250MB anyway, so I just will let it be unless I ran into space problems.

Thanks for the answer!

When installing the NVIDIA drivers the first time, it removes the Mesa related libGL, libEGL, and two more. Installing a bundle that has a dependency may reinstall the libraries that the NVIDIA installer removed. Ditto for updating the system via swupd i.e. new versions of Mesa GL libs. When this happens, the system then has two variants Mesa GL libs and NVIDIA GL libs. You may not notice it but after a while you begin to wonder why something isn’t right or slower.

@lebensterben put together various scripts for folks using NVIDIA graphics.

Regarding Clear Fraction, hardware video acceleration does not work for NVIDIA graphics. If choosing this path, what are missing are the NVDEC-backend and VDPAU-backend VA-API drivers.

The disk swupd disk usage /var/lib/swupd was captured while the system was updating. I’m not sure what makes it consume nearly 10GB while updating or if triggered somehow due to NVIDIA driver or sparse files. I have seen this happen 3 times.

1 Like

Oh my :slight_smile: I just received a notification that today is my 1 year anniversary joining Clear Linux. What a journey it’s been.

3 Likes

Hang on, hang on, stop right there. So, nvidia remove Clear Linux libraries and this is Clear Linux fault? Are you out of your mind?

are the part of open source Mesa project and removing them is stupid and abusive behavior. Go to nvidia forums and tell the Jacket to write solid drivers.

Finally, Linus Torvalds: Nvidia, Fuck You! - YouTube

1 Like

Yikes! I simply shared my experience :slight_smile: Yes, it can be frustrating.

Disclaimer: I like Clear Linux a lot and have it installed in another drive.

Tonight, I learned that Ubuntu has vendor neutral OpenGL dispatch libraries (i.e. deb packages libglvnd0, libgl1, libegl1, libgles2, and libglx0). That explains seeing both Mesa and NVIDIA libraries co-exist. For example, libEGL and libGLX.

$ ls -l libEGL.*   # libEGL vendor neutral dispatch library (libegl1 package)
lrwxrwxrwx 1 root root    11 Mar  7 18:21 libEGL.so -> libEGL.so.1
lrwxrwxrwx 1 root root    15 Mar  7 18:21 libEGL.so.1 -> libEGL.so.1.1.0
-rw-r--r-- 1 root root 80512 Mar  7 18:21 libEGL.so.1.1.0

$ ls libEGL*   # Mesa and NVIDIA EGL libraries co-exist
libEGL_mesa.so.0      libEGL_nvidia.so.0           libEGL.so    libEGL.so.1.1.0
libEGL_mesa.so.0.0.0  libEGL_nvidia.so.470.103.01  libEGL.so.1
$ ls -l libGLX.*   # libGLX vendor neutral dispatch library (libglx0 package)
lrwxrwxrwx 1 root root     11 Mar  7 18:21 libGLX.so -> libGLX.so.0
lrwxrwxrwx 1 root root     15 Mar  7 18:21 libGLX.so.0 -> libGLX.so.0.0.0
-rw-r--r-- 1 root root 141912 Mar  7 18:21 libGLX.so.0.0.0

$ ls libGLX*   # Mesa and NVIDIA GLX libraries co-exist
libGLX_indirect.so.0  libGLX_nvidia.so.0           libGLX.so.0
libGLX_mesa.so.0      libGLX_nvidia.so.470.103.01  libGLX.so.0.0.0
libGLX_mesa.so.0.0.0  libGLX.so

I installed the proprietary driver via Software & Updates > Additional Drivers.

1 Like

Ah, right, so there may be some issues when using the NVIDIA’s propietary stack after all…

I will keep this in mind for the future, I will likely try CL on my desktop someday and see if I run into significant issues across the way while using it, the NVIDIA installer removing stuff doesn’t seem pretty good, swupd will probably reinstall what NVIDIA’s driver removes and guess that replacing the NVIDIA’s stuff with (Mesa it’s called?) then that will probably call for trouble.
Hope some kind of fix for this can be done in the future, at least I now understand what you meant by swupd not being aware of NVIDIA’s stack, if swupd can be updated to get some kind of workaround… or simply detect NVIDIA’s propietary driver as system stuff… since it’s unlikely that NVIDIA will release a fix just for CL.

Thanks for sharing your experiencie and the clarification!

1 Like

Why should the clear Linux maintainers be bothered with accommodating arbitrary third party software that messes with the system?

Soon there will be another big player in the GPU market :

4 Likes

For the simple reason that without drivers, the GPU won’t work properly. Sure, there is Nouveau I think, but it has pretty dissapointing performance. Not viable at all.

This looks interesting, we will see when they get released and gets compared with NVIDIA’s and AMD’s stuff. Recently they managed to more or less close the gap with AMD in the CPU department, let’s see how they fare in the GPU market now since they didn’t do good with Intel HD Graphics.

1 Like
1 Like