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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
