You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Why/when is/will the nvidia proprietary driver not/be supported? #490
I am also waiting for an Arch Linux update (will use testing, if available earlier). I am also running Kernel 4.5 from testing for a while and experienced no issues.
Tried it out with aur/wlc-git, and it does work. For some reason, most apps I've been running made sway run quite awful slow and use a lot of CPU. Could be xwayland related, I haven't tried it out extensively. But it works, without obvious glitches.
Sorry to revive this topic, but as someone finding out about Sway just now I'd like to ask how is the support for the NVIDIA proprietary driver as of now (december/2018)?
The NVIDIA proprietary driver still doesn't support the standard GBM interface, which is what literally everyone else uses. We don't plan to add code for NVIDIA-specific proprietary interfaces in wlroots. NVIDIA not supporting Sway is a NVIDIA bug, please report this bug to them if you care.
Please use Nouveau and consider supporting vendors that actually care about open-source.
I appreciate this is a political issue more than a technical one, and have read the arguments for and against supporting EGLStreams. Regrettably I have a GTX 1080 Ti in my workstation (using the Nouveau driver) and there are some instability issues I haven't had a chance to debug, so I would like to see support for the proprietary driver from a pragmatic POV, and I'd also like to work on a Vulkan-based project which Nouveau doesn't support.
However I can acknowledge unless people vote with their code (and wallets) this situation won't change (and has been discussed at length previously).
Orthogonally, is this likely be made moot if/when a Vulkan backend is completed for Sway/wlroots? Does the WSI interface provide an alternate buffer path or is it still incomplete without GBM or EGLStreams? I'd rather wait for Intel's Xe than replace a powerful NVIDIA card with a slower AMD one TBH, and from a political point of view it seems Intel's support for open source is far better than AMD's or NVIDIA's.
I appreciate this is a political issue more than a technical one
There are technical aspects too.
As far as I understand it, the rendering model of EGLStreams is very different from what we have, meaning it is certainly not trivial to add support.
It's another code path that we'd have to add, making the code significantly more complicated.
EGLStreams is unsurprisingly tied to EGL, which means that it does not work with Vulkan.
It goes against our policy of writing any driver-specific code (even for open-source drivers), due to the maintenance and testing costs of doing so.
Does the WSI interface provide an alternate buffer path or is it still incomplete without GBM or EGLStreams?
Vulkan does not have a WSI for GBM nor EGLStreams. The lack of "native GBM" support is one of the main reasons I'm dropping the use of the Vulkan WSI or EGL platforms and handling the low-level buffers ourselves via GBM. It'll make the (eventual) Vulkan and OpenGL code much more consistent with each other, and well as make the DRM backend more consistent with the other backends.
It's all about reducing the different number of code paths, so everything is easier to maintain and test. EGLStreams have no place in this goal.
Nvidia was talking up some GBM-replacement called liballocator a while ago, and I'm not opposed to changing to this. However, it appears they have lost interest and the repository hasn't been touched for quite a while.
Intel's support for open source is far better than AMD's
While Intel's driver is still the most high-quality, AMD's open-source driver has improved significantly over the last several years (since amdgpu). Basically, their open-source driver is great now, and is perfectly usable.
Thanks for the comments, I find as a layman developer it's very hard to get a handle on the whole stack.
While Intel's driver is still the most high-quality, AMD's open-source driver has improved significantly over the last several years (since amdgpu). Basically, their open-source driver is great now, and is perfectly usable.
Good to know. I haven't actually had an AMD card in years but maybe it's time for another go. Hopefully CES has some good news...
I am very pumped about wayland and sway. However so right this standpoint may be, about not supporting nvidia (due to technical reasons too, as have been mentioned), my ROG laptop has no card switching and has the nvidia card clamped to the display for vsync. In short, i am stuck (out of the sway experience). I want to use sway by any means, as my kind of permanent replacement for i3, and my hardware doesn't let me use nouveau (ROG support for recent nouveaus is so bad, distros recommend using nvidia instead in nouveau bug reports!). Can't just buy another laptop. Translates to i can't use sway 😢
With the new (now deleted) comment, I'm going to swoop back in with some other arguments, now that I've heard some more points from people much smarter than myself.
EGLStreams completely breaks the Wayland rendering model and does not provide the atomicity guarantees that Wayland was explicitly designed around. You can only get the latest buffer, and not deliberately hold onto buffers longer if needed, without doing stupid shit like copying it. I've heard of there being inherent deadlocks with EGLStreams/Wayland, but I don't know of the exact technical details of it.
EGLStreams removes the possibility for direct scan-out and overlay planes to be supported. When you configure a stream, you cannot change it without tearing the whole thing down again. When you create a stream to a GL texture, you cannot migrate it over to a DRM/KMS plane.
EGLStreams does not allow for technologies such as Pipewire to work.
These are the main arguments I have heard as to why EGLStreams were not accepted into Weston, and these are really good arguments. EGLStreams are straight up broken, and the existing Wayland compositors that support it just choose to ignore the issues.
There are overwhelming technical and non-technical arguments as to why we are not going to support it. Face it, we are never going to support them. There is absolutely no point bringing it up; you are not going to change our minds.
Activity
ddevault commentedon Feb 16, 2016
That's nvidia's fault.
z3ntu commentedon Feb 16, 2016
So they don't support wayland? Anyway, thanks for the info!
ddevault commentedon Feb 16, 2016
Correct.
z3ntu commentedon Feb 16, 2016
Thanks again for the clarification!
z3ntu commentedon Mar 21, 2016
Newest driver supports wayland! https://www.reddit.com/r/linux/comments/4bcm9w/nvidia_releases_display_driver_36412_with_wayland/
ddevault commentedon Mar 21, 2016
Fuck yeah! I'm going to test it out when I get home and I'll pull out the warnings if it works.
ddevault commentedon Mar 21, 2016
Well, on second thought, I'm going to wait before it hits arch stable before dropping the warnings. Will probably add a version check, too.
z3ntu commentedon Mar 21, 2016
I am also waiting for an Arch Linux update (will use testing, if available earlier). I am also running Kernel 4.5 from testing for a while and experienced no issues.
ddevault commentedon Mar 21, 2016
I don't mind building nvidia myself to test it out, I just don't want to drop the warning for all of our users until the new driver is in stable.
z3ntu commentedon Mar 22, 2016
So can you add a nvidia-version check? I really want to test it :)
nvidia-betain the AUR is the newest version (https://aur.archlinux.org/packages/nvidia-beta/)ddevault commentedon Mar 22, 2016
I'll install nvidia-beta tonight and see what I can do.
z3ntu commentedon Mar 22, 2016
Thanks!
z3ntu commentedon Mar 25, 2016
Cloudef/wlc#138
That's why it doesn't / won't work right now...
EDIT: Oh sorry, you apparently already know.
lindhe commentedon Jan 11, 2017
Is there any plans on implementing EGLStream to get it to work with the proprietary Nvidia driver?
http://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-Mainline-EGLStream
4 remaining items
vially commentedon Apr 2, 2017
wlc just added support for the proprietary NVIDIA driver.
@SirCmpwn would you accept a PR which removes the warning about the proprietary NVIDIA driver?
ddevault commentedon Apr 2, 2017
No. The warning is just a warning, it doesn't stop sway from trying anyway. Once I hear positive feedback from some users, I will remove the warning.
vially commentedon Apr 2, 2017
I've tried sway with the latest git version of wlc and it seemed to work. But it definitely requires testing from more users.
asumagic commentedon Apr 24, 2017
Tried it out with aur/wlc-git, and it does work. For some reason, most apps I've been running made sway run quite awful slow and use a lot of CPU. Could be xwayland related, I haven't tried it out extensively. But it works, without obvious glitches.
telmotrooper commentedon Dec 26, 2018
Sorry to revive this topic, but as someone finding out about Sway just now I'd like to ask how is the support for the NVIDIA proprietary driver as of now (december/2018)?
emersion commentedon Dec 26, 2018
The NVIDIA proprietary driver still doesn't support the standard GBM interface, which is what literally everyone else uses. We don't plan to add code for NVIDIA-specific proprietary interfaces in wlroots. NVIDIA not supporting Sway is a NVIDIA bug, please report this bug to them if you care.
Please use Nouveau and consider supporting vendors that actually care about open-source.
telmotrooper commentedon Dec 26, 2018
@emersion Thanks for the reply!
tokyovigilante commentedon Dec 26, 2018
I appreciate this is a political issue more than a technical one, and have read the arguments for and against supporting EGLStreams. Regrettably I have a GTX 1080 Ti in my workstation (using the Nouveau driver) and there are some instability issues I haven't had a chance to debug, so I would like to see support for the proprietary driver from a pragmatic POV, and I'd also like to work on a Vulkan-based project which Nouveau doesn't support.
However I can acknowledge unless people vote with their code (and wallets) this situation won't change (and has been discussed at length previously).
Orthogonally, is this likely be made moot if/when a Vulkan backend is completed for Sway/wlroots? Does the WSI interface provide an alternate buffer path or is it still incomplete without GBM or EGLStreams? I'd rather wait for Intel's Xe than replace a powerful NVIDIA card with a slower AMD one TBH, and from a political point of view it seems Intel's support for open source is far better than AMD's or NVIDIA's.
[EDIT] Hmm, seems like GBM is still required. OK, forget NVIDIA ;)
ascent12 commentedon Dec 26, 2018
There are technical aspects too.
Vulkan does not have a WSI for GBM nor EGLStreams. The lack of "native GBM" support is one of the main reasons I'm dropping the use of the Vulkan WSI or EGL platforms and handling the low-level buffers ourselves via GBM. It'll make the (eventual) Vulkan and OpenGL code much more consistent with each other, and well as make the DRM backend more consistent with the other backends.
It's all about reducing the different number of code paths, so everything is easier to maintain and test. EGLStreams have no place in this goal.
Nvidia was talking up some GBM-replacement called liballocator a while ago, and I'm not opposed to changing to this. However, it appears they have lost interest and the repository hasn't been touched for quite a while.
While Intel's driver is still the most high-quality, AMD's open-source driver has improved significantly over the last several years (since amdgpu). Basically, their open-source driver is great now, and is perfectly usable.
tokyovigilante commentedon Dec 26, 2018
Thanks for the comments, I find as a layman developer it's very hard to get a handle on the whole stack.
Good to know. I haven't actually had an AMD card in years but maybe it's time for another go. Hopefully CES has some good news...
karansapolia commentedon Jan 11, 2019
I am very pumped about wayland and sway. However so right this standpoint may be, about not supporting nvidia (due to technical reasons too, as have been mentioned), my ROG laptop has no card switching and has the nvidia card clamped to the display for vsync. In short, i am stuck (out of the sway experience). I want to use sway by any means, as my kind of permanent replacement for i3, and my hardware doesn't let me use nouveau (ROG support for recent nouveaus is so bad, distros recommend using nvidia instead in nouveau bug reports!). Can't just buy another laptop. Translates to i can't use sway 😢
ddevault commentedon Jan 12, 2019
Use i3, then.
ascent12 commentedon Mar 11, 2019
With the new (now deleted) comment, I'm going to swoop back in with some other arguments, now that I've heard some more points from people much smarter than myself.
These are the main arguments I have heard as to why EGLStreams were not accepted into Weston, and these are really good arguments. EGLStreams are straight up broken, and the existing Wayland compositors that support it just choose to ignore the issues.
There are overwhelming technical and non-technical arguments as to why we are not going to support it. Face it, we are never going to support them. There is absolutely no point bringing it up; you are not going to change our minds.
emersion commentedon Mar 11, 2019
Additionally, proper multi-GPU support cannot be implemented with EGLStreams because it lacks DMA-BUFs.
For reference, here are some more discussions about EGLStreams: