[RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

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 at amd.com> 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