AMD Releases Open-Source Driver Support For Next-Gen Polaris GPUs (phoronix.com) 38
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.
Why add this to the kernel? (Score:1, Insightful)
Re: (Score:3)
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? (Score:2, Funny)
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: (Score:3)
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: (Score:2)
They're both part of the kernel source, either way (unless I know less than I think I do - which is very possible).
Re: (Score:2, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
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 differenc
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2, Informative)
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: (Score:3)
"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 doze
Re: (Score:3)
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.)
Re: (Score:2)
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? (Score:5, Insightful)
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: (Score:1)
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 publi
Re: Will it perform? (Score:2)
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: (Score:3)
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 befo
Re: (Score:2)
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: (Score:2)
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 r
Re: (Score:3)
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: (Score:1)
won't be in the mainline kernel until at least 4.7 (Score:4, Informative)
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.