Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

lists.freedesktop.org

Post reply on HN
Print view View original

141–150 of 284 posts

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#141

Post by lamontcg »

Spivak wrote: post #23

I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect. His arguments see…

> the 'year of the Linux desktop'.

What was that 2001? I can probably dig up an old slashdot and find it...

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#142

Post by [deleted] »

hubert123 wrote: post #121
prodigal_erik wrote: post #120

Earlier quoted context omitted.

The whole point of putting drivers in the kernel tree is that they get properly maintained as part of kernel development. All the kernel hackers are responsible for keeping all the in-kernel drivers working. If it's at all acceptable for a kernel change to break a driver with no fix, that driver doesn't belong in the kernel tree.

The whole point of plugins is that they dont need to be maintained as part of the core product. Seeing AMD's response, it's obvious that they dont expect Linux kernel devs to maintain this thing. They should offer a proper and easy plugin interface for the kernel where devs can make drivers for it without having to merge code into the kernel itself. This really seems too obvious, at some point the kernel will have to…

[deleted]

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#143

Post by wtallis »

chris_wot wrote: post #127
hubert123 wrote: post #121

Earlier quoted context omitted.

The whole point of plugins is that they dont need to be maintained as part of the core product. Seeing AMD's response, it's obvious that they dont expect Linux kernel devs to maintain this thing. They should offer a proper and easy plugin interface for the kernel where devs can make drivers for it without having to merge code into the kernel itself. This really seems too obvious, at some point the kernel will have to…

They do already have clear interfaces that do this. Some modules have less clear interfaces, but if you followed what they were saying they actually said that it would have been easier if they had subclassed some of the code and followed the way that most folks were writing atomic code. And there was a function with the bane "validate" that didn't, well, validate . In a bit of code that rung alarm bells.

An email from one of the Intel devs clarified that the validation was actually happening in the correct place, it just was hard to see that on first reading because the code was too foreign:

> And by following that pattern (and again you can store whatever you want in your own private dc_surface_state) it makes it really easy for others to quickly check a few things in your driver, and I wouldn't have made the mistake of not realizing that you do validate the state in atomic_check.

https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#144

Post by trome »

dman wrote: post #114
bsder wrote: post #111

Earlier 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.

Infused them with money? If you are talking about the legal settlement then this is a very charitable description on what happened from Intels side. https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v... .

Your link is broken, below is the correct one. More importantly, Intel wants AMD to stay alive and keep vaguely competing with them since they avoid significantly worse anti-trust rulings in the future (here is a current one[1]) due to there being no active x86-64 competitors.

Additionally, think about Google, Amazon, MS Azure and all the other big players who push large volume on Intel's higher end SKUs, what do you think they will do if Intel becomes their sole source vendor? I'd predict all 3 will take their current dabbling in ARM servers and amp it up, since being captured by a single vendor is a serious issue for all of them.

Correct Link: https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v....

1 - http://www.theverge.com/2014/6/12/5803442/intel-nearly-1-and...

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#145

Post by cromwellian »

cypher543 wrote: post #67
smnc wrote: post #29

> Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android. Could someone here fill in the details for the uninitiated? Do the kernel…

I don't know the details either, but honestly, I'm amazed that Google hasn't just thrown Linux out and built a microkernel with a Linux-compatible syscall API. That way there's a single binary that only cares about standard ARM things like memory management and scheduling and doesn't require hardware vendors to tweak it for every new SoC. The SoC-specific drivers can be written and updated separately just like apps.…

They have, it's called Fuchsia. I think most the arguments for monokernels have weakened with age. You have L4 microkernels in every iPhone A7 processor now. The demands of security, crash resistance, and portability I think outweigh any small advantages in performance. We've got performance to waste these days, what we're lacking is more secure, crash resilient software.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#147

Post by trome »

phkahler wrote: post #63
bhouston wrote: post #55

Earlier quoted context omitted.

It is hard to get resources to do things right sometimes, even in big companies. There are a lot of competing priorities.

>> It is hard to get resources to do things right sometimes, even in big companies. There are a lot of competing priorities. AMD has the resources. The problem seems to be getting them allocated to this particular issue. I also find your phrasing interesting. Doing it "right" is always my top priority and every compromise from that is considered and balanced. In my experience, not doing it right is almost always more…

AMD could likely allocate the resources, but what will they cut to do so? At this point they are a token competitor to Intel and are losing money and have been losing money for years, so how much of their financial runway are they willing to burn up on a platform that doesn't use them for servers and minimally uses them for gaming (where the platform has no marketshare).

I as a full time debian user for the past few years get it. AMD's Linux devs heavily dislike direct rendering manager and want to provide all the cool crap their proprietary driver does to Mesa, cause DRM is legacy tech and they have over 1000 SKUs of cards to support, 2 competitors breathing down their neck on both the GPU, CPU and SOC sides, and they wanna get this shipped.

I hope I've illuminated the state of the situation for you, I do think the right decision was made to not merge this code, but be realistic about AMD's position, they are so far in the hle financially that customers are having chips made to order after paying, meaning its at least 3 months from the time f order until you get your chip. They spend nearly all that time making the silicon, then packaging it so it can go onto your motherboard.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#148

Post by qb45 »

quanticle wrote: post #140
tw04 wrote: post #102

Earlier quoted context omitted.

Yes, AMD should definitely dedicate an entire team to focusing on writing drivers for desktop Linux. An OS that currently captures less than 1% of the overall desktop gaming market[1]. In other news, McDonald's should really start tailoring their marketing and in-store experience to people making over $10 million/year. [1] https://en.wikipedia.org/wiki/Linux_gaming#Market_share_vs._...

But then why bother? Why even pretend to support Linux? The fact that the Linux team at AMD exists means that upper management must see some value in keeping them around.

> some value

I think you have answered your own question here :)

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#149

Post by geezerjay »

kstrauser wrote: post #79
fbreduc wrote: post #53

Earlier quoted context omitted.

> They don't have the resources to do it right. Honestly I hear this quite often from big companies and it always is the biggest load of BS ever..

Correction: we have the resources. We just don't want to allocate them and would prefer that you did the work instead.

> Correction: we have the resources. We just don't want to allocate them and would prefer that you did the work instead.

Perhaps it's just internal politics: the company did in fact allocated the resources, the people put in charge failed to do their job, and once their screwup goes public they opt to shift the blame elsewhere.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#150

Post by geezerjay »

vacri wrote: post #47
Spivak wrote: post #23

I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect. His arguments see…

You missed the bit where AMD chides kernel maintainer for attacking AMD's corporate culture rather than technical merits, and then goes on to chide maintainer culture in the same paragraph. And it's not even true what AMD says - that to commit to the kernel you need to be a funky part-time hacker or an immense behemoth. There are tons of small hardware shops out there with drivers in the kernel, written by paid devel…

> You missed the bit where AMD

I don't believe he is speaking on behalf of AMD. He is speaking for himself and trying very desperately to shift his blame onto anything he could think of at that time.

He clearly tried to blame the problems caused by his technical decisions on subjective and social reasons.

I don't believe that a AMD PR employee would be so stupid to ever think of saying such nonsense, particularly in such an eggregious manner.

The developer claims he has been working for AMD for 10 years, and yet he still is unable to write a driver, let alone get one accepted. Facts speak for themselves.

Post reply on HN