Announcement

Collapse
No announcement yet.

AMD Publishes Initial Open-Source Driver Code For Next-Gen Polaris

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

  • AMD Publishes Initial Open-Source Driver Code For Next-Gen Polaris

    Phoronix: AMD Publishes Initial Open-Source Driver Code For Next-Gen Polaris

    One week after the surprise of delivering a beta of their new hybrid "PRO" driver stack, here's another big surprise: AMD has just published the initial open-source code for driver support with their upcoming "Polaris" graphics processors!..

    http://www.phoronix.com/scan.php?pag...ourced-Polaris

  • #2
    Originally posted by atomsymbol

    There is no "DisplayPort 3.0". There exist specifications for DisplayPort 1.3 and 1.4.
    Right, just a silly typo. Fixed now, thanks.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #3
      Your HBM2 guess for Polaris is VERY unlikely.
      First, AMD showed the slide with a VEGA gpu which has HBM2 as a feature (so probably their first HBM2 chip) and that gpu has a time frame end of 2016/start of 2017.
      Second, mass production of HBM2 was announced to start end of 2016 which also doesn't fit for Polaris.
      GDDR5x is also scheduled for later this year...
      So, I expect GDDR5 memory for Polaris 10 and 11.

      What I still don't understand. Is it really necessary to get this DAL into the kernel before Polaris can be supported? Or, can it be supported with a newer AMD GPU-PRO driver, but not yet with the MESA driver?

      Comment


      • #4
        Michael about upstreaming DAL: https://lists.freedesktop.org/archiv...ch/103398.html

        Comment


        • #5
          Originally posted by mibo View Post
          What I still don't understand. Is it really necessary to get this DAL into the kernel before Polaris can be supported? Or, can it be supported with a newer AMD GPU-PRO driver, but not yet with the MESA driver?
          DAL is just the display modesetting component in the kernel (i.e., turning on the displays). It has nothing to do with hybrid/pro vs. open. We just don't want to support two display modesetting code paths in the kernel driver (pre-DAL and DAL).

          Comment


          • #6
            Do someone really think DAL is going to be mainlined soon? Linux coding standards are quite a bit higher than the Catalyst code base, to have even the slightiest chance of being mainlined it requires massive amounts of work, and this will probably be enough just to enter staging...
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #7
              The DAL we are working on upstreaming was written from scratch for amdgpu. The fglrx display code was shared with windows.

              Comment


              • #8
                Originally posted by darkbasic View Post
                Do someone really think DAL is going to be mainlined soon? Linux coding standards are quite a bit higher than the Catalyst code base, to have even the slightiest chance of being mainlined it requires massive amounts of work, and this will probably be enough just to enter staging...
                From agd5f's post that andrei_me linked above:

                Tasks to be completed for 4.7:
                - Remove (malloc/free/sleep/delay/etc.) wrappers for building DAL in userspace (done)
                - Switch to using Linux i2c subsystem (done)
                - Switch to using Linux drm aux interface (in progress)
                - Convert cursors to planes API (in progress)
                - Switch to native drm EDID fetching (in progress)

                Tasks post 4.7 (we will attempt to fix these sooner as time permits):
                - Using common Linux infoframe infrastructure
                - Migrating to common logging infrastructure
                - Refactoring DC

                Comment


                • #9
                  Originally posted by darkbasic View Post
                  Do someone really think DAL is going to be mainlined soon? Linux coding standards are quite a bit higher than the Catalyst code base, to have even the slightiest chance of being mainlined it requires massive amounts of work, and this will probably be enough just to enter staging...
                  I think you're right, which mean hopefully it will be a high priority to get it right quickly.

                  EDIT: Oops, spoke too soon I guess. ^^^

                  Comment


                  • #10
                    Polaris includes the ELLESMERE and BAFFIN chip families.
                    Michael We're calling them Polaris 10 (was Ellesmere) and Polaris 11 (was Baffin) now, any chance you could tweak the article accordingly ?

                    Thanks !

                    Comment

                    Working...
                    X