Hacker News Reader

Comment by dzhang50 | Hacker News Reader

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.

View on HN

It does, in fact, report around the gross profit I specified. Why don't you look at the financials [1]. I think many people in this thread, including you, don't know what the term "gross profit" means.

[1] http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-fundIncomeA

But just because they have a seemingly sufficient gross margin doesn't mean they don't have significant unavoidable costs that can't neatly be attributed to cost of sales.

I had to look it up. And you're right, I didn't know what the accountants think gross profit means. The thing is, gross profit doesn't include operating expenses[0]: "rent, equipment, inventory costs, marketing, payroll, insurance and funds allocated toward research and development."[1] As you can see on the page you linked, for a company like AMD, their operating expenses are huge. And that's not even including expenses from taxes and debts. So the number we really want, and what I imagine most people are thinking you meant, is net income. Which, you'll notice is sadly rather negative.

[0] http://www.investopedia.com/ask/answers/031015/what-differen...

[1] http://www.investopedia.com/terms/o/operating_expense.asp

Gross profits don't include things like R&D and Sales just the Revenue - cost of goods sold. They have a negative net profit margin. They are hemorrhaging cash, and have a lot of debt. The have negative share holder equity. They are in a bad financial position. Therefore it is kind of commendable they have some one trying to improve their linux drivers. They can't just "Afford" to just throw more people at the problem because of their financial issues.

Writing the software that makes your hardware work is much more of a revenue-based issue than a profit-based issue. Even if you're losing money you need to balance your development budget, and not cut any segment too far.

Their revenue is from Windows, Apple and Cknsoles, not from Linux.

It's impossible whether to tell if it'd be better if their drivers sucked less. It's certainly a massive barrier to Linux being usable.

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

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.

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.

You make some really valid points. I'm sorry I overlooked the part about past drivers because I haven't had the misfortune of experiencing them (from what you say I feel lucky for that).

I don't have an AMD card handy but could you tell me more about the open radeon drivers? And if we do have those, why did this discussion start in the first place?

Are you talking about the Intel firmware or the OpenGL mesa drivers? I would say it has improved but the one pain of tearing videos and panning windows makes me really sad.

The open radeon drivers were developed outside of ATi, using the (limited/sparse) documentation they were provided under extraordinarily strict NDA. As a result, we didn't have things like Z Buffering in the drivers until this year. But despite that, the drivers were in a much better shape.

This discussion (which if you read the dri-devel thread, ended with the ATi guys saying "we're sorry. we'll do better") is happening because AMD's marketing department dictates that they keep as much of the driver closed and developed in-house as possible. They're completely opening the kernel driver, but every layer above that is planned to be closed. There will be a free Mesa/Xorg/Wayland stack developed by volunteers in parallel with the proprietary drivers, for those that actually want to use their computer and not experience kernel panics (at a performance cost, due to not having full documentation of the card). Oh yeah, the proprietary drivers haven't even begun support for Wayland yet, and probably won't for another year or two.

This is a step up from before, mind you; AMD's previous setup under fglrx was a closed-source kernel driver with binary blobs, which would usually require a recompile every time you upgraded your kernel. In addition, because their software team was insane, they would take a snapshot once a year of the mainline kernel/X11, and build against that instead of merging to the latest tree. This means that all distros would have to pin their kernel/Xorg packages to a specific version (again, a year out of date), otherwise you just plain wouldn't have accellerated video. Arch (and other rolling distros) got so fed up with it that they stopped building fglrx in their repository, forcing people to use the open radeon/si/hd drivers. You had to do a rather immense amount of voodoo (add third-party repository, pin xorg/kernel to ancient versions included only in that repository, downgrade packages) just to get them working. If there's an exploit in the kernel or xorg, tough. If you want to have system uptime measured in days/weeks/months, tough. If you want Xinerama (good multi-monitor that plays nice with xrandr) support, tough.

In comparison, this new situation is a lot better. AMD is at least playing nice with the kernel developers, and the development team has fought enough with the marketing department to embrace a semi-open development model, which is where this dri-devel discussion comes in. We also got a pretty good inside view of way that AMD develops drivers/hardware, and some amusing commentary by the dri-devel maintainers (including Intel employees) about how screwed-up AMD's internal culture is to produce these sorts of problems. For instance, their software team cannot communicate with the hardware team, because by the time the drivers are started, the hardware team has moved on to another card, and all the knowledge is pretty much lost/changed/irrelevant. This bears repeating: the hardware and drivers are developed separately and at different times.

The end result of the thread is that they're going to split this 100,000 lines of hardware abstraction into much smaller chunks and merge it piece by piece. Hopefully this means that AMDGPU will be worth using in Kernel 4.10 or 4.11, depending on how long it takes.

I'm still using intel's mesa/kernel drivers in my chromebook. Yes, tearing/panning is gross, but if I had to pick between Intel and AMD's code on my machine, it's a no-contest.

Thanks for taking the time out for such a super detailed reply.

> Linux drivers on the nVidia side are OK.

Except for the annoying tearing. I'm considering a RX480 for my next GPU thanks to it.

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.

> some value

I think you have answered your own question here :)

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.

They are doing to to compete in the high margin part of the market, which is workstations, cloud rendering, GPUs, and console contracts. They care zero about low end linux desktop. But what nvidia learned is that the people who do all that high end stuff would much prefer it to just work, and will steer business accordingly.

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.

Your example re wifi is not great, works fine for me. Dell hardware.

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

Reply on news.ycombinator.com