NVIDIA: Issues with OpenGL support

[Anti-Ultimate]

Trying to run an application built with OpenGL support using Gnome SDK and 3.20 runtime on a NVIDIA GTX 970.

Driver version: 367.27
Using Arch Linux

from json:
"finish-args": [ "--share=ipc", "--socket=x11", "--socket=pulseaudio", "--socket=wayland", "--share=network", "--device=dri", "--filesystem=home:rw" ],

Using this gives me:
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

This does not happen on my laptop using an Intel GPU.

[alexlarsson]

Yeah, you need to use the nvidia driver opengl extension. I wrote some about that before:
https://blogs.gnome.org/alexl/2015/09/23/playing-games-with-runtime-extensions/

But we need to update the scripts, and make this easier to use. Unfortunately we can't actually redistribute the nvidia drivers, so it will never be super easy.

[alexlarsson]

See also #72

[Anti-Ultimate]

How would I add this to the json?

[alexlarsson]

If you're interested in this and have a nvidia machine I'd love it if you could help out.
We need to at least update the script to the latest version of the driver, but it would also be nice if the entire thing could be made buildable with flatpak-builder, including the download. Then the extraction and stuff is properly sandboxed, etc.

[alexlarsson]

No need to modify the app. As long as you have the right gl extension installed matching the runtime the app uses then it will automatically be used.

[Anti-Ultimate]

And there's no way you could just skip all of that and use the native driver?

Don't get me wrong, it's a good idea, but is this going to work when e.g. new hardware arrives?

[alexlarsson]

In general you can't use the native driver because it links to dependencies on the host which can easily conflict with the ones in the runtime. Also, the app can't actually even see the host /usr/lib.

However, in the specific case of the nvidia driver it has a pretty good story wrt dependency issues, so one alternative is to write a script that takes the native gl driver and makes a GL runtime extension from it.

[stuffandthings]

My second desktop has got a GTX 970, I can help out. I'll hit you up after work today

[hadess]

There's a few problems with making a json file:

• flatpak-builder doesn't know how to make runtime extensions, as seen when I made the gst-libav extension in flatpak-fusion
• flatpak-builder doesn't know how to create empty source directories for Makefiles, etc. to be downloaded into (which would be useful for flatpak-games)
• flatpak-builder doesn't know how to download "file" sources (as seen in the retroarch json in flatpak-fusion)

[hadess]

The current horror:
https://paste.fedoraproject.org/384000/50837146

[fishxz]

whos job is it to build the nvidia gl extenstion? im really confused about this.

i tried the extension stuff a few month ago and a simple driver update has broken the extension. so how this can even work this way?

[hadess]

whos job is it to build the nvidia gl extenstion? im really confused about this.

Right now, the end user because we can't ship it.

i tried the extension stuff a few month ago and a simple driver update has broken the extension. so
how this can even work this way?

I have no idea what that means.

[fishxz]

I have no idea what that means.

it simply means the extensions stopped working after a driver update.

so the extension has to be build for every nvidia version and has to match it?

[hadess]

What does "stopped working" means? That it complained that the driver didn't match the libGL shipped? That the extension failed to build?

[fishxz]

if i remember right, it was a mix of both.

[alexlarsson]

@hadess Does using "org.freedesktop.Platform.GL.nvidia" really work? The GL extension doesn't do "subdirectories=true", so we should only be able to have one GL extension (called "org.freedesktop.Platform.GL".

Also, I'm thinking of making it possible to create extensions by just having a named directory. Say "~/.local/share/flatpak/extension/org.freedesktop.Platform.GL/x86_64/1.4". This would make it easy to do things like copying the host GL drivers, or installing themes for a particular runtime.

[hadess]

@hadess Does using "org.freedesktop.Platform.GL.nvidia" really work? The GL extension doesn't do "subdirectories=true", so we should only be able to have one GL extension (called "org.freedesktop.Platform.GL".

I didn't actually test this. I guess I need to fix this.

Also, I'm thinking of making it possible to create extensions by just having a named directory. Say "~/.local/share/flatpak/extension/org.freedesktop.Platform.GL/x86_64/1.4". This would make it easy to do things like copying the host GL drivers, or installing themes for a particular runtime.

