 Hi guys, Jensen's gone right? I wanted to ask what you guys thought of Mantle, just to see, since you guys are considered luminaries and large developers, what you guys think? Oh, and important. You guys want to start? Okay, I mean, my opinion on it is, in terms of actions, I think the question is, should NVIDIA have a response to Mantle? And I think that's unequivocally no. They should know. It would be, I think, a horrible mistake if, for some reason, somehow NVIDIA got panicked by this and made some lower level NVIDIA API. You already have very good low level access through the GPU extensions that NVIDIA has always rolled out, ahead of anywhere else, give you as much performance as you want to trade the inconvenience of doing NVIDIA proprietary stuff on them. Now, Mantle is, 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 width. It was just a way to do on the PC, be 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 widths with a similar architecture that you can get on the PC. Developers will be making systems architectural changes that could aid with those. So, I think it's not a stupid thing for AMD to be doing at this point. There are some benefits that they can reap from it. It could have implications for Steam, Steambox type things there. But, they're probably, if Microsoft and Sony both embraced it, that would be very, very powerful for AMD, but it doesn't look like they're going to at least Microsoft with the words that they're mouthing now. I mean, if I was still doing all of the major technology coding or 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, when I would dispassionately step back and look at it, I probably wouldn't come down on the side of saying it's worth the effort there. Obviously, others come to different conclusions. Sure, there are some good ideas in Mantle. 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 Drag Techs and OpenGL, there's a lot of overhead in those APIs and the multiple layers of them and the fact that they date back to the old SGI model of hardware rendering, which is very, very different than the modern shader-based hardware 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 a ton of the API functions for every little thing you want to do. So, there are good ideas there. I hope that really helps the OpenGL community and Microsoft shoot their future APIs. I mean, if you ask me what I'd much prefer to have a low level API for accessing the GPU, the answer is yes. But, five of them, each for different hardware architectures and vendors and operating systems, absolutely not. That is the wrong direction for the industry to go. And to have yet another API on the PC that's still different than the standard PC Drag Techs API, and it's different than the OpenGL, the OpenGL ES that adjusts on Mac and Android and iOS, and it's different than the PlayStation 3, PlayStation 4's low level rendering API, and it's different than what Microsoft provides in Xbox, I don't think it's a good idea. Yeah, so... One of the key things about it is, and one of the main reasons for 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 PCS platform, all the stuff we've been talking about today, like the robust performance, consoles type of robust stable performance, those are things we can experiment with and work with. We do that with ECU, we do that with GL also, of course. This is another avenue you can see. It's also really interesting, just essentially opening up something that we're quite familiar with already, we've been spending the last two years working on the next-gen consoles, and the architectures are the same. We've been intimately familiar with those architectures, and it's a good fit there, just as John described. And I see, even though we're not done with our work with it, and it's definitely not done yet either to be shipped out, I still see it as a success even right now, actually, just because of these conversations and the amount of things that actually...the amount of developments and the amount of both enthusiasm and even the opposite of enthusiasm, all of the type of...it's been a bit stale, especially in the PC graphics space. Microsoft, they switched focus for quite some time over to other things which they probably really didn't need to do. But I think now, going forward, it's a really exciting opportunity, both on the PC space and stuff we're experimenting with, mental learning on the consoles, but also mobile, as we discussed before, of, okay, what should be the future graphics pipeline, sir? There's a lot of movement in all of these things, and it's just good to have lots of different avenues to experiment and actually hopefully deliver concrete value indexes. But I completely agree with both John and Tim that if video would do their own API and then Intel would do an API and then Podcom would do an API, that's not the future we want to be in. That would be a bad future. That would be a lot of work for you. I think Microsoft and Prognos does play an important part of all of this, and I hope mental will be quite influential in many of these aspects also. And what we're doing right now, also specifically with AMD, is just a start. Thank you, Rolf. Yeah, you've used the guy where we just read that he's bad for the marketing materials. What would you say is the two questions, what do you think is the cost, like in man years, whoever, of implementing manual support and battlefield, and what do you think is the ultimate gain on the PC? Could you try to quantify that? It is too hard to quantify. We've been very busy just making sure our game works overall and actually shipping it out. We're almost done with it. So it's too early to say we'll have a lot more information in November, and it will be interesting to see. I think it's important also to, one thing that people, general people that are not developers, it can be difficult to understand that because ballnics, it's actually, it's not like the ball. We sold this one, we're done, go home, and the game will run as well. Ballnics is like Wacom. You find, fix one, and then you thought that that was the thing, you made that four times faster, and then the next ballnics shows up after 10% of that. Of course, the biggest issue is that really you have to architect your large scale vision to take maximum intelligence. No API just all of a sudden really makes a dramatic difference on things because if you built a good game engine to any API, even if you magically made all that API over in advance, it doesn't make that much of a difference. It's the possibility of doing that. There's not one, the GCNs that I'm very excited about, some of the asynchronous pipeline queues for different things that would be great to take direct control over, but then that's, you either design for that or you don't design for that. It will be a gradual approach also. Sure, we're doing Belfort, it's not like Belfort is only dedicated for a specific API, it's a rich game there. You want to work with something and deliver concrete benefits and then evaluate 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 actually a good change for the entire industry, even though people sometimes do get stuck up on the overall thing, thinking again, the same discussion as I had before, mobile will replace all the PC. No, that cannot happen. Same mantle will not replace all of the EX or all of the EL. That's very complementary. Well, actually, when you use mantle it's not complementary, but it's complementary in the actual industry overall. You want that competitiveness, not necessarily by having five different APIs, but having movement. I think that's really, really interesting. Cool, I appreciate it a lot. Can you tell us how much they pay for you to use it? Let's just keep that alone. 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 type of ideas for many, many years for every single vendor. It's actually, talking just about my own egoistic view of solving my own specific problem is that we see a lot of stalls, we see a lot of performance gone missing in many areas that we actually want to get at that performance. We want to learn how to program a machine on a lower level that has a really good architecture for that. I think that's something that will sort of roll out going forward also. So it's good as an R&D platform for developers that sit here a bit. John, you were talking about the desire to have front-end buffer access for the lower-end API. I think it's also that if it pushes Microsoft and OpenGL folks to improve their drivers by realizing that, hey, you can actually achieve a lot more performance on PC, what's the more low-level that means? I think it would only be bad if the outcome of this is that now we have to deal with five vendor-specific APIs for all that. 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 API also, but that's something we're completely open for and something the API is open for also. It's just that that's not the right way to go at it initially. There are those avenues already with Cronus and with these APIs. If it were an open API, it wouldn't be a low-level API. Well, actually, I don't call it a API. Sure, you can make an API that's completely down to the level of what you like on a PC. We worked very, very thin on the structure now, but it was completely specific for that architecture. I do think the way modern GPUs work is quite different from how the absolutely GL design was from the beginning. There are extensions at least in GL language and access to many things, but there are commonalities between all our products. It's like Bindy, for example. That's an awesome thing that the Pivot has been working on with GL. That is really the future for all GPUs. And if you ask the different vendors, even vendors perhaps on mobile space that do not have it yet, they believe that is the future. Well, now you're talking for all mobile vendors. Well, yeah, probably not. Overall, it makes sense as a modern design product. And you see some convergence towards things that are generally good design. And then some people are looking at some designs that come a little bit later for that. But when it's a great fit for key hardware and it's a great fit for developers, then that's the way it will go. My point about unified memory is absolutely here. And we really need to get down to GPUs are just peers on the same memory pool as the CPU. And we really need like documented texture layouts. And that's not to say that everything is becoming SOCs also. So even the GPU is a combination of tons of different processors, a significant amount of processors. Even if it's an Intel GPU, if it's a named GPU, there's quite a lot of quite independent engines there. And that's something that's hidden from us now. The GPU is something that you from the CPU, you prepare your commands, you just give it to them. It has a driver that tries to figure out which goes where. That's just generally good design to expose those things. Like if you're trying to do something picky like using the hardware video decompression stuff or then re-encoding there, you have to get a brand new API to get that capital. Or even things like compute, for example. One of the best use cases of compute is for graphics, which is kind of... It feels a little bit weird. But it's not like you want to use it both tightly coupled with your graphics, and you want to use it completely separately that the CPU drives for loading this stuff. And you want to have background tasks that have, well, can have really high latency and not in the background and just eat up whatever vector units that are free on your GPU. That's also generally good design for... Even in the GPU space, I'm hitting on these issues where I want GPU task scheduling. We have no concept of prioritization between GPUs to use where we need to be able to specify time slices and priorities. It's bounding the CPU scheduler for a finite number of years. And it will likely take quite a lot of time until we find a convergence to a definite model there. But in the meantime, it's good to have a couple of models, both from hardware and from software, sort of competing or being tested there and see what sort of comes out of that. Because I do think there will be quite an interesting convergence there. There's clearly a large amount of enthusiasm in the panel for G-Sync. Is it thus fair to say that you will be playing the games that you're developing on Nvidia hardware at this point on? Wow. Well, Nvidia, they have G-Sync. I have to say they have Nvidia because we don't have the Manitou. It starts getting a little bit tricky. In my view, Nvidia had Manitou and we had G-Sync, or we had... Ideally, all vendors should have all of these. That would be the best solution for the industry. But I think what you're seeing, if you look at it from a practical point of view, you'll have person mover advantages for the companies that invest their energy effort and actually bring something else and something out there. So I'll play the game on both. So is the G-Sync software side of things and hardware side on the card, is that going to be licensable? Like aren't Intel and AMD going to be able to... We haven't precluded the notion of it, frankly. We're first trying to get it going. Get the<|cs|><|translate|> Go and get the display guys going. We had to change the GPU architecture to get it going. And then we haven't precluded anything in the future. That sounds like a software... Yeah. Only that pesky GC in the thing. I'm just kidding. Tim? We primarily use a video hardware and we buy less than that. But my Tribal shorts so...