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

71–80 of 284 posts

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

#71

Post by prodigal_erik »

hubert123 wrote: post #38

I am not familiar at all with this stuff but honestly people should be working on a way to isolate external code in the kernel at runtime somehow. I wouldnt want to be in either position, I dont want to maintain somebody else's shitty code or get any kind of bugs for my own code from it but I also wouldnt want to be in AMDs position and adhere or rewrite some code that I'm absolutely fine with as it is. There is a la…

The problem isn't runtime isolation. The problem is that if you merge a Windows driver into the Linux kernel, the Linux hackers won't be able to make effective and safe changes to it as the rest of the kernel evolves, because it's nearly unreadable to them.

An unmaintainable mess with lots of users is not a victory unless users are paying you for shitty work.

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

#73

Post by snarfy »

izacus wrote: post #25
zznneezznnee wrote: post #11

The kernel maintainers don't necessarily want your code. Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception. Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a…

Then again, we're not talking about some wierd network card driver here. We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog hap…

> A driver which has caused a large amount of desktop users to return to Windows due to its historical issues.

Kernel developers do not care. They care about good software.

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

#74

Post by j1vms »

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? 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 important to more technical Linux users (including corporate).

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

#75

Post by drewg123 »

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 recent example is that I was debugging a rogue DMA issue in a driver that uses the linux kpi shims. I wanted to use the Intel DMAR to try to catch the DMA, but because of the use of linux shims, the driver would not work at all with the DMAR. We had to improve the linux kpi shims to do busdma, rather than just use pmap_kextrect() to convert kernel virtual to physical addresses (and this was a hack, because there is a gigantic imedence mismatch between dma_map_single and busdma). And, as soon as we had the driver working with the DMAR, we caught the rogue DMA.

Weeks of my time could have been saved if, instead of writing to Linux, the vendor driver had included a full hal that supported busdma. Instead, they wrote to the linux kpi.

And I fully blame the Linux kernel maintainers for this. They're on top of the world and can dictate to hardware vendors to remove their portability shims. Meanwhile, other OS projects get the dregs.

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

#76

Post by dzhang50 »

lvs wrote: post #57
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 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,…

AMD doesn't have "gross profit in the $1 - 2 billion range". They have about $1B in revenue per quarter and have had negative profits (i.e. they lose money) for quite some time now. They were on the verge of bankrupcy about a year ago. Maybe Zen can turn their fortunes around, but they're correct in that they don't have the resources for a dedicated development team right now.

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

#77

Post by fapjacks »

this-dang-guy wrote: post #46
fapjacks wrote: post #33

Earlier quoted context omitted.

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.

I'd prefer to see NVidia style drivers, personally. I don't give a rat's beans if optimized video card, nic, etc drivers are open. I just want a system that will work properly without them. Not 60FPS on Ultra settings in work, I mean boot and function as a normal user's desktop.

Yeah, I don't care about nvidia drivers, either. AMD doesn't need this in the kernel anymore than nvidia does (and they don't). Kernel modules work just fine for drivers. I don't want some convoluted shit crammed into mainline because chooses to ignore feedback about their code. I am perfectly fine with this one guy shooting down AMD's pretentious attitude here. If it weren't for those kernel devs, good luck getting a Linux system to "boot and function as a normal user's desktop" because of all the crap that would be in there. Like systemd, just piles of crap in a confused, kitchen-sink orgy.

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

#78

Post by [deleted] »

lvs wrote: post #57
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 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,…

[deleted]

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

#79

Post by kstrauser »

fbreduc wrote: post #53
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…

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

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

#80

Post by quickben »

serge2k wrote: post #42
izacus wrote: post #37

Earlier quoted context omitted.

The "answer" 6 months ago was "Yeah, you'll have to write a full Linux driver yourself and maintain it." type deal. It was unreasonable then as it is now. If I tell you "You need to rewrite your product in Brainfuck or I'll kick you out in 6 months.", the fact that I told you that doesn't make it any less insane.

> I can respect your technical points and if you kept it to that, I'd be fine with it and we could have a technical discussion starting there. Why is that so unreasonable?

By the look of it, he's trying to be reasonable now; after half a year of hope that the code will just get checked in because it's coming from AMD, regardless of quality.

If I recall correctly, Google tried the same thing some time ago and it didn't go well for them either.

Post reply on HN