[RFC] Using DC in amdgpu for upcoming GPU

[Cheng, Tony]

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.
>
> BR,
> Jani.
>
>