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