That'd be useful, but I'd rather have support in flatpak-builder to fix those issues I mentioned above.

[alexlarsson]

What exactly do you mean by: "flatpak-builder doesn't know how to create empty source directories for Makefiles, etc. to be downloaded into (which would be useful for flatpak-games)"

Can't you use "dest": "subdir"? Which will create a subdirectory and extract/download that source there?

[hadess]

What exactly do you mean by: "flatpak-builder doesn't know how to create empty source directories for Makefiles, etc. to be downloaded into (which would be useful for flatpak-games)"

I don't have any archives to unpack that flatpak-builder would know how to unpack, so I'd want to do have a directory created, and unpack stuff "by hand".

Can't you use "dest": "subdir"? Which will create a subdirectory and extract/download that source there?

It might, do you have an example using this?

[alexlarsson]

I can't think of one offhand, but something like:

    {
        "type": "file",
        "path": "foo-Makefile",
        "dest-filename": "Makefile"
        "dest": "foo"
    }

Would create a directory "foo" in the toplevel dir and put the "Makefile" file in that.
Similar for an archive type it would extract the archive in that directory.

[clopez]

Why do you say you can't redistribute the NVIDIA drivers?

The license of the Linux/FreeBSD NVIDIA drivers clearly states that this is allowed.

From http://www.nvidia.com/content/DriverDownload-March2009/licence.php?lang=us:

2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files).

