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.
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.
Driver support on platform -> Games released on platform -> Gamers using the platform.