Well, they've developed their EGLStream approach and that probably cost some resources on their end so the question is why they decided to go that way at all. It seems like a waste to me to develop something nobody is going to use and I don't see the business reason for this particular development.

afaict the only people who really care about EGLStream are nvidia. And while GNOME and KDE might have the resources to support both API's (much as they don't want to), smaller projects like sway simply don't have the resources to worry about that.

I think one of the biggest failings of wayland is that it requires so much duplication of effort between different compositors. Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.

>Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.

That would require a single standard for communication with GPUs and the problem is that Nvidia is refusing to implement that standard.

All it requires is a single standard interface for managing buffers, which exists and is named GBM.

Wayland doesn't care how you draw your buffers, and a custom EGL library as they already do, while gross as hell, is not at all a compatibility problem.

Or some kind of abstraction layer.

Even KDE was only able to gain support for EGLStreams after an NVidia developer Erik Kurzinger contributed the necessary changes to Kwin.

As far as I know that was mostly because they refused to even try and not because it was too hard or even complicated.

If one of the kwin developers had nvidia hardware, likely they would have cared enough to try. And if they didn't, how would they test and maintain the nvidia-specific code? Adding an entirely new code path for rendering would be a large support and testing burden that they may not have had the resources to take on.

> If one of the kwin developers had nvidia hardware,

So what your are saying is that NVIDIA could have just sent them a crate full of low end $50 dollar hardware and been done with it? I find that rather unlikely, or rather as an end user I prefer to think that there wouldn't be that much drama over what amounts to nothing.

Maybe? I don't know.

But, either way, having two completely separate graphics code paths means a much larger maintenance burden than one. Even with hardware to test on, I'd consider it perfectly reasonable to decide to only support one, especially if the odd company out is one with a history of not playing ball with the community.

EGLStreams is heavily used in industrial embedded, eg in nvidia's car platforms.

You got that the wrong way around:

Nvidia's platforms are a large part of industrial embedded, on which the users have no option but to use EGLStream.

So, I find this a bit weird

The nvidia driver doesn't play well with some basic apps, but it plays extremely well with games and other professional apps running on Linux (the whole reason for nvidia to put up a driver)?

The reason is simple: those using profesional apps are typically >100k/year engineers using apps that cost >10k/year. The developers of these Apps either put in a lot of money into supporting nvidia proprietary APIs, or, they contract nvidia to implement support for them. If you are big enough, nvidia does this for free.

It doesn't matter if AMD sells the exact same GPU as nvidia, because when you then switch BLAS for cuBLAS, the nvidia GPU becomes 100x better than AMD.

And that's just libraries, there is also tooling, engineering support, and well, software in general. Nvidia invests a lot of money on making sure that their GPUs come with a great proprietary AMD-incompatible software stack, and in integrating this stack with anyone developing products using GPUs.

I've worked on a couple of national supercomputers using AMD hardware, and AMD pays for ~1 AMD engineer full-time that works on improving the applications that run there. Nvidia pays for a couple of engineers that manage and tune the cluster for you, and a bunch more that work on peoples applications. Easily, 10x more engineers than AMD.

Even if AMD were to build better hardware, no sane industry person would pick them up over nvidia due to all other services nvidia offers.

It's chicken and egg problem. Nvidia was major backer of OpenGL, but their drivers were never conformant implementations that allowed a lot of incorrect shaders to compile and run. Yet Nvidia had best developer support so most of commercial apps were developed and tested against their drivers. As result those apps use non-standard codepath that simply dont work on conformant drivers. On top of that OpenGL compatibility contexts are not well documented or tested, but it's not strictly Nvidia fault.

In case of Wayland it was was opposite. It was developer by everyone, but Nvidia. Open source graphics stack developers found a way that work best for their hardware and supported it for decade. Recently Nvidia tried to join the parry while extending it with own incompatible addition that no one else needs. Obviously many open source proponents dont give a damn about their closed drivers so they only going to support primary APIs.