from Hacker News

Linux kernel maintainer says no to AMDGPU patch

by pero on 12/9/16, 3:21 AM with 263 comments

• by indolering on 12/9/16, 4:06 AM

  Dave Airlie's followup is pretty great,

  > Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl. Got some new HDMI features that are secret, talk to other ppl in the same position and work out a plan for moving forward. At the moment there is no engaging with the Linux stack because you aren't really using it, as long as you hide behind the abstraction there won't be much engagement, and neither side benefits, so why should we merge the code if nobody benefits?

  > The platform problem/Windows mindset is scary and makes a lot of decisions for you, open source doesn't have those restrictions, and I don't accept drivers that try and push those development model problems into our codebase.

• by laurentoget on 12/9/16, 4:59 AM

  I suspect some bearded guy at AMD is having his 'i told you so' hour of glory sometime this week.

• by fowl2 on 12/9/16, 5:32 AM

  Quite professional, well written and clearly the words of someone who cares about the product.

  Lack of profanities already exceeded the LKML reputation.

  I think the point about rules being applied consistently is very true. If Alice does the work to comply then Bob shouldn't be able to get away without doing it just because he's bigger.

• by joeguilmette on 12/9/16, 4:07 AM

  Anyone want to explain this in simple terms for us folk not knee-deep in kernel graphics driver politics?

• by bentona on 12/9/16, 3:53 AM

  What's the practical effect of this? We'll have to wait until someone writes a reasonable alternative for these GPUs to be supported in Linux?

  Edit: Here's the start of the thread https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

• by mVChr on 12/9/16, 4:38 AM

  For any other layer-7-only arm-chair mechanics who also weren't sure what a HAL[1] was, I'm here to help.

  [1] https://en.wikipedia.org/wiki/HAL_(software)

• by codys on 12/9/16, 4:00 AM

  Summary: HALs in the linux kernel are a not acceptable, even large companies are held to some standards.

  Well, at least for the DRM (Direct Rendering Manager) subsystem.

• by microcolonel on 12/9/16, 4:52 AM

  As far as I'm concerned, it would be great to have more sophisticated modesetting available on my new AMD hardware; but if it means a compromise in the DRI I won't stand for it. There's no sense in having a review process if a vendor can largely ignore a review and go silent for three quarters, then ask for whatever they have to be merged because they'd like it that way.

• by MrQuincle on 12/9/16, 8:29 AM

  It seems people think only about games for now, but taking a maintenance perspective is also wise from the perspective of using GPUs for other purposes.

  One of these is cloud computing on large clusters of headless machines using the parallelization that GPUs are known for. If you want to do this right you definitely need input from a lot of sources, not just hacks in AMD delivered code.

• by ageofwant on 12/9/16, 4:04 AM

  This is why the Linux kernel runs and will continue to run the world.

  The No men is all that stands between us and the Yes men.

  Praise and salutations to the No men, God bless you.

• by leni536 on 12/9/16, 7:55 AM

  Many people in this thread implicitly suggest that this will have a negative impact on end users. I'm not so sure, amdgpu still can be distributed separately to the vanilla kernel.

  So this rejection is about maintainership that negatively affects distribution of the amdgpu module as a side effect. It's nothing that can't be solved by linux distributions though.

• by theparanoid on 12/9/16, 3:57 AM

  Sucks to be an AMD graphics driver developer, right now.

