Hi Alex, I'll leave the other bits out, just replying to atomic/android comments. On Fri, Dec 9, 2016 at 6:32 PM, Deucher, Alexander <Alexander.Deucher@xxxxxxx> wrote: > I understand forward progress on APIs, but frankly from my perspective, atomic has been a disaster for stability of both atomic and pre-atomic code. Every kernel cycle manages to break several drivers. What happened to figuring out how to do in right in a couple of drivers and then moving that to the core. We seem to have lost that in favor of starting in the core first. I feel like we constantly refactor the core to deal with that or that quirk or requirement of someone's hardware and then deal with tons of fallout. Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android. Are you basically telling us that you'd rather we water down our driver and limit the features and capabilities and stability we can support so that others can refactor our code constantly for hazy goals to support some supposed glorious future that never seems to come? What about right now? Maybe we could try and support some features right now. Maybe we'll finally see Linux on the desktop. Before atomic landed we've had 3 proof-of-concept drivers. Before I've added the the nonblocking helpers we've had about 5-10 drivers doing it all wrong in different ways (and yes the rework highlighted that in a few cases rather brutally). We know have about 20 atomic drivers (and counting), and pretty much all the refactoring, helper extractions and reworks _are_ motivated by a bunch of drivers hand-rolling a given pattern. So I think we're doing things roughly right, it's just a bit hard. And no Android isn't everything we care about, we want atomic also for CrOS (which is pretty much the only linux desktop thing shipping in quantities), and we want it for the traditional linux desktop (weston/wayland/mutter). And we want it for embedded/entertainment systems. Atomic is pretty much the answer to "KMS is outdated and doesn't match modern hw anymore". E.g. on i915 we want atomic (and related work) to be able to support render compression. And of course I'd like to invite everyone who wants something else with DRM to also bring that in, e.g. over the past few months we've merged the simple kms helpers for super-dumb displays to be able to be better at the fbdev game than fbdev itself. Not something I care about personally, but it's still great because more users and usecases. And the same applies of course to AMD. But what I'm seeing (and you're not the only one complaining, Michel has raised this on irc a few times too) is that you're not in the driver seat, and AMD folks don't really have any say in where DRM overall heads towards. As an outsider looking in I think that's because AMD is largely absorbed with itself, doesn't have people who can just do random things because they see the long-term benefits, and is occopied absorbing new teams that don't yet design and develop with an upstream first approach. Personally I'm not really happy about that, because I'd like more of AMD's perspective in infrastructure work. But I don't think that's because upstream and maintainers reject your stuff, I'm trying as hard as possible to drag you folks in all the time, and tons of people get stuff merged with even smaller teams than you have.I think it's simply because core work seems not to be a top priority (yet). I can't fix that. You're other criticism is that all these changes break shit, and agree there's been a bit much of that. But otoh if we can't change e.g. fb refcounting anymore because it would break drivers, or try to deprecate old interfaces to get rid of the plenty of rootholes in there, then upstream is dead and why should we bother with having a standardized, cross-vendor modeset interface. And I'm trying to fix this mess, by emphasising CI, building up a cross-vendor validation suite in igt, inviting folks to participate in drm-misc to make sure core stuff is working for everyone and moves in the right direction. And again lots of people pick up on that offer, and we have multiple people and vendors now e.g. looking into igt and starting to contribute. But again AMD is left out, and I don't think that can be blamed on the community. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
