Live data from Hacker News

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

lists.freedesktop.org

261–270 of 284 posts

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

#261

Earlier quoted context omitted.

Huh, not sure I understand all of it but good information nonetheless; thanks!

Essentially: accounting is an art. If you do not have profits, you pay less taxes, for example. Paper "losses" are a thing. Money losses are another.

That's a very clueless way to answer their question.

Accounting has several layers:

- Cash flow: this is what you'd look at for your lemonade stand. Actual money comes in and goes out (either "cash cash" or you bank balance, both is "cash" in this regard)

But that layer isn't the most important one for incorporated companies. Yes, running out of cash is a problem. But what usually / actually happens is failure on the "value" level:

- Your company has a value of which cash is only one, usually small, part. Stuff you own, like buildings and patents and brands are another. So is debt your customers have with you. On this level, you can spend money without any effect on the value: If you buy a skyscraper in Manhattan, you may spend %2 billion in cash, but you get a $2 billion building in return. You can also increase the value ("make a profit") without actually getting any money: if you sell the skyscraper for $4 billion on December 20th, 2016, you've made a $2b profit in 2016, even though the money will only arrive in 2017.

The reasoning is that this system results in a more accurate picture of a company's finances.

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

#262

Earlier quoted context omitted.

And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). This is the reason that the AMD open source drivers are within 10~20% of performance of the closed source drivers on a number of chipsets (not all) whereas on Nvidia chipsets the open source driver is often just to boot a system and get X running enough to install the closed source driver.

> And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). That is only relevant if any third-party has any interest in taking up the challenge of developing an alternative driver.

And the open source drivers that do exist (and are far better than the Nvidia open source drivers) are proof that said third parties exist. So the net take away is that if you are a pragmatic open sourcer then you should buy AMD hardware. And even better support the open source coders who do write these drivers; cash, bug reports, testing, documentation, etc.

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

#263
I absolutely love that the maintainers can stick up to any company that tries to add shit code to the kernel.

There is no excuse for AMD. The response reads like a total whine to me.

It's not the kernel maintainers fault that your company does not give you proper resources or approach Linux in a correct way.

If you had proper opensource drivers I'm sure the "in" crowd hackers you speak of would take it from there...

I've personally had horrible experiences with AMD drivers on both Windows and Linux. I had a GPU that worked wellfor my purposes, even ran games well enough for me, but you dropped driver support for it, so I was left with no option but to buy another card...

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

#264

Earlier quoted context omitted.

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…

I have come to fear that we will eventually need GPU drivers in the kernel directly, thanks to more and more of the graphics code out there assuming DRM/DRI etc.

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

#265

Earlier quoted context omitted.

> Without any conflict, uh? > Nvidia has been the single worst company we've ever dealt with. > - Linus This had nothing to do with the kernel and everything to do with the lack of optimus support (years later, its still shit). > Kernel devs are antagonizing the only two GPU makers that matters Maybe the 2 should ask Intel for some pointers on how to contribute to the kernel the right way. > Open source devs are imma…

Sarah Sharp worked for Intel and apparently didn't manage to contribute to the kernel in a way that would make communication with Torvalds particularly pleasant. I extend my sympathy to anyone paid to contribute code to Linux.

to me Sharp came across as trying to score social points by being a "woman in tech" rather than being honesty interested in tech. Something i fear is going on a whole lot in recent years in the FOSS world.

I keep seeing already cash strapped projects go off the rails because someone decides that they need a gender oriented outreach program, complete with elaborate gatherings and whatsnot.

And when that crash and burns, their excuse for the cash bonfire is that the FOSS world is misogynistic...

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

#266
post #243

Earlier quoted context omitted.

This got into negative territory, but I was being serious. Define "good." Is quality a thing just defined by code style and properness, or is it defined as fitness for a purpose, connection to human use and usefulness, usability or function, or lack of defects to the end user? Define "software." Is software just code, or does it also include the experience the code generates for the user? Is software only considered…

Developers are also users, and a part of the application they use is the source code. Having good quality source code benefits all users, not just developers. Linux is where it is today because of the quality of the code. Things like "use and usefulness, usability or function" have different meanings to a developer looking at the source code.

This is why—effectively—use and application of Linux is limited to developers.

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

#267

Earlier quoted context omitted.

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

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.

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

#268

Earlier quoted context omitted.

That argument is too broad, because it could be used against /any/ effort to get code into the kernel by a large corp. Linux is no longer in the weak position it once was. It has won the war for server market share (at least to a degree where using it has nothing to do with being a "hippy" programmer), and it has lost the desktop war so thoroughly that at this point it really doesn't matter anymore. In this position,…

A lot of people are unhappy with Windows 10 and would love to switch. Now if Linux only wants to be a server OS then that is fine but if it wants to try and grow then it does need either AMD or Nvidia. I think that for now Nvidia will continue to do what they have always done(binary blob) but if AMD gains market share by being more open then Nvidia will respond in turn.

GNU/Linux will never be anything more than a server or embedded device OS.

Anyone that is serious about graphics programming is on Windows and Mac.

I learned the hard way that the way that FOSS religion and graphis programming industry don't mix (lost a few job opportunities due to that).

As for the movie industry, they basically have heavily customised GNU/Linux workstations, using the workflows they ported from SGI workstations into GNU/Linux.

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

#269
post #192

Earlier quoted context omitted.

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

For perspective, 3dfx had stellar drivers for their cards, and never had issues with linux kernel maintainers refusing merges of their code for lack of quality.

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

#270

Earlier quoted context omitted.

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…

This. Exactly this. The treatment AMD got from LKML was slightly deserved but doing that they alienated a hardware partner and indirectly set the precedent for doing closed source binary releases that use HAL anyway. It sucks for the consumers and that's what drives the installed base of Linux.

> slightly deserved

ATi was legendary for their terrible drivers. The fglrx drivers took literally 5 years to not suck on first-generation radeon cards. By "not suck", I mean that the system would not have kernel panics at least once a day due to them. While they were piling on support for newer drivers in their proprietary stack, they were leaving triaged bugs open for years. When AMD bought them out, they didn't fire every developer they had and replace them with better talent, which is why we're seeing this LKML thread today.

I attempted to use ATi/AMD video cards in systems every time they'd make a big linux announcement, to attempt to support them for their decisions. Every time, I would have new linux converts telling me they were going back to windows due to how unstable their linux systems were, all thanks to these terrible bug-ridden drivers.

I and many other linux zealots now refuse to use ATi/AMD video cards to this day for that reason. It's clear that AMDGPU is only slightly improved from that situation, so I don't anticipate myself changing that opinion any time soon. The open radeon/radeonsi/radeonhd drivers are substantially more stable than the proprietary ones, adhere to kernel standards, and are now starting to reach feature/performance-parity with the proprietary drivers, with barely any help from ATi/AMD.

The Linux kernel will be just fine without ATi's terrible code infecting the tree. Eventually, the vendors start playing ball once they realize the kernel doesn't budge on code quality/standards, as the net80211 debacle proved. If they had just released all the specs without substantial NDA's in the way, ATi could rely on the volunteer kernel hackers to produce a driver that outperformed their windows equivalents, just like how Intel is currently benefitting.

Post reply on HN