Announcement

Collapse
No announcement yet.

AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Veerappan View Post
    but the kernel/X.org drivers which were custom for *NIX anyway will now be sharing development with the open-source driver.
    .
    Are there serious performance problems in that part of the driver?? I thought more development was needed in the g3d part of the driver.

    Comment


    • #12
      All new open-source GPU support will be on this new driver with no new GPU support being planned for AMD's existing Radeon Linux driver -- the open-source driver as we know it today. This new kernel driver is based on the current Radeon DRM code and Alex explained they used Sea Islands graphics processors for prototyping and testing the new kernel driver, but when merged and in production this driver will be used for post Radeon R9 290 graphics cards. "There are no current plans to enable support for any ASICs which are already supported in Radeon."
      This is bummer. It's mean none of AMD hardware I have going to be supported by this new driver.

      Still will be interesting to wait if this driver going to be mainlined before new AMD GPUs released.

      Comment


      • #13
        I still feel pretty hazy on how this works and what products will be affected. It seems like a good idea overall but:
        1. Is catalyst itself just a closed-source user-space application used to configure the GPU, but the drivers themselves stand separately as open source?
        2. Will you be able to install strictly the drivers without catalyst? In the event where you want to install these drivers on a non-x86 platform (or perhaps a completely GNU-friendly platform), what options do users have?
        3. Will features like openGL 4.x, crossfire, freesync, etc be available at launch?
        4. It appears everything before the R9 290 series will not be part of this driver. If this is true, will the current state of the FOSS drivers remain in development maintaining these older devices?
        4a. If the last answer is yes, what exactly is the plan for that? Will they eventually gain all their advertised hardware features or will they just try to maintain mesa compliance and leave it at that?
        5. Will this new catalyst driver be mesa compliant?

        Sorry if some of these questions are obvious or have already been answered, there just seems to be a bit of ambiguity here.
        Last edited by schmidtbag; 10-08-2014, 10:48 AM.

        Comment


        • #14
          This is like Chrome and Chromium, we have a open source base with some closed parts (Flash, Widevine, formerly PDF, ect). Keep up the good work AMD, I'll definitely be sticking with you for my gaming rig.

          Comment


          • #15
            Originally posted by schmidtbag View Post
            I still feel pretty hazy on how this works and what products will be affected. It seems like a good idea overall but:
            1. Is catalyst itself just a closed-source user-space application used to configure the GPU, but the drivers themselves stand separately as open source?
            2. Will you be able to install strictly the drivers without catalyst? In the event where you want to install these drivers on a non-x86 platform (or perhaps a completely GNU-friendly platform), what options do users have?
            3. Will features like openGL 4.x, crossfire, freesync, etc be available at launch?
            4. It appears everything before the R9 290 series will not be part of this driver. If this is true, will the current state of the FOSS drivers remain in development maintaining these older devices?
            4a. If the last answer is yes, what exactly is the plan for that? Will they eventually gain all their advertised hardware features or will they just try to maintain mesa compliance and leave it at that?
            5. Will this new catalyst driver be mesa compliant?

            Sorry if some of these questions are obvious or have already been answered, there just seems to be a bit of ambiguity here.
            1. On Linux, (and probably everywhere else as well) drivers have two parts: one system-wide (which is privileged and has control over things like modesetting - this part is a kernel module called a DRM/KMS module under the Linux model, also the DDX in the display server) and one per application (this part translates API calls into hardware-specific commands - under Linux this is typically a shared library).
            The latter part is the one that is supposed to remain closed-source, while the former one will be open-source and shared with the Mesa Radeon driver (for supported hardware)
            2. Likely the Mesa driver for Radeon will get support for this new Kernel module and the DDX will be open-source as well, so yes - you will be able to install a working GUI system without Catalyst, which will probably even support games when [Insert gfx API here] is supported well enough in Mesa.
            3. Well, Mesa does not have support for OpenGL 4 right now, but it may get it in the next months (but if support for it will be supported day-one is doubtful).
            Catalyst will most likely support GL4 at launch (would be an embarrassment if it didn't).
            FreeSync would likely mostly need Kernel support. IDK if support for this is planned for launch of the new driver or launch of the hardware it supports.
            AFAIK there are no games or APIs that support Multi-GPU on Linux thus far, but since the new kernel module supports DRM/KMS and therefore likely DMABUF, cross-device data transmission will be supported by the infrastructure.
            4. IDK, I would assume so
            5. In the sense that you could use both on the same machine at the same time, yes. If you mean it being a part of mesa or using Mesa infrastructure (like Gallium3d) then no.

            If anyone knows better than me, feel free to correct me.

            Comment


            • #16
              "There are no current plans to enable support for any ASICs which are already supported in Radeon."

              So... Intel / Intel+nVidia for my new laptop and discrete nVidia for my desktop.

              Got it, thanks AMD.

              Comment


              • #17
                So eagerly waiting for 20nm products next year , hm maybe i will be interested in switchable ARM_64/X86_64 socket

                But really new driver is expected with APU raise and ARM in the game, together with HSA that might need also entirely new MM, etc.
                Last edited by dungeon; 10-08-2014, 11:43 AM.

                Comment


                • #18
                  Awesome strategy Sharing the code means it has to be good, because everyone depends on it. And that the new AMD cards will use the opensource DDX aswell is even better, as everyone knows how much better the opensource driver is in everything 2D related (2D performance, tearing, video...).

                  Would be interesting to know if the R9 285 will be supported, because that's a brand new IP, newer than Hawaii (R9 290) or Bonaire (R7 260). Anyways, I will upgrade the GPU when the new drivers are out in the coming months.

                  Comment


                  • #19
                    Originally posted by blackout23 View Post
                    This driver model still seems a bit inflexible. Imagine NVIDIA doing the same thing. They could roll out a new version of their closed source OpenGL implementation easily, which is good, but other features (think G-Sync etc.) are bound to the kernel version and release schedule (and indirectly the schedule of distros). On Windows AMD and NVIDIA can just roll out stuff whenever they want and it just works. Companies need a direct path to their users/customers and the OS and distros should not get into their way like this.
                    You actually mean to say that this model is very flexible, as you do not have to patch your nvidia kernel proprietary license wrapper code to match new kernel API's, since the API is already defined, and there is no proprietary code in the kernel anymore.
                    The current nvidia and fglrx drivers both have the obnoxious problem that their proprietary kernel modules are usually lagging.
                    It usually is up to the distro's to fix those drivers.
                    With the new model there is no proprietary code, so distro's that want to give the users the latest and best experiences do not have to wait on AMD anymore. They just have to wait on NVIDIA.
                    Containing your proprietary part in usersspace is the best solution ever.

                    Comment


                    • #20
                      Originally posted by Veerappan View Post
                      ... this might also open up the way to Catalyst on BSD.
                      Very important, as on the BSDs you currently don't have a choice.

                      AMD's Pirate Islands graphics cards are rolling out in 2015 to succeed the Southern/Sea/Volcanic Islands.
                      So Tonga/R9 285 will be the only Volcanic Islands ASIC? Maybe Carrizo?

                      Comment

                      Working...
                      X