Carmack, Sweeney and Andersson Unplugged

My opinion on it, in terms of action items: should Nvidia have a response to Mantle? And that's unequivocally no. It would be a horrible mistake if somehow Nvidia got panicked by this and made some lower level Nvidia API. You know, you already have very good low level access through the GPU extensions that Nvidia has always rolled ahead of anywhere else that give you as much performance as you want, to trade the inconvenience of doing Nvidia proprietary stuff. Now, Mantle is AMD. AMD has talked many times in the past about close to the metal type architectures and it only ever became interesting because of their dual console win and if it was just a way to do, on the PC, a little bit more lower level for them I couldn't have cared less.

The landscape does matter that they have both the major console wins with the similar architecture you can get on the PC. Developers will be making systems architectural changes that favour those, so I think it's not a stupid thing for AMD to be doing at this point. If Microsoft and Sony both embraced it that would be very, very powerful for AMD but it doesn't look like they are going to, at least Microsoft from the words that they're mouthing. I mean if I was still doing all of the major technology coding for next-gen game stuff I probably would not be embracing Mantle right now but there would be days when it would be extremely tempting, but I would dispassionately step back and look at it... I probably wouldn't come down on the side saying it's worth the effort there. Obviously others have come to different conclusions.

There are some good ideas in there... we really like the idea of having low level, low overhead access to the GPU. I mean, if you look back at what's in both DirectX and OpenGL, there's a lot of overhead in those APIs and the multiple layers of them and the fact that they gave that to, you know, the old SGI model of hardware rendering which is very, very different than the modern shader based model that we have now where you have potentially unified memory and a lot of processing power available on the GPU and lots of ways of sharing data that go beyond just calling tons of API functions for every little thing you want to do. So there are good ideas there and I hope that it really helps the OpenGL committee and Microsoft shape their future APIs.

If you ask me would I much prefer to have a low level API for accessing the GPU, the answer is yes, but, five of them each for a different hardware architectures and vendors and operating systems - absolutely not. That is the wrong direction for the industry and to have yet another API on the PC that's so different from the standard PC graphics API that's different than the OpenGL, the OpenGL ES that exists on Mac and Android and on iOS and it's different than the PlayStation 3 and the PlayStation 4's low level rendering API and it's different than what Microsoft provides on Xbox. I don't think it's a good idea.

One of the key things about it - and one of the main reasons we're doing it - is that it's not a replacement. It's not designed that way at all. The idea is that we can solve some of the long term problems that we've actually been having on the PC as a platform, all of the stuff we've been talking about today of getting more robust performance, console type of robust, stable performance - those are things we can kind of experiment with and work with today. We do that with D3D and we do that with OpenGL also, of course. This is another avenue that is also really interesting, of just opening up something that we're quite familiar with already... [we] have been spending, well, essentially the last two years working on the next-gen consoles and the architectures so we're intimately familiar with those architectures and I see - even though we're not done with our work with it - I still see it as a success even right now just because of these conversations... It's been a bit stale, you could say, especially in PC graphics...

Microsoft, they have switched focus for quite some time over to other things which they really did need to do but I think now, going forward, it's a really exciting opportunity on the PC space... but I completely agree with both John and Tim that, if Nvidia would do their own API and then Intel would do an API and then someone else would do an API, that's not the future we want to be in, that would be a bad future... Microsoft and Khronos do play an important part in all of this and I hope Mantle will be quite influential in this sense and what we're doing right now specifically with AMD is just a start.

Well, you've used the API, where we have just read the marketing materials. What do you think is the cost, like, in man-years or whatever of implementing Mantle support in Battlefield and what do you think is the ultimate gain on PC? Could you try to quantify that?

It is too early to quantify. We've been very busy just making sure that our game works overall and actually shipping it off. We're almost done with it, so it's too early to say. We'll have a lot more information in middle November when we talk more about it... but when it comes to bottlenecks it's not like the bottleneck, OK, we solve this one, we're done, go home and the game runs well. Bottlenecks are like Wac-a-Mole, where you finally fixed one and then you thought that that was the thing that you made that was four times faster and then the next bottleneck shows up after 10 per cent of that.

Of course the biggest issue is that, really you have to architect your large scale vision to take maximum advantage of things. No API just all of the sudden really makes a dramatic difference on things, because if you've built a good game engine, you know, any API, even if you magically made all that API overhead vanish it doesn't matter or make much of a difference it's the possibility... there's stuff like GCNs that I'm very excited about, some of the asynchronous pipeline cues for different things that would be great to, you know, to take direct control over but then you either design for that or you don't design for that.

Yeah, there will be a gradual approach... we're doing Battlefield 4 and it's not like Battlefield 4 is only dedicated for a specific API. It's a rich game there and where you work with something and deliver concrete benefits and then evaluate it. And then go forward and see where we are, and hopefully in the future we'll design games based on many of the concepts that we're proving out a lot earlier now than what we can do otherwise. I think that that's eventually a good change for the entire industry.

Well actually, let's be nice.

No, no, no, I can answer a couple of questions. They wouldn't have to pay us anything to use it. I've been pitching these types of ideas for many, many years for every single vendor... talking just about my own egotistic view of solving my own specific problems that we see a lot of stalls, we see a lot of performance gone missing in many areas [and] that we actually want to get back that performance. We want to learn how to program a machine on a lower level... it has a really good architecture for that and I think that's something that we'll sort of roll out going forward also.

OK, so it's good as an R&D platform for a developer that sits here and John was talking about a desire to have front buffer access or something like that and a lower level API will be more likely to provide that. Thing is also that if it pushes Microsoft and the OpenGL folks to improve their drivers by realising that, hey, you can actually achieve a lot more performance on PC with some more low level techniques, I think it would generally be bad if the output of this is that now we have to deal with five vendor specific APIs.

I agree, yeah, and, also the vision for Mantle - well it can play out in many ways. You can't really say for sure but the vision for Mantle is that it can become an open API also and that's something we're completely open for. It's something AMD is open for also, it's just that that's not the right way to go at it initially...