Sway: Why/when is/will the nvidia proprietary driver not/be supported?

Created on 16 Feb 2016  路  32Comments  路  Source: swaywm/sway

As I can see in the wiki, the Nvidia proprietary driver is not supported. Is this because of an issue on Nvidia's side or on this/sway's side?

btw I have 0 knowledge on wayland

Most helpful comment

Tell that to nvidia.

All 32 comments

That's nvidia's fault.

So they don't support wayland? Anyway, thanks for the info!

Correct.

Thanks again for the clarification!

Fuck yeah! I'm going to test it out when I get home and I'll pull out the warnings if it works.

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.

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.

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.

So can you add a nvidia-version check? I really want to test it :) nvidia-beta in the AUR is the newest version (https://aur.archlinux.org/packages/nvidia-beta/)

I'll install nvidia-beta tonight and see what I can do.

Thanks!

https://github.com/Cloudef/wlc/issues/138

That's why it doesn't / won't work right now...
EDIT: Oh sorry, you apparently already know.

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

Implement it if you want. I'm happy on nouveau.

I'll put it in my "Whenever I get time for it"-list.

Problem is can't do much on nouveau. My main reason is to run CUDA apps like tensorflow, etc. :'(

Tell that to nvidia.

wlc just added support for the proprietary NVIDIA driver.

@SirCmpwn would you accept a PR which removes the warning about the proprietary NVIDIA driver?

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.

I've tried sway with the latest git version of wlc and it seemed to work. But it definitely requires testing from more users.

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.

@emersion Thanks for the reply!

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

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...

Tell that to nvidia.

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

Use i3, then.

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.

Additionally, proper multi-GPU support cannot be implemented with EGLStreams because it lacks DMA-BUFs.

For reference, here are some more discussions about EGLStreams:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  4Comments

johanhelsing picture johanhelsing  路  3Comments

dnkl picture dnkl  路  4Comments

WhyNotHugo picture WhyNotHugo  路  3Comments

StephenBrown2 picture StephenBrown2  路  4Comments