Slashdot Mirror
AMD Develops New Linux Open-Source Driver Model
An anonymous reader writes "AMD privately shared with Phoronix during GDC2014 that they're developing a new Linux driver model. While there will still be an open (Gallium3D) and closed-source (Catalyst) driver, the Catalyst driver will be much smaller. AMD developers are trying to isolate the closed-source portion of the driver to just user-space while the kernel driver that's in the mainline Linux kernel would also be used by Catalyst. It's not clear if this will ultimately work but they hope it will for reducing code duplication, eliminating fragmentation with different kernels, and allowing open and closed-source driver developers to better collaborate over the AMD Radeon Linux kernel driver."
Better integrated GPUs in lower-cost CPUs. Why choose Intel?
Get free satoshi (Bitcoin) and Dogecoins
... do they have to keep a proprietary driver anyway?
If they put all their man power just into the open source/ free software driver, who's damage would it be?
Seems AMD have taken on-board what Nvidia chose to ignore.
Being the advice offered by the Kernel devs
http://lists.linux-foundation....
Lower power consumption in better CPUs. Why choose AMD?
Who besides AMD would bother writing drivers for AMD hardware? And why?
Ever since I read this article, I have been taking a closer look at AMD. What I find is that this is a company in trouble. When I visit computer shops, I do not see anything equivelent to AMD Inside!
Question is: Does AMD still matter?
The X community has said specifically that this sort of end-run around the GPL is strictly forbidden. I expect yet another flame war over this at any moment.
"Trademarks are the heraldry of the new feudalism."
if they state Catalyst exposes OpenGL 4.4 instead of the 4.3 that is the reality for the rest of us. Minor nit but...
Linux has roughly 10% of the desktop market in the United States. You'd think that this kind of story wouldn't be so uncommon. As soon as SteamOS is released M$ won't have a chance. Windows 9 will likely be the last version of Windows.
It doesn't sound all that different. Everyone wanting to stay proprietary has a separate firmware to load by the module; but, the proprietary module has a few more whistles than the one from the community. Is this not the same thing?
Having to work for a living is the root of all evil.
That point was specifically addressed the the article. It isn't that AMD can't legally open up the code, but that is where they view their secret sauce of optimizations and tweaks. If they were to open it up, they fear that competitors might get a leg up and be able to use the same tricks.
As I've been Linux user for a while now, and am well aware of the articles that Phoronix put out on their god-awful website, is there a particular reason that AMD and other companies seem to cater to them on this front? As far as I can tell, they don't do much that's special other than being an announcement portal of sorts. If their claim to fame is just the latest 'bleeding edge' of graphics support for games on the Linux desktop and slapping it up on an advertised site, I guess I get it. If they're target audience is Linux desktop rookies pontificating of about framerates while waiting for the dev's to up the performance, they seem to have hit the mark. I'll admit, there was a time early on, pre in kernel radeon and AMD doc's share that they hit the mark on a few articles, but since then, I don't see them contributing much that's new to the conversation. I just don't see them doing much more than what you would find several thousand Linux users doing with their various dists. to squeeze more out of the graphics front. I guess they just have the name recognition. I can't be the only one who has heard them referred to as Moronix. Am I?
Maybe it's their hideous website. Maybe it's the ho-hum web illusion that they're an analysis site. Maybe it's just me. It just seems like they get special treatment for, well, not being special.
Not sure what you're thinking..
A Linux graphics card driver has 3 components: the kernel module, the X module and the libGL/CL/etc implementation.
There are two AMD driver for Linux -- the proprietary one and the open source one, each with it's own 3 components.
The proprietary one offers better OpenGL/OpenCL performance and features (eg, OpenGL 4.4 instead of 3.1), as well as official certification for a number of applications.
But it also tends to suffer from system integration issues, at the kernel and X level. Sometimes, they work poorly for basic things, they don't work with the latest kernel or X for a while, etc.
So, what looks here is that AMD wants to reduce the proprietary to the libGL/CL component and leverage on the open source for the kernel driver. Maybe X driver too, eventually.
Is VIA still in the race, at all? Last VIA I heard about was the C7, so it's been a hwile.
Get free satoshi (Bitcoin) and Dogecoins
...I would put a lot more trust in this development. Things like hangs and inability to standby (5+ year old problem) or more recently brightness control that worked until approx 14 months ago and since then was never (fully) fixed despite dozens of bug reports. I mean, this is a simple matter of comparing the code for brightness between the version 14+ months ago and the latest one to figure out what is the problem and then fixing it once and for all... Instead, they announce "fix" for it in two consecutive versions, neither of which address the problem in its entirety, and consider it fixed... Yes, some will argue open-sourcing this may help fix things faster. My experience tells me otherwise whenever you have this level if incompetence involved, because after all it is that same incompetence that will drive the separation of open and closed components... Downvote or not, I would love to be proven wrong so that I can finally install a fglrx driver that actually works as it should.
Intel is akin to a Toyota Camry as AMD is a Scion FR-S. On the Camry side of things, presuming the Camry has a V-6, it'll utterly smoke the FR-S, in the quarter mile and 0-60, it's much more practical, room for six and a big roomy trunk. The FR-S is less expensive but less practical, sits lower, a much smaller trunk a non-existent back seat and has proven to be much less reliable. Then again, the FR-S is a zooty two-door, rear wheel drive, and an utter hoot to drive, while the Camry is . . . a Camry.
Having just purchased an AMD Kaveri A10-7850, I've been having fun playing with the newness of the chip, yeah, sensors don't work, the Radeon (ATI) drive is butt-slow and Catalyst is in beta. Still I'm pretty sure that Kaveri has more under the hood than is initally obvious. For Radeon cards in the 4000,5000,6000 range, the open-source driver is neck and neck with the proprietary Catalyst driver. The 7000-8000 R7, R8 series has a ways to go for now but if those two drivers can start sharing more, everyone wins.
Just to let everyone know, my new Kavei is about as fast as my Intel Core I7-920 in most things and faster in others. As for gaming, I'm a Linux weenie, how many AAA games that really stress a GPU are even available (yet?) for Linux. Yes my gaming system is an Intel I7 and an nVidia 660 TI video card while my play system is my new Kaveri. I enjoy playing with Linux, trying out the bleeding versions of Mesa and the latest x11-driver-video-ati but if I'm going to waste time playing games in Windows, it had better "just work".
Intel needs AMD to keep from being a monopoly so instead of bashing either company, embrace them both, it is a nerd thing after all.
Most of the people who write drivers for Linux do so as part of their "day job"; they add a driver they (and their employer) need and everybody else benefits. There are no vast armies of highly-skilled driver writers sitting around looking for osbcure hardware that's just beggin for a clever driver and desperately hoping to do that tedious work for free. You can create a new device and release the specs on the web and you will NOT be confronted by a dozen great programmers volunteering to write free drivers. This teenage pipe-dream of how the world works has been repeatedly proven wrong.
What IS true about your comment is that SOME hardware attracts programmers who get a bit of hardware they want, get docs for it, and write free drivers that are "good enough" to satisfy their personal desires. Once the drivers do what THEY want, however, they typically lose interest (or get married and have kids, etc) and the code never reaches a level of general completeness to be seen as "professional"
Don't bother arguing about this if you have not written any complete drivers for a device on Linux (I have). Too many in Linux-land argue an ideology and support an ideal they BELIEVE in (like a quasi-religion). They believe in "open source" code like many religious people believe in "heaven" - but just like so many religious people, "they are unwilling to do what they must to get there" (i.e. live a "sin-free" life, or actually write and release significant open-source code).
The terms of both the GPL and the LGPL can be (according to my lawyer) interpreted to taint anything they touch (depending on how a judge reads them). The simple fact is that NONE of the code you write in C or C++ actually makes it into your binaries. The ones and zeros that comprise your binaries were copied into "your" object files NOT from your source code but rather from Mr. Stallman's compiler and linker. Your binary files can, therefore, be viewed as very complex derivatives of HIS code, or at the very least as having been linked with thousands (millions?) of fragments of his GPL'd compiler and linker programs. If the judge sees things this way, then even using the GNU tools taints your stuff and gives control of it to Mr. Stallman. If the judge sees things even slightly this way, then even dynamically linking to LGPL files is unsafe. This could have all been made explicitly clear by clear language in those licenses but the authors of those licenses intentionally did NOT add that clarity... there's NOTHING in those licenses that acknowledges the binary data produced by compilation and linking as originating in the compiler/linker and releases any legal liability for binary code thus produced. Stallman and his friends know this is how the binary code is produces, but they include NO language to resolve the issue. Indeed, I have been advised that the text of the LGPL is so self-contradictory (indicating that it's both safe and unsafe to "link" without being clear enough to illuminate lawyers) that it is more dangerous than the GPL.
Computer people tend to forget that most judges and lawyers are not coders, and "the law" is very complex and not always tethered to "common sense". If you think you are safe with the GPL and the LGPL you probably also do not believe "patent trolls" exist.
? "tainted" is just a flag, nothing more. It's there in case womeone sends them a bug report (a crach for instance), if the kernel is "tainted" their answer will probabaly be : try again without the "tainting" module and see what happens : if the problem goes a way they'll send you crying to the one responsible for THAT module, periode.
There's absolutely NO denying anything to any module.
Amen. Fingers crossed.
Hi there, you don't need the proprietary drivers anymore. I use steam games, like portal, and portal2 (beta, but works better than on windos 7, where my kids say it crashes a lot) on an ATI 75xx video card using pure open source drivers (ubuntu 14.04) and it runs really, really well. I don't know what, if anything is missing, The card may run a little hotter and a bit slower than the proprietary drivers, but it works well enough that I am thrilled not to have to bother with them anymore.
you're a f'in sellout troll. why don't you just move back to windows where you belong?
in this case I don't think there could be any claim made by the person distributing the GPL code.
to:
in this case I don't think there could be any claim made under trademark law by the person distributing the GPL code.
I think we've pushed this "anyone can grow up to be president" thing too far.
I've been using Linux since Slackware first came out.
As long as the response of Linux fanboys to any criticism is "Go away, you troll!" or "Go back to Windows, dude!" or "RTFM!" or "Use the Force, Read the Source!" ..... Linux cannot go mainstream. Real successful products pay attention to criticism and fix their failures. Religious cults denounce anybody who sees faults. The harm does not come from vendors of real products, it comes from crazy cultists attacking heretics.
There are calls that are not exposed to so-called "tainted" code. If recent Linux kernels see that you are running a proprietary driver (like the Nvidia driver) they refuse to allow that driver to make those calls and, in doing so, reduce the functionality ... so NO, it's not just that the word "tainted" shows-up in some logs (which would be mildly annoying like a child throwing a tantrum) this is the actual sabotaging of OS calls when you run code that disagrees with the political views of one or more Kernel Devs. So much for user "freedom"
The actual bytes of binary code in "your" executable (NOT the symbols in your source code) are copied into "your" binary file by the compiler as it connverts your source into a binary.
If your C++ code contains "int x=1;" and this translates (in part) into "mov eax,1" assembler YOU did not type that assembler code, the C++ compiler did... and NOT by having an invisible gnome type it (which would NOT be a legal issue) but rather by having an automated process copy it from within the body of the compiler's binary (which IS a legal issue if your compiler's license infects anything bits of it are copied into or linked to). Then in the Assembly pass, YOU did not convert that into the machine code (something like 0x1234 ... I'm not gonna compile something tupid to get the real value just for this post, but you get the idea I hope) the compiler/assember you used probably copied a piece of itself (from an internal table that matches binary opcodes to ascii opcode name strings) into the resulting binary file. This means "your" binary is actually a massive blob of binary code fragments copied into it from within the compiler (the copying process having been guided by the contents of your human-readable ascii source code file). NONE of your actual C or C++ code (well, except for constants) ends up in the binary executable file. Those ones and zeroes were all copied into that file from within the compiler or were dynamically generated in the compiler (in this latter case of generated bytes it's NOT a GPL/LGPL problem, but in the former case of copied bytes it potentially IS).
The point is that TECHNICALLY, given the poor quality of the GPL and LGPL writing, a judge and jury could easily rule that anything compiled and linked with GNU tools gets infected by the GPL or LGPL - and this COULD have been a hazard that was entirely eliminated if Stallman and friends had chosen to make this clear in their licenses BUT for some reason these very bright fellows who are intimately familiar with how we get from ascii source code to compiled binaries decided to leave a lot of gray area here for the courts to have a field day. This is a potential danger area for businesses, and commercial compilers are NOT a risk here because they are not tied to so-called "viral" license schemes (licenses that demand that they get inherited by other stuff they touch). There are many fine and admirtable aspects to the GPL, but I have been advised that the LGPL's supposed greater freedom is actually illusory and that both of these licenses make the GNU tools hazardous for the compilation/linking of non-open-source code.