[RFC] Using DC in amdgpu for upcoming GPU

[Matthew Macy]

 ---- On Fri, 09 Dec 2016 12:34:17 -0800 Dave Airlie <airlied at gmail.com> wrote ---- 
 > On 10 December 2016 at 05:59, Daniel Vetter <daniel at ffwll.ch> wrote:
 > > I guess things went a bit sideways by me and Dave only talking about
 > > the midlayer, so let me first state that the DC stuff has massively
 > > improved through replacing all the backend services that reimplemented
 > > Linux helper libraries with their native equivalent. That's some
 > > serious work, and it shows that AMD is committed to doing the right
 > > thing.
 > >
 > > I absolutely didn't want to belittle all that effort by only raising
 > > what I see is the one holdover left.
 > 
 > I see myself and Daniel have kinda fallen into good-cop, bad-cop mode.
 > 
 > I agree with everything Daniel had said in here, and come next week I might
 > try and write something more constructive up, but believe me Daniel is totally
 > right! It's Saturday morning, I've got a weekend to deal with and I'm going to
 > try and avoid thinking too much about this.
 > 
 > I actually love bandwidth_calcs.c I'd like to merge it even before DAL, yes
 > it's ugly code, and it's horrible but it's a single piece of hw team magic, and
 > we can hide that. It's the sw abstraction magic that is my issue.
 > 
 > Dave.
 

David - 
 I recognize that the maintainer role you play is critical to the success of Linux. 
You need to honor your responsibilities as well as maintain 
your rapport with Linus. In FreeBSD committers are largely siloed and 
no one is designated to facilitate the import of outside contributions. As a 
consequence, vendor driver developers are given commit bits and 
not infrequently commit near unmaintainable garbage. Academic 
committers commit half baked code to meet a publishing deadline - which 
they subsequently abandon. And much work by non-committers never makes it 
in. Frequently, the self-appointed gatekeepers in the community will block work 
with little visible discussion or negotiation about how to meet their demands 
(ENOTIME being the typical response). When I talk to people outside the 
community about the ways in which FreeBSD most notably fell short of Linux, 
the one point that resonates the most is the lack of clear path or transparency 
in upstreaming contributions. 

As maintainer your responsibility is first and foremost to the long term health of 
Linux - not being popular with contributors. 


That said, as a prospective AMD shareholder I have a few observations to make 
about what they should do. 

First of all, by any measures AMD graphics profit margins are razor thin. Even 
when their products have been clearly superior to Nvidia's consumers have, 
as a group, held off and paid more for Nvidia's. See the following youtube video 
if you're curious as to just how poorly they have fared in mindshare: http://bit.ly/1J7020P 
I have no doubt that they lack the resources to support Linux at the same level 
of Windows without large amounts of code sharing. I was under the impression 
that their ROC compute stack would be near ready for mainline this summer. It's 
now clear that, at best, it won't happen any sooner than next summer. 

As a downstream consumer of Alex's code on Linux and FreeBSD I *hope* that 
AMD will do whatever it takes to put their codebase on par with Windows. There are 
only two makers of high end GPUs and one one of them is opaque and closed source. 

However, as a prospective shareholder who is under the impression that almost none 
of their income comes from Linux users - if they need to have a fully native 
Linux driver I think they have 3 real choices: 

a) Dumb down the driver. It just needs to push pixels. Admit that Nvidia has won the mindshare 
for anything like high end graphics on Linux. Just be good enough to run X and basic mesa demos. 

b) Go back to a closed source driver. Although the DRM layer churns rapidly, the underlying 
KPIs that it uses change very slowly. To the limited extent they need to it's not that hard to 
decouple from the underlying kernel. Nvidia's seen little to no blowback for only providing 
binary support for a narrow set of Linux kernels. 

In fact - the reason I run Linux is because of the Linux only binary CUDA stack. Blobs can 
have some nice lock-in benefits for Linux. 

c) a+b - write a "good enough" driver for open source and keep a closed driver for selected 
large consumers. 

AMD's responsibility is first and foremost to its shareholders. If doing right by Linux is in 
conflict with that the choice is clear. It is those of us dependent on it being open source that lose 
the most. 

I think the net consequence of this will be to reinforce the dominant position of Nvidia and  the marginal relevance of open source graphics outside of embedded (Intel's support for Linux is great, but it really is not in the same league as Nvidia or AMD).

-M