NVIDIA's List Of Known Wayland Issues From SLI To VDPAU, VR & More

[WannaBeOCer]

Even with Nvidia's driver support, Wayland will still be useless for any creative professional/vision researcher since color management/present-timing protocols are missing. Frustrating that gamers are influencing enterprise distributions like Ubuntu. I'm fine with Wayland being the default on rolling releases/bleeding edge rolling releases but leave the enterprise distributions out of it until there is feature parity.

https://gitlab.freedesktop.org/wayla...ge_requests/14
https://gitlab.freedesktop.org/wayla...e_requests/103

[zexelon]

birdie & oiaohm impressive back and forth... it would be helpful to check emotion at the door before engaging though. Both Nvidia & AMD are playing a business game, they are no more for or against FOSS then any other hardware vendor. They are all about revenue, margin and profit. They have extremely smart people (at least a couple of them...) that have made the evaluations on what the best move is to FOSS parts of their eco systems and keep others behind locked doors.

Dying on a hill for either of these companies is not worth it... the rest of the world wont know you breathed your last anyway. This is a harsh reality of being human, so instead of flaming write code?

That said, sometimes flaming can elicit a pleasurable dopamine response so I get it.

On a 100% personal note... so far wayland sucks... it takes way to much effort to get it to work, and way to much effort to keep it working regardless of the hardware (though yes, Nvidia was "harder" then AMD for the longest time... now I think they are getting closer in the nerd level requirements). Its like the old RPGs where you had to level up enough to get the "sleeping skill"... again... personal opinion! To those that get wayland working, keep it up, eventually it will make my life easier

[oiaohm]

birdie & oiaohm impressive back and forth... it would be helpful to check emotion at the door before engaging though. Both Nvidia & AMD are playing a business game, they are no more for or against FOSS then any other hardware vendor. They are all about revenue, margin and profit. They have extremely smart people (at least a couple of them...) that have made the evaluations on what the best move is to FOSS parts of their eco systems and keep others behind locked doors.

Dying on a hill for either of these companies is not worth it... the rest of the world wont know you breathed your last anyway. This is a harsh reality of being human, so instead of flaming write code?

The reality here is Nvidia with Linux platforms has been pulling teeth. Before 2012 from early 1998 there was agreement with all the open source opengl drivers on a Linux but we had to wait for the "libglvnd: the GL Vendor-Neutral Dispatch library" from Nvidia developers to in fact stop Nvidia drivers from basically delete the competitions libraries. Yes the description of libglvnd proposal makes out that no dispatch system existed before Nvidia made one when this was not the case one did exist but Nvidia refused to use it. There is very strong NIH(not invented here) syndrome.

Nvidia drivers having issues when you use the Linux kernel framebuffer interface... This is the problem NIH has been very strong at Nvidia. ATI before AMD acquired them also had a very strong NIH inverted here point of view as well. Yes the opengl extension wars between ATI and Nvidia resulting in games and applications that would only work on one or the other you might be able to make a business case for this behavour but its not good for end users.

Eglstreams this is proposed by Nvidia after Intel, AMD and Arm have all agreed on the KMS DMA_BUF route then they wonder why no other party goes and implements Eglstreams on Linux. Again case of NIH. This is really bad because not only did Nvidia decided at first not to follow everyone else route they never fully implemented Eglstreams. Yes the missing features from Wayland compositors are also features Nvidia never implemented with Eglstreams.

zexelon at some point you need to look track history and see Nvidia does not play well with others. Take AMD graphics upscaling FSR that designed to work on Intel, AMD and Nvidia graphics cards so that developers of applications and end users have a predicable time. Yes AMD could be still trying to be ATI and make the technology exclusive like NVIDIA still does with DLSS and many others but they don't.

Yes there is a business game here but the way you play the business game is up to the individual company. There are cases where a company is doing things that is about vendor locking and being bad for consumer choice.

NIH does have some horrible costs in developer for company doing it and for end users on the receiving end of it.

Please not the Eglstreams vs KMS/DMA-BUF did result in different protocol extentions on Wayland getting bogged down on how to handle the difference between the Eglstreams implementation and the KMS/DMA-BUF implementation..

When it comes to a functional graphical stack you are not wanting a major party doing massive amount of NIH. Instead you want basic agreements on core functionality that all parties have to agree to. Microsoft hard balled with Window Vista to make that happen. Linux world its been a slow hard grind with one party being the biggest problem. Yes getting AMD, Intel , Arm, Qualcomm... and many more on the same page was not easy Nvidia was and is the last annoy hold out.

[zexelon]

