[RFC] Using DC in amdgpu for upcoming GPU

[Daniel Vetter]

On Mon, Dec 12, 2016 at 09:05:15PM -0500, Harry Wentland wrote:
> 
> On 2016-12-12 02:22 AM, Daniel Vetter wrote:
> > On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> > > Current version of DC:
> > > 
> > >  * https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > > 
> > > Once Alex pulls in the latest patches:
> > > 
> > >  * https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
> > 
> > One more: That 4.7 here is going to be unbelievable amounts of pain for
> > you. Yes it's a totally sensible idea to just freeze your baseline kernel
> > because then linux looks a lot more like Windows where the driver abi is
> > frozen. But it makes following upstream entirely impossible, because
> > rebasing is always a pain and hence postponed. Which means you can't just
> > use the latest stuff in upstream drm, which means collaboration with
> > others and sharing bugfixes in core is a lot more pain, which then means
> > you do more than necessary in your own code and results in HALs like DAL,
> > perpetuating the entire mess.
> > 
> > So I think you don't just need to demidlayer DAL/DC, you also need to
> > demidlayer your development process. In our experience here at Intel that
> > needs continuous integration testing (in drm-tip), because even 1 month of
> > not resyncing with drm-next is sometimes way too long. See e.g. the
> > controlD regression we just had. And DAL is stuck on a 1 year old kernel,
> > so pretty much only of historical significance and otherwise dead code.
> > 
> > And then for any stuff which isn't upstream yet (like your internal
> > enabling, or DAL here, or our own internal enabling) you need continuous
> > rebasing&re-validation. When we started doing this years ago it was still
> > manually, but we still rebased like every few days to keep the pain down
> > and adjust continuously to upstream evolution. But then going to a
> > continous rebase bot that sends you mail when something goes wrong was
> > again a massive improvement.
> > 
> 
> I think we've seen that pain already but haven't quite realized how much of
> it is due to a mismatch in kernel trees. We're trying to move onto a tree
> following drm-next much more closely. I'd love to help automate some of that
> (time permitting). Would the drm-misc scripts be of any use with that? I
> only had a very cursory glance at those.

I've offered to Alex that we could include the amd trees (only stuff ready
for pull request) into drm-tip for continuous integration testing at
least. Would mean that Alex needs to use dim when updating those branches,
and you CI needs to test drm-tip (and do that everytime it changes, i.e.
really continuously).

For continues rebasing there's no ready-made thing public, but I highly
recommend you use one of the patch pile tools. In intel we have a glue of
quilt + tracking quilt state with git, implemented in the qf script in
maintainer-tools. That one has a lot more sharp edges than dim, but it
gets the job done. And the combination of git track + raw patch file for
seding is very powerful for rebasing.

Long term I'm hopefully that git series will become the new shiny, since
Josh Tripplet really understands the use-cases of having long-term
rebasing trees which are collaboratively maintainer. It's a lot nicer than
qf, but can't yet do everything we need (and likely what you'll need to be
able to rebase DC without going crazy).

> > I guess in the end Conway's law that your software architecture
> > necessarily reflects how you organize your teams applies again. Fix your
> > process and it'll become glaringly obvious to everyone involved that
> > DC-the-design as-is is entirely unworkeable and how it needs to be fixed.
> > 
> > From my own experience over the past few years: Doing that is a fun
> > journey ;-)
> > 
> 
> Absolutely. We're only at the start of this but have learned a lot from the
> community (maybe others in the DC team disagree with me somewhat).
> 
> Not sure if I fully agree that this means that DC-the-design-as-is will
> become apparent as unworkable... There are definitely pieces to be cleaned
> here and lessons learned from the DRM community but on the other hand we
> feel there are some good reasons behind our approach that we'd like to share
> with the community (some of which I'm learning myself).

Tony asking what the difference between a midlayer and a helper library is
is imo a good indicator that there's still learning to do in the team ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch