Besides that, how could they stop development of the free driver? Even if they fire the open source developers I bet the driver would be continued by volunteers, in the same way the nouveau team works.
Last edited by Vim_User; 03-25-2014 at 07:27 AM.
With a common DRM driver, GPU resets for us older R600 cards might be fixed if fglrx's kernel bits fold into the radeon DRM driver this is something I hope can happen. I can't just replace my laptop GPU you know, stability has been a big issue for me on my RV635 and perhaps fglrx's kernel has some errata/workarounds.
I wonder, shouldn't AMD let the FLOSS AMD employees see fglrx's kernel driver directly instead of keeping the teams separate? Or they do?
You also do know that Mr Bridgman did not release all the documentation he handed us, contrary to our agreement?
You also do know that documentation stopped in february 2008, when AMD ran out of money and the work with SuSE discontinued? (only recently did some documentation seep out again).
And before you say "But,", you should also know that the Instruction Set Architecture documents were not released by Mr Bridgman, but were released by the AMD GPGPU guys, a team which was wholly separate from ATI in late 2007 already.
People might want to read the original proposal written by Egbert, Emmes and myself, which started this whole open source strategy, and which pushed ATI to a point where they couldn't backtrack anymore.
You might want to consider the bit:
"AMD may additionally provide 3D shader optimization in an encapsulated module that can be dynamically loaded into libGL."
We wanted fglrx to turn into a module with solid, opensource: modesetting/display, 2D support, Media support and basic 3d support. But Mr bridgman had other plans, and helped foster competing projects, and only released Docs as far as he was forced to by AMD (which died the second AMD ran out of money).
Now, about the future: you will not get fglrx running on top of KMS. You will also not get it working with Mesa or other things. The kernel driver will, _at_ _most_, be moulded into a form where fglrx can make use of some shared in kernel memory management. I doubt command submission/CP will even be shared.
Oh boy. When reading the article I thought "libv is going to see this eventually..." and so he did, as grumpy about it as ever
Ok, I get that. But in recent years the open source driver got most features one way or the other.Fortunately then, "common sense it not so common." Just as we have workstation customers that need the features and performance of the Catalyst driver, we need the open source stack to service others. Embedded customers use a huge variety of Linux variants and it's difficult to support them all using closed source. The open source drivers are not going away.
Can you people guarantee that the gallium driver will be treated as a first class citizen and still get all the features/docs or it will be used only as a fallback in cases catalyst can not be used?
If people expect the community to take over the development (as suggested in a post) then this would be a huge step in the wrong direction in my opinion.
If I miss something then I apologise