Slashdot Mirror
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.
You're a little late in helping decide the driver model for Linux. Open source drivers go in the kernel, wanted or not.
People sensible about kernel size can always configure and recompile it.
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.
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.
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?
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.
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.
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.
Higuita
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.
Anons need not reply. Questions end with a question mark.
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.
Higuita
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.
"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.
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.)
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.