NVIDIA Is Working On DMA-BUF Passing That Should Help Improve Their Wayland Support

[mdedetrich]

You are probably unaware of a lot of work done in the Fedora space. Check out the notes on Nvidia from blog posts like these

https://blogs.gnome.org/uraeus/2016/11/01/discrete-graphics-and-fedora-workstation-25/

https://blogs.gnome.org/uraeus/2019/09/23/fedora-workstation-31-whats-new/

I am sure if you read more of the blog, you will find regular updates on what has been done to support them

Well we are talking in context of Wayland, the first link you have is wrt hybrid graphics (which I actually have) and the second point isn't actually supporting the "redhat caving into NVidia's demands" but rather "we have to wait for NVidia to add support to their blob" for XWayland which is entirely something else.

[CommunityMember]

How is it not an option?

Because the nvidia GPU is soldered to the motherboard in some laptops? Because nvidia gpu computation is required for other activities? Because money is tight right now, and may be for quite some time?

Having options is good, but not everyone has options all the time.

[mdedetrich]

Maybe this qualifies

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-Mainline-EGLStream

In any way, there are discussions ongoing between redhat and nvidia all the time. Check christian Schaller's blog.
So, seems that nvidia does demand stuff and redhat complies.

On the nvidia graphics interface, they started the story about replacing eglstreams with something new, accepted by the community and then did nothing. They seem like the type which wants to get something but not actually doing anything.

Also, why would any kernel dev budge to support greedy company? The right statement would be 'nvidia refuses to higher kernel developers to fix their driver support'.

And if we go back to their 'nvidia alliance' or whatever was the name of that anticompetitive campaign few years back, we can *for sure* say that nvidia is extremely bad player when it comes to linux. Probably doing amazing for the stock owners.

Not really.

Gnome and KDE actively refused to support the NVidia blob and since they didn't collaborate with NVidia they ended up being forced to use EGLStreams since they couldn't just kill off all of their users who have NViida cards. NVidia has already stated that they can't use GBM with their blob, so its not really a demand but rather "if you want to use the blob we have to come up with another solution".

The part about NVidia being a greedy company is also just pointless smearing, so are AMD and Microsoft and they are massive contributors to the kernel. This is more about a conflict of ideologies and philosophies rather than being greedy.

[mppix]

Calling it an interface is a stretch, and its also not vendor neutral because its been largely been design by Linux OS devs without input from all graphics vendors and its also tied to Mesa. NVidia has already stated why they can't use GBM, it incurs a heavy performance penalty because GBM works very differently compared to how NVidia's blob is designed (this is why NVidia designed EGLStreams in the first place).

No!

GBM was chosen [for Wayland] by Linux devs, application devs and GPU vendors (everybody was invited). However, Nvidia has a wait and see attitude with Linux since forever (and did not show up).
Nobody [outside of Nvidia] knows EXACTLY why Nvidia does not support GBM and many reasons have been suggested...
However, they certainly did not invent EGLStreams. A concept like EGLStreams was even discussed for Wayland. However, GBM was chosen since it was the technically superior and Nvidia did not show up to generate opposition when it counted.

[mdedetrich]

No!

GBM was chosen [for Wayland] by Linux devs, application devs and GPU vendors (everybody was invited). However, Nvidia has a wait and see attitude with Linux since forever (and did not show up).
Nobody [outside of Nvidia] knows EXACTLY why Nvidia does not support GBM and many reasons have been suggested...

This is false, NVidia has stated many times why they cannot use GBM with their blob. The synchronization strategy used by GBM doesn't work well with NVidia's blob and hence you get a non trivial performance loss. This is one of the fundamental differences between EGLStreams and GBM, EGLStreams allows you to collect/act on buffers asynchronously which work much better with the blob. Even Phoronix reported on this many times.

This is why EGLStreams is vendor neutral (in design), it doesn't make any assumptions about how drivers are supposed to behave (note that the design was largely copied from how Android did compositing at the time).

As the article states, EGLStreams is obviously has issues however so does current design for GBM when using their blob. Something new is needed so its good to see that progress is being made here.

[jrch2k8]

1.) Calling it an interface is a stretch, and its also not vendor neutral because its been largely been design by Linux OS devs without input from all graphics vendors
2.) and its also tied to Mesa.
3.) NVidia has already stated why they can't use GBM,
3.B) it incurs a heavy performance penalty because GBM works very differently compared to how NVidia's blob is designed
4.) this is why NVidia designed EGLStreams in the first place

1.) It was designed with input from Intel and AMD and community developers expert on graphics and today even works on ARM drivers as well, as do with software drivers, this is not something any random dev without deep graphic hardware understanding can pull off its ass

