And I disagree with that. AMD has said they'd publish it openly, but only in a version that relies on their abstraction layer.
Because implementing it the first time already is over budget and past deadline, implementing it twice would be impossible.
You can have a working, open source, version in a few weeks just by compiling AMDs kernel branch, and modules. But you'll never get it in mainline. And mainline will always be months or years behind.
Then if there is no licensing issue with the code they provide, someone is free to merge it to the mainline driver.
> implementing it twice would be impossible.
au contraire. Implementing anything twice is well within the realm of possibility, and porting the original implementation is even more likely. that is if the original implementation is open source.
If AMD had started releasing their Windows driver source, but refused to do any work with Linux, then the Linux dev team would be porting the entire driver. Fortunately, AMD has done better than that: they are working with Linux, at least for the most part, leaving the Linux dev team with much less to port, and us with a much better time-frame for feature-parity.
> And mainline will always be months or years behind.
I don't believe that. I believe that if AMD decides to start working with the kernel, as opposed to working with an abstraction layer, that we will start seeing these updates happen rather quickly and painlessly. Some at AMD may believe that working with mainline directly is too difficult, but I don't find that argument very compelling.
...then we wouldn't see any driver, or AMD would be dead.
AMD is months (!) to years (!) behind schedule already with a single platform to develop for.
How do you suggest they develop for two entirely different platforms, with the same budget, in less time?
> If AMD had started releasing their Windows driver source, but refused to do any work with Linux, then the Linux dev team would be porting the entire driver. Fortunately, AMD has done better than that: they are working with Linux, at least for the most part, leaving the Linux dev team with much less to port, and us with a much better time-frame for feature-parity.
Any time frame that isn't immediate is broken.
> Then if there is no licensing issue with the code they provide, someone is free to merge it to the mainline driver.
Yes, and the kernel maintainers refuse to do that, as they'd have to either maintain an entire separate driver, or continuously merge AMDs driver again, and again, and again.
________________________
They write one single driver for all platforms, and have already problems to do that development.
The alternatives are such:
(1) No AMD support on Linux at all.
(2) You personally pay the necessary billions to fund AMDs dev team
(3) An open AMD driver is continued, functionality is heavily limited and it is useless for any serious applications, so NVIDIA continues to dominate
(4) an open source driver is implemented for all platforms on top of a DAL
My goal is: A GPU with open source driver that is competitive with the best possible product on the market, and open.
The only scenario where this is possible is by either someone doubling AMD's budget, or with the DAL. Any action to prevent the DAL leads to more proprietary code in my life, therefore I consider it an attack on myself.
This is the problem with proprietary software. There are politics involved. Note that when I refer to AMD, I am referring to a group of people, not a single individual. Those at AMD and those third parties that they work with that insist on proprietary software have made my life miserable. The hours I have spent trying to find a stable configuration to run fglrx are a direct result of their belief in the need for proprietary software. I'm sick of their excuses. I'm happy to finally have a free driver for my RX480. It's not perfect, but it's a leap in the right direction.
> And it looks like we’ll end up with a significant (factor of 2 or worse) performance difference between Linux and Windows in the next years for AMD drivers due to that.
That is true. I see that as AMD's fault, not the Linux devs'.