[RFC] Using DC in amdgpu for upcoming GPU

[Harry Wentland]

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 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).

Harry

> Cheers, Daniel
>