2.) Mesa is the main user but is not tied or dependent on(will make sense why, when you realize all linux drivers are in Mesa outside nVidia ...)

3.) That was a PR presentation and got like 90% debunked few years ago except a small set of nitch cases.

3.B) This is not a Linux problem, is an nVidia's problem and as time has show all the "performance issues" were fixed(non existent in some cases) since RADV is actually as fast or faster that the BLOB in most comparable products

4.) https://www.khronos.org/registry/EGL...KHR_stream.txt exist since 2009-2011 and literally nobody implemented it ever in any driver or any OS until nVidia needed something that could work(ish) with Wayland and you can google around why

[Bobby Bob]

Lets see, buy an NVIDIA GPU or AMD GPU..

If I buy an NVIDIA GPU, the advantages are that they're usually faster, have superior raytracing performance, can run CUDA-only software like Meshroom, and in Blender allows me to have real time viewport denoising with OptiX and hardware accelerated raytracing when rendering, and the driver support at launch is way better than AMD..

If I buy an AMD GPU, the advantages are being able to be self righteous on this forum about not using 'the blob' and.. Oh wait that's it.

Tough decision.

mdedetrich is speaking straight facts here. I wouldn't even buy a new AMD GPU let alone throw out an existing NVIDIA GPU to replace it with an AMD GPU.

[RahulSundaram]

Well we are talking in context of Wayland, the first link you have is wrt hybrid graphics (which I actually have) and the second point isn't actually supporting the "redhat caving into NVidia's demands" but rather "we have to wait for NVidia to add support to their blob" for XWayland which is entirely something else.

Your summary doesn't cover most of the details.

For anyone interested, I would recommend reading through the blog posts (and rest of the blog) and you will find plenty of information on what has been done to support Nvidia. Red Hat doesn't have access to Nvidia's proprietary driver so there are some limitations but in particular, things like libglvnd are concrete examples of what Red Hat has done and a lot of core pieces are things that both Xorg and Wayland take advantage of.

[ssokolow]

Gnome and KDE actively refused to support the NVidia blob and since they didn't collaborate with NVidia they ended up being forced to use EGLStreams since they couldn't just kill off all of their users who have NViida cards.

KDE compromised. Originally, they refused to write or maintain an EGLStreams backend but now, they maintain an EGLStreams backend that nVidia wrote and contributed.

[mdedetrich]

1.) It was designed with input from Intel and AMD and community developers expert on graphics and today even works on ARM drivers as well, as do with software drivers, this is not something any random dev without deep graphic hardware understanding can pull off its ass

Yeah and they ignored NVidia, hence why we have a problem with NVidia. Hint: Drivers and also graphics cards differ between vendors, just because some vendors have input into the design doesn't mean you take into account all possible designs.

2.) Mesa is the main user but is not tied or dependent on(will make sense why, when you realize all linux drivers are in Mesa outside nVidia ...)

I think you missed the point, GBM/Mesa was coded with the current open source drivers in mind, it was never designed (nor intended) to work with closed source solutions that could be designed differently.

Claiming otherwise is being disingenuous.

3.) That was a PR presentation and got like 90% debunked few years ago except a small set of nitch cases.

3.B) This is not a Linux problem, is an nVidia's problem and as time has show all the "performance issues" were fixed(non existent in some cases) since RADV is actually as fast or faster that the BLOB in most comparable products

Actually it is a Linux problem, Windows/BSD's/Mac have no issues in working with multiple graphics card vendors. Again, using a different GPU vendors open source implementation (RADV) as evidence that GBM can work with NVidia's blob is misleading and wrong.

4.) https://www.khronos.org/registry/EGL...KHR_stream.txt exist since 2009-2011 and literally nobody implemented it ever in any driver or any OS until nVidia needed something that could work(ish) with Wayland and you can google around why

Yeah Linux ignored NVidia, up until they started pushing Wayland really hard and realized they needed to actually work with NVidia so that they wouldn't screw over NVidia linux users.

Also again repeating Linux is the ONLY OS that has this problem, and thats because Linux refuses to to work with ALL of the GPU vendors in providing a stable, agnostic interface (and this is true, Linux devs themselves said that they don't want to create such an interface, they instead want all drivers to be open source and sit in kernel tree). So other solutions are required.

Your summary doesn't cover most of the details.

Maybe, but I have read plenty on this topic but importantly there was never a case of "Redhat giving into NVidia's demands" and the articles you posted definitely do not give that impression.

KDE compromised. Originally, they refused to write or maintain an EGLStreams backend but now, they maintain an EGLStreams backend that nVidia wrote and contributed.

Correct, and they were throwing a tantrum over what ended up being like ~300 lines of code which NVidia ended up having to contribute.