Also, Debian distributes this drivers on the non-free repository (they don't simply distribute a script that fetches the drivers, but the drives themselves repackaged on a .deb) :

• https://packages.debian.org/jessie/libgl1-nvidia-glx
• https://packages.debian.org/jessie/amd64/libgl1-nvidia-glx/filelist
• http://metadata.ftp-master.debian.org/changelogs/non-free/n/nvidia-graphics-drivers/stable_copyright (see the e-mail exchange copied at the bottom of this file that clarifies better if redistribution is allowed or not)

[Anti-Ultimate]

Months later, nothing has changed. You can redistribute the NVIDIA driver just fine, as said above it's perfectly legal. It says the same thing in different languages even.

I really don't understand why you are excluding every single NVIDIA user that wants to use Flatpak.

But I can say that as long as NVIDIA drivers don't work with Flatpak by default, it's going nowhere.

[alexlarsson]

We want to make the nvidia driver experience better, and some of the work we're doing will help. But sometimes things take slower than you want...

[kwizart]

I don't understand why you would want to redistribute the nvidia driver at all, (nor any libGL libs).

It should be part of the base system . If you start to redistribute theses, you will need to redistribute the matching libGL version than the nvidia kernel module version. So it means you will need to redistribute all possible nvidia libGL version.(past and future)
Of course this is totally broken by design.

[kwizart]

To me a "runtime" could eventually bundle libglvnd (that will provide libGL.so but dlopen the appropriate libGLX backend (either Mesa or NVIDIA , etc). But that's just move the problem, something (libGL.so, or libGLX, and others) has to be taken from the host.

[alexlarsson]

Initial work on this happening: https://lists.freedesktop.org/archives/xdg-app/2017-February/000534.html

[alexlarsson]

Yes, one could use the host drivers, but that requires specific knowledge about how they are installed on your particular distro/installation, which is not something flatpak itself can do. However, we do support a "host" opengl driver which a distro could use to package the driver for flatpak.

[kwizart]

ldconfig -p |grep libGLX_nvidia.so.0
libGLX_nvidia.so.0 (libc6,x86-64) => /usr/lib64/nvidia/libGLX_nvidia.so.0
libGLX_nvidia.so.0 (libc6) => /usr/lib/nvidia/libGLX_nvidia.so.0

So this show both arches on my system (1), nothing to "learn" about, just ask the right tool.

(1). and the RPM Fusion packages will move them from _libdir/nvidia to _libdir by the time glvnd will be the default, so it's very welcomed not to hardcode anything in this area.

[alexlarsson]

Its possible to write scripts that would get things mostly right yes, but it will always run into issues like things changing in different nvidia versions, glvnd being used on the system or not. I don't think its possible to do this well enough in a generic way that we can't test on all users (and all later versions). So, the alternatives as i see it is that we work on an exact well known source (the nvidia upstream) which we can test, or we make it possible for a distro to put the host driver in the right place. Flatpak does both.

If you're interested in writing a sample script for the later that would be nice. Just put the right libraries in
/var/lib/flatpak/extension/org.freedesktop.Platform.GL.host/x86_64/1.4. Look at the current nvidia extension for the expected layout.

[adityashah1212]

I will try this, though I am not sure whether I would need only mesa/nvidia libs in case of libglvnd based systems or both with libglvnd to be copied

[adityashah1212]

hostglextract.zip
Guys can you give this a try and see if it is extracting all the files from the system. On mine all the install files are being extracted, but there are some files missing from my system itself, also for now this thing will only work outside sandbox... don't try to use it with a sandbox

[jiri-janousek]

Hello guys. An user of my app has nvidia driver 375.66, which is not listed in flatpak remote-ls gnome | grep nvidia. I hope it will be packaged soon. Meanwhile, is there any way an app inside flatpak sandbox can detect that there is no matching org.freedesktop.Platform.GL.nvidia extension? I would like to provide users with a helpful message instead of crashing with "The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program". Thanks.

[achernetsov]

fenryxo, solved similar issue (with nvidia 375.66 version) by updating drivers to 381.22 (https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa) then reinstalling application in flatpak

[jiri-janousek]

It still doesn't solve this:

Meanwhile, is there any way an app inside flatpak sandbox can detect that there is no matching org.freedesktop.Platform.GL.nvidia extension? I would like to provide users with a helpful message instead of crashing with "The program 'WebKitWebProcess' received an X Window System error. This probably reflects a bug in the program".

For now, I use --filesystem=/sys/module/nvidia:ro and check whether there is the corresponding /usr/lib/GL/nvidia-XXX directory, but it feels hacky.

[valentindavid]

I am getting the same problem unless I put manually /usr/lib/GL/nvidia-xxx into the LD_LIBRARY_PATH. I wonder why org.freedesktop.Platform.GL.nvidia does not put its directories into the ldconfig cache.

[valentindavid]

Oops. I have just figured out that LD_LIBRARY_PATH was initialized by flatpak to contain /usr/lib/GL/nvidia-xxx and I overwrote it. I was not expecting Flatpak would used that variable.

[alexlarsson]

We have to use LD_LIBRARY_PATH. the ld.so.cache is in the runtime, so it is fixed and cannot be different at runtime or between different apps.

If you need to use LD_LIBRARY_PATH in an app you need to extend it, not replace it.

[RyanNerd]

What a mess ==> the tail (game devs) have been wagging the dog (Nvidia) for years now.
I love flatpak (especially now that Linux Mint 18.3 supports it out of the box).
However, I have the Nvidia 387.34 driver installed and I installed Godot but upon launching I get this log vomit from flatpak:

flatpak run --branch=stable --arch=x86_64 --command=/app/bin/godot --file-forwarding org.godotengine.Godot
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  37
  Current serial number in output stream:  38

Any workarounds for this issue? Adding the --filesystem=/sys/module/nvidia:ro switch didn't help.

[hadess]

What a mess ==> the tail (game devs) have been wagging the dog (Nvidia) for years now.

We're really not interested in this sort of comments.

[TingPing]

I believe this can be closed?

[jiri-janousek]

What does happen when Nvidia Flatpak driver is not installed? Does it still crash with libGL error: failed to load driver: swrast or is software rasterizer used as a fallback?

[CWhyMedia]

I was able to launch Signal, not sure if it had software fallback. But Gravit Designer just gave a black rectangle, and Gnome MPV crashed, and both mentioned that libGL error. Thanks to TingPing I've now ran "flatpak update", and they both run fine.

[TingPing]

Does it still crash with libGL error: failed to load driver: swrast or is software rasterizer used as a fallback?

Sadly not. I have reported this issue here where it belongs though: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/350

[gigglylo]

any news about this issue?

[yhojann-cl]

Any update for this? have same problem using Steam in Flatpack with War Robots game and Nvidia 1060 with 510 driver from ubuntu lts 20.04.