[1] http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-fundIncomeA
[0] http://www.investopedia.com/ask/answers/031015/what-differen...
[1] http://www.investopedia.com/terms/o/operating_expense.asp
[1] https://en.wikipedia.org/wiki/Linux_gaming#Market_share_vs._...
I think you have answered your own question here :)
Driver support on platform -> Games released on platform -> Gamers using the platform.
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.
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.
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.
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.
Except for the annoying tearing. I'm considering a RX480 for my next GPU thanks to it.
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 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.
I can understand AMD wanting to unify their codebase. I agree with the parent that they shouldn't worry so much about upstreaming into the kernel. I think their HAL approach is the right engineering one, given the constraints that their team is working under. The team seems to be trying to do the best with what they've been given.
Also, hasn't the graphics division been spun-off into a separate company now (Radeon Graphics Group)? Or is it just a more focused internal division within AMD?
Their paid developers are being outclassed by volunteers who write more solid drivers. Somehow this doesn't sink in.
Well, as far as I understood, that's exactly what the entire discussion is about: their HAL that would allow them to reuse large parts of their well optimized and tested Windows code and integrating that into the kernel.
Later in the dri-devel thread, they even admit that DC isn't even being used in the Windows drivers, because by the time the software devs get to write drivers, the hardware devs they should be hooking up with have already moved to the latest/greatest thing, and can't be bothered with legacy.
AMD's drivers are far from "well-optimized", and their internal developer culture perpetuates this problem.
That being said, the current situation is bleak, and no, they never made a ridiculous amount of money. They've had to go to pretty extreme lengths not to go under already (eg, selling off their headquarters building, then leasing it back, just to scrape together some quick cash). They're very, very cash strapped. So much so that the news they signed a somewhat nebulous licensing deal with a Chinese company to help them make servers caused their share price to jump 52%, just because they'd be getting ~$300m in licensing fees.
How can you lose billions of dollars and still be in business? Are they borrowing the money from someone? Where is the money they don't have coming from?
Each year you spend $100 million on salaries, rent, and materials, and you earn $500 million in sales, leaving you with $400 million in the bank at the end of year 1, $800 million after year 2, $1.6 billion after year 4, etc.
Pretty good, right? Not really.
You're cash flow positive to the tune of $400 million/year, but you're not profitable. You spent $9 billion on that fab; since it'll last for 15 years that means each year costs about $600 million. Or to put it another way, at the end of 15 years you'll have $6 billion in the bank, but you started with $9 billion. Turning $9 billion into $6 billion is the opposite of a profit. And since it's not enough to build a new fab, it's also the opposite of "having a functional business".
Another example might be selling off a profitable business for an injection of cash. The cash helps you pay salaries and keep the lights on, but if that's all you do with it you're now even less profitable than when you started. Or as in AMDs case, you could sell off your headquarters, then lease it back. You get a pile of cash initially, but you then have to pay it all back and more just to keep using your headquarters, and the increased costs will lower profits.
Similarly, if you can convince people to keep investing, you can run keep running a loss but not run out of cash.
(All numbers utterly hypothetical. I'm also simplifying a lot.)
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.
Looking at the quarterly data, as of Sept 2016, you can see in the Balance Sheet, there is a "Capital Surplus" line showing they have raised $8.2B of equity over the life of the Corp. Now look at the "Retained Earnings", they have lost $7.7B of it. They also have $1.6B in debt.
AMD's existence prevents Intel from having to face prosecution for monopoly status.
Additionally, think about Google, Amazon, MS Azure and all the other big players who push large volume on Intel's higher end SKUs, what do you think they will do if Intel becomes their sole source vendor? I'd predict all 3 will take their current dabbling in ARM servers and amp it up, since being captured by a single vendor is a serious issue for all of them.
Correct Link: https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v....
1 - http://www.theverge.com/2014/6/12/5803442/intel-nearly-1-and...
http://www.tgdaily.com/business/44723-amd-to-use-intel-cash-...
Even that is misleading... More recently, AMD lost $406 million between June to Sept 2016.
The belie, however, is an appalling response really:
I realize you care about code quality and style, but do you care about stable functionality? Would you really merge a bunch of huge cleanups that would potentially break tons of stuff in subtle ways because coding style is that important? I'm done with that myself. I've merged too many half-baked cleanups and new features in the past and ended up spending way more time fixing them than I would have otherwise for relatively little gain. The hw is just too complicated these days. At some point people what support for the hw they have and they want it to work. If code trumps all, then why do we have staging?
Wut? If you want stable functionality, then you follow the kernel conventions, practices and coding styles.
This whole screed equates to: "We've got some code we've put together in our silo, you amateurs who want perfection are wrong and our unified layers and push to get our processors to market mean you can't comment on our code."
The bit about cleanups makes little sense to me, they seem to have some fundamental issues baked into their code that will necessitate these very cleanups...
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 codebases is a lot harder than doing it once. Certainly too much work for a handful of people who just want to plug their code into Linux.
Stability here is on the driver/hardware interaction, not the kernel/driver boundary, which is what the kernel folks seem to care about, naturally.
HTH.
I think not. So no, it didn't help.
> There's only so much time in the day; we'd like to make our code perfect, but we also want to get it out to customers while the hw is still relevant.
And this has always been the damn problem with AMD's drivers, even in their wheelhouse, Windows. They just have a slipshod attitude toward the software end of their core business.