• by mijoharas on 12/9/16, 11:54 AM

  Can anyone explain what the acronym DC stands for in these emails? (managed to get most of the others, but googling DC kernel doesn't turn up much :) )

• by fithisux on 12/9/16, 4:05 PM

  The bright side is that they are OSS friendly, not like NVIDIA, and they can take their code to github for cleanup and further inclusion.

• by UhUhUhUh on 12/9/16, 4:59 PM

  I side with the little guy (i.e. < 2.5% market share) who makes my personal life easier everyday.

• by hobarrera on 12/12/16, 11:31 AM

  What are the chances that some lone developers will pick this source up and patch it up enough to be acceptable inside the kernel?

  I mean, it is all GPL, so it's perfectly okay. Is it too much for some dev in seek of fame to do this?

• by danvet on 12/10/16, 11:14 AM

  I commented a summary on the phoronix forums already, copypasting here. I'm the good cop in the good cop/bad coop game Dave&I have been playing in this. Maybe this helps clear up some of the confusion and anger here.

  This is me talking with my community hat on (not my Intel maintainer hat), and with that hat on my overall goal is always to build a strong community so that in the future open source gfx wins everywhere, and everyone can have good drivers with source-code. Anyway:

  - "Why not merge through staging?" Staging is a ghetto, separate from the main dri-devel discussions. We've merged a few drivers through staging, it's a pain, and if your goal is to build a strong cross-vendor community and foster good collaboration between different teams to share code and bugfixes and ideas then staging is fail. We've merged about 20 atomic modeset drivers in the past 2 years, non of them went through staging.

  - "Typing code twice doesn't make sense, why do you reject this?" Agreed, but there's fundamentally two ways to share code in drivers. One is you add a masive HAL to abstract away the differences between all the places you want your driver to run in. The other is that you build a helper library that programs different parts of your hw, and then you have a (fairly minimal) OS-specific piece of glue that binds it together in a way that's best for each OS. Simplifying things of course here, but the big lesson in Linux device drivers (not just drm) is that HAL is pain, and the little bit of additional unshared code that the helper library code requires gives you massive benefits. Upstream doesn't ask AMD to not share code, it's only the specific code sharing design that DAL/DC implements which isn't good.

  - "Why do you expect perfect code before merging?" We don't, I think compard to most other parts in the kernel DRM is rather lenient in accepting good enough code - we know that somewhat bad code today is much more useful than perfect code 2 years down the road, simply because in 2 years no one gives a shit about your outdated gpu any more. But the goal is always to make the community stronger, and like Dave explains in his follow up, merging code that hurts effective collaboration is likely an overall (for the community, not individual vendors) loss and not worth it.

  - "Why not fix up post-merge?" Perfectly reasonable plan, and often what we do. See above for why we tend to except not-yet-perfect code rather often. But doing that only makes sense when thing will move forward soon&fast, and for better or worse the DAL team is hidden behind that massive abstraction layer. And I've seen a lot of these, and if there's not massive pressure to fix up th problem it tends to get postponed forever since demidlayering a driver or subsystem is very hard work. We have some midlayer/abstraction layer issues dating back from the first drm drivers 15 years ago in the drm core, and it took over 5 years to clean up that mess. For a grand total of about 10k lines of code. Merging DAL as-is pretty much guarantees it'll never get fixed until the driver is forked once more.

  - "Why don't you just talk and reach some sort of agreement?" There's lots of talking going on, it's just that most of it happens in private because things are complicated, and it's never easy to do such big course correction with big projects like AMD's DAL/DC efforts.

  - "Why do you open source hippies hate AMD so much?" We don't, everyone wants to get AMD on board with upstream and be able to treat open-source gfx drivers as a first class citizen within AMD (stuff like using it to validate and power-on hardware is what will make the difference between "Linux kinda runs" and "Linux runs as good or better than any other OS"). But doing things the open source way is completely different from how companies tend to do things traditinoally (note: just different, not better or worse!), and if you drag lots of engineers and teams and managers into upstream the learning experience tends to be painful for everyone and take years. We'll all get there eventually, but it's not going to happen in a few days. It's just unfortunate that things are a bit ugly while that's going on, but looking at any other company that tries to do large-scale open-source efforts, especially hw teams, it's the same story, e.g. see what IBM is trying to pull off with open power.

  Hope that sheds some more light onto all this and calms everyone down ;-)

• by partycoder on 12/9/16, 4:07 AM

  I wonder why this feedback came just now and not earlier.

  It will be time consuming to change now.

• by nice_byte on 12/9/16, 4:18 AM

  honestly, i'd rather have a functional but proprietary driver than have nothing at all. this is wrong.