Possible incompatibility between Freedesktop's Mesa libraries and Mesa libraries or kernel driver on the host #3673
Comments
|
@nwnk, whats your opinion here. Can we do better than just assuming whatever mesa version should work with whatever kernel driver version? For nvidia we do extract the kernel driver version and only use the exact matching userland driver. |
|
It would be interesting to have another test where you have he EL7 era userspace but newer kernel. New Mesa might well tickle some (at that point) less tested and buggy (but since fixed) codepaths in the older kernel. |
|
There probably is a minimum kernel version that a particular version+driver in Mesa would support, but it's likely both ancient and not especially well documented. (And wildly misleading for like RHEL, where the drm gets regular updates despite the "kernel" version being pinned.) Frankly the behavior described sounds like a bug in Mesa 20, I'm reasonably sure we did not intentionally raise the minimum kernel version for Intel drivers between 19 and 20, and even if we had RHEL7 would not have been a target we'd have dropped. |
|
Using a non-standard kernel on a daily basis is not an option for me, so I tried to run an another instance of EL7 with a newer kernel, just for testing purposes. I was unable to boot system with kernel-lt (4.4.227-1.el7.elrepo.x86_64), but fortunately it worked with kernel-ml (5.7.2-1.el7.elrepo.x86_64). However, the mentioned problem still persisted. Then I tried a fresh install of CentOS 7.8. I was able to install and run Widelands 20 (Freedesktop 19.08) under GNOME, so I returned to my RHEL 7 to see what is wrong with it. Thanks to GDB, I was able to locate the potential source of this issue: Full log: It is probably related to this bug in Mesa (Iris driver): Actually, we have plenty of issues related to the "iris" driver. This one occurs only on Intel Graphics with the "intel" driver (not "modesetting"). When I tried to run Widelands with Log: GDB output: It should be noted that I use the "intel" driver instead of "modesetting". This is mainly because I have to use the "TearFree" option, which isn't available for the general driver. While the current version of marco (MATE's window manager) has support for XPresent, EPEL7 provides only MATE 1.6, which was released in 2016. What is worse, the XPresent extension could work only with DRI3, and I have to use DRI2 because of other issues. So, even with experimental packages of MATE 1.18, it couldn't work, and they still have some issues with MATE applets. In the past, I've tried to use Compton, but besides it didn't fully solve the problem with tearing, it had very poor integration with MATE (Alt-Tab window previews, Workspace Switcher, shadows under window borders, etc.). Anyway, this is my X.Org configuration when it comes to the Intel GPU: To summarize, this issue is probably related to a Mesa bug, and it should be fixed in Freedesktop 19.08. |
|
Yes, this isn't flatpak issue so you can close this. |
|
Freedesktop issue: |
Since it occurs only with the |
|
Flatpak uses X server from host so eventual bug in xorg isn't flatpak issue to resolve. |
The DRI driver from the host works fine with the DDX driver and X.Org Server, so it's hard to blame the distribution about this issue. |
|
This may be bug in mesa, ddx, sdl, xorg or whatever but neither scenario suggest it's a bug in flatpak itself which is my point. This is wrong place for this issue. Youe even said it yoursef so I don't understand why you argue when I just agreed with you:
Mesa on host is irrelevant and kernel dev ruled out kernel issue. |
At this point, we don't know where exactly the source of this error is located. It could be caused by many components, including kernel, Mesa, X.Org, glibc, libstdc++, LLVM, etc. |
This is quite interesting, because Lionel Landwerlin (member of Mesa, DRM and X.Org) stated that Iris requires a kernel 4.16 or higher. In FAQ we have:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/283#qa Someone else suggested that it may require even a 5.x+ kernel. |
|
@scx that seems highly problematic. Sounds like Iris should be somehow be opt-in if it's breaking compatibility expectations to this extent. |
|
Okay, so current plan is to --prefer-iris=false in Mesa at least for 19.08 and this is going to be released soon. If the intent is to support CentOS 7, then the i965->iris migration is really a no-go until there are host-side fixes. This is a clear regression during runtime support cycle and is clearly not okay. We're discussing how to handle 20.08 which is about to be released. |
IssuesThere are several issues related to the I. For most distributions, it doesn't work when I've already reported this problem in EL and Fedora:
I also created a COPR repo with patched However, I doubt that Ubuntu LTS or RHEL will get patches anytime soon. It should be noted that this configuration is quite popular on EL7, due to a lack of other options to prevent screen tearing outside GNOME3. Maybe we should consider performing additional checks to verify if See: II. The iris driver cashes on Linux < 4.16 (at least without backports related to Some time ago Mesa provided the code that should handle such a situation and fallback to software rendering in case of failure. It was introduced in Mesa 20.1.0 and then backported to Mesa 20.0.6. However, this code is simply broken. Instead of fallbacking to software rendering, it just crashes. Even the latest release (Mesa 20.1.3) is affected. However, it may be fixed upstream in the future release. Anyway, at this moment, both Mesa 20.0.5 from It should be noted that Mesa is trying to fallback to See:
III. Some time ago Mesa released the distro packaging guidelines for Intel/Iris. They literally recommend "upgrading to xserver 1.20.7 and libepoxy 1.5.4 before shipping iris". They also explicitly recommend to not use There was a discussion about this in Ubuntu. There are experimental Mesa 20 packages for Ubuntu 18.04 LTS in Commit date: 2020-06-17 I think we should do the same if we really care about older distributions. See:
SolutionsThere are a few possible solutions for these problems. I. Do not ship the See: II. Build Mesa with the This is probably what we are gonna to do in short term. This will require some fixes for Tiger Lake, e.g. upgrading Mesa to a version that will appear in the future to make proper fallback in case of older kernel. However, we should allow users to choose See:
III. Perform additional check to select the best possible driver. It could look like this:
As for software rendering: try Anyway, it could be done in Mesa, Freedesktop or in Flatpak itself. Please keep in mind that
What could such a test look like? It could be a pretty simple windowless program (there are several ways to create a dummy window, e.g. I know, it is a dirty hack, but if you really want to support a whole range of distributions, from 5 years old to bleeding-edge distros, you can either test them all or provide some mechanisms that will do it for you. The current approach just doesn't work well. See: |
Is |
|
It should work if not suppressed by app. I just checked and there are no runtime-level suppressions. |
|
There is now newer GL extension published for 19.08 which will prefer i965 on hardware supported by both i965 and iris. If issues still persist, please report exact GPU used so we can determine if it's supposed to be supported by i965 at all. |
|
20.08 will also possibly be released with --prefer-iris=false depending on whether distro support for iris has improved before it's out. |
|
This has apparently resulted in even more breakage now. Apparently if you have Iris on host but i915 in guest, there may be crashes. So this preferring Iris to make things work on RHEL may be resulting in more and more crashes on newer distros. Also if you should not combine the two, simple configuration switch most definitely isn't enough as a solution for this. |
As you know, for NVIDIA hardware flatpak makes sure that it uses exactly the same driver version as it is on the host. So, for example, if you have NVIDIA 440.64 on the host, it will install the 440.64 driver as a runtime extension. This is because NVIDIA driver requires exactly the same version of the userspace libraries and the kernel driver.
However, when it comes to Mesa drivers, Freedesktop runtime tries to provide a relatively fresh version of libraries, without looking at what is on the host.
For example, Freedesktop 18.08 uses Mesa 19.1.7 and Freedesktop 19.08 uses Mesa 20.0.5. And your operating system of course may use a completely different version, e.g. Mesa 18.3.4. The same applies to the kernel driver. In mid 2019, I was assured that this should never be an issue. However, we strongly believe that this may be a source of potential problems. I suspect that Mesa 20.0.5 from the Freedesktop 19.08 runtime may be somehow incompatible with old Mesa libraries or kernel driver on host, at least when it comes to OpenGL 4.6 support.
Actually, I hit this issue with Widelands on RHEL 7 with an Intel GPU (HD Graphics 630). After about 1 minute (61 seconds), the application terminates itself without any warning message.
This problem does not occur when:
More details:
widelands/widelands#3937
The text was updated successfully, but these errors were encountered: