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

191–200 of 284 posts

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

#191

Post by Certhas »

notalaser wrote: post #178
quetzthecoatl wrote: post #118

Earlier quoted context omitted.

Isn't it because the high end hardware becoming useless because of the very lack of drivers? Nobody wants to spend lot of money on hardware and don't get to use it optimally. Driver support on platform -> Games released on platform -> Gamers using the platform.

Linux drivers on the nVidia side are OK. I've had excellent performance, and no trouble with them for what I think are already 10 years now, if not more. Lack of driver support is not what's stopping people from releasing Linux games.

And they are closed source. AMD tried to go open source and upstream and found out that that is not viable, because they would need to duplicate a lot of work in order to avoid putting abstractions in the kernel.

The upshot is, kernel developers have been complaining about nVidia lots for the route they took. When I install Linux on a reasonably recent desktop I still have to fiddle with boot options and/or blacklist the nouveau driver for some nVidia cards. And now nVidias approach has been completely vindicated.

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

#192

Post by Zelmor »

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.

Fear of missing out on market segment, as well as support for super-computer configurations. Without keeping a foot in the door for these segments, they risk fading away into obscurity like 3dfx did back in the days (for other reasons, however).

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

#193

Post by Certhas »

chris_wot wrote: post #173
mcpherrinm wrote: post #164

Earlier quoted context omitted.

I think the argument here is that stability is gained from having code shared as closely as possible with the Windows codebase, which is where most of the QA work happens, and what the real experts debugging their ASICs use. From a hardware and driver development standpoint, I think that makes a decent amount of sense. Hardware is often weird and quirky, so making sure you handle all the edge cases in two different c…

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.

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

#194

Post by dorianm »

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

Proposed driver code: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d...

The file with the atomic functions: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/d...

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

#195

Post by aseipp »

bostik wrote: post #157
serge2k wrote: post #43

Earlier quoted context omitted.

why does AMD need to be in the kernel? Why can't they release the way nVidia does? or open source it, develop along with upstream but don't make it part of upstream.

You're asking a question with a very complex answer. I'll start with a short answer - AMD wants to have at minimum a reasonably good baseline functionality on linux, out of the box. If that answer doesn't make much sense, please read on for the complex bits. To provide some historical context, Linus gave a VERY public, VERY brutal rant on NVIDIA and their drivers four years ago.[0] At the time, NVIDIA's closed driver…

> In effect, if you wanted to run linux, you were best off without NVIDIA.

Depends on your choices. I guess if you throw Intel in there as an option, then maybe. But as of 4 years ago, if you were running a desktop -- Nvidia was pretty much the only acceptable choice if you wanted discrete graphics on Linux of any form, IMO, and driver quality was a massive part of why this is true.

Optimus, though -- that's what was really the debbie-downer for Linux/Nvidia, and Optimus is what inspired the question which lead to Linus's "Fuck you" rant, because Optimus support was so bad, and is still bad.

But the mainstream cards have worked fine for a long time, and, at least for me and everyone I know -- were the only acceptable ones for Linux, until relatively recently, and most certainly as of ~5yrs ago. As opposed to AMD, where I don't think I ever heard of a single instance of fglrx ever being anything but a nightmare.

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

#196

Post by geezerjay »

threeseed wrote: post #108
CamperBob2 wrote: post #69

Earlier quoted context omitted.

They don't have the resources to do it right. I loved that line from his post, in particular. "We have the resources to design a billion-transistor GPU, but not to write a Linux driver for it." Poor management on AMD's part does not constitute an emergency on the Linux kernel's part.

How is that poor management ? Linux gaming is a blip when you compare it to (a) the total gaming market, (b) the professional creative market and (c) the big data/deep learning market. All of which AMD is selling graphics cards into. And it's not like Linux is even some massive growth market that justifies some risky investment.

GPU support means high-performance computing.

Today's 3rd spot on Top500 is occupied by a GPU-based supercomputer.

...which is equipped with NVidia cards.

https://www.top500.org/system/177975

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

#197

Post by digi_owl »

pas wrote: post #166
jwr wrote: post #159

This is yet another situation where I (as a user) am being held hostage [1]. The net result of attitudes like these is that I can't have a working multi-monitor desktop Linux setup, because everything is hopelessly broken and requires many hours of tinkering just to kind-of sometimes work. I find it sad. [1] Apple has been excelling at this recently, too, with the forced move to USB-C and dropping of the headphone ja…

Hm, some folks have installed Ubuntu, plugged in monitors, and it works for them. KDE usually screws up when I plug a monitor into my notebook, but Xfce doesn't. It's not a kernel issue. KDE has a guy, he's singlehandedly awesome, yet of course a bit strange when it comes to interacting with mortals, who works on "these" things: https://blog.martin-graesslin.com/blog/2016/09/to-eglstream-... And see, that it's NVIDIA…

Best i can tell, Xfce gets it right because by virtue of being short staffed they trust X to not screw up. KDE and Gnome would rather see X get out of the way and let them do their "magic".

Sadly the latter people are now in control of "X" development, or perhaps i should say post-X development, thanks to Wayland.

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

#198

Post by makomk »

trome wrote: post #158
AstralStorm wrote: post #136

Earlier quoted context omitted.

Not really severely. It has a few questionable tweaks here and there. The questionable part is CPU companies not pushing for upstream integration, so you get e.g. Qualcomm Linux. In fact, the process is not pushing, it is pulling. (some people have started working on it, still long way off) It can be done, as shown by efforts by TI, ARM and many more...

Hell, even Rockchip, Allwinner and Sony can do it, Qualcomm, Mediatek, Google and Samsung are just not doing it because they are able to skate by without doing it. The funny part is on Windows Phone, Microsoft learned from the kernel development process and made Samsung, LG, HTC, et all upstream their drivers, whereas Google in the same position with the same vendors has not done this and thus Sony is the only OEM pu…

Upstream Allwinner support is a community effort, and it takes so long to convince the kernel developers to merge code that parts are generally years obsolete by the time they're fully supported. I think the upstream support may almost be at the point that C.H.I.P could use it - but they're using a single-core SoC from early 2012. I've seen patches for basic functionality like clock controllers (without which nothing works) get stuck in endless mailing list arguments about the most elegant approach, contradictory requirements from different maintainers, all sorts. It's not working.

The kernels used by actual Allwinner-based Android devices have almost nothing in common with the upstream support. They use a completely different mechanism for describing the hardware configuration, a completely different set of drivers, and are based on a kernel that predates upstream support.

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

#199

Post by carlosrg »

nottorp wrote: post #162

Well, there's a reason I only ever buy NVidia video cards, even for AMD CPUs. I'm fine with AMD not being interested in Linux support, I'll just vote with my wallet.

Yes, because NVIDIA has been great contributing kernel code. /irony

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

#200

Post by geezerjay »

serge2k wrote: post #43
izacus wrote: post #27

Earlier quoted context omitted.

The kernel essentially demanded they drop the idea of cross-platform driver (which is what makes nVidia drivers work so well on Linux and is keeping them in lockstep with Windows releases) and maintain a full separate copy with a small team. It was unrealistic six months ago as it is now. And yet, I still don't see a constructive debate from Linux (or AMD) side on how to sync the goals. All I see is Linux people post…

why does AMD need to be in the kernel? Why can't they release the way nVidia does? or open source it, develop along with upstream but don't make it part of upstream.

> why does AMD need to be in the kernel?

Speaking as an ATI user, having the drives in the kernel means that the GPU card just works right out of the box.

No need to mess up with drivers. Just install a distro and you're good to go.

Post reply on HN