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

[phoronix]

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

[Michael]

There is no "DisplayPort 3.0". There exist specifications for DisplayPort 1.3 and 1.4.

Right, just a silly typo. Fixed now, thanks.

[mibo]

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?

[andrei_me]

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

[agd5f]

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

[darkbasic]

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

[agd5f]

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

[bridgman]

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

[duby229]

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

[bridgman]

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 !