I wasn’t originally going to even waste time on these developments… but over the past weeks I’ve been noticing a lot of confusion on the net, so I will just give my two cents here.
Well, yet another linux distribution… As John Carmack already said, linux is not the right OS for video games. He would know, he has published a few games for linux in the past, and uses linux for the flight computers at Armadillo Aerospace.
He is not so much talking about technical issues, but as he says, it is just a poor business case, mainly because of the low market share. He proposes an emulation layer such as Wine, so that Windows games can run as-is. Which I suppose he is saying because Windows is a consistent platform (you know exactly what libraries and APIs to expect), where linux is not.
The fact that Valve feels the need to release their own linux distribution seems to mirror that notion. This way Valve can at least make sure that there is one linux distribution that comes with the right libraries, APIs, drivers and whatnot, so that games will run out-of-the-box as they do on Windows. As I said earlier, if they would stick only to third-party linux distributions, they would run the risk that OS updates would introduce incompatibilities with certain games, or even Steam itself. But the question is: are they supporting linux this way, or just SteamOS?
Google is doing something similar with Android. They use the linux kernel, but other than that, the Android platform is pretty much a parallel universe to the GNU/linux platform. It is quite possible that SteamOS will take a similar route, where it will be difficult, or even impossible to get Steam games running on other linux-based OSes, because they are just too different.
Things could also go the other way: What if Steam support would become a priority of other linux distributions? An organization such as Ubuntu has more manpower and experience available when it comes to tweaking and fine-tuning a linux distribution. So what if Ubuntu would actually run Steam games better than SteamOS itself?
It will be interesting to see where this is going. The biggest problem however is simply: how do you get gamers interested in running SteamOS (or any other linux) over Windows? Valve is going to launch a SteamBox, but judging by the hardware, it is not going to be cheap. It is not going to be in the price range of other consoles. And it will only be able to play Steam games which have been ported to linux, which is not a whole lot. Yes, they want to stream Windows games from another box, but what’s the point in that? You’d need their expensive console AND another decent gaming PC in order to run the Windows games. Might as well just install Windows on the SteamBox itself then. There are just so many more Windows games, that I don’t see any way they can make SteamOS or the SteamBox an attractive deal.
As for Mantle, AMD’s vapourware graphics API… Let’s defuse some nasty rumours first… Has Intel expressed interest in supporting Mantle? No they have not. Andrew Lauritzen, an Intel employee, has expressed personal interest in the API on his personal twitter account. Which is not surprising. I mean, I would like to have a look at the Mantle API as well. Does not mean that I am going to use it, I will decide that once I’ve seen it. However, the same tweet also said that AMD did not provide him with any information. People just pulled that small tweet completely out of context, and made it into Intel officially stating that they were going to support Mantle.
Is it even likely that Intel is going to do that? I don’t think it is. The main redeeming value of Mantle is that it allegedly reduces the CPU overhead. Why would a CPU company like Intel be interested in that? I can see why AMD wants/needs it: their CPUs are much slower than Intel’s. But for Intel, the more CPU overhead, the better, really.
Is Mantle an open API? That depends on how you look at it. CUDA is an open API in the sense that nVidia will allow other vendors to implement support. Nobody ever did however, since CUDA is obviously designed for nVidia’s architectures, and supporting a completely different architecture would prove to be quite inefficient. Not to mention that you are at nVidia’s mercy when it comes to API updates and extensions. You never know what nVidia will think of next.
Mantle is a very similar story. The API is tied quite closely to the hardware. So closely, that it does not even run on all of AMD’s own DX11-class GPUs, but only their Graphics Core Next architecture. As AMD’s Chris Hook himself said in an interview:
So Mantle is not an open standard ? Let’s say some IHVs [Independent Hardware Vendors] want to write a Mantle backend/driver, what would be the requirements for them ?
Chris Hook, Head of PR – There aren’t many companies of course… Because of GCN they don’t have Mantle capable hardware today…
So, according to AMD, the competition does not even have Mantle-capable hardware in the first place. So they couldn’t support Mantle if they wanted to. They would have to make a GCN-like architecture first, and then they could implement Mantle. That is not likely to happen. So even though they say “it’s not AMD’s CUDA”, it very much is.
Is Mantle used on consoles? Again, unlikely. Microsoft and Sony already supply their own APIs, which already have the advantage that they are a minimal abstraction layer over specific hardware, so minimum CPU overhead. They also already expose the full functionality of the GPU, because only one GPU has to be supported.
Besides, as Carmack points out, if Mantle indeed boosts performance on PC hardware, it would make them more competitive with their own consoles, and why would they want that?
Does Mantle make API calls 9x as fast? If it sounds too good to be true, it usually is. What AMD probably meant to say is that the calls are up to 9x as fast. This may well be true, in some isolated cases. However, in practice, there is a lot more to it.
Not all draw calls are equal, so I doubt that they can claim the same 9x figure on every single draw call. Aside from that, what does it really mean to have faster draw calls? That depends on a lot of things. Even if you were to reduce the CPU overhead, the GPU won’t magically get faster. So you will just run into GPU-limited territory sooner (it would basically just mean that the faster draw calls make the CPU wait longer on the GPU or other CPU-threads). So it all depends on just how much of a factor the CPU-overhead is in the overall performance. I personally expect Mantle to be something like 10-15% faster than Direct3D on a high-end system in practice. We will see once the Battlefield 4 patch with Mantle support will arrive.
And that is giving them the benefit of the doubt. For years we’ve had people claiming that OpenGL calls had less overhead than Direct3D as well. Yes, that may well be true, but it did not result in OpenGL having better performance than Direct3D. The same can be said for Direct3D 10+ vs Direct3D 9. The API in Direct3D 10+ works in a much more efficient way, theoretically, where you can update large blocks of state information with just a single call. Since my engine supports both Direct3D 9 and 10+, I have done some testing on that. I came to the conclusion that although my test scene needed 83 calls in Direct3D 9, and only 11 calls in Direct3D 10+, the Direct3D 9 version actually ran at a fractionally higher framerate (and that is on Windows 7, where Direct3D 9 runs slightly slower than on Windows XP anyway).
So draw calls, call overhead and all that… It is not as simple as just counting the number of calls, or just trying to measure the overhead of a single call. Direct3D 9 may be less efficient than Direct3D 10+ on paper, but apparently a lot of optimization has gone into the drivers over the years, so all that theoretical overhead just isn’t an issue in practice.
So, let’s just wait and see if this Mantle is really as good as AMD claims it is. I am skeptic… firstly, because it is yet another vendor-specific API, which is not a lot of incentive to support it (especially since even for older AMD hardware you still need to have a Direct3D or OpenGL fallback path). Secondly, because I don’t expect the performance gains to be all that dramatic in practice. Thirdly, it appears that AMD and DICE are just making the Mantle API up as they go along, so it is still very much vapourware at this point (I suppose the Mantle project is what Richard Huddy was getting at a few years ago, since repi aka Johan Andersson of DICE was the one to back him up on that. So their solution to making the API go away is to introduce Mantle… an API? And I was right in saying we need something like Direct3D, since although Battlefield 4 will support Mantle, it also includes a Direct3D renderer for compatibility with a larger range of hardware). And lastly… if it is indeed tied so closely to the hardware, what will happen with future architectures from AMD? If we look at the PowerSGL API for example… The first few generations of PowerVR hardware supported the API, but the newer Kyro architecture did not, so you could no longer run any PowerVR-specific code on them, only Direct3D and OpenGL. Mantle may suffer a similar fate.
Apparently AMD was a bit ahead of itself… Microsoft has officially announced that Mantle is NOT available on Xbox One:
The Xbox One graphics API is “Direct3D 11.x” and the Xbox One hardware provides a superset of Direct3D 11.2 functionality. Other graphics APIs such as OpenGL and AMD’s Mantle are not available on Xbox One.
There are also doubts about the availability of Mantle on the PlayStation 4:
While not confirmed, it’s also likely Mantle is not compatible with the PlayStation 4. AMD’s Ritchie Corpus, director of ISV relations, told TechSpot at the GPU14 Tech Day event that “the current Mantle as we launched it was entirely developed on PC”, and although he didn’t confirm whether a version or subset of Mantle was implemented on consoles, it appears the API is specific to PC.