oiaohm Respectfully I must disagree with your premise. Nvidia actually plays very well with people and technology... the ones that pay... this is how they have achieved 60% margins and profit values that exceed that GDP of a disturbing number of countries on this planet. Nvidia does not play well perhaps with the negligible 1% of possible users in the desktop space running Linux.

For comparison sake, I would say Nvidia actually plays very well with Linux users than OS X users. There is no Nvidia hardware that beyond I think the 1000 series that can be used in OS X. They dropped the whole platform, and that was a much larger user base then Linux users. There was a ton of politics around it of course, but never the less they dumped OS X and have continued to support Linux users even though a large number of key Linux users/developers have given them the literal finger.

Also to put it bluntly there is no performance comparison from team red (aka AMD) that reaches the levels achieved by Nvidia in this generation, even on Linux! Sure it would be nice if they embraces FOSS and now they are making very positive moves in that respect to reach the same level as AMD and that is awesome to see... but lets not delude ourselves, both AMD and Nvidia are only doing it for the profit results because at the end of the day they make money.

I have just finished playing Satisfactory on Linux using Xorg on Nvidia hardware via Proton for several hours and I can safely say that the experience has been purely fluid and absolutely enjoyable! At this point if I can get a couple of CAD packages (i'm looking at you SolidWorks and Revit) and maybe MS Office on Linux that would be epic... you want people who dont play nice, look at Desault and Autodesk!

[omer666]

To bring a brighter note here, it looks like nvidia is really looking to develop their Linux ecosystem this time. Yet we're very early into it, but now that I have read some more about it on Christian Schaller's blog, I have good hope.

Dividing the user base between nvidia haters and supporters is too simple here. While I had good reasons to be angry at them lately, if it was not for their drivers I would not be gaming on Linux at all to begin with.

The problem is that when there is a collective effort to make things better, you have got to put some effort into it. Nvidia literally did not get involved, and decided to do its own thing. What used to be its strength in the ecosystem - its drivers - progressively became a drawback for its users.

As a dumb Linux user when they'll put their **** together I'll be a happy consumer again.

[mdedetrich]

birdie stop moving the goal posts. Not one of those 3 that you just linked was in the Nvidia list. The Nvidia list are Nvidia particular problems. I did not say there were not other problems.

Interesting point is the mozilla bug mentions that the problem with tearing was not appearing when using Intel and AMD with update drivers. Turned out to be a driver bug https://gitlab.freedesktop.org/mesa/mesa/-/issues/1992 Not wayland protocol. Yes part uploading textures under X11 would also causes flicker/tearing.

That keylogger one is kind of a joke and you fell for it hook line and sinker as normal birdie. What is the point of putting LSM protections around X11 server when the X11 protocol says you can key log anything. Wayland protocol is designed to be secure so if you protect the wayland compositor and wayland applications with lower down layers it does come protected.

The HDR one is real problem.

Birdie there are a lot problems that turn out to be vendor or driver problems not wayland protocol problems. Yes some cases Wayland compositors made existing random opengl issues under X11 totally repeatable bugs instead of hard to diagnose intermitt bugs

birdie there are a list of faults that are intel or amd particular as well that are bought out by running Wayland compositors being faults that really did existed with or without wayland compositor. The difference is how repeatable they were.

I did not say Nvidia was making stuff up. There are such things as Nvidia drivers particular problems just like there are AMD or Intel particular problems with their drivers. These driver problems have very little linkage to the wayland protocol.

https://en.wikipedia.org/wiki/File:W...r_protocol.svg Take a close look at this diagram birdie. Notice all the usage of EGL.

Wayland layout moves a lot outside Wayland protocol and Wayland domain. Yes EGL is not wayland protocol.

https://www.khronos.org/registry/EGL...buf_import.txt

Yes disputes over EGL are argued over at khronos group. Yes Nvidia was massively backing the EGLStreams solution while Intel AMD... were backing the DMA-BUF solution on Linux, freebsd.... This is a EGL implementation dispute. Lot of things Nvidia says new EGL extentions are need are in fact already implemented for AMD and Intel on the DMA-BUF backend. Of course since Nvidia was not involved in the writing of the EGL DMA-BUF stuff there is going to be issues. This is Nvidia problem to resolve at EGL Khronos group.

Lot of so called Wayland problems are not Wayland problems instead EGL khronos group problems including the fight over EGLStreams vs DMA-BUF solutions.

Yes yelling at Wayland protocol developers over a problem that has to be addressed at EGL khronos group is not going to get you anywhere. These are problems you need to yell at AMD/Intel/Nvidia... graphics driver developers so they can raise solutions with Khronos.

Actually you are conveniently ignoring that the majority of issues are due to defencies in Linux's graphics stack not support explicit synchronization, which is something even Intel/AMD admitted. NVidia's driver no longer supports implicit sync because its a decades old way of rendering and NVidia refuses to put back implicit sync into their driver because its a huge amount of effort for a workaround and that amount of effort would be better spent just implementing explicit sync properly in the Linux graphics stack.

Due to the design of X11 this wasn't an issue but this isn't possible with the Wayland stack because every single component of the stack needs to support explicit sync properly (and it currently doesn't).

Educate yourself by reading https://gitlab.freedesktop.org/xorg/...7#note_1358617 (this is actually the reason why there are Glamor problems with NVidia, its because of lack of support for explicit sync) and https://lwn.net/Articles/814587/.

These discussions are happening in the open on mesa's gitlab and the lack of proper support for explicit sync was the reason why NVidia created EGLStreams in the first place.

[Kivarnis]

HDR initially had nothing to do with games but everything to do with wide color depth, i.e. 30/36 bit displays which Vista indeed supported. I'm not stupid, crazy or say imbecilic things.

And I'm sorry to break it to you but HDR under Linux is in a state of poo poo. It doesn't work under Xorg (too many applications are completely broken), it's not supported under Wayland. It's 2022 and we've had such monitors for more than a decade now.

Your issues with HDR are not about Windows not supporting it but about multiple HDR standards and implementations which are hella difficult to get right. Except in Linux of course where HDR plain doesn't exist.

I appreciate you trying to "educate" me, but all you've done is further prove my point. I also never said Linux's HDR state was good nor bad, I said it was shit on Windows, and it is, good day sir.

[birdie]

I appreciate you trying to "educate" me, but all you've done is further prove my point. I also never said Linux's HDR state was good nor bad, I said it was shit on Windows, and it is, good day sir.

It [perfectly] works [in Windows] where there was an industry effort to get it right and it only doesn't work where there are no standards or too many conflicting standards and implementations.

Your assessment of Windows is so fucking disgusting it's beyond repulsive. In Linux there's no HDR at all, yet in Windows where hundreds of people try to make it work and it mostly works "it's shit".

That's everything you need to know about Linux zealots. Please don't reply to my messages ever again as I will ignore you from now on. I prefer to deal with people who use the brain, who are intelligent and who deal with reality. All these things are severely lacking in lots of Linux fans.

[Kivarnis]

It [perfectly] works [in Windows] where there was an industry effort to get it right and it only doesn't work where there are no standards or too many conflicting standards and implementations.

Your assessment of Windows is so fucking disgusting it's beyond repulsive. In Linux there's no HDR at all, yet in Windows where hundreds of people try to make it work and it mostly works "it's shit".

That's everything you need to know about Linux zealots. Please don't reply to my messages ever again as I will ignore you from now on. I prefer to deal with people who use the brain, who are intelligent and who deal with reality. All these things are severely lacking in lots of Linux fans.

Thankfully you can't tell me what to do. So I shall do as I please, same as you do. It does -NOT- "perfectly" work, it has never perfectly worked, it is a constant pain point for all HDR content consumption on Windows. There is nothing special about this, or my last 3 rigs capable HDR that it regularly broke and over brightened or simply failed to activate on numerous occasions. LTT has shown it breaking a multitude of times on everything from a movie, to photoshop. You're wrong, you won't admit it and that is okay, you got a agenda, I get that, just wish you were honest about it.

For the record, I've used Windows almost my entire life, I stopped using HDR because it works so inconsistently, though amazing when it does. I do hope Linux gets it sorted sooner than later, for sure. But I stopped using Windows because 10 a is pile of crap and breaks a lot. I have more faith Linux will get it sorted than it ever getting sorted in Windows, being how long it's been "in the works" like so much else, including tabbed file explorer!

[oiaohm]

Actually you are conveniently ignoring that the majority of issues are due to defencies in Linux's graphics stack not support explicit synchronization, which is something even Intel/AMD admitted. NVidia's driver no longer supports implicit sync because its a decades old way of rendering and NVidia refuses to put back implicit sync into their river because its a huge amount of effort for a workaround and that amount of effort would be better spent just implementing explicit sync properly in the Linux graphics stack.

Yes Nvidia might want that but you did not read what you quoted carefully enough.

Due to the design of X11 this wasn't an issue because of the design of X11, but this isn't possible with the Wayland stack.

Educate yourself by reading https://gitlab.freedesktop.org/xorg/...7#note_1358617 (this is actually the reason why there are Glamor problems with NVidia, its because of lack of support for explicit sync) and https://lwn.net/Articles/814587/.

Would have paid to read that LWN Article closer.

- Vulkan: Explicit synchronization all the way but we have to go implicit as soon as we interact with a window-system. Vulkan has APIs to import/export sync_files to/from it's VkSemaphore and VkFence synchronization primitives.
- OpenGL: Implicit all the way. There are some EGL extensions to enable some forms of explicit sync via sync_file but OpenGL itself is still implicit.
- Wayland: Currently depends on implicit sync in the kernel (accessed via EGL/OpenGL). There is an unstable extension to allow passing sync_files around but it's questionable how useful it is right now (more on that later).
- X11: With present, it has these "explicit" fence objects but they're always a shmfence which lets the X server and client do a userspace CPU-side hand-off without going over the socket (and round-tripping through the kernel). However, the only thing that fence does is order the OpenGL API calls in the client and server and the real synchronization is still implicit.

Vulkan yes the standard allows you to implement a driver without implicit until you interface with the OS window system this is not a Linux only limitation this is a limitation on all platforms where Vulkan is implemented. That LWN write up as not that clear.

Opengl and EGL that Wayland compositor use don't have a properly agreed on method for anything other than Implicit. The reality is Nvidia needs to implement Implicit to conform with what the opengl and EGL standards say.

These discussions are happening in the open on mesa's gitlab and the lack of proper support for explicit sync was the reason why NVidia created EGLStreams in the first place.

EGLStreams was push up to Khronos group and basically not taken on board. Vulkan that has implicit sync when dealing between the host OS and application has been taken on board.

https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html#dma-fences

Does DMA-BUF support support Explicit sync the answer is yes it does with the sync-file system this existed when DMA-BUF was first created. Yes the lwn writeup mentions this.

Yes there are EGL and OpenGL extentions to use DMA-BUF with sync-files.

The only change to DMA-BUF is add the ability to put the sync-file in the DMA-BUF metadata with call to added to sync-file to the meta data and call to abstract it from the metadata. Yes that change removed the need for the Wayland protocol to ship around sync-files. Yes another possible change would be making Implicit Fence Poll work correctly with a sync-file connected DMA-BUF so that legacy compositors and applications cope with being handed Explicit sync metadata DMA-BUF by having it act like Implicit sync if that function is used.

Being tear free you still need to resolve the sync when you get to KMS so this being implicit sync or explicit sync makes limited difference because this is a sync resolve point.

mdedetrich something to remember DMA-BUF comes out of joint work between Intel and Nvidia over PRIME support so there is no missing core functionality here the ABI many need a little modification to be more user-friendly. That is the hard point DMA-BUF has always had Explicit sync and Implicit sync.

Eglstreams going it own way never made much sense since in shared output GPU setups Nvidia driver had to deal with DMA-BUF because it part of prime to use the output connected by Intel or AMD on Linux.

The major reason why Nvidia wanted Eglstreams was not to solve the explicit sync problem but to keep as much of the internals of their driver secret as possible.

The feature difference between KMS/DMA-BUF and Eglstreams solutions are not major. You do run into problems with Eglstreams in cases where you must have Implicit sync and everywhere is fairly much coded Explicit only this is where Vulkan was smart with particular areas being implicit sync. Remember your legacy opengl and EGL applications don't know Explicit sync at all and even your modern wayland applications when dealing with the platform can be expecting implicit sync.

The horrible reality is GPU drivers or GPU stack need to implement support for both implicit sync and explicit sync. Yes its really simple to miss that opengl, egl and vulkan mandate at least some implicit sync support. This is not wayland protocol problem. This is existing graphical stack standards problem. Yes this is very much should have been Khronos group problem this as requires all GPU vendors to come to a proper agreement. Eglstreams from Nvidia proves this cannot be brute forced by them. mdedetrich the fact this is having to be sorted out in the Mesa mailing, LWN and so on is really a failure of the Khronos group to come to properly resolved solution.

Yes there are particular problems that are not Wayland protocol but some people will attempt to claim are Wayland protocol problems. Wayland protocol removes means to not resolve them properly. Yes some of the horrible issues you run into with open-gl applications and nvidia on Windows and Linux is caused by the non conformance to standard over this sync problem.

Yes I would like to see this stuff with sync sorted out properly. Yes Nvidia, Intel, AMD, Arm .... developers all sitting in a room possible locked in there until they have come up with the properly aggreed standard modifications that they will all agree to implement so this is no longer a mess. Yes getting everyone on DMA-BUF does get us one step closer to properly resolving this sync problem. But there are still a lot of problems with Opengl and EGL with it.