Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
AMD Graphics Open Source Hardware Linux

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.
This discussion has been archived. No new comments can be posted.

AMD Releases Open-Source Driver Support For Next-Gen Polaris GPUs

Comments Filter:
  • by 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?
    • You're a little late in helping decide the driver model for Linux. Open source drivers go in the kernel, wanted or not.

      • by 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.

      • 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?

        • 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)

            by 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.

      • by Kjella ( 173770 )

        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

    • People sensible about kernel size can always configure and recompile it.
    • by aliquis ( 678370 )

      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)

      by 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.

    • by Xtifr ( 1323 )

      "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

      • by Xtifr ( 1323 )

        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.)

  • by Gravis Zero ( 934156 ) on Thursday March 24, 2016 @11:00AM (#51769051)

    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.

Any sufficiently advanced technology is indistinguishable from a rigged demo. - Andy Finkel, computer guy

Working...