FS#53284 - mesa-17.0.1-2 introduces extreme unresponsiveness on nvidia system with wayland

Attached to Project: Arch Linux
Opened by Matt Sturgeon (mattsturgeon) - Monday, 13 March 2017, 01:13 GMT
Last edited by Laurent Carlier (lordheavy) - Friday, 13 September 2019, 15:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Laurent Carlier (lordheavy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 48
Private No

Details

Description:

I have just tried updating mesa (and lib32-mesa) from 17.0.1-1 to -2 and experienced some strange
behaviour including extremely unresponsive mouse and keyboard input, high CPU usage, multiple monitor
layout changes, conky not rendering only while using gdm or gnome wayland (gnome xorg was unaffected)
with the latest mesa version.

Downgrading to mesa 17.0.1-1 fixed all issues. At first I thought this was related to nvidia-libgl being
merged into nvidia-utils, but that is not the case as I can reproduce this with both versions of nvidia.
I have not tested if nouveau is affected.

Hardware:
* Chipset z170
* CPU i5-6600k 4.5GHz
* RAM 16GB DDR4 2400MHz
* GPU MSI GTX 970

Software:
* mesa 17.0.1-2
* gdm 3.22.3-1
* gnome-shell 3.22.3-1
* nvidia-dkms 378.13-3
* nvidia-utils 378.13-5
* libglvnd 0.2.999+g4ba53457-1


Steps to reproduce:

* Install gdm and mesa 17.0.1.2 on a nvidia machine with the proprietary drivers; observe poor performance and other strange behaviour.
* Downgrade to mesa 17.0.1-1; observe normal performance and behaviour
* xorg and tty sessions are not affected. AFAICT only wayland sessions (including gdm) are affected.
This task depends upon

Closed by  Laurent Carlier (lordheavy)
Friday, 13 September 2019, 15:06 GMT
Reason for closing:  Upstream
Additional comments about closing:  GNOME on Wayland works relatively well now with the NVIDIA driver, with the exception of XWayland apps. This is unrelated to the original bug report and has been documented in the wiki.
Comment by Gerhard Bogner (slashME) - Wednesday, 15 March 2017, 10:13 GMT
This affects me too - though i wasn't aware that gnome shell currently uses wayland with the binary nvidia drivers (since gnome 3.24 wasn't released yet). I can confirm however that setting EnableWayland to false in /etc/gdm/custom.conf works around the issue.

In addition gdm sometimes starts to act normally after a couple of seconds.
Comment by Carlos (karlospv94) - Sunday, 19 March 2017, 18:22 GMT
I have the same issue with exactly the same result. I am using KDE Plasma in an Asus UX501 and when I boot the system I only see a black screen and I must change to another tty to use a terminal.

I am using:
mesa 17.0.1-2
lib32-mesa 17.0.1-2
nvidia 378.13-3
nvidia-utils 378.13-5
libglvnd 0.2.999
lib32-libglvnd 0.2.999
sddm 0.14.0-2
sddm-kcm 5.9.3-1

I attach my journalctl and Xorg.0.log
   Xorg.0.log (31.5 KiB)
   journalctl (237.4 KiB)
Comment by Matt Sturgeon (mattsturgeon) - Wednesday, 22 March 2017, 16:31 GMT
karlospv94: That sounds like a separate issue to me. I didn't experience any blank screens caused by mesa.

I have experienced blank display managers and/or display managers not starting before, but those issues were usually caused by updates to the nvidia package.

slashME: I've not actually checked if Wayland is being used or not, but I only experienced the bug in gdm and the normal gnome session (the "GNOME on Xorg" session wasn't affected). I probably should have checked if forcing gdm not to use Wayland in gdm.conf has any impact.
Comment by Carlos (karlospv94) - Wednesday, 22 March 2017, 17:25 GMT
Matt Sturgeon: Thanks! It was caused by nvidia. I have downgraded the version of nvidia and nvidia-utils to 378.13-3 and now it works perfectly!
Comment by Sebastiaan Lokhorst (lonaowna) - Saturday, 08 April 2017, 22:51 GMT
Same issue here. It only happens under Wayland. Also with GNOME Shell 3.24 from [gnome-unstable]: with Xorg it runs fine but with Wayland terrible.

