[RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

Thanks Alex my reply was a little off topic :)

-----Original Message-----
From: Alex Deucher [mailto:alexdeucher at gmail.com] 
Sent: Wednesday, December 14, 2016 1:02 PM
To: Cheng, Tony <Tony.Cheng at amd.com>
Cc: Jani Nikula <jani.nikula at linux.intel.com>; Lukas Wunner <lukas at wunner.de>; Bridgman, John <John.Bridgman at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; Grodzovsky, Andrey <Andrey.Grodzovsky at amd.com>; amd-gfx mailing list <amd-gfx at lists.freedesktop.org>; dri-devel <dri-devel at lists.freedesktop.org>
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU

On Wed, Dec 14, 2016 at 12:23 PM, Cheng, Tony <tony.cheng at amd.com> wrote:
>
>
> On 12/14/2016 4:57 AM, Jani Nikula wrote:
>>
>> On Tue, 13 Dec 2016, "Cheng, Tony" <tony.cheng at amd.com> wrote:
>>>
>>> I am struggling with that these comminty contributions to DC would be.
>>>
>>> Us AMD developer has access to HW docs and designer and we are still 
>>> spending 50% of our time figuring out why our HW doesn't work right. 
>>> I can't image community doing much of this heavy lifting.
>>
>> I can sympathize with that view, and certainly most of the heavy 
>> lifting would come from you, same as with us and i915. However, when 
>> you put together your hardware, an open source driver, and smart 
>> people, they
>> *will* scratch their itches, whether they're bugs you're not fixing 
>> or features you're missing. Please don't underestimate and patronize 
>> them, it's going to rub people the wrong way.
>
> I aplogize if my statement offended any one in the community.  I'll 
> say more about bugs below.
>>>
>>> Dave sent us series of patch to show how it would look like if 
>>> someone were to change DC.  These changes are more removing code 
>>> that DRM already has and deleting/clean up stuff.  I guess we can 
>>> nak all changes and "rewrite" our own version of clean up patch community want to see?
>>
>> Please have a look at, say,
>>
>> $ git shortlog -sne --since @{1year} -- drivers/gpu/drm/amd | grep -v 
>> amd\.com
>>
>> Do you really want to actively discourage all of them from contributing?
>> I think this would be detrimental to not only your driver, but the 
>> whole drm community. It feels like you'd like to have your code 
>> upstream, but still retain ownership as if it was in your internal 
>> repo. You can't have your cake and eat it too.
>
> That's none "dal" path.  It's just Alex plus a handful of guys trying 
> to figure out what register writes is needed base on windows driver.  
> You knwo who has been contributing to that code path from AMD and we 
> know it's a relatively small group of people.  Alex and team does 
> great job at being good citizen on linux world and provide support. 
> But in terms of HW programming and fully expolit our HW that's pretty 
> much the best they can do with the resource constraint.  Of course the 
> quality is not as good as we would like thus we needed all the help we 
> can get from community.  We just don't have the man power to make it great.
>
> We are proposing to get on a path where we can fully leverage the 
> coding and validation resources from rest of AMD Display teams (SW, 
> HW, tuning, validation, QA etc).  Our goal is to provide a driver to 
> linux community that's feature rich and high quality.  My goal is 
> community finds 0 bug in our code because we should've seen and fixed 
> those bug in our validation pass before we release the GPUs. We do 
> have a good size team around validation, just today that validation covers 0% of upstream source code.
> Alex and I are trying to find a path to get these goodies on the 
> upstream driver without 2x size of our teams.  We know 2x our team 
> size is not an option.
>
> I just want to say I understand were community is coming from.  Like I 
> said in my first respond to Dave that I would've say no if someone 
> want to throw 100k lines of code into project (DAL) I have to maintain 
> without knowning what's there and the benefit we are getting.  We 
> already made a lot of change and design choice in our code base to 
> play well with community and absorbing the effort to restructure code 
> on other platforms as result of these modification.  We are going to 
> continue making more modifications to make our code linux worthy base on the good feedback we have gotten so far.
>
> DAL3/DC is a new project we started a little over years ago and still 
> early enough stage to make changes.  Like how community is pushing 
> back on our code, after 1 or 2 future generation of GPU built on top 
> of DC, the AMD teams on rest of platforms will start pushing back on 
> changes in DC.  We need find find the balance of what's HW and what's 
> core and how to draw the line so community doesn't make much 
> modification in what we (both AMD and
> community) deem "hardware backend code".  We need to have the linux 
> coding style and design principals baked in DC code so when our 
> internal teams contribute to DC the code is written in a form linux community can accept.
> All of this need to happen soon or we miss this critical inflection 
> point and it's going to be anther 6-8 years before we get another 
> crack at re-archiecture project to try getting the rest of extended 
> AMD display teams behind our upstream driver.

I think the point is that there are changes that make sense and changes that don't If they make sense, we'll definitely take them.
Removing dead code or duplicate defines makes sense.  Rearranging a propgramming sequence so all registers that start with CRTC_ get programmed at the same time just because it looks logical does not make sense.

Alex