AMD Releases Open-Source Driver Support For Next-Gen Polaris GPUs (phoronix.com)

An anonymous reader writes: For the first time ever, AMD has provided open-source support for next-generation discrete GPUs ahead of the product's launch. AMD developers published initial open-source Linux driver support for Polaris GPUs with the addition adding over sixty-seven thousand lines of code to the Linux kernel. AMD Polaris graphics cards are expected this summer while AMD released the open-source driver support in advance for preparing their new Linux hybrid driver that relies upon the open-source AMDGPU kernel driver.

Comments

Why add this to the kernel?

[Anonymous Coward]

It doesn't seem efficient that drivers for a specific piece of hardware would bloat the Linux kernel, even for people that do not have and will never have that specific piece of hardware. I thought Linux was supposed to be a model of streamlined efficiency, a kernel done correctly?

Re:Why add this to the kernel?

[omnichad]

You're a little late in helping decide the driver model for Linux. Open source drivers go in the kernel, wanted or not.

Re:Why add this to the kernel?

[jszpilewski]

People sensible about kernel size can always configure and recompile it.

Re: Why add this to the kernel?

[Anonymous Coward]

Yup. Also, while Linux folks were screaming about getting the graphics frame buffer into the kernel to make it more competitive with Windows for games, Windows was quietly doing the opposite. And now we have the year of the Linux desktop, of course.

Re:Why add this to the kernel?

[aliquis]

Your thoughts about the model of the Linux kernel is simply wrong.
It may not use much resources for those not using the drivers though anyway. Just because it's in the kernel source code doesn't necessarily mean you have to load it even though you don't need it.

Re:Why add this to the kernel?

[Wootery]

Perhaps my Linux-fu is weak, but there's a difference between a loadable kernel module, and what's baked into the core kernel, right? Can't kernel modules be used for graphics drivers, for the best of both worlds?

Re:Why add this to the kernel?

[omnichad]

They're both part of the kernel source, either way (unless I know less than I think I do - which is very possible).

Re:Why add this to the kernel?

[Anonymous Coward]

Do you prefer manually installing all of your drivers just to get to the point where you can use your network card to... wait for it... install more drivers? Basic hardware drivers are built into the kernal to make Linux as hardware universally compatible as possible, but usually they are extremely trimmed down drivers... bare bones, rock solid functionality ensures that even if you have nothing more than a bootable Linux USB stick, you still have a fully functional operating system, no matter what PC you plug it in to. If you want more specialized drivers, go get them yourself.

Also, I think you are imagining a 200+MB driver file getting embedded in the Linux kernal... yeah right... the kernel would be huge if you consider all of the hardware that the kernel supports.

Re:Why add this to the kernel?

[Anonymous Coward]

I don't see how. Adding a driver to the kernel means adding the source code to Linux's source tree, not adding it to the kernel image, typically resulting in whoever builds the kernel gaining the choice of having the driver be omitted, built as a loadable kernel module, or statically linked directly into the main kernel image.

Most drivers added to the kernel are either disabled or set to compile as loadable kernel modules by default, and there's no reason to believe that this will be an exception.

Re:Why add this to the kernel?

[Anonymous Coward]

Very true. But in this case it doesn't even affect kernel size. It's just an extra file, called "pro.ko" or something, which can be deleted from your hard drive if you don't need it and really want to save a little bit of space.

Re:Why add this to the kernel?

[Anonymous Coward]

Yes, it's part of the source.

And this is where the user has full control. You can build it into the kernel, build it as a module and load/unload it when needed, or not build it at all.

Re:Why add this to the kernel?

[Anonymous Coward]

This is exactly why normal people don't bother with Linux. Who wants to fuck around with that stuff?

Re:Why add this to the kernel?

[mrchaotica]

If you were to get your Linux computer pre-loaded from a vendor (like most people do with Windows and all people do with Mac), the vendor would have handled it for you.

Conversely, if you built your Windows computer yourself, you'd equally have to fuck around with installing drivers manually.

Re:Why add this to the kernel?

[The_countess]

that's why most distributions do this for you.

Re:Why add this to the kernel?

[Anonymous Coward]

That's how they all are: if you don't want them, just uncheck them. Or if you don't want to use the memory but you happened to notice that hard disk sizes somehow got obscene over the last couple decades, put an "M" there.

Can you even imagine an approach which might be better? Linux does do this right.

Re:Why add this to the kernel?

[Kjella]

