It's very simple, Linux won't bend the rules for anyone, and that includes AMD.
The sooner they realize that, the faster they can actually work together with Linux kernel maintainers.
AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
211–220 of 284 posts
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#212Earlier quoted context omitted.
You say "so what", but that is the so what. A core Linux developer saw a massive commit come though from AMD and couldn't understand it easily. The point that has been made over and over in these threads is that if you want to develop Linux code then you can't just stick a development team to work in complete isolation from everyone else in the Linux development community and expect to be able submit grand unifying a…
I'm not arguing with you over what they did, I have not read about it enough. I didn't even read the the exchange in full. This is purely political and a sign of a lack of leadership. The Linux guys should be so grateful for these drivers that they do everything they can to keep AMD happy. > The point that has been made over and over in these threads is that if you want to develop Linux code then you can't just stick…
> I'm not arguing with you over what they did, I have not read about it enough. I didn't even read the the exchange in full. This is purely political and a sign of a lack of leadership.
"I literally don't even know what I'm talking about at all, I'll admit it -- but definitely, trust me and my immediate assessment of the situation, it's accurate"
LOL.
>> The bottom line is: AMD want to merge this into the kernel's main tree
> No, AMD wants to have working AMD drivers on Linux.
Are you even reading the words you type? AMD _already has working drivers_. They're right there. You can go look at the code right now, 'git pull' it and install it on your machine. What's stopping you? Your inability to read, apparently?
No, it is literally -- by the definition of the above email -- the case that they want to merge already existing code upstream, into the kernel, and have upstream share the maintenance burden. That's part of the deal -- if AMD code goes upstream, everyone helps maintain it, and in turn, they help maintain everyone elses.
But it turns out, upstream doesn't want their code in its current state. Of course, they don't have to merge it upstream -- they just want to. They don't even have to merge it upstream now or "soon", but they would have liked that. They could easily ship the AMDGPU driver as an external module using DKMS or something, just as things like ZFS-on-Linux do, and start ironing out problems for upstreamability while actually shipping drivers to people.
They have drivers. The drivers work already, in fact. Having them upstream is totally different. Try reading the article and doing some digging through this thread to understand the context.
> But hell, maybe Linux devs think that Linux is so important now that they can pressure AMD devs into doing whatever they want from them. Maybe it works, maybe it wont.
You realize that given AMD's history -- it's entirely possible AMD needs Linux more than Linux needs AMD, right? Linux doesn't need to win the desktop or win over AMD, it thrives in its own market and has been surviving perfectly well without them.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#213"This is something you need to fix, or it'll stay completely painful forever. It's hard work and takes years, but here at Intel we pulled it off. We can upstream everything from a _very_ early stage (can't tell you how early). And we have full marketing approval for that. If you watch the i915 commit stream you can see how our code is chasing updates from the hw engineers debugging things. Daniel Vetter Software Engi…
Well, whatever Intel has been doing, they're just successful as merging their codebase. It doesn't mean the driver is stable though.
The KMS/dri driver itself certainly has _major_ unsolved issues since basically forever. The KMS driver for broadwell graphics was trashing the screen with massive horizontal flicker until kernel 4.8. That's not a long time ago. It's still not solved BTW, just got less frequent. Random pipeline stalls happen on an hourly basis. Tons of graphical glitches and random performance issues with the "glamour" accell path. I've stopped reporting issues at their tracker, as they just get ignored.
The performance of the KMS driver is also inferior to their existing xorg driver in a number of very important scenarios (Xrender is particularly affected).
Sure, I do have vulkan drivers as first class, but my screen flickers, I get graphical corruption and the driver hangs the entire system with certain shaders. I can see inkscape repainting beneath my eyes like it's '84. Wow. And I'm trying that with 4.9 rc8.
I've been using laptops with integrated graphics for almost 10 years. The moment you can get the intel driver to work half-decently, they're already rewriting it. I wish I was kidding.
Intel does have the money. They're actually doing worse in my mind.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#214Earlier quoted context omitted.
> We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer Nvidia manages to do this without any conflict with the kernel maintainers by simply not mainlining the code. If functionality trumps code quality, AMD can release kernel modules. Perhaps the best current solution for all parties is for AMD publish sources on github and release kernel modules while getting…
Without any conflict, uh? https://www.youtube.com/watch?v=iYWzMvlj2RQ > Nvidia has been the single worst company we've ever dealt with. > - Linus Kernel devs are antagonizing the only two GPU makers that matters. Besides the kernel, there has been some flame going between NVIDIA and Wayland devs too. Open source devs are immature men who do not understand the word compromise.
[deleted]
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#215Earlier quoted context omitted.
I don't know if HALs in the kernel would have been the smart thing to do here (I'm not familiar enough with the problem to comment; generally, abstracting hardware access behind a HAL is a smart thing, but "generally" is a really bad snare trap). On the other hand, I'd really love to see the Linux team getting the same treatment that Microsoft gets whenever they encourage lack of portability, even where portability w…
> I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now" AMD was told 6 months ago that it wouldn't be merged if they didn't follow certain guidelines. Then they didn't follow the guidelines. What bothers me here, is the way AMD's management has handled the whole thing. It seems like management demanded it be a c…
You may be right but do you have any evidence? It's too convenient for developers to just blame managers when stupid things happen.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#216Earlier quoted context omitted.
Huh, not sure I understand all of it but good information nonetheless; thanks!
Essentially: accounting is an art. If you do not have profits, you pay less taxes, for example. Paper "losses" are a thing. Money losses are another.
Accounting is a conart
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#217Earlier quoted context omitted.
Essentially: accounting is an art. If you do not have profits, you pay less taxes, for example. Paper "losses" are a thing. Money losses are another.
Accounting is a conart
Well, no; it doesn't really even impact whether you pay dividends/taxes or not, but it does impact when you pay them. It's not that difficult to shift things across financial years, although eventually you'll show the profit/loss accurately, cumulatively.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#218Didn't the AMD guy respond months ago that he expects they'll reduce it to like 30k loc? What happened to that?
Not that this is the crux of the problem, just curious.
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#219Earlier quoted context omitted.
Intel infused them with money the last time they were about to go under. AMD's existence prevents Intel from having to face prosecution for monopoly status.
Thanks! But what does "infused them with money" money mean? They wrote them a check for a few billion dollars? Would you mind explaining like I'm completely clueless (which I kind of am)? I literally don't know (or if I did, remember) anything about this so the missing details are not helping. Thanks!
Intel actually gave about 1.25B$ to AMD in 2009, in order to rid itself of an unfair competition and patent claim. This helped AMD to stay afloat. Without it, Intel would be in an effective monopoly position and that would bring in all sorts of restrictions (due to competition laws particularly in the US and EU) it doesn't want to have.
http://www.tgdaily.com/business/44723-amd-to-use-intel-cash-...
Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch
#220Earlier quoted context omitted.
Stability for whom? Trying to contort Linux code to follow the practices that work well for Windows does not strike me as either maintainable, or even particularly stable!
What does this have to do with Windows vs Linux? It's about closely working with hardware engineers.
"I think the argument here is that stability is gained from having code shared as closely as possible with the Windows codebase".
HTH.