On 12/14/2016 4:57 AM, Jani Nikula wrote:
On Tue, 13 Dec 2016, "Cheng, Tony" <tony.cheng@xxxxxxx> 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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
