---- On Fri, 09 Dec 2016 12:34:17 -0800 Dave Airlie <airlied@xxxxxxxxx> wrote ---- > On 10 December 2016 at 05:59, Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
