[RFC] Using DC in amdgpu for upcoming GPU
mmacy at nextbsd.org
Sat Dec 10 00:29:19 UTC 2016
---- 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.
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
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
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).
More information about the dri-devel