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

[SystemCrasher]

staging drivers work just as good as non-staging

Not to be taken as granted. I've got quite nasty FTBFS in some staging drivers recently but I can't remember something like this for mainlined drivers.

[SystemCrasher]

Oh, btw, congrats to AMD! They finally reached milestone they've been talking about a while ago. Quite an achievement, any day.

[zanny]

You AMD guys are the worst, I want to buy a Polaris card now to show support for all this great work, but you keep making my 290 faster every release making me content with what I have!

[W.Irrkopf]

See post #9... maybe half way through the changes already.

https://www.phoronix.com/forums/foru...387#post860387

Note the pushback was more about code in DAL that duplicated existing framework functionality (some that appeared in parallel with writing DAL) than about coding standards.

Nope, not even close. The initial feedback is being addressed, but the verdict of the DRM maintainer is basically: Back to the drawing board

[azari]

See post #9... maybe half way through the changes already.

https://www.phoronix.com/forums/foru...387#post860387

Note the pushback was more about code in DAL that duplicated existing framework functionality (some that appeared in parallel with writing DAL) than about coding standards.

It seems that airlied is still not happy with it though, he replied to alex's post about an hour ago: https://lists.freedesktop.org/archiv...ch/103468.html =(

Although he did suggest it might be accepted in staging as long as there is agreement that DAL will be evolved to meet the kernel's requirements.

I'm not familiar with how distributions deal with staging; are distributions known for enabling staging stuff on release kernels? for instance, can we expect Arch and Ubuntu to enable DAL by default if it makes it into staging, or will we have to compile our own kernels regardless?

[pal666]

I've got quite nasty FTBFS in some staging drivers recently but I can't remember something like this for mainlined drivers.

https://lists.debian.org/debian-kernel/2016/03/msg00128.html

[pal666]

Nope, not even close. The initial feedback is being addressed, but the verdict of the DRM maintainer is basically: Back to the drawing board

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

[duby229]

https://lists.debian.org/debian-kern.../msg00128.html

I think you misunderstood. The link you posted has nothing at all to do with what you quoted.

[SystemCrasher]

https://lists.debian.org/debian-kern.../msg00128.html

I wouldn't hold my breath about S390 which isn't what I call widespread, not to mention it is not a platform to try advanced kernel configuration options and so on, so I would generally expect crappy, "enterprise grade" testing coverage of these cases. But I've got FTBFS on usual x86-64 and ARM, which receieves orders of magnitude better testing coverage, due to large amount of devives and people involved. So I can't remember FTBFS even if running pre-RC kernels. Yet, I can name at least 2 staging drivers failed to build in late mainline RCs, these were Lustre and wilc-something (wi-fi driver). So I had to explicitly disable these. Sure, there was one pesky security feature in mainline which has broken ARMs, so I had to disable it either, but it wasn't FTBFS, so it does not counts :P.

I mean the following: if I get FTBFS in configuration which isn't what I would call terribly exotic, like your S390, it means commited code has faced really poor testing, well below of what could be anticipated. When security feature has clashed with ARMs, it probably was hard to predict due to intrusive nature of feature and deep impact on core part. But driver which just fails to build in typical configuration? Damn, its way too evil.

[Thatguy]

the users of Haiku would love to have AMd GPU support, come on over, not muss no fuss.