Live data from Hacker News

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

lists.freedesktop.org

271–280 of 284 posts

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

#271

Earlier quoted context omitted.

Maybe this is why their net is negative; because they don't allocate money to the right things.

In my experience supporting Linux desktop is hardly ever the right thing. Example: ubutnu cannot consistently ship a version of network manager that supports reconnecting to a wifi network suspend with out being manually restarted. I suspect that at a dollar value there is most no point but I don't have access to enough data to prove it.

> Lennart Poettering's NetworkManager

Your experience is limited, and tainted. wpa-supplicant by itself can accomplish what you desire; NetworkManager (poorly) adds three or four extra layers of abstraction on top of that.

Meanwhile, Wicd and connman do exactly what you need, and don't constantly crash while doing it.

Blame ubuntu for following Red Hat's lead, and using their "solutions" to the problem.

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

#272
post #57

Earlier quoted context omitted.

The claim that AMD, a company with gross profit in the $1 - 2 billion range, does not have the resources to support a dedicated development team that can do a good job on upstream-able code is just farcical. That's a question of corporate priorities, not resources, and gets precisely to the critique of corporate culture that was in question. > There's only so much time in the day; we'd like to make our code perfect,…

That may have been true of their driver quality in the past, but it's really not so true now. On Windows, their constant work at improving drivers, leading up to the release of their Crimson driver software, has been evident over the last two years. I have not had an AMD driver issue since maybe late last year (when there was a persistent incompatibility for a long time between Oculus Rift and the drivers). I run a d…

In The Thread: Windows users thinking improved windows performance somehow equates to improved linux driver quality.

Their paid developers are being outclassed by volunteers who write more solid drivers. Somehow this doesn't sink in.

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

#273

Earlier quoted context omitted.

Also GPU-as-a-service seems to be a growth market, and Linux is usually the first choice in X-as-a-service.

That's what's frustrating to me. I have an AMD R9 290 and an Intel integrated GPU. I want to use them together for GPGPU stuff (simulating dybamical systems), but the driver situation has consistently been kindof a mess. I get it working and then all the sudden things shift and I have to configure again... Reminds me of the good old days of configuring xorg.conf in 2004.

if you're still using fglrx, configuring xorg.conf is still a part of your life.

the sooner fglrx dies, the better off the planet will be.

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

#274
post #183

Earlier quoted context omitted.

Or even better, give us an open source out-of-tree driver, and wait. Someone in the community will do the cleanup and get it upstream eventually. For free .

While that's probably true, it won't happen overnight, and I understand their position of wanting it merged before rolling out new hardware, or more generally, as soon as possible.

How come Intel can do this, but ATi/AMD can't?

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

#275

Earlier quoted context omitted.

That may have been true of their driver quality in the past, but it's really not so true now. On Windows, their constant work at improving drivers, leading up to the release of their Crimson driver software, has been evident over the last two years. I have not had an AMD driver issue since maybe late last year (when there was a persistent incompatibility for a long time between Oculus Rift and the drivers). I run a d…

In The Thread: Windows users thinking improved windows performance somehow equates to improved linux driver quality. Their paid developers are being outclassed by volunteers who write more solid drivers. Somehow this doesn't sink in.

> In The Thread: Windows users thinking improved windows performance somehow equates to improved linux driver quality.

Well, as far as I understood, that's exactly what the entire discussion is about: their HAL that would allow them to reuse large parts of their well optimized and tested Windows code and integrating that into the kernel.

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

#276
post #17

Earlier quoted context omitted.

I suppose the intended notion, would be given the number of Linux distributions and use cases out there, the number of companies involved, the number of products built on top of the Linux kernel... it's amazing that one guy with little financial interest in the results or effects can make that call for everyone. I'm not sure if that's a good thing or a bad thing, to be honest, it's just... particularly interesting ab…

It's amazing that one guy with little financial interest in the results or effects can make that call for everyone. Impartial expert judges are usually considered a good thing. Note that Dave Airlie is not acting on a whim here; the Linux development community has discussed HALs for probably 20 years and has come to the conclusion that they are a net negative. For better or worse, the Linux development process does n…

Yep, each vendor that doesn't want to deal with it, just forks it, never contributing anything back.

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

#277

What I don't get is how one kernel maintainer can make such a massive decision that affects all of Linux. That's some near-totalitarian level of power. After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.

The Good King is how Linux has come to run the world's servers. I am perfectly fine missing out on some incidental functionality here or there in order to keep this power structure which had protected the Linux kernel thus far. It seems to work extremely well.

Being a free beer clone of expensive UNIX workstation OSes helped.

Of course companies had an agenda to improve it to the point they wouldn't need to keep paying Sun, SGI, HP, IBM, Compaq, Unisys,...

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

#278
This was all a big ado over nothing. John Bridgman and two other AMD devs have backed away from Alex's initial flame-y post, and are trying to de-silo their codebase, break up the commit into smaller patches, and move forward (despite their marketing dept. getting in the way of fully-upstreaming beta cards the way Intel does).

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

#279

Earlier quoted context omitted.

In The Thread: Windows users thinking improved windows performance somehow equates to improved linux driver quality. Their paid developers are being outclassed by volunteers who write more solid drivers. Somehow this doesn't sink in.

> In The Thread: Windows users thinking improved windows performance somehow equates to improved linux driver quality. Well, as far as I understood, that's exactly what the entire discussion is about: their HAL that would allow them to reuse large parts of their well optimized and tested Windows code and integrating that into the kernel.

> well-optimized

Later in the dri-devel thread, they even admit that DC isn't even being used in the Windows drivers, because by the time the software devs get to write drivers, the hardware devs they should be hooking up with have already moved to the latest/greatest thing, and can't be bothered with legacy.

AMD's drivers are far from "well-optimized", and their internal developer culture perpetuates this problem.

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

#280

Alex, from AMD, has now posted a response saying he over-reacted https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

Everyone should take a deep breath and read this - it wasn't even a merge request originally, just an RFC.
Post reply on HN