AMD's 2016 Linux driver plans (AnandTech)
The significant change here is that by having the RTG closed source driver based around the open source driver, the company is now only maintaining a single code base, is pushing as much as possible into open source, and that the open source driver is receiving these features far sooner than it was previously. This greatly improves the quality of life for open source driver users, but it’s also reciprocal for RTG: it’s a lot easier to keep up to date with Linux kernel changes with an open source kernel mode driver than a closed source driver, and quickly integrate improvements submitted by other developers."
Posted Dec 15, 2015 21:13 UTC (Tue)
by fandingo (guest, #67019)
[Link] (28 responses)
On Linux, sure, but in general, untrue. I remember reading on Phoronix (so take that with a grain of salt) several years ago that Nvidia engineers disclosed that their proprietary Linux and Windows driver have >85% identical code. That's why Nvidia's drivers have always been so good on Linux: There's far less duplication of effort, and the significantly smaller Linux market benefits from the resources available from the Windows market.
Perhaps AMD is taking this approach, but that's not what's said in the article. It seems that they're still going to have separate Linux and Windows drivers, and there's no indication that the Linux driver will actually catch up with performance.
Even just on Linux, they have two drivers. I'm not sure how you can say that totally separate OpenGL, HSA, and OpenCL libraries don't make a new driver, and I'm at a loss to explain the desire to duplicate efforts. If they want to do open source, they need to open source their more performant closed-source drivers. If they don't want to open source those bits, just go with a proprietary driver and try to make it as great as possible.
Posted Dec 16, 2015 1:38 UTC (Wed)
by ken (subscriber, #625)
[Link] (3 responses)
I wish that the people working on graphics sat down and design some way to make it a lot safer and easier to change drivers. If you play with the kernel it installs in parallel if it do not work you simply start the old on. with graphics you have like 20 separate modules that all install over the old one with no way to get back it's just a mess.
This also makes it really hard to get started to contribute. you need to spend a week on reading before you even have a ruff idea what to do just to test the latest source in git.
And now most new desktop computer also have GPUs from two different vendors not really helping make things clearer.
Posted Dec 16, 2015 8:06 UTC (Wed)
by niner (subscriber, #26151)
[Link]
Posted Dec 17, 2015 19:36 UTC (Thu)
by tomstdenis (guest, #86984)
[Link]
1. It tends to have new device support sooner and a lot of that is still under NDA.
2. There are IP constraints (e.g. things that cannot be disclosed to the public) that would need to be sanitized. That's why there are all these magical constants in the open source UMD/amdgpu.
Posted Dec 17, 2015 20:52 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
Yes, I have been thinking that too, as I maintain the (not yet in use) DRM driver for VirtualBox guests, and I would rather like to have it upstream, but would also like users to be able to have an up-to-date driver on distributions which are not updating it. My current idea, whenever I have some scarce cycles to spare for that task, is that the kernel could boot with whatever driver it comes with, and early in the init stage the kernel driver could be told via an IOCtl to tell the kernel that the device was unplugged, at which point we could simple "rmmod" the in-kernel driver and load the new one. The old one would still be around if something went wrong, though in practice most forms of going wrong are still going to be painful.
Posted Dec 16, 2015 8:11 UTC (Wed)
by niner (subscriber, #26151)
[Link] (11 responses)
As a user, I really don't want them to open up their closed source driver. The free radeon driver may lag with regards to features and performance, but it works without a glitch. It has a well written code base that never had to suffer due to any business needs, so it's in a much better position for long term sustainability. I'd take this reliability over some 20 % performance gain any day.
Posted Dec 16, 2015 13:20 UTC (Wed)
by nix (subscriber, #2304)
[Link] (10 responses)
Posted Dec 16, 2015 14:14 UTC (Wed)
by fandingo (guest, #67019)
[Link] (9 responses)
A fast, working driver is better than a slow, incomplete but open source driver. One of the particular problems with graphics drivers is how dependent on GPU architecture they are. Combine that with the extreme complexity of the drivers, and the iterative approach that these lower-staffed open source projects employ doesn't yield good results. That's precisely what we're seeing from AMD yet again: Their existing driver project is plodding along and users don't like it, but the fix is really more and better developers. They can't make that work (due to Linux market share and the state of AMD's R&D), so they break compatibility and only support a subset of hardware. AMDGPU is for newer hardware only, leaving their existing user base in the lurch.
> If all you care about is game framerates, maybe... but my workstation has used AMD hardware for years specifically because the open drivers make it not like sticking spines in my eyes, unlike, say, nvidia.
I'm confused why you'd have anything other than Intel graphics if you don't care about performance. What's the point of having fast hardware with a really, really slow driver that has no power management? What specifically about Nvidia is "like sticking spines in my eyes?" The driver works, it's extremely fast, has a reliable installer, is packaged well on almost every distro, supports hardware going back over a decade, and has excellent compatibility with all kernel and Xorg releases. On the other hand, we have FGLRX, which has lackluster performance, and woeful kernel and Xorg support. We had radeon, which is CPU-limited, slow, has limited hardware compatibility, and apparently a single developer. Now we have AMDGPU that is also slow and has limited compatibility.
My main complaint is that AMD always over-promises and under-deliveries. They have a habit of reinventing these projects after just a few years, breaking compatibility. I'm skeptical that AMD has the follow-through to execute. They simply aren't good at writing software or allocating the resources to write good software.
I guess the question is: When do you think that AMDGPU will have similar performance to the official Windows driver? Will that take so long that the new hardware architectures have changed so drastically that AMD decides it would be better served by starting a new open source driver project? Neither of those question lead much confidence to a prospective buyer of AMDGPU compatible hardware.
Posted Dec 16, 2015 16:00 UTC (Wed)
by MattJD (subscriber, #91390)
[Link] (7 responses)
While AMDGPU is new and only supports newer GCN hardware, it isn't a complete break like you specify. AMDGPU is the kernel side of the driver. While it is clearly important, it still shares the same radeonsi driver in mesa, afaik. Thus, my older GCN card will still receive updates when radeonsi improves, even if AMD concentrates on AMDGPU.
Also, I believe AMD stated they would be fine if the community decided to extend AMDGPU to the older GCN cards as well. They just weren't going to do it. So if AMDGPU provides a large benefit, someone can step up to do that work.
>A fast, working driver is better than a slow, incomplete but open source driver.
Sure, but I find the OSS stack is a better working driver. For me, fglrx has more issues with compositing and general day to day tasks compared to mesa. While it supports more Opengl features, mesa has caught up enough that it is solidly in the good enough category. While on the tin fglrx is better, in practise the answer is less clear.
>I'm confused why you'd have anything other than Intel graphics if you don't care about performance. What's the point of having fast hardware with a really, really slow driver that has no power management?
First, the open source driver does have power management available for all cards, afaik. The new Fury cards may not be in a stable kernel yet, but it is out there in patch form if not merged into the drm-next tree. And second, even if my card runs at half its possible performance (which is unlikely), it is still heads and shoulders above an Intel graphics solution running at peak efficiency. This isn't to speak bad about Intel's engineering, as my card is a higher end AMD card. But if you care about performance, getting AMD over Intel (for GPUs!) is not a bad option.
Posted Dec 16, 2015 16:32 UTC (Wed)
by fandingo (guest, #67019)
[Link] (6 responses)
Oh great, the prospects for performance improvements get even worse.
> Sure, but I find the OSS stack is a better working driver. For me, fglrx has more issues with compositing and general day to day tasks compared to mesa.
A potato provides a better experience on a current distro than FGLRX.
> First, the open source driver does have power management available for all cards, afaik.
Not really. They depend on the GPU's VBIOS to essentially handle all the power management, and only newer cards have sufficient VBIOS support. (That's not a bad design decision, though, but it does leave more users without a solution from AMD.)
> But if you care about performance, getting AMD over Intel (for GPUs!) is not a bad option.
And, this statement is like 4000% more true if you /s/AMD/Nvidia/ and s/Intel/anything else/. On Linux, the moment performance becomes an important factor there's no dispute which vendor/community deliveries the fastest hardware+driver combo: It's Nvidia and will be for the next several years. At the high end, Nvidia offers over 2x the performance per dollar (https://www.phoronix.com/scan.php?page=article&item=s...) of AMD cards, and that's entirely due to Nvidia's competent drivers.
Posted Dec 16, 2015 16:43 UTC (Wed)
by MattJD (subscriber, #91390)
[Link] (5 responses)
? Why would that be the case? They don't have to reimplement everything to get back to the current state, which gives them more time to work on performance issues.
>A potato provides a better experience on a current distro than FGLRX.
:)
>Not really. They depend on the GPU's VBIOS to essentially handle all the power management, and only newer cards have sufficient VBIOS support. (That's not a bad design decision, though, but it does leave more users without a solution from AMD.)
How far back does this go? I haven't had really old AMD cards, so I'm not aware of everything. But my pre-GCN cards all have power management implemented, and it did require kernel support to get. And the newer cards also needed some kernel work to activate, so it isn't all in the VBIOS.
>And, this statement is like 4000% more true if you /s/AMD/Nvidia/ and s/Intel/anything else/. On Linux, the moment performance becomes an important factor there's no dispute which vendor/community deliveries the fastest hardware+driver combo: It's Nvidia and will be for the next several years. At the high end, Nvidia offers over 2x the performance per dollar (https://www.phoronix.com/scan.php?page=article&item=s...) of AMD cards, and that's entirely due to Nvidia's competent drivers.
In terms of all the raw numbers, yep Nvidia does generally win. I prefer AMD anyways due to there open source commitments, and they have been following through (though obviously not as fast as we'd like). I also prefer fglrx to Nvidia's driver, oddly enough. But I know I'm an outlier. And I don't hate Nvidia's official driver.
Posted Dec 16, 2015 23:11 UTC (Wed)
by adler187 (guest, #80400)
[Link] (4 responses)
> How far back does this go? I haven't had really old AMD cards, so I'm not aware of everything. But my pre-GCN cards all have power management implemented, and it did require kernel support to get. And the newer cards also needed some kernel work to activate, so it isn't all in the VBIOS.
All the info is here: http://xorg.freedesktop.org/wiki/RadeonFeature/
dpm is supported back to r600/r700 (back to HD2400 and up, but not all HD2xxx cards)
dynpm and profile are supported on all the cards AFAICT.
dpm = hardware based power management
Posted Dec 17, 2015 9:46 UTC (Thu)
by niner (subscriber, #26151)
[Link] (3 responses)
Posted Dec 17, 2015 19:09 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Nouveau still doesn't have full production-quality reclocking (so it's slaughtered by the binary driver).
ATI drivers have had reclocking for some time, but it's nowhere close to what fglrx does. I remember that an ATI guy told on forums that the number of lines of code for power management in binary ATI drivers is greater than the total size of Mesa.
Posted Dec 17, 2015 21:13 UTC (Thu)
by adler187 (guest, #80400)
[Link]
AMD just added preliminary PowerPlay support to AMDGPU: https://www.phoronix.com/scan.php?page=news_item&px=A... So at cards from Volcanic Islands on should be on equal footing with Catalyst in that regard.
Posted Dec 17, 2015 21:07 UTC (Thu)
by adler187 (guest, #80400)
[Link]
Posted Dec 16, 2015 16:40 UTC (Wed)
by drag (guest, #31333)
[Link]
That's not the choice we are facing. The open source driver is slower for many things, but it's also much more compatible with software like Gnome and many games. The performance for the open source driver has been increasing continously as well.
The AMD proprietary driver is also compatible with some games and incompatible with others. Also it's buggy, unstable, and a nightmare for end users to deal with.
> . Combine that with the extreme complexity of the drivers, and the iterative approach that these lower-staffed open source projects employ doesn't yield good results.
A much bigger issue is that application developers have to support multiple OpenGL implementations.
One of the massive reasons why DirectX is successful is because Microsoft enforces consistency between hardware and provides unified application stack.
With Linux it's not just a matter of supporting 'linux', each OpenGL stack is a different platform. Combine that with the differences in Linux distros (which is largely due to a sort of passive-aggressive infighting in the community, rather then valid technical advantages over one another) then it's obvious to see why Linux is such a nightmare for application developers to target.
Now most Linux users interested in gaming have a decent package management system via Valve and Steam so that helps mitigate of one of the biggest problems (to bad it's proprietary.), but having multiple OpenGL implementations to support is still a major issue.
> I'm confused why you'd have anything other than Intel graphics if you don't care about performance. What's the point of having fast hardware with a really, really slow driver that has no power management?
How much experience do you actually have with AMD open source driver?
The AMD open source driver with AMD hardware is faster then Intel by a long shot. Intel is good for having 'no brainer' style support in mainstream laptop and desktop Intel chipsets and AMD is much more spotty, but it's also much faster.
I can do Blender and play many games, including stuff on steam, no-problem using open source AMD and they are plenty fast for what I need.
> I guess the question is: When do you think that AMDGPU will have similar performance to the official Windows driver?
That's not a criteria that I find important.
It would be nice to have, but Linux has a lot of other things that need to be fixed beyond just performance before it's really competitive with Windows.
A improvement over what we have now is still a improvement. If you try to take the approach that 'Unless it's matches Nvidia OpenGL versions and is fast as DirectX for Windows then it's worthless' then no progress is possible.
Posted Dec 16, 2015 8:26 UTC (Wed)
by adler187 (guest, #80400)
[Link] (9 responses)
Frankly, open sourcing the Catalyst drivers is not going to happen. First there's licensing issues and second it doesn't perform that great to begin with and seems to be pretty poor code from what I understand. It's probably easier to improve RadeonSI and Mesa than to deal with an open source Catalyst.
Posted Dec 16, 2015 14:19 UTC (Wed)
by fandingo (guest, #67019)
[Link] (8 responses)
Once it catches up? I'd say that it's far from certain that they can achieve performance parity with their Windows driver. The radeon project couldn't even get close.
> It's probably easier to improve RadeonSI and Mesa than to deal with an open source Catalyst.
And who's going to do that work? It might be easier in theory, but if they're not going to dedicate the resources to fixing FGLRX, why do you think they'll dedicate the necessary resources to fixing outside projects?
Posted Dec 16, 2015 14:59 UTC (Wed)
by Sesse (subscriber, #53779)
[Link]
Posted Dec 16, 2015 16:47 UTC (Wed)
by drag (guest, #31333)
[Link] (3 responses)
Hopefully the guys they waste on FGLRX currently.
> It might be easier in theory, but if they're not going to dedicate the resources to fixing FGLRX,
Screw FGLRX. It's a shitty approach and it has never really worked that well. It's likely that it's not fixable.
It seems that the amount of resources devoted to the open source driver has yielded superior results to the much more resources they have been devoting to the closed source driver. Sometimes development methodologies actually do matter.
Posted Dec 16, 2015 16:57 UTC (Wed)
by fandingo (guest, #67019)
[Link] (2 responses)
That's scary. Those people can't write decent software for any OS, and it's been that way since before AMD bought ATI.
Posted Dec 21, 2015 13:36 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Dec 21, 2015 15:53 UTC (Mon)
by Felix (guest, #36445)
[Link]
And you can already see new contributors from AMD due to the amdgpu strategy like Chunming Zhou, Junwei Zhang, Sonny Jiang, Jammy Zhou, Ken Wang, Monk Liu, Flora Cui, Samuel Li and some others (just took random @amd.com names from the pull requests, probably quite a few).
And as you can see for the public reviews there is no "rude awakening". Just the usual "new dev gets acquainted to the (sometimes harsh, sometimes arbitrary) Linux kernel rules".
Posted Dec 17, 2015 0:07 UTC (Thu)
by adler187 (guest, #80400)
[Link] (2 responses)
> And who's going to do that work? It might be easier in theory, but if they're not going to dedicate the resources to fixing FGLRX, why do you think they'll dedicate the necessary resources to fixing outside projects?
https://www.phoronix.com/scan.php?page=news_item&px=A...
They're already funding at least 4 people, possibly more to work on just the open source Linux driver and Mesa, so they seem willing to dedicate resources to the task. In addition a few Catalyst developers have been working on the open source Linux efforts to get Catalyst up and running on AMDGPU. I think they've seen the writing on the wall with fglrx and put it in maintenance mode on Linux. As Mesa improves and fglrx gets further in to maintenance, they can redistribute those developers to Mesa/AMDGPU as well.
The problem for AMD is that their OpenGL performance is awful in Catalyst, on Windows as well as Linux. Nobody cares on Windows since 99% of developers use DirectX, so there's just not enough incentive from the Catalyst Windows team to fix their OpenGL code. So AMD's strategy going forward is to work on improving OpenGL in Mesa and move its Linux customers there, leave the OpenGL code to rot on Windows while continuing to invest in DirectX there, and push Vulkan to replace OpenGL on all platforms (which largely gets the driver out of the user's way and is supposed to fix the problems with OpenGL).
Posted Dec 17, 2015 0:18 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
The greatest threat to fglrx is not Mesa, it's Vulkan. With Vulkan drivers become radically simpler. Once you get all the buffer management and DRM ready, pretty much the only major remaining part is the shader compiler and AMD uses LLVM for that.
Posted Dec 17, 2015 7:24 UTC (Thu)
by adler187 (guest, #80400)
[Link]
Posted Dec 16, 2015 11:52 UTC (Wed)
by Jonno (subscriber, #49613)
[Link]
Well, what they are replacing at this time is the linux-only kernel driver and the linux-only X11 driver in Catalyst. The OpenGL driver in Catalyst (which is mostly shared with windows) will remain, but will be modified to speak to the same open-source kernel module as Mesa does (and the replacement X11 driver will use Glamour and will be able to sit on top of either the Mesa or Catalyst OpenGL driver).
So the proprietary OpenGL driver will have to add some more linux-only code, but the two linux-only proprietary components will be dropped, meaning a total reduction in linux-only proprietary code.
Posted Dec 17, 2015 19:34 UTC (Thu)
by tomstdenis (guest, #86984)
[Link]
Posted Dec 16, 2015 17:06 UTC (Wed)
by brunowolff (guest, #71160)
[Link] (3 responses)
Posted Dec 17, 2015 20:04 UTC (Thu)
by flussence (guest, #85566)
[Link] (2 responses)
AMD cards are very, very dependent on proprietary firmware blobs. The last ones that didn't were the AGP 9xxx cards, and it seems even *those* now require blobs that weren't present in older kernel/X releases.
There was an attempt to develop a blob-free driver around the time the first R400 hardware started appearing, which would've given AMD the same level of libre-ness Nouveau has today, but people turned out to be more interested in instant gratification and the whole effort was buried.
Posted Dec 17, 2015 21:17 UTC (Thu)
by adler187 (guest, #80400)
[Link]
Posted Dec 17, 2015 22:26 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
There wasn't. RadeonHD originally didn't use the ATOM code from the option ROM, but it's R600-era (R400 was supported with reverse-engineered code, AMD didn't release R500 specs until R600 was already a thing) and still relied on closed GPU firmware if you wanted any acceleration on R600 or later.
Posted Dec 26, 2015 15:43 UTC (Sat)
by sbergman27 (guest, #10767)
[Link]
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
<snip>
>We had radeon, which is CPU-limited, slow, has limited hardware compatibility, and apparently a single developer. Now we have AMDGPU that is also slow and has limited compatibility.
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
> Oh great, the prospects for performance improvements get even worse.
AMD's 2016 Linux driver plans (AnandTech)
dynpm = software/driver based power management
profile = manual power management
AMD's 2016 Linux driver plans (AnandTech)
For context: cards in that era had OpenGL 2.1 support, typically about 256MB of memory and about 1/100 of the power of the current generation.
And all that's missing on even older cards is memory reclocking.
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
Wol
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
AMD's 2016 Linux driver plans (AnandTech)
> On Linux, sure, but in general, untrue.
AMD's 2016 Linux driver plans (AnandTech)
Is this going to allow support in libreboot of AMD video cards?
Is this going to allow support in libreboot of AMD video cards?
Is this going to allow support in libreboot of AMD video cards?
Is this going to allow support in libreboot of AMD video cards?
AMD's 2016 Linux driver plans (AnandTech)