You're a little late in helping decide the driver model for Linux. Open source drivers go in the kernel, wanted or not.

The driver model and source control are pretty unrelated anyway. Even if you make a microkernel with a fixed ABI you'd normally want to ship the latest version of the most commonly used drivers with the kernel. If you know your hardware you can compile with those flags from source or just not ship the blobs you don't need. I'm sure you could create a system where they're dynamically fetched from a repository, not just dynamically loaded too if that'd make any sense. Really the only time it makes a difference is if you want to ship a closed source blob, since otherwise you can always go from source to binary easily enough.

Re:Why add this to the kernel?

[Anonymous Coward]

Back in 2012, 5.3mil LOC of Linux's 15m LOC were drivers. It's pretty much always been this way. Want to boot your computer? Drivers must be in the kernel. Of course "in the kernel" also includes all loadable modules.

Re:Why add this to the kernel?

[cb88]

Actually this is what udev does automatically ... all the distribution has to do is build the module.

It's not like Linux doesn't Plug and Play... However, on many of the recent computers I have used it gets the default sound card wrong still (note this is stock alsa not pulseaudio which may fair better at the cost of bloat and having to run "evil" Lennart Poettering's code)

Re:Why add this to the kernel?

[cb88]

Somehow I doubt this is true... certainly pro.ko has lots and lots of dependencies in the kernel that you wouldn't have to build in if you never intended to load it.

If you have ever built a kernel yourself you'd know that everything affects kernel size and complex drivers are the worst offenders along with protocols and filesytems.

Re:Why add this to the kernel?

[Anonymous Coward]

Because adding 67kLOC to the kernel just to talk to a bit of hardware is the thing to do these days. Back when graphics drivers sat outside the kernel, but since "KMS" and even before ("DRM") that no longer flies, even for Xorg. Caused quite a bit of problems for non-linux OSes that wanted to keep some X11 going too. In that sense, it's eerily reminiscent of *cough* other software *cough* that is unabashedly linux-only yet manages to ingrate itself until indispensable with all sorts of big large FOSS projects. How they do it? I haven't the faintest. The reason, though, is readily inferable for people who look a little beyond technical minutia: Politics. Amazing how many of the people in the community evidently cannot look beyond the technical details.

And no, linux is not "done correctly", it just re-did what everyone else did back when. See Tanenbaum disagreeing with Torvalds. linux just happens to be popular, not "designed right" or anything. The thing Linus does reasonably well is keep a lid on the derpage in submitted code, but that's about all.

Re:Why add this to the kernel?

[drinkypoo]

Conversely, if you built your Windows computer yourself, you'd equally have to fuck around with installing drivers manually.

If you buy all-Intel and don't get too fancy-pants, all your drivers will probably be delivered by Windows. Maybe even from the installation media. You can even have a nVidia GPU.

Re:Why add this to the kernel?

[FlyHelicopters]

Conversely, if you built your Windows computer yourself, you'd equally have to fuck around with installing drivers manually.

Except, you largely don't...

I have installed Windows 10 on new and old computers alike, and with very rare exceptions, never had to install a driver.

Yes, the newest AMD and NVidia drivers are usually (but not always) better than what Windows installs, but what Windows installs is serviceable.

Re:Why add this to the kernel?

[wertigon]

Windows 10? Explains it.

Try installing Windows 8.1 that has been out a few years by this point.

Windows in general is pretty good at keeping up-to-date with their drivers - But after a year or two that windows release is still shipping with the same, now two-year old drivers.

Re:Why add this to the kernel?

[FlyHelicopters]

Try installing Windows 8.1 that has been out a few years by this point.

Windows 8.1 reinstalls fine on hardware that was current when Windows 8.1 was current.

But if you're trying to install Windows 8.1 on brand new stuff, it will slowly get worse at that over time.

---

But after a year or two that windows release is still shipping with the same, now two-year old drivers.

Two points:

1. Windows Update has updated drivers for awhile now.

2. Windows 10 now provides an updated image to do clean installs with. You no longer have to do a clean install with Win 10 RTM, the Fall Update is the new image, and we'll get another new one soon enough.

If MS keeps that up, then clean installs will not be the headache they used to be.

It also helps that a lot of tech is far more standard than it used to be. I remember Windows XP installs that needed all kinds of help on newer hardware, but the pace of motherboards and add ons in the 2000s was faster than today. Today, the chipset does more or less everything and if you have either a RealTek or Intel Ethernet adapter, then Windows supports it out of the box, and a quick Windows Update fixes almost everything else.

Re:Why add this to the kernel?

[Xtifr]

"Bloat"? Driver modules don't get loaded unless the hardware in question is detected. If you're worried about disk space, well, you should be compiling your own kernels, which allows you to leave out the portions you know you're not going to use. Not because of this device specifically, but because of the thousands of devices you don't have which have modules sitting on your disc unused and unneeded.

$ find /lib/modules/4.3.0-1-amd64/ -name '*.ko'|wc -l
3180

That's over 3000 modules, many of which support dozens, if not hundreds, of devices.

Re:Why add this to the kernel?

[Xtifr]

Oh, and for comparison:

$ lsmod|wc -l
80

So, of the 3000+ modules I have on my drive, 80 of them are actually in use. (79, actually, since the first line of output from lsmod is a header describing the fields below.)

Will it perform?

[nichogenius]

I'd like to know when AMD plans on releasing a Linux driver that actually manages to use the hardware. NVIDIA at least gives a closed-source effective driver... why can't AMD? Put some of that open-source love towards us Linux gamers please :D

Re:Will it perform?

[Anonymous Coward]

That kind of defeats the purpose of open-source, doesn't it.

Re:Will it perform?

[higuita]

They are doing it!

The vulkan was inspired in the mantle and allows more direct control of the hardware... we already have vulkan out, have initial drivers and developers are starting to play with it.

OpenGL, they are mostly killing their close source drive and trying to push and improve the open source one. It already faster than the close source one in some games, but it still needs more work (features and performance optimization, like all open drivers)

Yes, the AMD close source drive is bad, full of bloat and bugs.. they know that and they are fixing it by replacing it with the open source one.
After the open drive is good enough, the close source one will be used only for those that need certified opengl drivers. AMD already recommends the open drivers for all the R600 cards and most radeonSI cards.

nvidia is the one that is doing nothing (or almost nothing) to support the open drivers, both intel and AMD have many developers working in the open drivers, with AMD moving developers from the closed driver team to the open source developer team

Sadly also, nvidia also pushes the game developers to use features that perform well in nvidia, but badly in AMD... and with all the AMD close source driver bugs (and game bugs too), many game developers only test/develop in nvidia, making the AMD cards a lot look worst than they are.
With the open drivers, game developers will be able to see why the code is performing badly and fix either ends (check the steam comments how the open drivers allowed to debug performance problems in game engines, that helped the games perform better, even in windows)

So we are all waiting , things are already a lot better than 2 years ago... but AMD IS FIXING THE PROBLEM... not only that, but FIXING IN THE GOOD WAY, with open source drivers.

Re:Will it perform?

[U2xhc2hkb3QgU3Vja3M]

Windows isn't free.
Linux is free.

If all the games were available for Linux, PC gamers would never have to buy Windows.

Re:Will it perform?

[drinkypoo]

The vulkan was inspired in the mantle and allows more direct control of the hardware... we already have vulkan out, have initial drivers and developers are starting to play with it.

Vulkan was inspired by Mantle, but Mantle never really worked; performance using Mantle was worse than with D3D. As well, nVidia is supporting more of their devices with Vulkan than AMD is.

Yes, the AMD close source drive is bad, full of bloat and bugs.. they know that and they are fixing it by replacing it with the open source one.

As noted, this is literally the very first time they have made a serious effort at that, by actually releasing before the cards hit the streets. Time will tell just how serious the effort actually is.

nvidia is the one that is doing nothing (or almost nothing) to support the open drivers,

That's true. They are, however, capable of publishing closed drivers that work. They are contractually prevented from publishing GeForce driver information, probably due primarily to their involvement with Microsoft in the original Xbox era. That is sad, but at least I have working drivers.

So we are all waiting , things are already a lot better than 2 years ago... but AMD IS FIXING THE PROBLEM... not only that, but FIXING IN THE GOOD WAY, with open source drivers.

I'll believe it when they work as well as nVidia's drivers. Maybe then I'll even consider giving AMD some money, but they have to have working Windows drivers, too. I may want to dual-boot for gaming.

Re: Will it perform?

[Type44Q]

probably due primarily to their involvement with Microsoft in the original Xbox era.

I doubt very much that Microsoft owns any of the IP relating to the original XBox's 1st-gen nForce chipset or its hybrid GeForce3/4Ti graphics processor. I'd be more likely to suspect SGI patents at stake...

Re:Will it perform?

[higuita]

Mantle was performing good on various games and cards... the game engine and the driver and game quality matter a lot... but it was also a experiment, with little tuning, that showed how capable a new layer closer to the hardware could be

By moving the kernel code to open source, they need to support the open driver for the close part also to work. So if they want to sell new cards to linux, video studios, CAD companies and medical equipment, they need to release the open kernel support for the new card before it is released. That will be how all the new AMD cards will work for now on. Mesa support might still be delayed, but unless it is a radically different hardware, most of features should work with a few changed in to the previous card mesa support

They are contractually prevented from publishing GeForce driver information

Bullsh*t! they don't release because they don't wanted to!
AMD released many docs and specs and still hide all the DRM and video extensions, due legal reasons... AMD also is the supplier for all the current consoles and have any problem release the card specs!
Nvidia could release some info... the most important was the hardware reclocking registers... it would be easy for then to release (and they released SOME a several months ago, after YEARS of begging! yet many cards are still missing that info)

They also don't have any problem to release specs for the hardware that will run with android (as they are having problems forcing their drivers on android, they must support open drivers for that hardware to be able to sell)

Right now radeon and radeonSI work well for most games opengl 4.2, as long they don't require features that are still missing). AMDGPU is almost at same level as radeonSI, with just a few bits missing. the new close source driver, based on the AMDGPU kernel support is also working +- at same level as the catalyst driver but with the vulkan part added and still without any optimization work on it.

i can play all my games in my AMD card in linux and i'm using the open drivers. i don't know about you, but this is good enough for me.

Re:Will it perform?

[drinkypoo]

They are contractually prevented from publishing GeForce driver information

Bullsh*t! they don't release because they don't wanted to!

They have outright said that they cannot release this information because of contractual obligation. They have hinted that it was Xbox-related. We may never actually find out.

They also don't have any problem to release specs for the hardware that will run with android

Yes, that is a wholly separate line from the product line used for the PC, and therefore it is not subject to the same encumbrance.

(as they are having problems forcing their drivers on android, they must support open drivers for that hardware to be able to sell)

What do you mean "forcing their drivers"?

Re:Will it perform?

[sexconker]

They are contractually prevented from publishing GeForce driver information, probably due primarily to their involvement with Microsoft in the original Xbox era.

I just want you to know that this is absolute nonsense. It's completely made up (likely by you) and completely untrue.

Re:Will it perform?

[untoreh]

Also the fact that "mantle never really worked" is horseshit. Tried first hand on the first couple games it came up with, bf4 and thief and it was all it said it was, reducing cpu overhead and pretty much gaining 25%~ more fps thanks to that. Thief was also the first and only game up to now to use amd trueaudio but thats another thing

Re:Will it perform?

[higuita]

They did release some info for the geforce, only after many years of begging and after all the benchmark showing nvidia cards in last, using open driver, mostly because it was always running at the lowest speed.. they might have some limitation, but not for everything... yet they don't care

As forcing their drivers, all android devices had closed drivers, but that created the old problems of locking upgrades and stability. new devices should push the drivers to the main kernel and google and many producers refuse now hardware without proper open drivers (already include or with a clean plan to push then). China even refused a large gpu cluster based on nvidia due the closed drivers, going to AMD instead because of the open drivers and the better future support on then. Even with good close source drivers, people don't want then due the long ter support

If you pay top money for a tablet with a nvidia gpu, you want it to work for a long time, for various android versions and the closed drivers for android was causing problems on that. Nvidia was then pushed to open up their new light gpu, to avoid builders to go to cheaper and/or open alternative GPU makers. Nvidia gpu for android is so expensive that they really need to remove all other road blocks.

Even after the nvidia "help" on those cards, most of the work is still done by the independent nouveau team and by the mesa, intel and amd teams (due code sharing). nvidia is still just simply not doing enough!

nvidia owners should all thanks to the nouveau team (and mesa/intel/amd teams). sadly is nvidia that in the end keeps the money for their inactivity.

again, intel and amd are supporting the open drivers, both work well already, with the amd being better performance for obvious reasons. no need for close drivers

won't be in the mainline kernel until at least 4.7

[Gravis Zero]

well in the past couple weeks, AMD has dropped a whopping 150k lines of code to add to the kernel. the reason it's so obscenely large is it includes duplicate functionality that is already in the kernel and a lot of abstractions. therefore, the code is being worked on to rip out the redundant crap and actually use existing kernel functionality before it's accepted and thusly not making it into 4.6. after it's whittled down to just the code that's actually needed, it can be added to the kernel.