On Fri, Dec 9, 2016 at 3:30 PM, Dave Airlie <airlied at gmail.com> wrote: >> I think this is part of the reason a lot of people get fed up with working upstream in Linux. I can respect your technical points and if you kept it to that, I'd be fine with it and we could have a technical discussion starting there. But attacking us or our corporate culture is not cool. I think perhaps you have been in the RH silo for too long. Our corporate culture is not like RH's. Like it or not, we have historically been a windows centric company. We have a few small Linux team that has been engaged with the community for a long time, but the rest of the company has not. We are working to improve it, but we can only do so many things at one time. GPU cycles are fast. There's only so much time in the day; we'd like to make our code perfect, but we also want to get it out to customers while the hw is still relevant. We are finally at a point where our AMD Linux drivers are almost feature complete compared to windows and we have support upstream well before hw launch and we get shit on for trying to do the right thing. It doesn't exactly make us want to continue contributing. That's the problem with Linux. Unless you are part time hacker who is part of the "in" crowd can spend all of his days tinkering with making the code perfect, a vendor with massive resources who can just through more people at it, or a throw it over the wall and forget it vendor (hey, my code can just live in staging), there's no room for you. > > I don't think that's fair, AMD as a company has a number of > experienced Linux kernel developers, who are well aware of the > upstream kernel development process and views. I should not be put in > a position where I have to say no, that is frankly the position you > are in as a maintainer, you work for AMD but you answer to the kernel > development process out here. AMD is travelling a well travelled road > here, Intel/Daniel have lots of times I've had to deal with the same > problems, eventually Intel learn that what Daniel says matters and > people are a lot happier. I brought up the AMD culture because either > one of two things have happened here, a) you've lost sight of what > upstream kernel code looks like, or b) people in AMD aren't listening > to you, and if its the latter case then it is a direct result of the > AMD culture, and so far I'm not willing to believe it's the former > (except maybe CGS - still on the wall whether that was a good idea or > a floodgate warning). > > From what I understood this DAL code was a rewrite from scratch, with > upstreamability as a possible goal, it isn't directly taken from > Windows or fglrx. This goal was not achieved, why do I have to live > with the result. AMD could have done better, they have so many people > experienced in how this thing should go down. I think I over-reated a bit with this email. What I really wanted to say was that this was an RFC, basically saying this is how far we've come, this is what we still need to do, and here's what we'd like to do. This was not a request to merge now or an ultimatum. I understand the requirements of upstream, I just didn't expect such a visceral response from that original email and it put me on the defensive. I take our driver quality seriously and the idea of having arbitrary large patches applied to "clean up" our code without our say or validation didn't sit well with me. Alex
