<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p>Yep, good point. We have tended to stay a bit behind bleeding edge because our primary tasks so far have been:</p>
<p><br>
</p>
<p>1. Support enterprise distros (with old kernels) via the hybrid <span>driver</span> (AMDGPU-PRO), where the closer to upstream we get the more of a gap we have to paper over with KCL code</p>
<p><br>
</p>
<p>2. Push architecturally simple code (new GPU support) upstream, where being closer to upstream makes the up-streaming task simpler but not by that much</p>
<p><br>
</p>
<p>So 4.7 isn't as bad a compromise as it might seem.<br>
</p>
<p><br>
</p>
<p>That said, in the case of DAL/DC it's a different story as you say... architecturally complex code needing to be woven into a fast-moving subsystem of the kernel. So for DAL/DC anything other than upstream is going to be a big pain.
<br>
</p>
<p><br>
</p>
<p>OK, need to think that through. </p>
<p><br>
</p>
<p>Thanks !<br>
</p>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> dri-devel <dri-devel-bounces@lists.freedesktop.org> on behalf of Daniel Vetter <daniel@ffwll.ch><br>
<b>Sent:</b> December 12, 2016 2:22 AM<br>
<b>To:</b> Wentland, Harry<br>
<b>Cc:</b> Grodzovsky, Andrey; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; Cheng, Tony<br>
<b>Subject:</b> Re: [RFC] Using DC in amdgpu for upcoming GPU</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:<br>
> Current version of DC:<br>
> <br>
>  * <a href="https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7">
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7</a><br>
> <br>
> Once Alex pulls in the latest patches:<br>
> <br>
>  * <a href="https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7">
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7</a><br>
<br>
One more: That 4.7 here is going to be unbelievable amounts of pain for<br>
you. Yes it's a totally sensible idea to just freeze your baseline kernel<br>
because then linux looks a lot more like Windows where the driver abi is<br>
frozen. But it makes following upstream entirely impossible, because<br>
rebasing is always a pain and hence postponed. Which means you can't just<br>
use the latest stuff in upstream drm, which means collaboration with<br>
others and sharing bugfixes in core is a lot more pain, which then means<br>
you do more than necessary in your own code and results in HALs like DAL,<br>
perpetuating the entire mess.<br>
<br>
So I think you don't just need to demidlayer DAL/DC, you also need to<br>
demidlayer your development process. In our experience here at Intel that<br>
needs continuous integration testing (in drm-tip), because even 1 month of<br>
not resyncing with drm-next is sometimes way too long. See e.g. the<br>
controlD regression we just had. And DAL is stuck on a 1 year old kernel,<br>
so pretty much only of historical significance and otherwise dead code.<br>
<br>
And then for any stuff which isn't upstream yet (like your internal<br>
enabling, or DAL here, or our own internal enabling) you need continuous<br>
rebasing&re-validation. When we started doing this years ago it was still<br>
manually, but we still rebased like every few days to keep the pain down<br>
and adjust continuously to upstream evolution. But then going to a<br>
continous rebase bot that sends you mail when something goes wrong was<br>
again a massive improvement.<br>
<br>
I guess in the end Conway's law that your software architecture<br>
necessarily reflects how you organize your teams applies again. Fix your<br>
process and it'll become glaringly obvious to everyone involved that<br>
DC-the-design as-is is entirely unworkeable and how it needs to be fixed.<br>
<br>
>From my own experience over the past few years: Doing that is a fun<br>
journey ;-)<br>
<br>
Cheers, Daniel<br>
-- <br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
<a href="http://blog.ffwll.ch">http://blog.ffwll.ch</a><br>
_______________________________________________<br>
dri-devel mailing list<br>
dri-devel@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/dri-devel">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a><br>
</div>
</span></font></div>
</div>
</body>
</html>