New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVIDIA: Issues with OpenGL support #138

Open
Anti-Ultimate opened this Issue Jun 22, 2016 · 49 comments

Comments

Projects
None yet
@Anti-Ultimate

Anti-Ultimate commented Jun 22, 2016

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

This comment has been minimized.

Member

alexlarsson commented Jun 22, 2016

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

This comment has been minimized.

Member

alexlarsson commented Jun 22, 2016

See also #72

@Anti-Ultimate

This comment has been minimized.

Anti-Ultimate commented Jun 22, 2016

How would I add this to the json?

@alexlarsson

This comment has been minimized.

Member

alexlarsson commented Jun 22, 2016

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

This comment has been minimized.

Member

alexlarsson commented Jun 22, 2016

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

This comment has been minimized.

Anti-Ultimate commented Jun 22, 2016

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

This comment has been minimized.

Member

alexlarsson commented Jun 22, 2016

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

This comment has been minimized.

stuffandthings commented Jun 22, 2016

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

@hadess

This comment has been minimized.

Contributor

hadess commented Jun 24, 2016

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

This comment has been minimized.

Contributor

hadess commented Jun 24, 2016

@fishxz

This comment has been minimized.

fishxz commented Jun 24, 2016

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

This comment has been minimized.

Contributor

hadess commented Jun 24, 2016

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

This comment has been minimized.

fishxz commented Jun 24, 2016

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

This comment has been minimized.

Contributor

hadess commented Jun 24, 2016

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

@fishxz

This comment has been minimized.

fishxz commented Jun 24, 2016

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

@alexlarsson

This comment has been minimized.

Member

alexlarsson commented Jun 27, 2016

@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

This comment has been minimized.

Contributor

hadess commented Jun 27, 2016

@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

This comment has been minimized.

Member

alexlarsson commented Jun 27, 2016

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

This comment has been minimized.

Contributor

hadess commented Jun 27, 2016

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

This comment has been minimized.

Member

alexlarsson commented Jun 27, 2016

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.

@vinszent vinszent referenced this issue Aug 16, 2016

Closed

Flatpakization #157

@clopez

This comment has been minimized.

clopez commented Nov 4, 2016

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) :

@Anti-Ultimate

This comment has been minimized.

Anti-Ultimate commented Nov 23, 2016

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

This comment has been minimized.

Member

alexlarsson commented Nov 23, 2016

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

This comment has been minimized.

kwizart commented Dec 23, 2016

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

This comment has been minimized.

kwizart commented Dec 23, 2016

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

This comment has been minimized.

Member

alexlarsson commented Feb 6, 2017

@adityashah1212

This comment has been minimized.

adityashah1212 commented Feb 9, 2017

Hi,
It seems that the repo is pointing to wrong commitmeta file for nvidia GL libs. When I run
flatpak install gnome org.freedesktop.Platform.GL.nvidia-375-26

I get this

Installing: org.freedesktop.Platform.GL.nvidia-375-26/x86_64/1.4 from gnome

1 metadata, 0 content objects fetched; 313 B transferred in 3 seconds           
error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Error pulling from repo: Error opening file /home/aditya/.local/share/flatpak/system-cache/repo-ZD7FVY/1ca0fc4d5416e0a5e91cbabfbae5f9bb0e93e6e32ed4eb0426150d1168189e64.commitmeta: No such file or directory


It seems the repo is pointing to
/home/aditya/.local/share/flatpak/system-cache/repo-ZD7FVY/1ca0fc4d5416e0a5e91cbabfbae5f9bb0e93e6e32ed4eb0426150d1168189e64.commitmeta
instead of
/home/aditya/.local/share/flatpak/system-cache/repo-ZD7FVY/objects/1ca0fc4d5416e0a5e91cbabfbae5f9bb0e93e6e32ed4eb0426150d1168189e64.commitmeta

@adityashah1212

This comment has been minimized.

adityashah1212 commented Feb 15, 2017

I tried this with flatpak 0.8.3 on Arch Linux and it seems to work now. Though what I am not sure is didn't you guys decide not to redistribute NVIDIA binaries? I am confused now

@alexlarsson

This comment has been minimized.

Member

alexlarsson commented Feb 15, 2017

The binaries are not redistributed by us, they are downloaded from nvidia.

@adityashah1212

This comment has been minimized.

adityashah1212 commented Feb 15, 2017

Yeah true, but wouldn't it be easy to just copy the binaries from the host system, that way one doesnt have to keep a track of actually version of binaries installed on the system. Now we need keep updating the flatpak runtime everytime we update the drivers. Just keep a hash of these binary blobs on the system and compare them to the hashes of the binaries in flatpak runtime before launching the app, if they don't match then just copy the new ones.

@kwizart

This comment has been minimized.

kwizart commented Feb 15, 2017

It looks completely fuzzy concept to download any binaries from nvidia when the appropriate one are available on the "host system".
At least libglvnd would help to dlopen the (glvnd enabled) nvidia GL libraries without need of a ldconfig call (if that matters).

@fishxz

This comment has been minimized.

fishxz commented Feb 15, 2017

nvidia 378.13 is missing as GL extension for the freedesktop runtime.

@alexlarsson

This comment has been minimized.

Member

alexlarsson commented Feb 16, 2017

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

This comment has been minimized.

kwizart commented Feb 16, 2017

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

This comment has been minimized.

Member

alexlarsson commented Feb 21, 2017

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

This comment has been minimized.

adityashah1212 commented Feb 21, 2017

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

This comment has been minimized.

adityashah1212 commented Feb 22, 2017

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

@fenryxo

This comment has been minimized.

fenryxo commented Jun 2, 2017

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

This comment has been minimized.

achernetsov commented Jun 19, 2017

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

@fenryxo

This comment has been minimized.

fenryxo commented Jun 21, 2017

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

This comment has been minimized.

Contributor

valentindavid commented Jun 22, 2017

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

This comment has been minimized.

Contributor

valentindavid commented Jun 23, 2017

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

This comment has been minimized.

Member

alexlarsson commented Jun 28, 2017

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

This comment has been minimized.

RyanNerd commented Nov 29, 2017

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

This comment has been minimized.

Contributor

hadess commented Nov 29, 2017

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

This comment has been minimized.

Member

TingPing commented Aug 31, 2018

I believe this can be closed?

@fenryxo

This comment has been minimized.

fenryxo commented Aug 31, 2018

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

This comment has been minimized.

CWhyMedia commented Aug 31, 2018

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

This comment has been minimized.

Member

TingPing commented Aug 31, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment