Valve Confirms Official AMD-Powered Steam Machines For 2014
forbes.com
forbes.com
The linked article doesn't mention this possibility, but perhaps the reason that Valve made no mention of AMD machines is because AMD's Linux drivers are complete and utter crap.
The initial run has Nvidia, Valve has been working with Intel on their graphics drivers, and are going with AMD for some sort of run of Steam Boxes next year? Sounds like any. I don't see how that is too surprising; that is how they roll on Windows too.
What I find surprising is the idea that AMD must necessarily be out of the running. Both the Xbox One and the PS4 are getting AMD GPUs, so how irrelevant could AMD possibly be?
Consider the options:
* AMD GPU / fglrx: good hardware, terrible drivers.
* AMD GPU / radeon: good hardware, good but incomplete drivers.
Why would anyone interested in gaming opt for a dramatically worse experience by choosing AMD? You can't play games with the radeon drivers, and the fglrx drivers don't work.It's not about the hardware. AMD's hardware is great. You just can't actually use it reliably when running Linux -- you get to pick between having a working, but limited, set of features (radeon), or having the full set of features and crashing once a day or more (fglrx).
@drivebyacct2, who is unfortunately hellbanned, makes a good point too:
"Well, in the other corner you have NVIDIA, who still won't (and I'm willing to partially blame Canonical) step up and say for sure that they will support KMS and/or Wayland. Without that, it's going to always be something of a workaround to output wayland-on-nvidia and won't be a really good experience."
You also have to consider that the PS4 graphics APIs will likely be a lot simpler and down to the metal than DX9/10/11 and (especially) OpenCL.
They're not going to support KMS immediately, as it's too simplistic for the full range of stuff that they would need to do (complicated modes, stereo support, etc.). The FOSS driver people are working on atomic modeset and atomic pageflip, which NVIDIA will investigate the API and see if it fits their needs.
They're also happy to support this stuff if we give them an API that ties into their driver and allows them to drop some of their code, but we first need to do that, with their feedback. The community is actively working on that.
It's a kernel driver so triple the fun.
They should just follow Intel and switch effort to the free drivers, fglrx has been in this rotten state for years and years and it's clearly not getting fixed.
My gaming machine has always been in "Windows only" territory due to the fact that I tend to run configurations that are slightly outlying -- my current machine has three monitors and two AMD 6970 videocards, with two monitors attached to one videocard, one attached to the other. I was incredibly surprised to find that this configuration worked 'out of the box' on #!, and continued to work perfectly after the install of fglrx drivers. No issues with hardware acceleration, no crashes, no difficulties whatsoever (beyond having to increase the 'virtual' resoluting in xorg.conf so I could move screens where I wanted in xrandr.)
All this brings me in a roundabout way to my point: If my wacky configuration can work relatively seamlessly in an arbitrary distro, I tend to think that AMD will probably be able to manage to get fully supported configurations running on SteamOS in a straightforward fashion.
That, or I can pray they make the free driver at least somewhat useful. Currently, it seems you get what you pay for..
The graphics performance is good and they have the fastest and most feature complete OpenCL implementation by far. Early buffer swap latency problems have been ironed out.
The only real gripes I have is that vsync with multiple monitors doesn't work too well and KMS isn't supported.
And at least with AMD I can be sure that my card will keep being supported by open source drivers once Catalyst support is dropped.
The open source drivers are a terrible power drain on laptops.
Perhaps some of this varies depending on the part? But none of this inspires confidence.
<Shrug> ... worksforme...
I have AMD Radeon cards on my machines at work. Work fine with Linux drivers, even have a 3 monitor setup going.
It was interesting how they had this announced. First they said "we certainly are planning to make AMD hardware for SteamMachines, but ask Valve yourselves" and then Valve issued a press statement (probably slightly under pressure).
That model seems to appeal to nobody but tech people.
http://www.amazon.com/Best-Sellers-Computers-Accessories-Lap...
In general, that's very true for a lot of places in the US. While I can find a lot of free wifi in NYC these days, they are slow and some of them aren't secured either. So while chromeOS might be secure as OS, I still don't quite trust the connection.
It's not quite "red ocean" and not quite "blue ocean" because they are targeting the gap between the two markets, and many customers will probably own both a console and a Steambox, or a PC and a Steambox, but of course some may forgo all but the Steambox.
I'd argue it surely beats sitting on decade old hardware an entire console cycle. That was probably one of the primary motivators for SteamOS as a consolesque platform - Sony and Microsofts inertia circa 2012 was presenting a gaping hole in the market, and Nintendo's Wii U was (and still is) underwhelming. If Valve could get an open platform with vendor competition and constant product iteration in the living room, it would cement them there as much as it did on Windows digital distribution.
That plan might not have come to complete fruition the way they were hoping, though - both of their chief competitors will have months and a holiday season ahead of them, and SteamOS hasn't announced any launch titles or exclusives to attract early adopters (of the whole living room platform and haptic controller, at least).
Then Linux takes the blame for worse driver support, impairing adoption. It's a vicious circle.
The real ray of sunlight is that huma (heterogeneous unified memory access?) might close some of the gap.