Regarding EGLStreams Support in KWin(lists.sr.ht)
lists.sr.ht
Regarding EGLStreams Support in KWin
https://lists.sr.ht/~sircmpwn/public-inbox/%3C20190220154143.GA31283%40homura.localdomain%3E
42 comments
Either the technical or the political appeal is enough to reject the EGLStreams series.
There are APIs that offer the same features and are used by every other Open Source driver. Just implement those.
Nvidia truly is the last vendor in the GPU space that is actively hostile to Open Source.
Don't get me wrong, the developers at NVidia that are out there contributing to projects are nice&intelligent people with the best intentions. But their corporate parent is actively hostile.
There are APIs that offer the same features and are used by every other Open Source driver. Just implement those.
Nvidia truly is the last vendor in the GPU space that is actively hostile to Open Source.
Don't get me wrong, the developers at NVidia that are out there contributing to projects are nice&intelligent people with the best intentions. But their corporate parent is actively hostile.
There are actually technical reasons GBM can't be used by nVidia.
first is that it's tied to Mesa and secondly it has performance issues with non-display outputs (e.g. VR).
first is that it's tied to Mesa and secondly it has performance issues with non-display outputs (e.g. VR).
GBM doesn't necessarily have to be the answer here.
Just providing an implementation of EGLStreams support for mesa could be another.
Just providing an implementation of EGLStreams support for mesa could be another.
Or the allocator library, they were talking about and didn't get anywhere.
I am not sure if open source developers rage against nVidia for justifiable reasons or not.
They were the first to provide actually usable GPU drivers on Linux. But then the kernel guys became upset because they couldn't see the insides of the drivers. IIRC they started the holy crusade when they introduced the tainted flag in the kernel and made it policy to ignore all bug reports from kernels with that flag set. That was designed specifically to make nVidia look like a bad actor. There have been a number of similar sleights against them from various developers and the company took the beating and has so far worked stoically around all of these hurdles that were erected.
I am not saying that they are saints, but singling out the vendor of the objectively best GPU hardware and software package in the market like that does not feel right, either. There are tons of users out there that have practically no alternative to that hardware and they are being screwed over. And they are one of the few markets in which Linux actually has a dominant share in.
Long story short: I believe that kind of ideology first thinking might do the Linux software stack in in the long run.
They were the first to provide actually usable GPU drivers on Linux. But then the kernel guys became upset because they couldn't see the insides of the drivers. IIRC they started the holy crusade when they introduced the tainted flag in the kernel and made it policy to ignore all bug reports from kernels with that flag set. That was designed specifically to make nVidia look like a bad actor. There have been a number of similar sleights against them from various developers and the company took the beating and has so far worked stoically around all of these hurdles that were erected.
I am not saying that they are saints, but singling out the vendor of the objectively best GPU hardware and software package in the market like that does not feel right, either. There are tons of users out there that have practically no alternative to that hardware and they are being screwed over. And they are one of the few markets in which Linux actually has a dominant share in.
Long story short: I believe that kind of ideology first thinking might do the Linux software stack in in the long run.
> But then the kernel guys became upset because they couldn't see the insides of the drivers.
I think you are misunderstanding how drivers and linux work. Being able to inspect how the code works is a technical requirement. Linux internal API is not stable and drivers get refactored over time. Drew makes that point in his post and gives an example of Wifi drivers in it.
I think you are misunderstanding how drivers and linux work. Being able to inspect how the code works is a technical requirement. Linux internal API is not stable and drivers get refactored over time. Drew makes that point in his post and gives an example of Wifi drivers in it.
Define "technical requirement". It's not really technical, it's political. As an end user, I couldn't care less about being able to inspect how the code works. What I would like is for Linux to have a stable API for drivers, so out-of-tree drivers could work on every release without DKMS or crap like that. Windows could do it, so it's definitely not a "technical requirement".
If they are afraid of getting bug reports from guys running out-of-tree drivers, they can still keep using the "tainted" mechanism. It is not incompatible with having a stable API.
If they are afraid of getting bug reports from guys running out-of-tree drivers, they can still keep using the "tainted" mechanism. It is not incompatible with having a stable API.
Windows developers have access to the source code under NDA. This is much less feasible for Linux developers, obviously.
That's got nothing to do with having a stable API. There are thousands of device drivers that were written over 10 years ago which work perfectly well on current versions of Windows and which will keep working for years to come.
Linux made the political decision not to allow this, at the expense of end users.
Linux made the political decision not to allow this, at the expense of end users.
That seems the exact opposite of my experience. Most hardware drivers break after one or two Windows versions once the vendor stops updating the driver, eg. audio hardware, printers. On Linux things generally keep working. As an end user, having drivers in-tree is one of Linux's best features.
Having drivers in-tree is great, but a lot of drivers can't or won't be in-tree. My webcam (using qc-usb), PDA (using synce) and TV capture card (I can't remember what the project that supports those was called) all stopped working on Linux, even though the drivers were open-source and seemingly high-quality, because that's not enough for Linux - you have to be in-tree or you'll get broken.
At the time when I had TV capture card (Hauppage PVR250; it was analog TV tuner with MPEG-2 hw encoder), it stopped working in Windows way before Linux: in XP, the driver installation was showing HRESULT errors, but once a blue moon it would succeed. Forget anything newer. With Linux, I think it should work with the current ivtv driver, but I don't have it anymore to try.
Another example are scanners. Does your driver for Windows use TWAIN? Well, then it won't work in Windows 10 anymore, which made WIA the only option. Lot of fun for folks, who were automatically updated.
Another example are scanners. Does your driver for Windows use TWAIN? Well, then it won't work in Windows 10 anymore, which made WIA the only option. Lot of fun for folks, who were automatically updated.
Tell that to my Brazos GPU that lost capabilities with AMD driver's reboot.
Being open source didn't help at all.
Being open source didn't help at all.
> thousands of device drivers that were written over 10 years ago which work perfectly well on current versions of Windows
Is that really true? A couple months ago I bought a USB to serial adapter that advertised Windows Vista support on the packaging. It did not work with Windows 10 at all, and I ended up returning it.
I have plenty of hazy memories of printers that worked fine under Windows 9x not playing nice with Windows XP.
Is that really true? A couple months ago I bought a USB to serial adapter that advertised Windows Vista support on the packaging. It did not work with Windows 10 at all, and I ended up returning it.
I have plenty of hazy memories of printers that worked fine under Windows 9x not playing nice with Windows XP.
It's unfair to use printers as an example. For one, they're still a huge problem in Linux, but for two they're universally regarded as some of the crappiest things to work with in all of IT.
Printers under Linux have also one positive feature: if the specific model is supported, it is really plug and play.
The hard part is to choose, which model to purchase.
The hard part is to choose, which model to purchase.
In my experience that is not true. The few printers I've had to set up on a Linux device required me to go find PPDs.
My experience is, that I go to the printer control panel and the printer is already there.
Fedora & Ubuntu; mostly HP printers.
Fedora & Ubuntu; mostly HP printers.
You sound like everyone who talks about how Linux "just works" if only they choose exactly the right hardware and distribution combination.
Well, if you choose a more hardcore distribution that doesn't "just work" and requires tinkering, it is hardly a Linux fault.
Well, 9x and XP were two completely different operating systems that just implemented similar user space APIs. That was a one time transition. Drivers written for NT or 2k might have worked.
> Linux made the political decision not to allow this, at the expense of end users.
There are many pros and cons of having a stable API, and it can be technical and political and more. Saying it's just a "political decision" is plain wrong.
There are many pros and cons of having a stable API, and it can be technical and political and more. Saying it's just a "political decision" is plain wrong.
I believe that the Linux folks don't want a stable ABI because they want to be able to smoothly redesign the internal architecture of their kernel whenever they want. Once you have a stable ABI, you have to worry about continuing to support the model of that ABI for a long time (or, if something akin to the "don't break userspace" policy were adopted, forever), which ossifies your design & blocks you from adding certain features. Additionally, by applying technical and political pressure to move drivers in-tree, the kernel devs gain the power to self-maintain over time (even Windows breaks its ABIs every once in a while and causes havoc: see Vista)
That's the rationale Linux people give. But FreeBSD has managed to maintain much stronger backwards compatibility (with older ABIs gradually moved into -compat modules and eventually removed entirely) than Linux without it noticeably damaging kernel development speed. Linux is the only major platform where hardware that worked frequently stops working (not just because of closed-source drivers; the same problems exist for open-source drivers that are out-of-tree for whatever reason - there are plenty of high-quality open-source drivers that the kernel doesn't accept in-tree or that don't want to be in-tree), and what do you actually gain for that high price?
> What I would like is for Linux to have a stable API for drivers, so out-of-tree drivers could work on every release without DKMS or crap like that. Windows could do it, so it's definitely not a "technical requirement".
Quit the rage and just stick to Windows then. I'm using NVIDIA card and don't want to have this supposedly "stable API" which would leave me at the mercy of their whimsy. NVIDIA as a company deserves much more shame than the middle finger which Linus gave them. And there's no politics here, it's simply their business decision not to support Linux, not the other way around. Once you make an exception for one company you ought to do this for everyone else, it's not how that works in the Kernel community. So yeah it is a "technical requirement", technically it is how drivers get their stable implementation there.
Quit the rage and just stick to Windows then. I'm using NVIDIA card and don't want to have this supposedly "stable API" which would leave me at the mercy of their whimsy. NVIDIA as a company deserves much more shame than the middle finger which Linus gave them. And there's no politics here, it's simply their business decision not to support Linux, not the other way around. Once you make an exception for one company you ought to do this for everyone else, it's not how that works in the Kernel community. So yeah it is a "technical requirement", technically it is how drivers get their stable implementation there.
> They were the first to provide actually usable GPU drivers on Linux.
Indeed. They raised the bar for Linux graphics. Maybe 10-20 years ago?
And then later ATI/AMD came along. And now their driver, the only driver, is open-source.
That is, they publish not only a driver, but more importantly the driver source. As is now true for pretty much all drivers for all HW Linux supports.
The bar has clearly been raised again. And now Nvidia is the only one lagging.
I don’t see anything unreasonable about asking them to contribute at the same level as everyone else.
Imagine how Linux would look today if all vendors got a free pass with doing things “their way” like Nvidia does. I doubt it would be functional at all.
I’m not going to cut Nvidia any slack today over what they did back in the days where everyone agreed M$ was evil and Google could do no wrong. It was a loooong time ago.
Indeed. They raised the bar for Linux graphics. Maybe 10-20 years ago?
And then later ATI/AMD came along. And now their driver, the only driver, is open-source.
That is, they publish not only a driver, but more importantly the driver source. As is now true for pretty much all drivers for all HW Linux supports.
The bar has clearly been raised again. And now Nvidia is the only one lagging.
I don’t see anything unreasonable about asking them to contribute at the same level as everyone else.
Imagine how Linux would look today if all vendors got a free pass with doing things “their way” like Nvidia does. I doubt it would be functional at all.
I’m not going to cut Nvidia any slack today over what they did back in the days where everyone agreed M$ was evil and Google could do no wrong. It was a loooong time ago.
Unless you have a really old OS version, you actually don't get your driver from AMD, you get it as a part of your Linux kernel: most Linux drivers aren't managed as standalone open source software projects, they are simply merged into the kernel itself.
> you actually don't get your driver from AMD, you get it as a part of your Linux kernel
Thankfully.
However, the open source driver that is now part of the Linux kernel did indeed come from AMD, and could not have come from anywhere else.
Your parent said AMD publishes the sources to its (only) driver. That they happen to publish it with the Linux kernel wrapped around it, through kernel.org, is also true, but not incompatible with the claim that they publish it.
Thankfully.
However, the open source driver that is now part of the Linux kernel did indeed come from AMD, and could not have come from anywhere else.
Your parent said AMD publishes the sources to its (only) driver. That they happen to publish it with the Linux kernel wrapped around it, through kernel.org, is also true, but not incompatible with the claim that they publish it.
> And then later ATI/AMD came along. And now their driver, the only driver, is open-source.
Open-source is great but is their driver remotely competitive in terms of actual usability/quality? As a desktop user I find ATI/AMD is still nowhere near the bar set by NVidia. I believe open-source generally results in better-quality software, but that hasn't actually come to fruition in the ATI/AMD drivers IME.
Open-source is great but is their driver remotely competitive in terms of actual usability/quality? As a desktop user I find ATI/AMD is still nowhere near the bar set by NVidia. I believe open-source generally results in better-quality software, but that hasn't actually come to fruition in the ATI/AMD drivers IME.
> is their driver remotely competitive in terms of actual usability/quality?
A resounding 'yes'. You must not be using their open source driver, or are using a very old one in your 'comparison' with nvidia's linux driver?
A resounding 'yes'. You must not be using their open source driver, or are using a very old one in your 'comparison' with nvidia's linux driver?
I tried it twice a few years ago. The first time I tried it it just had no support at all for the card (apparently too new); the second time it "worked" but felt pretty flaky, things like locking up much of the time if you tried to switch between X and console. Maybe it's better now - my experiences were bad enough that I swore off AMD for a while. (This was well after the point when their open-source drivers were established and people on HN were telling me they were good, though)
I have Vega 64 in my desktop, since the non-blower designs became available, and I had no problem with the amdgpu+mesa driver.
It is nice to have it work out of the box.
It is nice to have it work out of the box.
It is common knowledge that the AMD FOSS drivers nowadays work quite well. Spending a couple of minutes on Phoronix can verify that (they regularly report on such news). You even got multiple drivers to pick from (2 FOSS, 1 proprietary).
How much do you stress the GL implementation? See, I write rendering code fairly regularly and I need drivers that don't keel over in use cases that aren't covered by desktop compositing and the occasional properly ported AAA game title. What I have seen from AMD so far did not encourage me to even try and buy one of their cards.
> How much do you stress the GL implementation?
Quite a bit, I guess? I play a number of games, but no idea if they are "properly ported".
Quite a bit, I guess? I play a number of games, but no idea if they are "properly ported".
Properly ported simply means a renderer using OpenGL or Vulkan directly with the exact same feature set as the Windows version. Cutting corners in the port of the renderer counts against that.
I do research into rendering algorithms and that sometimes involves straying from the trodden paths. This means that I always get sceptical when I need to use a feature that is a bit more obscure. With nVidia, I rarely encountered bugs in the driver.
I know for a fact that the Mesa software renderer sometimes lies about what it really supports amd does something different and completely inappropriate under the hood instead. A good example is that Mesa claimed to support floating point textures even if the support was not compiled to avoid patent licensing issues. Instead it would use 8 bit per channel internally, which totally broke some algorithms. I had to find out the hard way because the values I read back were suddenly horribly quantized.
What I want to say with these anecdotes is that "being able to render games so that they are playable" just shows that the driver quality is passable. A great driver needs to get a ton of additional things right that are not commonly used for games.
I do research into rendering algorithms and that sometimes involves straying from the trodden paths. This means that I always get sceptical when I need to use a feature that is a bit more obscure. With nVidia, I rarely encountered bugs in the driver.
I know for a fact that the Mesa software renderer sometimes lies about what it really supports amd does something different and completely inappropriate under the hood instead. A good example is that Mesa claimed to support floating point textures even if the support was not compiled to avoid patent licensing issues. Instead it would use 8 bit per channel internally, which totally broke some algorithms. I had to find out the hard way because the values I read back were suddenly horribly quantized.
What I want to say with these anecdotes is that "being able to render games so that they are playable" just shows that the driver quality is passable. A great driver needs to get a ton of additional things right that are not commonly used for games.
Except that anyone using older AMD cards on laptops is pretty much alone, using a driver that only offers partial support for hardware features, unless we go back using legacy distros as means to use fxglr.
So much for open source driver.
So much for open source driver.
Using a laptop with a nVidia graphics card, where they have a monopoly, would also make you rage at them. For a year installing their drivers would prevent some laptops from even using text-mode because of improper PCI-E initialization, something that was only worked around on the latest kernel release.
They only care for Linux CUDA farms and it shows.
They only care for Linux CUDA farms and it shows.
Then again, it lead to very high quality drivers from first Intel and then AMD being included by default in every Linux distribution.
The user experience with that hardware is so much better as a result, it isn't even funny.
The user experience with that hardware is so much better as a result, it isn't even funny.
On the one hand, I agree about the ideology thing and think it is silly not to have stable driver ABIs, but on the other it is difficult to argue with the kernel devs' point when Linux currently has the best hardware support of any open source operating system, and some proprietary ones, by a ridiculously large margin.
> They were the first to provide actually usable GPU drivers on Linux.
You mean for 3d? Cause for 2d, we had Matrox Millenium/Parhelia in the previous century already. Which worked on Linux.
EDIT: As per [1] at least 3dfx of the famous Voodoo GPUs were there before Nvidia. In other comments throughout that thread people mention S3. I remember each of these brands being in the Linux kernel config.
[1] https://news.ycombinator.com/item?id=19182624
You mean for 3d? Cause for 2d, we had Matrox Millenium/Parhelia in the previous century already. Which worked on Linux.
EDIT: As per [1] at least 3dfx of the famous Voodoo GPUs were there before Nvidia. In other comments throughout that thread people mention S3. I remember each of these brands being in the Linux kernel config.
[1] https://news.ycombinator.com/item?id=19182624
(It doesn't appear in the thread because it's been forwarded)
EDIT: and here is a blog post about EGLStreams from another KDE developer (2016): https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-...
Here is a follow-up blog post from the same author (2017): https://blog.martin-graesslin.com/blog/2017/10/plasmawayland...
Here are some (technical) discussions on wayland-devel about EGLStreams (2016): https://lists.freedesktop.org/archives/wayland-devel/2016-Ma...
Here are some recent IRC logs from #wayland, also discussing EGLStreams: https://dri.freedesktop.org/~cbrill/dri-log/?channel=wayland...