Not really. You're still so stubborn about having no DAL.
How do you propose should AMD develop an additional driver functionality for Linux, Mac, Windows and Android, and release them on the same day, without writing code twice, without such a DAL?
You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
But that's not true for GPU drivers anymore.
GPU drivers have to get feature updates every few weeks, and add new functionality and new APIs on all platforms at the same time with the same APIs. Often APIs that are completely new.
You can't write all this functionality 5 times for every platform while staying competitive with NVIDIA. The only choice is having a stable ABI to write driver extensions that implement the same new functionality for all platforms, or you'll never get the functionality.
And, guess what, that's exactly what happened.
Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality. They absolutely can not release new features every week for the mainlined driver in the official kernel and write them separately for every OS. The alternative is a DAL, or no functionality.
Thank you for driving more users to Windows.
That isn't necessary.
> without writing code twice
That isn't anywhere near as difficult as you make it out to be. Writing code is not difficult, or particularly time-consuming. Designing code is.
Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. to run incorrectly to optimize for a specific proprietary game engine. Those updates are to the OpenGL/etc. implementation itself, not the communication with the kernel, meaning those changes will be similar, if not exactly the same in each driver, without any extra abstraction. Also remember that most of these AAA title games do not have Linux support in the first place, and many of them only support DirectX, which will not be implemented in the Linux driver.
Here in Linux, we care about FPS in proprietary game engines much less than correct working drivers.
> You're still thinking of drivers in the old-school thinking of implementing an existing ancient API that, once it works, only ever gets bugfixes.
It's true that graphics APIs (especially Vulkan) are continually changing, and that those changes must be implemented in each driver. That still does not mean it is significantly easier to write one implementation for windows, and just copy it to the Linux driver. In fact, those who work on Linux itself believe the opposite. It's also worth noting that Vulkan is meant to be so low-level that its implementations will likely be quite different between Windows and Linux.
> AMD has to compete with NVIDIA (which has a DAL!) with less developers, less money, and needs to provide the same functionality.
If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
> Now we'll never get freesync, HDR10 support, AMDs ANSEL competitor, or any of the other functionality on Linux.
You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for. That means you are relying on AMD alone to implement them, so I am entirely unable to help you. That is the situation we started with for the entire driver, and AMDGPU marks a significant improvement.
You may believe that Linux devs compromising to allow AMD to create a complicated layer in their mainline driver would help them, but I don't believe that to be the case, and neither do they.
The true reason that AMD wants a DAL in their driver is that they aren't willing to entirely discard their old habits, and instead insist on a driver that is, at least partially, closed source. As long as they do that, they require themselves to do wildly unnecessary work, and create entirely worthless incompatibilities, purely out of stubbornness. Stubbornness that will continue to be reciprocated by the Linux dev team.
I will continue to do what I can to support AMD, as long as they make strides toward Free drivers, but I know there are always politics involved, and that AMD won't change overnight.
Yes it is, if you care about your users.
> Most of the "updates" you are talking about are usually tuning OpenGL/Direct3D/etc. t
Thanks to Vulkan that’s irrelevant anyway – I’m talking about stuff like shadowplay or similar functionality, and the APIs for that.
> It's true that graphics APIs (especially Vulkan) are continually changing
> You mentioned a few of the "technologies" that AMD seems insistent on a proprietary implementation for.
Stop being so stubborn, please. You still don’t get it. I’m not talking about the graphics APIs, which change on a scale of months to years.
I’m talking about exactly these additional functionalities, which are basically addons to the driver, hook into the driver, and for example dump the driver state at a moment (for 3D screenshots), or keep a memory buffer of the current videostream (for instant replay and share), or so on.
None of this functionality has to be closed source.
If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
> If AMD works with the kernel devs, they will have more developers. It's the idea that a manufacturer must force themselves to do all the work that makes no sense to me.
You mean, developers that still don’t get the entire point of what I’ve been talking about, developers that suggest they’d rather have people use Windows than add a stable driver ABI into Linux, developers that want to force a release cycle of several years onto drivers?
Because that’s the reality of forcing drivers to be mainlined without a stable ABI.
The majority of users will be stuck on a several year old kernel.
How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
I do. Believe me, I do.
> developers that still don’t get the entire point of what I’ve been talking about
They do too. They acutely understand all of the advantages and drawbacks of a HAL, and how it would effect the project that they work on, and have chosen explicitly not to allow one. I'd like you to understand why, because these are intelligent people, many of them dedicating time and expertise for nothing in return but the satisfaction of the contribution itself.
It sounds like a great idea to have an abstract interface for these things. That's what a microkernel is all about. Microkernels are great, but Linux is a monolithic kernel. That is the core of its design. Linux isn't going to adapt its core design to be more compatible with proprietary software. In fact, Linux should do nothing to be more compatible with proprietary software, because that would simply perpetuate the problem.
A monolithic kernel does have some advantages.
* The kernel can change without breaking drivers, because drivers are part of the kernel
* There is no layer between drivers and the kernel, meaning no overhead, no translation, but raw communication.
These advantages are fundamentally broken by introducing abstraction layers. Extra abstraction also introduces more maintenance work.
If AMD really wants a microkernel, it can start focusing on its FreeBSD driver.
> None of this functionality has to be closed source.
That is entirely my point.
> If you want to have this functionality open, the best solution is to work on a stable ABI for them, so that AMD builds many separate modules for each, and you can slowly clone each of them with an open version, or AMD can selectively open them.
That is a compromise. A compromise that kernel devs are not willing to make. Linux is Free Software. Free as in Freedom. Free software users do not have to deal with the problems that are caused by proprietary software, of which there are many.
> How the hell do you propose adding functionality with a latency of a few days or weeks between design and release into a kernel that only does releases every half year, and LTS releases every few years?
> The majority of users will be stuck on a several year old kernel.
The "majority of users" are running enterprise servers. That is the only reason to use a longterm kernel release. Users of a longterm kernel will not expect driver updates, in fact expecting the opposite. The vast majority of users similar to you will be running stable kernels.
> Stable kernel updates are released on as-needed basis, usually 2-3 a month. [1]
That is an entirely reasonable time-frame for updates. If users want a more bleeding-edge release, they will use prepatch (RC) kernels.
Okay, I had to seriously burst out in laugh there. You do know Torvalds opinion on the GPL, and how he has ridiculed people trying to enforce the GPL on companies that fork Linux and publish proprietary forks?
And you do know that Torvalds considers the best option to find a compromise with the company, and slowly work on that?
> The vast majority of users similar to you will be running stable kernels.
And yet, where is Ubuntu 16.04 now?
> I do. Believe me, I do.
And yet, you don't seem to.
> If users want a more bleeding-edge release, they will use prepatch (RC) kernels.
I want the in-kernel functionality to be stable and LTS, but additional user-space functionality to be the most recent.
That kind of modularity is only possible if you actually have a modular system.
Do you know how annoying it is to debug a kernel crash when you're writing a device driver, because the kernel devs again changed some random API slightly around? And how much nicer it is to do this in userland? If you've ever written drivers, you know. And do you know how much nicer it is to separate a driver into modular pieces for the base functionality, and additional modules for addon functionality, such as the macro functionality of my keyboard?
Yet, with Linux, users get worse software, later, with more breakages, and half their hardware doesn't work. Tanenbaum was right.
Monolithic kernels are broken by design.
Yet, the kernel dev team do not want this particular compromise. It would go against the design they prefer to work with.
> And yet, where is Ubuntu 16.04 now?
Why are we talking about Ubuntu 16.04? Oh, right, you are trying to run AMDGPU-pro, and that is the specific distro version that AMD chose to support. Are you mad at the Linux devs or mad at AMD?
> I want the in-kernel functionality to be stable and LTS, but additional user-space functionality to be the most recent.
> That kind of modularity is only possible if you actually have a modular system.
Those are entirely reasonable things to want, but you aren't likely to find them with Linux. Linux is monolithic. It sounds like what you want is FreeBSD, with the support from AMD that Linux is getting. Currently, FreeBSD isn't very popular, so AMD chooses to ignore it.
> Yet, with Linux, users get worse software, later, with more breakages, and half their hardware doesn't work.
That has not been my experience during the years I have spent using Linux. In fact, I have experienced better software, sooner, with fewer breakages (especially in NixOS), and the vast majority of my hardware works. The only hardware that doesn't work are sound cards or obscure wifi adapters that have only incompatible proprietary drivers (I actually ran out of those. All my wifi adapters currently work without effort.). So sound cards are the only issue I have left. That's it. I have a nice USB DAC anyway.
I'm running KDE Neon, which only exists as version based on Ubuntu 16.04
> Those are entirely reasonable things to want, but you aren't likely to find them with Linux. Linux is monolithic. It sounds like what you want is FreeBSD, with the support from AMD that Linux is getting. Currently, FreeBSD isn't very popular, so AMD chooses to ignore it.
My goal is this:
(a) 100% free software in my life
(b) no compromise on cost, or functionality.
The DAL is the only possible way I can get that.
I want 100% of the functionality, at the cheapest price, with entirely free software.
That's why I've been spending 4 years of my life to build a hacky copy of every single cloud service or proprietary software I might rely on. And that's why I want the same for the drivers, it's why I've been writing hundredthousands (!) of lines of code by now to replace software, cloud services, and android driver modules.
The DAL with an open source, but out-of-tree driver, is the only way I'd ever get close to this. Any other option leads to more proprietary code in my life. Therefore, your actions are the same for me as the actions of Google: they attack my freedoms.
I was annoyed at the teething problems too, but the progress has been good enough that I stable API doesn't seem necessary. If they hadn't tried to work in their own abstractions then the progress might have been better.