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

[duby229]

for polaris they have a driver depending on non-mainlined kernel code

I think that's OK to a limited point. I'm certain AMD will get it upstreamed eventually and I don't expect it to take a year much less two.

[duby229]

EDIT: reply stuck in mod que.

[bridgman]

My last post just disappeared (not moderated), trying again...

So let me get it straight, the fully open source stack will not be ready for Polaris launch (most likely), but the hybrid stack using AMDGPU + GPU-PRO will have support?

No, nothing like that. The open source code comes first - I was just responding to whoever said that Polaris support would not be in a finished and released kernel until after the launch. It's not actually the "hybrid/pro-ness" which allows launch-time support, it's the use of DKMS driver packages that can plug into an already-released distro kernel along with driver code that adapts to multiple kernel versions so you don't need a different package for every version of a distro.

[tomtomme]

So let me get it straight, the fully open source stack will not be ready for Polaris launch (most likely), but the hybrid stack using AMDGPU + GPU-PRO will have support?

yes that was what bridgman said - not ready in a released mainline kernel.

IF DAL hits kernel 4.7 mainline (unliekely) there are now 124 days to go
(based on wikipedia numbers of kernel releases since 3.0; 134 days - 10 days that are already gone since 4.5)

that equals end of july
Polaris is set for Q2, so we definitely need the closed PRO driver or go with a staging driver

Maybe DAL will hit 4.8 at the end of september - when I want to build my new rig - if I am very lucky.

[pal666]

I'm certain AMD will get it upstreamed eventually and I don't expect it to take a year much less two.

but they have to plan for other possibilities besides fastest one possible

[W.Irrkopf]

if you read carefully, he is open for staging. you don't need any closer than that

I'm still slightly open to some sort of STAGING for this, but I think I'm nearly at the level, that I'd only accept that on the understanding we'd try and evolve the driver to this level, rather than think we can clean DAL to the kernel standards. *My* interpretation is that if the authors give him a clear perspective for the driver, he might go for STAGING. The feedback in the following posts isn't as "positive" as Dave's.

[castlefox]

This sounds like a great update from AMD. I hope this work keeps up.

[pal666]

*My* interpretation is that if the authors give him a clear perspective for the driver, he might go for STAGING

he will agree to staging if amd will agree to do rework in future. now explain why 4.7 merge window will close before amd will agree

[SystemCrasher]

1) you have no reason to assume amd will not test properly their main driver

AMD aren't new in kernel development so I doubt they are going to be like that. Yet I would expect code in staging to face much less testing and review. As for AMD's DAL, there could be many reasons why code left in staging and is seems Dave Airlie does not gets why AMD needs to drop such a huge chunk of code in one shot and/or why they need yet another abstraction layer and/or why it supposed to be useful for AMD GPUs only, etc and/or what is missing in DRM/KMS so AMD needs to do it this way. And/or why older code paths are suddely considered bad, etc. Actually such movie from AMD leaved me puzzled, I do not get their point. At first glance it looked like gross attempt to adapt AMDGPU to ex-CATALYST internals using cheap-and-dirty approach. However AMD explanations left me even more puzzled about this kind of activity and what they're up to. Then it called "abstraction library" but ... ok, it only affects some AMD GPUs? Then, fairly large "library" which is only being used by single GPU driver sounds a bit strange in some regards, no?

2) people consume released kernels built by someone else. if you build kernels manually, we shouldn't be discussing upstreaming dal at all, since you can build unreleased driver either from amd tree, or by applying patchset to your

When it comes to building kernels, distros could make different decisions, but overall, IMHO staging usage should be exception, not norm. Code in staging tends to pose a lot of troubles. Even if there was no FTBFS, it often of much worse quality, poorly tested or otherwise troublesome. Looking on code size of this DAL thing I would expect quite some bugs lurking around as well.

Well, when it comes to DAL, most interesting questions are listed above. It seems AMD managed to puzzle or even frustrate Dave Airlie, not just some random phoronix visitors. Maybe I've wildly missed some definitive explanation? I can understand critics DAL faced in mainline and it seems ppl like Dave Airlie aren't exactly fond of this approach and not really getting why it happens this way. So I'm puzzled a lot by these AMD actions. Nice PR action though, because phoronix wrote like 3 or 4 articles on AMDGPU

[veritas]

So as we have a AMD guy here... if you combine like 4 older 16-core Opterons (so 64 core PC ) with Radeon Pro duo and run some DX12/Vulkan/Mantle or Ashes of Singularity benchmarks - would that use all of 64 cores ?

It depends on game coding. For example Ashes of Singularity can use 18 threads, at max from what I've seen. And its the best dx12 implementation yet. I hope the vulkan version is as good too.