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

Post by sangnoir » Sat, Dec 10, 2016, 7:14 AM UTC

j1vms wrote: post #74

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.

> why does AMD need to be in the kernel? Why can't they release the way nVidia does? Perhaps it was strategically important to them to be upstream (marketing point, driver ubiquity)? It may not be the year of Linux on the Desktop, but GNOME and the like are well-placed to grow in usage over the next 5 or so odd years. As others here have said, that other than for average desktop users, I don't see this as being as im…

Post by jaredklewis » Sat, Dec 10, 2016, 7:18 AM UTC

drewg123 wrote: post #75

Coming from the FreeBSD perspective, I would freaking LOVE it if some drivers had a HAL (or, really, OSAL). Instead, for the vendors that cannot allocate the resources to properly support FreeBSD, we have a linux kernel compat shim that tries to translate from the linux kernel apis to FreeBSD ones. This is much harder to deal with than a HAL because it makes it even harder than a HAL to reason about the code. One rec…

Post by sangnoir » Sat, Dec 10, 2016, 7:20 AM UTC

gumby wrote: post #40

I didn't see where Dave slagged AMD's culture, and I think everyone was very polite and detailed about why this doesn't fit. I understand why AMD wants to have one code base, but the kernel needs to have one consistent code base and style and can't afford to do otherwise. There's nothing stopping AMD distributing the code, it just won't be upstreamed.

Post by sangnoir » Sat, Dec 10, 2016, 7:24 AM UTC

indolering wrote: post #90

cypher543 wrote: post #67

Earlier quoted context omitted.

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

Linus made the right engineering choice when he took the monolithic route in the 90's. However, the technical advantages of that architecture are now moot. Sooner-or-later, Google is going to get tired of Linux's shortcomings and build a replacement OS.

Post by nitrogen » Sat, Dec 10, 2016, 7:50 AM UTC

sangnoir wrote: post #124

threeseed wrote: post #108

Earlier quoted context omitted.

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.

> the professional creative market This is not true for the animation/CGI/effects industry where Linux not only looms large but is growing. I'm also sceptical of Linux having a small share of big data/machine learning since this is adjacent to servers where Linux dominates- would you mind sharing your sources? Nvidia's CUDA is cross-platform, this sets a baseline for whatever response AMD is planning.