It looks like it doesn't detect the NVIDIA driver at all. When I run glxinfo (from the Wayland session), there is only information about the mesa driver, not NVIDIA.

The following is shown in the journal when GNOME Shell is starting:
kernel: [drm:nvidia_drm_gem_import_nvkms_memory [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to import NVKMS memory to GEM object
kernel: [drm:nvidia_drm_gem_import_nvkms_memory [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to import NVKMS memory to GEM object
kernel: [drm:nvidia_drm_gem_import_nvkms_memory [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to import NVKMS memory to GEM object
gnome-shell[770]: Failed to apply DRM plane transform 0: Invalid argument
gnome-shell[770]: Failed to apply DRM plane transform 0: Invalid argument
org.gnome.Shell.desktop[770]: Disabling glamor and dri3, EGL setup failed
org.gnome.Shell.desktop[770]: Failed to initialize glamor, falling back to sw

Edit: to clarify: I'm using the proprietary driver with nvidia-drm.modeset=1
Comment by aimileus (Aimilius) - Monday, 17 April 2017, 13:59 GMT
This is fixed on mesa 17.1 (mesa-git from the AUR) and gnome-shell 3.24 (from gnome-unstable) with nvidia-drm.modeset=1 for me.
Comment by Sebastiaan Lokhorst (lonaowna) - Monday, 17 April 2017, 15:23 GMT
mesa-git uses a different packaging method without GLVND. This problem is definitely a packaging issue, which has something to do with GLVND/EGL.

You can verify that it was *not* fixed in 17.1, if you grab the mesa PKGBUILD from ABS and bump the version to 17.1.0-rc1, the issue is still there.
You can make these changes to the PKGBBUILD: https://gist.github.com/slokhorst/5f2f08cceb4924469684535474ec9229 . The two EGL patches can be skipped as they landed upstream (just before the 17.1 branch point https://cgit.freedesktop.org/mesa/mesa/commit/?id=ce562f9e3fab769d64b0e5453ec2b4f8710a31ce )
Comment by aimileus (Aimilius) - Monday, 17 April 2017, 18:34 GMT
Ah, I see. I wanted to test whether the issue was fixed with the mesa PKGBUILD, but at the time I tried it, mesa 17.1.0-rc1 wasn't released yet. For now mesa-git is fine :-).
Comment by Sebastiaan Lokhorst (lonaowna) - Monday, 17 April 2017, 22:11 GMT
Still good to have confirmation that the problem is with GLVND and not mesa itself, I hope that the maintainers can track down the issue..
Comment by Jordy van Wolferen (jordz) - Tuesday, 18 April 2017, 10:46 GMT
Support for libglvnd with EGL has been merged into mesa: https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1&id=ce562f9e3fab769d64b0e5453ec2b4f8710a31c

Edit: I'm stupid it was the same commit as on the 17.1 branch.
Comment by George (Vash63) - Friday, 21 April 2017, 00:52 GMT
I'm impacted by this, when trying to run 3.24 in testing I get extremely slow rendering. I installed mesa-git from AUR as suggested and that sped up the rendering but checking system logs left me with software acceleration:

Apr 20 17:35:58 vashnix gnome-shell[627]: Failed to apply DRM plane transform 0: Invalid argument
Apr 20 17:35:58 vashnix org.gnome.Shell.desktop[627]: Disabling glamor and dri3, EGL setup failed
Apr 20 17:35:58 vashnix org.gnome.Shell.desktop[627]: Failed to initialize glamor, falling back to sw

I was unable to run 'glxinfo' at all and the system painting was noticeably slower than normal (dragging windows around), and apps that depended on GLX were failing to open. Has someone found any other workarounds to ensure Nvidia's acceleration is working?
Comment by Matt Sturgeon (mattsturgeon) - Friday, 21 April 2017, 01:05 GMT
The workaround is to use X instead of Wayland.

Set WaylandEnable=false in /etc/gdm/custom.conf and login to the "GNOME on Xorg" session instead of the "GNOME" session.

Comment by Tim (blackout23) - Monday, 24 April 2017, 18:26 GMT
@George
NVIDIA driver doesn't support Xwayland, yet. Hence running GLXGears will run on LLVMPipe.
Comment by Mateusz (Arvamer) - Tuesday, 25 April 2017, 07:48 GMT
I found another workaround—move (or delete) /usr/share/glvnd/egl_vendor.d/50_mesa.json. Of course this will break EGL applications, but they were broken anyway on Nvidia-Wayland session before glvnd changes to mesa. (GLX apps still work with software renderer)
Comment by Guilherme Gonçcalves (guerch) - Tuesday, 25 April 2017, 16:02 GMT
I have this issue too, similar logs to @George, but, as usual the linux graphics stack always confuse me, why is mesa involved here? should nvidia proprietary driver be independent of mesa?
Comment by Freddie Haddad (ffhaddad) - Sunday, 30 April 2017, 13:28 GMT
Just installed mesa 17.0.5 from Arch Extra and issue is still present for me. I'm following @mattsturgeon suggestion of setting WaylandEnable=False for now. Can confirm that this is a Wayland only situation.
Comment by Sebastiaan Lokhorst (lonaowna) - Sunday, 30 April 2017, 13:56 GMT
I don't think this is actually an mesa issue, but rather glvnd and/or nvidia. The fact that this happened with the mesa 17.0.1-2 update is just because that coincided with the glvnd changes.
Comment by Freddie Haddad (ffhaddad) - Sunday, 30 April 2017, 22:01 GMT
I'm not sure if this is the official repo for glvnd (https://github.com/NVIDIA/libglvnd/issues) but there's no mention of this behavior on their site.
Comment by Matt Sturgeon (mattsturgeon) - Sunday, 30 April 2017, 22:05 GMT
I don't know what the underlying issue is, but I can confirm that when I reported this I tested downgrading mesa to 17.0.1-1 and found that fixed the issue (without changing any other packages).

Not using Wayland also works around the issue (WaylandEnable=false in /etc/gdm/custom.conf and login to GNOME Xorg session).

Comment by Freddie Haddad (ffhaddad) - Monday, 01 May 2017, 18:25 GMT
@mattsturgeon that's what I'm doing also (disabling Wayland). Would love to help debug, but this stuff is so over my head. I don't even know where to start looking. Side note, I was really excited to finally try Wayland. :(
Comment by George (Vash63) - Thursday, 04 May 2017, 04:01 GMT
This is definitely an issue with Nvidia, not Mesa. I tried downgrading to 17.0.1-1 and launching my EGLStream enabled weston from AUR and it did not work - mesa is not at fault for support Nvidia, the issue is that the Nvidia package for some reason is not supporting Wayland (or EGL?) even though it supposedly works on Fedora and has supported it for some time.
Comment by Matt Sturgeon (mattsturgeon) - Saturday, 06 May 2017, 23:50 GMT
George: are you saying that this is a nvidia regression and switching to an older nvidia package with better EGL support will fix the issue?
Comment by George (Vash63) - Sunday, 07 May 2017, 01:42 GMT
I am not aware if an earlier version of the Nvidia package would fix this, however I do know that downgrading to mesa 17.0.1-1 isn't really a 'fix' as all that does is fail to start Wayland and cause gdm/gnome to automatically fallback to X11. If anything this is progress as now we can at least use Wayland, just horribly slowly as it's using Mesa instead of Nvidia. Maybe some autodetection to disable Wayland automatically for Nvidia users would be helpful to user experience? I'm not sure if Arch is concerned with user experience due to poor configuration though, as such a setting would be against upstream and need to be reverted if the user _does_ want Wayland.

If this is possible to fix with the current Nvidia drivers, I believe the fix would have to be done with changes to the Nvidia or glvnd package, not the Mesa one. I'd be curious to test the same Nvidia driver set on Fedora to see if Wayland is working properly with their configuration.
Comment by George (Vash63) - Wednesday, 10 May 2017, 14:04 GMT
Some updates, I've still been messing around with this trying to get Wayland working. I am able to run weston-eglstream (from AUR) now with the command 'weston-launch -- --xwayland --use-egldevice'. Performance seems quite good and my weston log indicates Nvidia EGL is working (can upload if helpful), so gdm & gnome's failure to work with nvidia's egldevice is confusing to me. This may be out of scope of this bug at this point though as a xwayland even through weston-eglstream is using Mesa so it would still be a major regression for standard use.

I'm curious if this is related to the 'Failed to import NVKMS memory into GEM object' error, which Google leads me to believe is related to CONFIG_HARDENED_USERCOPY, however this doesn't happen with weston-eglstream so I'm really confused as to where the issue is.

Maybe for the scope of this bug, until XWayland on Nvidia has Nvidia glx support there should be a file included with that package that defaults GDM to use X11?
Comment by Freddie Haddad (ffhaddad) - Thursday, 11 May 2017, 14:36 GMT
I'm inclined to agree with @Sebastiaan since after installing the latest NVIDIA driver (381.22), the issue still exists.
Comment by Freddie Haddad (ffhaddad) - Friday, 12 May 2017, 18:14 GMT
Has anyone tried the Mesa 17.1? It's currently in testing.
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 12 May 2017, 18:31 GMT
@ffhaddad, yes, same as with 17.1.0-rc1, still poor performance and the "EGL setup failed" message.
Comment by Freddie Haddad (ffhaddad) - Friday, 12 May 2017, 19:40 GMT
@Sebastiaan, thanks. Can we assume that it's not NVIDIA driver or MESA and that it's something with GLVND and/or GTK setup/configuration? At one point, this was supposedly working. There are several videos on YouTube showing off NVIDIA + Gnome + Wayland.
Comment by François Guerraz (kubrick) - Saturday, 13 May 2017, 08:52 GMT
Yes, it definitely was working on my machine with the previous version of gnome, a patched mutter and no GLVND.
Comment by Matt Sturgeon (mattsturgeon) - Wednesday, 17 May 2017, 14:58 GMT
Since everyone seems to think this is a GLVND issue not mesa* I've forwarded this issue to GLVND as  FS#54099  - though I'm probably misusing the issue tracker by doing so, so feel free to merge these two issues as required.

* afaik mesa 17.0.1-2 was about mesa making use of GLVND, which would explain why that version bump revealed GLVND issues.
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 19 May 2017, 14:15 GMT
@scimmia, can you change the title of this bug? It's not in mesa but in libglvnd/nvidia
Comment by ask stack (askstack) - Thursday, 22 June 2017, 15:32 GMT
any update?
Comment by Peet (orangecake) - Tuesday, 27 June 2017, 18:32 GMT
I am wondering if this is only affecting Arch? (I am on Arch and haven't tested this os any other distros.)
Is there any update on the GLVND issue? Has this been reported upstream somewhere?
Comment by Sebastiaan Lokhorst (lonaowna) - Tuesday, 27 June 2017, 18:36 GMT
I don't know if this is Arch-only. I mentioned it at the GNOME EGLStream bug,[1] but got no answer.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=773629#c70
Comment by ask stack (askstack) - Wednesday, 28 June 2017, 18:11 GMT
With fully updated F26 and negativo17 nvidia-driver-381.22-6.fc26.x86_64, I still have gnome-shell[1261]: Can’t initialize KMS backend: could not find drm kms device.
If I add “nvidia-drm.modeset=1” to /usr/lib/modprobe.d/nvidia.conf, I will get "Disabling glamor and dri3, EGL setup failed, Failed to initialize glamor, falling back to sw". Wayland will start but in a software rendering mode. ( I am guessing.)

Edit:
I got my answer for fedora.

Fedora hasn't enabled --enable-egl-device in mutter including rawhide and f26
http://pkgs.fedoraproject.org/cgit/rpms/mutter.git/tree/mutter.spec#n117
Comment by Michael (Asympatric) - Thursday, 29 June 2017, 07:59 GMT
Wayland with Proprietary Nvidia drivers works fine on Ubuntu Gnome 17.04. Just need to install gnome-wayland-session and add nvidia-(your driver version number here)-drm.modeset=1 to your boot command in grub and it boots fine and the performance is great. The only problem is that OpenGL applications such as Dolphin-emulator and games are unable to open (Same with Vulkan instances). From what I understand, this problem doesn't happen for OpenSUSE Tumbleweed and Ubuntu Gnome 17.04.
Comment by Patrik Stutz (VanCoding) - Friday, 28 July 2017, 23:30 GMT
This bug still exists on a fully up to date arch linux installation at the time of writing this :(
Hope this gets fixed soon...
Comment by Darek (blablo) - Wednesday, 02 August 2017, 14:46 GMT
The libglvnd package should always be updated together with nvidia drivers release. Please try also egl-wayland (libnvidia-egl-wayland.so.1.0.2).
Comment by Leigh Scott (leigh123linux) - Wednesday, 16 August 2017, 09:11 GMT
Nvidia wayland fails on fedora due to missing device nodes, adding a udev rules file fixes the issue.


[drm:nvidia_drm_gem_import_nvkms_memory [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to import NVKMS memory to GEM object


https://github.com/negativo17/nvidia-driver/issues/27
Comment by Martin Wallin (guzzard) - Wednesday, 16 August 2017, 11:31 GMT
Udev rules make no difference for me at least. Before it was possible to start gnome-shell on wayland with nvidia drivers but it was extremely sluggish and using 100% cpu most of the time. Now it fails to start completely.

Devices are created by the udev rules:
0 crw-rw-rw- 1 root root 195, 0 16 aug 12.35 /dev/nvidia0
0 crw-rw-rw- 1 root root 195, 255 16 aug 12.35 /dev/nvidiactl
0 crw-rw-rw- 1 root root 195, 254 16 aug 12.35 /dev/nvidia-modeset

But gnome shell fails to launch, see log:
https://hastebin.com/vecerojude.pl
Comment by Darek (blablo) - Wednesday, 16 August 2017, 13:52 GMT
@guzzard, For me it looks like  FS#54980 
Comment by Leigh Scott (leigh123linux) - Thursday, 17 August 2017, 13:21 GMT
Sorry my bad, you need to patch mutter (see link for patches)

http://copr-dist-git.fedorainfracloud.org/cgit/mvicomoya/mutter-eglstream/mutter.git/tree/?id=cc8df0d436c549f2faf00a6ca50a8760b5d70e6e


https://copr.fedorainfracloud.org/coprs/mvicomoya/mutter-eglstream/
Comment by Leigh Scott (leigh123linux) - Thursday, 17 August 2017, 13:51 GMT
https://bugzilla.gnome.org/show_bug.cgi?id=782575
Comment by Martin Wallin (guzzard) - Thursday, 17 August 2017, 21:14 GMT
@blablo, yes you are correct. I was able to start gnome-shell with the lts kernel 4.9. Still extremely sluggish though..

@leigh123linux, do you mean that the patches should solve the sluggishness? From what I understand the bug report is about window resizing?
Comment by Darek (blablo) - Wednesday, 30 August 2017, 08:32 GMT
My upstream report - weston-eglstream (maybe somehow related): https://github.com/NVIDIA/egl-wayland/issues/6
Comment by Patrik Stutz (VanCoding) - Wednesday, 04 October 2017, 21:06 GMT
I've tried it again today, after applying all updates.
After my last comment, my system was unable to start using wayland for some time (as Martin Wallin said), but today it was able to start again. But with the same sluggishness as before though. So this issue is still there.
Comment by Patrik Stutz (VanCoding) - Wednesday, 04 October 2017, 21:17 GMT
I noticed something: The mouse usually lags extremely, but as soon as I run a steam game in fullscreen mode, the mouse becomes pretty responsive. But the games itself run REALLY slow, even if they run fine under X.
This info might help find the problem.
Comment by Aleksander Szczygieł (Aelspire) - Friday, 06 October 2017, 17:42 GMT
After last update gnome shell on wayland seems usable. But still looks like a little too low FPS for me.
Comment by Gerhard Bogner (slashME) - Friday, 06 October 2017, 18:46 GMT
I can confirm it works with gnome 3.26 (as long as gdm also uses wayland), and that the framerate seems low - as if the display was set to VSync with 30 Hz.
Comment by Jan Hicken (Brinox) - Monday, 09 October 2017, 14:59 GMT
I can also confirm that the experience has improved since GNOME 3.26 but the performance is still bad: Moving around my mouse on the screen causes a CPU load of 25 % (1 Core) on my machine (i5 760). This isn't the case when using X.
Comment by Martin Wallin (guzzard) - Tuesday, 10 October 2017, 22:13 GMT
With gnome 3.26 it's almost usable, 60 FPS here, but CPU usage is quite high and spikes at some points causing the mouse/whole screen to freeze momentarily. OpenGL applications running in Xorg causes CPU to go 100% etc.
Comment by Kartik Mohta (kartikmohta) - Tuesday, 10 October 2017, 22:20 GMT
Don't know if it helps, but just wanted to comment that it seems to be doing software rendering with Gnome 3.26 which leads to the high CPU usage.
Comment by Martin Wallin (guzzard) - Tuesday, 10 October 2017, 22:32 GMT
@kartikmohta didn't think about that.. you are correct, it's falling back to llvmpipe. Very impressive performance I must say! Fast enough to fool me into thinking it was GPU accelerated. Moving windows around and scrolling in Firefox looks like 60 FPS vsynced.

okt 11 00:23:19 - gnome-shell[5393]: Failed to apply DRM plane transform 0: Invalid argument
okt 11 00:23:19 - org.gnome.Shell.desktop[5393]: Disabling glamor and dri3, EGL setup failed
okt 11 00:23:19 - org.gnome.Shell.desktop[5393]: Failed to initialize glamor, falling back to sw
Comment by Jeremy Wilcox (JeremyW) - Sunday, 15 October 2017, 16:33 GMT
@guzzard I also see those errors in my journalctl log running gnome under Wayland.

I don't know if any of this helps but here is my experiences with Wayland session finally working with Nvida DRM.

I have observed that even though all nvidia related modules are loaded, the nvidia driver doesn't think there is a display and glxinfo seems to indicate that Mesa is running the show.


[ ~]$ nvidia-settings

ERROR: Unable to find display on any available system



[ ~]$ glxinfo | grep glx
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:

If I log out of a Wayland session and try to log back in to a Wayland session, gnome crashes back to the GDM login screen, however I can still log into a Gnome Xorg session.
even if I log into a Gnome Xorg session first, log out and log into a Wayland session, the Wayland session loads fine (with the exception of the above) but any attempt to log out
of a Wayland session and try to log back into a Wayland session a second or subsequent times, causes gnome to crash back to the GDM login screen. Re-booting again allows an initial
login to a Wayland session.
Comment by Cody Maloney (maloney) - Thursday, 19 October 2017, 07:11 GMT
This seems to be related to appliactions picking up glx as the EGL_PLATFORM rather than egl, If I add `export EGL_PLATFORM=wayland` to /etc/gdm/Init/Default so it gets set before things start, everything works, and both glxinfo and eglinfo show that nvidia is in use.
Comment by Segey Tereschenko (partizan) - Thursday, 19 October 2017, 08:04 GMT
@maloney what else did you changed?

i just added `export EGL_PLATFORM=wayland` and performance still bad.



~  glxinfo | egrep "(glx|OpenGL)"
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 5.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
~  echo $EGL_PLATFORM
wayland

Comment by Martin Wallin (guzzard) - Thursday, 19 October 2017, 08:18 GMT
@maloney

I have the same results as @partizan, still falling back to llvmpipe.

$ glxinfo | egrep "(glx|OpenGL)"
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 5.0, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

$ eglinfo
EGL API version: 1.4
EGL vendor string: NVIDIA

$ env | grep wayland
WAYLAND_DISPLAY=wayland-0
EGL_PLATFORM=wayland
XDG_SESSION_TYPE=wayland

from journal:
okt 19 10:06:45 gnome-shell[5405]: Failed to apply DRM plane transform 0: Invalid argument
okt 19 10:06:45 org.gnome.Shell.desktop[5405]: Disabling glamor and dri3, EGL setup failed
okt 19 10:06:45 org.gnome.Shell.desktop[5405]: Failed to initialize glamor, falling back to sw
Comment by Emil (xexaxo) - Friday, 22 December 2017, 14:23 GMT
"We currently have no plans to support Xwayland."
https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/post/5188874/#5188874


Which means that anything that uses GLX will be in a funky state, _apart_ from the need of custom EGL_stream codepath to have Wayland working with the blob.
AFAICT gnome-shell has the latter, while others (kwin, xfce?...) do not.

Although from a quick skim this report is going through multiple unrelated issues.
Comment by Segey Tereschenko (partizan) - Friday, 05 January 2018, 10:19 GMT
Yesterday after update my gnome-shell started to eat all CPU, i checked weston and it's exactly the same. (I was using nouveau drivers).
So i decided to check nvidia drivers again. And it is usable, does not eat cpu and feels smooth enough.

> glxinfo | egrep "(glx|OpenGL)"
still shows "OpenGL renderer string: llvmpipe (LLVM 5.0, 256 bits)"

But i don't care until it works good.
Comment by Segey Tereschenko (partizan) - Friday, 05 January 2018, 13:36 GMT
Not so good.
Closing application results in complete wayland freeze.
Comment by mastercoms (mastercoms) - Sunday, 07 January 2018, 19:19 GMT
Is this fixed with nvidia-beta 390.12?

"
* Added new application profile settings, "EGLVisibleDGPUDevices" and "EGLVisibleTegraDevices", to control which discrete and Tegra GPU devices, respectively, may be enumerated by EGL. See the "Application Profiles" appendix of the driver README for more details.
* Corrected the SONAME of the copy of the libnvidia-egl-wayland library included in the .run installer package to libnvidia-egl-wayland.so.1. The SONAME had previously been versioned incorrectly with the full version number of the library.
"
Comment by George (Vash63) - Monday, 08 January 2018, 02:14 GMT
390.12 did not fix it for me as far as I could tell. 'eglinfo' still shows mesa drivers, I'm not sure if there's a better way to check. Obviously glxinfo will show llvmpipe regardless as Nvidia doesn't support accelerated XWayland at AFAIK.
Comment by Emil (xexaxo) - Monday, 08 January 2018, 13:10 GMT
George (Vash63) - you're spot on the glxinfo front. WRT EGL one would have to pull up them sleeves and get their hands dirty.
Rough ideas:
- strace eglinfo or LD_DEBUG=libs eglinfo - see if libEGL_nvidia.so (or similar not 100% on the name) is attempted to be opened
- no: track what's happening in GLVND (aka libEGL.so) - might have to rebuild the package with debug symbols
- yes: forward the information to Nvidia - only they have the code for the driver :-\
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 18 May 2018, 16:59 GMT
This is fixed for me. (I think that Xorg 1.20 did it)

Anyone else still having issues or can we close this?
Comment by Segey Tereschenko (partizan) - Friday, 18 May 2018, 17:14 GMT
@lonaowna are you sure running wayland session? i just tried to test it, with nvidia-drm.modeset=1 but gdm started in xorg mode, and gnome running in xorg mode.
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 18 May 2018, 17:26 GMT
@partizan oops, looks like you are right.

I can't seem to start it in Wayland mode any more at all.. GDM starts it in X11 mode and running `XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session` from a TTY gives a bunch of errors.

Edit: https://bugs.archlinux.org/task/57957
Comment by Leon Möller (jkhsjdhjs) - Friday, 18 May 2018, 17:27 GMT
Still extremely unresponsive for me. Crashes when I try to close a window. Running KDE 5.12
Comment by Max Bruckner (FSMaxB) - Friday, 18 May 2018, 17:34 GMT
I am definitely running on Wayland, and it's quite horrible.
* The mouse pointer lags some of the time
* Sometimes Keyboard input just doesn't ever reach the application that I'm writing in.
* Animations etc. are lagging
Comment by Tim (blackout23) - Friday, 18 May 2018, 18:15 GMT
Xorg-server 1.20 is not built with XWayland EGLStreams support if you look at the PKGBUILD.
+# -D xwayland_eglstream=true \ # requires weston-eglstream from AUR
Not sure why it should require weston-eglstream.

So I wouldn't expect any improvements anyway. I might rebuild xorg myself to test it out.
Comment by Segey Tereschenko (partizan) - Tuesday, 16 April 2019, 20:05 GMT
For anyone iterested: yesterday i installed nvidia propritary driver. And it works better than last time, but still not completely.

xwayland still uses software renderer

> journalctl -x -o cat | grep glamor
glamor: 'wl_drm' not supported
Missing Wayland requirements for glamor GBM backend
glamor: Using nvidia's EGLStream interface, direct rendering impossible.
glamor: Performance may be affected. Ask your vendor to support GBM!


but things that support wayland is using nvidia driver, like

> glmark2-wayland
OpenGL Information
GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce GTX 1080/PCIe/SSE2
GL_VERSION: 4.6.0 NVIDIA 418.56

gnome-shell performance is quite good on software render (on AMD Ryzen 7 2700 at least)

But it's not stable enough, today i had two crashes.
Comment by Segey Tereschenko (partizan) - Tuesday, 16 April 2019, 20:08 GMT
And for the good news:

https://blogs.gnome.org/uraeus/2019/04/03/preparing-for-fedora-workstation-30/

Fedora folks working with nvidia, and by the fall we may have this issue fixed.
Comment by George (Vash63) - Wednesday, 17 April 2019, 11:53 GMT
I can confirm the above, with the latest nvidia drivers, mutter, gnome-shell and such Wayland is now working basically just as I would expect with no major issues. Unfortunately XWayland still falls back on llvmpipe making it pretty hard to use at the moment as a day-to-day, but this is definitely a step up from last time I tried it.
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 13 September 2019, 14:43 GMT
So with the exception of XWayland, things seem to be working pretty well as of GNOME 3.34. The subject of this bug also doesn't seem to be accurate anymore, so I suggest we close this bug.

I have updated [GNOME#Wayland sessions] and [NVIDIA#DRM kernel mode setting] in the wiki to explain the XWayland situation and added the link that partizan posted.

[1] https://wiki.archlinux.org/index.php/GNOME#Wayland_sessions
[2] https://wiki.archlinux.org/index.php/NVIDIA#DRM_kernel_mode_setting

Loading...