[embed]http://www.slideshare.net/IntelSoftware/realtime-game-optimization-with-intel-gpa[/embed]

Download Seth's Slides

All right, so my name's Seth Schneider. I work on the Intel GPA team, the developer products [INAUDIBLE] with Inside Intel. And then this is Russ Gleeser. He is the lead developer at Cascade Game Foundry. So we're going to be talking about GPA today. 

I wanted to focus-- Yeah, it's cut off a little bit. That's OK. 

[INAUDIBLE] So basically what we're going to do, is we're going to just take a real brief introduction to GPA. Just like a few slides, to kind of figure out what it is. And then we're going to talk about Cascade Game Foundry and Infinite Scuba. And then after that, we're going to actually go in to looking at Infinite Scuba live with our profiling tool. 

So, how many of you guys are game developers? You all produce games, right? I expect most of you dudes are game developers. OK, so who uses a game engine? OK, that's a lot of people, great. Who uses Unity? 

Best engine ever. 

OK, good! A lot of people. OK. So Infinite Scuba's Unity as well, and so we work with Unity games, and we focus on optimizing them. So what I'm going to be showing you is going to be in context of optimizing a Unity, which is great. So let's move in, and try to figure out what is Intel GPA. 

So kind of what I've eluded to, is that Intel GPA is a suite of tools that helps you optimize your games, right? Specifically Unity games, engine games, and games that are your own engine. So we work on PC, on mobile, pretty much all of the above. 

So when would you use it, right? So let's say you have your game, and you've implemented the majority of the initial functionality, right? You have your main look done, and you're ready to start saying, OK. Is this going to be performing? Right? So you take a look at the performance, and you're like OK, I'm getting maybe 5, 10, 15 fps. Not exactly where you want to be, right? Like none of us like playing games that just truck along. So that's where Intel GPA comes in, right? So you use Intel GPA to help you figure out where your game is slow. And we'll show you how to do that. 

So before I kind of go into the speed and feeds of what we support, and yadda, yadda, yadda, it's important to understand how we talk about our support. So how it works is host-target architecture. So the host is the system to where your analyzers [INAUDIBLE], right? This is your system analyzer, your frame analyzer. That's where the analysis actually takes place. So the target system is where your game's running. So you're connected to your target system either via network connection, or you're using the same target host. 

But when I say target, that's where your game's running. And when I say host, that's that system that's running your analysis. 

So here's kind of an eye chart for you. A giant eye chart. But this kind of just shows our support matrix, right? So one of the great things about Intel GPA is that we try to support as many different platforms as possible. With Unity making it so easy and Unreal making it so easy to develop and produce to pretty much any platform, right? It's just pretty much a couple clicks of a button and you just build for Ubunto, or even for Windows. We try to support as many of those different applications as possible. So just kind of moving through here, basically you choose your favorite host OS, and then we support a variety of different APIs. 

So for Windows we support DirectX 9, DirectX 10, DirectX 11 and x. New is DirectX 12. So we just implemented our DirectX 12 support. At GDC, if you saw us there, we had a nice demo of our brand new Direct X 12 support on our new frame analyzer. It was awesome. 

For our target hardware, you know we support Intel. We also do support NVidia and AMD, which is interesting, right? So let me talk about that for a second. 

So NVidia and AMD support is great. You get duration, but you don't get as many patches as Intel. So we focus primarily on authorizing for Intel, obviously. So you're going to get the whole performed story, there. And that's what we definitely recommend doing your performance analysis on. 

So if you're an Android game developer, great. You know, we support pretty much all the way up to Marshmallow. On your tablet, you don't even need to be rooted to optimize, which is great. And then we also support Ubuntu Gaming, as well. But I'm going to kind of skip over that. 

So lets talk about what's inside Intel GPA. So basically we have these four different tools, right? So we have the Graphics Monitor, which you'll see in the live demo, which is the launch point for the configuration for-- and that thing is kind of like backbone of our tool suite. It's where you launch all the games. It does all the connections. It's what  actually injects in your application when you start running it. 

So, insight here, you can do certain things like change your preferences and change your profile. And what's awesome about changing you profiles is that you can set triggers. So, let just say, when you're  playing a game, sometimes your frame rate will be great, right? 

You're playing along. You've got 50 frames per second. Then all of a sudden  you see them spike. So you want to know why that spike happened. Or it's really hard to press a hot key and  get that exact spike, cause you don't know when it's coming. 

So those triggers are going to help you be able to figure it out by saying, yes, my frame rate dips below 30 frames per second. Take the next frame. 

So that's what the monitor does. It sits there. It does exactly what it says. It monitors your graphics and waits for those type of events to happen. So that when you start analyzing offline, you're analyzing the frame that really mattered. You're looking at the actual  problem. 

So, next we have System Analyzer. And System Analyzer is your in-game, it's actually content analysis. So what that is, is it's just-- imagine like Windows Performance Monitor. You just as well use that. Press Control-Shift-Escape and you get this, a nice little  graph. It's like that, but on steroids. 

So, you get basically all your GPU metrics. You would get my MSI app converter. You'd get CPU metrics on top of it. So it's kind of like a good combination between those. You also get things like I/O, memory, all those awesome metrics that help you understand what your game is doing in real time. 

So that's playing on the target while System Analyzer is [INAUDIBLE] your host. Other things you can do are experiments. So your gonna help figure out if you're GPU or CPU bound. And we'll talk about that in a workflow here in just a second. 

So, the next tool is Platform Analyzer. Platform Analyzer is a timeline based tool. So this helps if-- going back to our scenario where you have that dip in performance. So, that's going to help to be able to figure out concurrency issues. 

So, sometimes it's not right to look at a performance problem in just a segment of a frame. You want to look at the problem over a duration of time. You may need, let's say five seconds to see, what does my GPU 2 look like? How  busy am I keeping it? Is it stalled? Am I driver bound, things like that. Platform Analyzer can really help [INAUDIBLE]. 

And you've got this Frame Analyzer, last but not least. It's pretty much the bread and butter of GPA. That's your single frame analysis. That's basically, think of like taking a snapshot in time. But it collects all the data [INAUDIBLE]. 

So basically, it [INAUDIBLE] in a single frame. It captures your textures, your geometry, your [INAUDIBLE], all your ETI calls. And then it gives it the ability to play back your game in, basically, a single frame. So, we'll see that in the demo. 

And moving on to the workflow here. So, workflow GPA, how do you use these things together? We talked about each of the different tools. But how do you put it all together? 

So, let's just say we have our game, like "Infinite Scuba." We run it with the HUD or System Analyzer. And what are we trying to do? So, why do we even do live analysis? 

What we're trying to figure out is where bottlenecked. So, if we're bottlenecked on the GPU, we take a frame capture and put it in frame analysis. If we're CPU limited or concurrent [INAUDIBLE] limited, we take a trace capture and put it Platform Analyzer. 

So we've split up these two things into in-game analysis and   offline analysis. So, during in-game analysis, your game is running. It's great. You're actually looking at the performance in real time. Then offline analysis is when you go into Frame Analyzer, Platform Analyzer. Your game's not running. You're primarily doing the analysis on the host. 

So, that's not how to use GPA, which is great. So all this sounds pretty complex. But it's really easy to get started. And, oh, by the way, it's free. 

So if you just to software.intel.com/gpa, download all these tools for free and start using them. So it's really easy to get up and start with it. 

You don't need any code changes. So you don't have to go into your source code or use a special Unity script internet for this profiler. In fact, you can just take your release version of your binary, take your EXE, and then plug it straight into GPA. And you should be able to start profiling from there. 

In fact, it's actually recommended. You want to be profiling your release version of your game, because that's going to be closest to the actual performance your customer's going to see. Because that's the [INAUDIBLE] point. So also, you don't need any environment changes, [INAUDIBLE], any special IDEs. So you don't need to write it in a  studio or anything like that. 

And then also, you can do dual or single system analysis. And not to that host architecture. For Android you don't need to be rooted. Rooting does make some things easier. But, basically, you can still, whether you're rooted or not, you can pan through your application and then do the same kind of analysis. 

So, moving on here, we're going to invite Russ up to stage to talk about Cascade Game Foundry. 

So, my name is Russ Glaeser. I'm the  development director and lead programmer at Cascade Game Foundry. We specialize in simulation experiences. In some ways simulation is, these days, kind of  a four-letter word. You know, they're not as popular as other genres of games. You might have heard some other names for simulations. You heard reality-based games, your gamification [INAUDIBLE], or anything like that. 

They're all essentially the same thing. It's taking something that's based in the real world and turning it into a game so that people can play it. 

We develop games for PC and Mac and desktop games, and just starting to [INAUDIBLE] into virtual reality. 

Middle of April, we were invited to show the game at Earth Day Texas in Dallas. And virtual reality headsets had just hit the market. There was tons of hype around them, seeing articles all over the place. 

So I said, hmm, wouldn't it be really cool if we have a VR demo that we could show, nothing real fancy, super simple. Just take the game that we have, take one of the scenes that we have, drop in-- they were built in Unity. So it should be really easy, right? Just drop in the Oculus camera rig, move it through the scene along a path so the users can look around. And we're done. 

So, we managed to get hold of somebody in Oculus. And they didn't think we were completely insane. So they were overnighted us a headset. 

And, if you've ever done any virtual reality development work, you know that you want a target-- for a good user experience, you want to target 90 frames per second. And that's 1080 by 1200, 90 time per second times two. One's for [INAUDIBLE]. 

So, we took one of our scenes, plugged in the Oculus camera ring. And we were getting seven frames per second. So, that was a very interesting five days. 

But earlier at GDC we had the opportunity to see a live demo of GPA running on our game. And the feedback that we got from that experience actually was incredibly helpful in helping us to get our frame rate. 

We never quite got to 90. We got to about 75. So some of the changes that we made to do the VR demo have been migrated over to the demo that you see today, not quite all of them. But we're working on that. 

Infinite Scuba, the game itself, there's a SCUBA diving simulator, tall real-world locations, real gear, real dive science. Interesting about SCUBA diving is that it generally is about a five foot experience. You know, you're interacting with stuff that's within arm's reach or maybe a little farther. 

But you can get a fairly long visual distance. So you're still-- you still see things from a long ways away. So, of course, having a really highly detailed five-foot experience and then being able to render 200 feet can cause a lot of performance issues. 

In addition to that, it's underwater. And game engines these days are not designed for necessarily underwater experiences. They're designed for a clear air experience. 

So you can see the examples of the underwater experience. You've got lightning works differently. Fog works differently. You get the blue shift. 

And so, in order to get these types of effects in the game, we ended up layering a ton of different effects on top of each other. And we were to create this underwater environment. 

All this stuff added up to a lot of performance issues. The water ended up being-- this is one of the things that we found through GPA was that the water surface ended up being incredibly inefficient, because we were reflecting the whole scene across the surface of the water. So that was big takeaway. 

One of things that we had a problem with, that caused some problems, is that we really have no graphics program. So we had a lot of experience writing games, but nobody on the team was really a graphics programmer. 

So one of the guys on our team learned enough about writing shares and learned enough about that type of thing in order to be dangerous. But, in general, what was ended up doing was, we would sort of tweak it around and play with it until it was good enough. And then we would move on. 

So we didn't really know a lot of what we were doing. But GPA, again, helped us find those areas where we get a lot of really good performance issues. 

And Unity does hide all the details from you. So you don't know what's going on under the covers. One of the tricks that we did to help with performance, that we though we were really being clever, was we would designate areas of coral. And then we would take that area of coral, and we would take all of the lowest level LODs and pre-compute one single batched mesh for all of those lowest level LODs. and the we would render that. 

Well what that did end up doing was making the whole thing slower, because then Unity wouldn't do any batching for us. Because those combined meshes were too large for Unity to do any dynamic batch [INAUDIBLE]. 

So, again, using GPU, we discovered there draw call we were unable to [INAUDIBLE]. 

So it ended up helping a bunch. Another thing that we found was the fish that we were rendering were causing problems. So it wasn't too much of an issue when we first released because we didn't have as many fish. 

And they were like, we really need to have more fish. So we tripled the number of fish. But none of our fish have been LOD. So we were rendering 2000 polygons for a couple of pixels off right at the very edge of the view distance. 

So GPA, again, helped us find those things. And it's really obvious when you look at the demo. You'll see 5,000 or 6,000 draw calls of these really tiny little batches of [INAUDIBLE]. 

So that is the game. 

Nice. 

So, I was going to run through a super quick demo of the game. And then Seth was going to get into the live demo of GPA. 

Just to show you what the game looks like, start with the [INAUDIBLE] view. 

That better show up online. All right, [INAUDIBLE]. 

There you go. 

Ah, [INAUDIBLE]. 

Yeah, yeah, just the top part of it. 

Oh [INAUDIBLE]. 

Huh, OK. 

So, usually you can see we have the HUD up there. But it's cut of on the screen. 

This one  is not cut off. 

Oh, yeah, you can see it up there. 

That one might be all right as well. 

OK. So, I'm not sure what you can and you cannot see. You can see some of display that you can get on that. 

This is just a regular old [INAUDIBLE] straight out  of Unity. You want to use [INAUDIBLE]. So, like I said, all of the dive sites in the game are real dive sites. 

This particular dive site is in Belize. That's American reef. All the fish and coral are what you really see when you're diving on the dive site. 

We have our little things to do box with different challenges, general, finding areas of the reef, naturalist, which is identifying fish and coral, historian, which is finding artifacts, under photographer, and reef cleanup. And as you completely each of these challenges, you can unlock field guide pages and things like that to tell you a little more about what you're look at, history of the area, people that live in the area, as well as the fish and coral that you're looking at, environmental problems. 

So it's really sort of a virtual tourism, found object, environmental advocacy, environmental education type of an experience. One of the most common questions we get is when are you adding a spear gun. And we are never adding a spear gun. 

So, as you swim around you can see lots of fish and things like that moving around. These are some of the fish that I was talking about. All these fish are 2500, 2000 to 2500 polygons. It wasn't too much of a problem when we didn't have as many. But then we increased the number of fish and really, really dragged the system down. 

So as you swim around, you can see different things. You get surge back and forth, the diver. You've got rays. You get water, surface water. We're actually not on our high quality here. 

You get the [INAUDIBLE] rays. You get the surface water. You get a little detritus floating in the water. You get little puffs of light and smoke and things like that in the various-- trying to give that underwater ambient feel. 

And then we have all of our fish and coral and things like that, animated sway back and forth in the breeze. And then, like I was saying, as you swim around and find fish and coral and things like that, you can-- and if I unlock the little field guide page, and it explains what's going on and things like this. That, in a quick nutshell, is the game. 

Nice. 

So, we're going to quickly share a couple of things about GPA within [INAUDIBLE]. So, you can kind of see the HUD up there, top left. You can't see it up on here, but up on the top left there's a frame rate number. That show you what your frame rate is. 

You can see these GPU or these metric graphs right here. So that's that live metrics that I was talking about. You can choose, basically, whatever metrics that you want. 

In the overlaid version of it, you just use four. So here we have our targeting applications CPU audit. So we can see how much CPU are we using. We can see our GPU audits. We're about 8% using the GPU. 

So already I'm starting to think, OK, we might be a little GPU bound. We look at our GPU integration and our pixels rendered. 

So, the HUD is really cool because you can override your actual graphic pipeline in real time. So if we wanted to figure our if we were GPU bound, we could open our little tool tab here and say, OK, what are some of the things that we can do? Things like disabling draw calls is a real good way to figure out whether you're CPU or GPU bound. 

At first you're like, why would I want to disable the draw calls? It's obviously displaying something to the screen. And what it does is it actually simulates a [INAUDIBLE] GPU. So if we hit CONTROL-ALT-N, the screen goes black. 

But for you guys that can see the frame rate, you see the frame rate goes up. That mean that, given an infinitely fast GPU, the CPU could handle up to 47 frames per second. So if we turn it off, we see our frame rate drops back down. 

So that's kind of a quick check that you can do to see, OK, am I GPU bound? Am I CPU bound? 

There's something cool we're [INAUDIBLE] and doing here as well, such as, for instance, we can turn on 2x in textures, which is CONTROL-ALT-U. Or, I guess that one's wire frame. OK, yeah. 

So wire frame. So re-rendering the whole scene in wire frame. You can do CONTROL-ALT-5, which is 2x in textures. Things like that we'd be able  to see. By looking at your frame rate and looking at how the metrics change while you do these overrides can help you figure out where your bottleneck [INAUDIBLE]. 

So at this point, we know we're GPU bound. So then we would take  the frame capture. So if you think back to that workflow slide, we're like, OK. Figure out we're GPU bound. Now we take your top line analysis and do a frame analysis. 

So let's exit the [INAUDIBLE]. And I can bring up Frame Analyzer. So here is-- let's  see, full screen that. OK, the resolution is kind of funny on this, guys. So let me just read, organize things here a little bit. 

So, I opened up the frame already. It just takes a little bit to load. So, when we take that frame capture, as I said earlier, it collects all of that data. So the frame file ends up being like 250 megs, because it basically has to have all the resources available to recreate your game in single frame. 

So, what makes GPA unique As a tool is that is does what's called play back. Other tools do play back as well, but we do playback [INAUDIBLE]. So any change that you can make to the  frame will play back on your target hardware and then get real metrics from whatever change you made. 

So, it's not just a view. A lot of people were like, OK, Frame Analyzer is a view for a frame and capture [INAUDIBLE]. It's a little bit more than that. I can make changes. I can change my [INAUDIBLE]. I can do experiments. And then it plays it back. And then it re-renders that single frame as if you were playing the entire game like that. 

So what it's supposed to do is it's supposed to help you increase your iterationals. So instead of going to Unity, changing your initiator recompiling your code, testing it, looking it in some kind of  frame rate monitor to see if the change that you made was effective, you can sit in here, make the change to the [INAUDIBLE]. And then see that in view. So it definitely increases your iterations. So that's why the frame file is so large. 

But let's take a quick tour through our Frame Analyzer real quick. So, this is our legacy version of Frame Analyzer. If you saw our demo at GDC and saw our direct [INAUDIBLE] port, you'd see our brand new Frame Analyzer. 

So the UI has been almost hanging up. It looks good. It looks less like Windows 95. But it's still a great tool. And it helps you figure out [INAUDIBLE]. So, it still works great. So we'll just take  a quick tour. 

Up here we have the bar chart. The bar chart here, it's really small for you guys. But each one of these bars represents what we call a ERG. 

So an ERG is anything that's up time on the GPU. So then if you're going to say, Seth, why don't you just call it a draw call. Well, most of them are draw calls. But there on other things like clear calls, dispatches, copies, things that actually do take up significant CPU time that aren't draw calls. So we try to display those. And we call basically the grouping of draw calls and anything that takes up time on the GPU, an ERG. So if I say ERG, I mean draw call most of the time. 

So that's what this bar graph is. Basically, if you can see up there, you can. But you can access this bar graph by whatever metric you'd like. So when I talked about [INAUDIBLE] supporting video. They don't have the metrics that we do, because we have access to our drivers. So that's how can take this bar graph and then look at the problem from many different angles. 

Since we have the access to our EUs, our samplers, things like that, we can view the calling in different lights based on whatever metrics you [INAUDIBLE]. 

Right now I just have it accessed by GP version and GP duration. Basically, the biggest, flowers are the things that take the most time on the GPU. It's kind of a nice [INAUDIBLE]. 

So, if we move on the left hand side here, we see our total number of rendered targets. And then we have kind of an RA challenge here. It's really scratched up. 

Basically, this is a different way of viewing your scene. Sorry, not AP analog. This is your tree graph. So, same way to try to traverse-- if  you don't like to work from a bar graph, we have this tree view here for you. 

So this is our render target viewer. And now we have all these tabs, which gives you details on your selection. So if you selected-- right now we have this large bar here selected. We can see the details and all the textures associated with that selection. 

So you can select multiple, but that's pretty much the basics of Frame Analyzer. 

So let's talk about some of the stuff in here. Let's start with [INAUDIBLE]. So something that I always like to do when we start opening up a frame is, especially people that weren't graphics engineers. So a lot of you guys  work in Unity, right? So how many of you guys are graphics engineers? How many of you write your own renderings? Yeah, only a couple of hands, right? 

So a lot of times it like, OK, I've got to figure out what Unity is doing first. So I can figure out how to optimize more. So that's where GPA is really helpful, because you're almost like reverse engineering what another engineer did. 

So you can see here. And now you can take your frame and then start to learn, OK, this is how Unity is handling certain things I'm doing in my [INAUDIBLE]. 

So, as Russ was saying, they thought if they docked some of the geometry, that Unity would like that. And then you would be getting  faster. But instead, Unity acted in a different way. So GT is going to be one of those ways to where we can check exactly what Unity is doing and figure out the best approach then work with Unity's graphics engine. 

So when I first start looking at a frame, I usually change to render target view. So it changes this bar graph to basically, OK, here's the time that each rendered target is taking each pass. 

So let's just walk through, and you can see the frame. You kind of see both things happening. So that in a high quality mode, we were displaying just the simple view. 

Usually you have these reflections in the water up here on top. And you guys can see my little cursor there, almost. But there's these reflections. So we do this reflection pass here, first of all. And then here in render target two, this is built as a deferred lighting rendering. 

So basically what we do is we calculate all the lighting up front, [INAUDIBLE] geometry. That  way when we go to the colored pass in rendered target seven here, we don't have to recalculate all the lighting. We can just reference it from texture that we've already created. 

So, it's called a deferred lighting render. And that's kind of how it works. So in render target two, we generate this thing called the G-buffer on the-- we lost connection. OK, lovely. We're gonna just reconnect and try again. 

Down here-- so anyway, I forgot what I was saying. I'm kind of talking about the deferred lighting pass here. Hopefully we're connected to a remote analysis system for the playback. And hopefully it will work. 

All right, so-- 

[INAUDIBLE] more time. See if we can connect. 

Yep, OK. So we lost connection to our remote. All right, lovely. So that make this a lot less interesting. 

[LAUGHTER] 

So, all right, that's kind of a bummer. Wait, some of the things we can talk about are the different lighting. So some of the things that we found within the game using Frame Analyzer here was basically that you can look at the geometry. You can see that LOD, which is great. 

Let's see here. I would really love to show it. You know what we could do? Let's go take a look at live analysis. And I can actually talk about some of the things just within live analysis that you can find in Frame Analyzer. 

So let me describe live analysis real quick. And  then we can talk about some of things that you would see in Frame Analyzer. 

All right. You always know  what they say about demos, right? I something can go wrong it will. All right. 

It's kind of looking at the-- Russ mentioned something about LOD. So who needs to know what LOD is? So I can kind of explain. OK, so you guys all know. As geometry moves farther away, the complexity of the geometry should decrease, right? 

So the thing that often made sense, you try to LOD things as much as possible. That's definitely something that Russ has been working super hard to try to make sure that it's happening correctly. 

But our Frame Analyzer in [INAUDIBLE] run quality-- so we go up here and we just turn up our quality settings. We'll notice that the scene changes a little bit. And the we start rendering things further. 

So the point is, you want the things furthest away to render a simpler mesh. So with Frame Analyzer, we can see that each of these little [INAUDIBLE] in my-- you can barely see. 

But there's a bunch of like one to two pixel fish here. So Frame Analyzer has this thing called pixel [INAUDIBLE]. So imagine you can take your frame, right? And so you can choose that rendered target in a color pass and click on it. 

It's just as easy as you take a little cross hair. You click on the fish, or the pixel that was the fish in the rendered target view. Then you get to look at the geometry in Frame Analyzer to see, OK, how complex is my mesh. 

So it's a good way of seeing, hey, am I LODing correctly? Is Unity actually doing the LODs that I want to do? Am I giving it the proper LOD thresholds to say, OK, this certain target, am I decreasing? 

So that's simply something that we were going to show you in Frame Analyzer. We have that issue, so also caching, right? So caching within Unity has actually done really well. 

So this  is why you choose one of those game engines. Is because it will optimize the rendering pipeline so well to where they say, oh, you're using the same material for a lot of these different objects. I'm going to batch those to reduce the number of state changes. 

So within Frame Analyzer, you can also see that by saying, hey, let me choose my shader or material and see how and object's draw calls are using that specific shape. 

So if we, in Frame Analyzer-- ooh [INAUDIBLE]. Random. But one of the definite things that you do is that if you're looking at all this stupid coral, you could see that it's all batched. So, ideally you want things that have the same materials to all be batched to reduce the number of state changes. 

And direct [INAUDIBLE] is what this is rendered [INAUDIBLE]. The more stages that you cut out, the more expensive each draw call is going to be. So even though this is roughly around 5,000 draw calls, it can still be not as expensive because the draw calls are batched. 

So you're not doing the state change between each draw call. And you don't have to then, [INAUDIBLE] an index box. So it actually makes it pretty efficient. And that's one of the good reasons to use Unity because it does a lot of that for you for free. 

But sometimes it doesn't work the way you think it's working. So that's why it's nice to go into this and check it out to say, OK, this is  actually what's happening. So that's why we took the frame and used the Frame Analyzer to show you that we [INAUDIBLE]. 

Or using it for lighting. Or, in Unity you have  a bunch of different lighting knobs that you could turn. And so, what I like to do when I'm developing in Unity is, basically, make a [INAUDIBLE] to each of my different lighting scenarios and then take a frame capture of each. And then you can see each of the different renderers and go from there. 

Anyway, I would have loved to shown you more in [INAUDIBLE]. It's a bummer that it has lost connection to the host. But we're going to be doing live optimizations. So I know a lot of you guys are here with your game for the showcase. Like you've brought your games with you. 

So we have a system set up back there, where we can actually look at your game with you  today, if you'd like. Just to see quickly in 45 minutes or so, we could just see, hey, let's just kind of  figure out what the profile of your game looks like. And maybe if you have some performance issues that you are trying to tackle, maybe  we can help. 

So from basically after this talk until whenever you want to leave, we can help you look at your app. And see what it looks like. 

Anyway, thanks, guys, for letting me show you this. And thanks to Ross for being an awesome partner of ours. We really appreciate that [INAUDIBLE]. 

Dudes, we're going to open it up for questions here for a few minutes, if anyone has any questions on the tools or optimization in general. 

Any questions? Yeah, back there. 

[INAUDIBLE] discover on Intel [INAUDIBLE] versus an [INAUDIBLE] 

Gotcha, yeah. So the question was, if I get performance optimization on Intel, will it transfer [INAUDIBLE]? So the answer is, yes. The various degrees are going  to change. GPU hardware is different. It handles things differently. But in general, a lot of the optimizations that you make are going to be free across hardware. 

There's exceptions to that  rule, obviously. There's things that you can do just for an Intel chip that's going to help just on Intel. But for the large majority of the things, especially the thing that you're going to find on Unity, like rendered, like draw [INAUDIBLE], stuff like that. 

On any GPU hardware, that's going to make a difference. If you're always rendering front to back, it's going  to help on any GPU. So, for instance, Russ was using a video chip for his VR now. But he used some definings in GPA to help him figure out what you could optimize. And  so those optimizations carried over in his VR. 

So, it's not, I guess it's not any black or white answer, yes or no. A majority of the time, optimizations that you're going to find are going to increase your performance on any hardware that you should [INAUDIBLE]. But there are some specific glass jaws in hardware problems that do arise. And you have to optimize for those specifically. Hopefully that answers your question. 

So this video [INAUDIBLE] 

[INAUDIBLE] 

I'm not really a [INAUDIBLE] 

Right. 

I was curious about, if you have a [INAUDIBLE] system and it runs fine, [INAUDIBLE] the fact that my standard system was something out of [INAUDIBLE]. It may not [INAUDIBLE] 

Right, yeah. 

So, [INAUDIBLE] simulate all our game specs. 

Right, yeah, that's a  good question. So, in live analysis, the [INAUDIBLE] platform, there is a way to downclock your CPU. Or you can just go in and downclock the GPU or whatever to try to simulate that. Now again, when you are optimizing, the platform that you want to choose is your main spec. Do your development on whatever your GTX Titan, whatever. Like that's  awesome [INAUDIBLE]. 

Great, but when you go to actually look at your performance story, do it on the main spec you choose. Whatever you put your scheme, you know, common sense. Hey, here's my minimum spectrum ID. That's what you want to be optimizing on. 

You can do some artificial downscaling to be able to see, hey, what's my performance ballpark going to be? But the best idea is to have your [INAUDIBLE] and do frequent checks on optimization against your main spec. There is some stuff in the tool that you take on that artificially down sampling. 

So again, as long as you're the same architecture, if that makes sense. But a down sample in GPU that's a [INAUDIBLE] don't really be transferred over to like [INAUDIBLE]. They're just different architectures. 

If you were [INAUDIBLE] at the same frequency, and lots of memory, [INAUDIBLE]. I hope that answers your question. 

Yeah. 

Do you have some idea how much CPU time [INAUDIBLE]? 

Yeah, that's a great question. So, a lot of times it's-- that's why we highly  recommend to do remote analysis. Often, if it's on, if you're using the same host and target, it's roughly about 10% to 15% [INAUDIBLE] performance is. 

So we have to have a metric in the HUD that shows your overhead for rendering [INAUDIBLE]. Because if it's using [INAUDIBLE] it's rendering something else other than your game. So obviously it is taking away some performance. 

So ideally, that's why you want to have that [INAUDIBLE], where the only performance impacted task is metrics collection under the HUD. And it's really very minimal. 

So, if you want to get the most clear performance story, you want to do remote analysis. But at the end of the day, when you're looking at performance, a couple of FPS is not as important as consistent performance. So, even at just, say 15%, [INAUDIBLE] The optimizations that you're going to make are going to be across the board. 

Awesome. Any other questions? Go ahead. 

I'm a [INAUDIBLE] like an awesome tool. But it's clearly [INAUDIBLE] 

[INAUDIBLE] The thing is, we want all games to run and run great on  our hardware. So, we want our goals to just make sure that games are running as fast as they can. The faster the game is, the better it's going to run on our platforms. And the better experience we're going to have on Intel. So that's our guide map. 

We don't want to have a barrier to entry to you guys getting in and optimizing for our platform. That doesn't make sense to us. That's not what we want. 

We want you guys to be the fastest games that run on [INAUDIBLE]. So that's what our team is starting to get. 

Any other questions for Neal or us? Yeah. 

[INAUDIBLE] 

Yeah, for VR optimization. So, we have been working-- we have an internal [INAUDIBLE] for VR type stuff. There's a lot of other good tools out there. It's difficult. Like a VR problem, optimization problem, is still pretty new. A lot of it comes from, if you're going to be pixel bound, because  now you're taking a-- this is 1080 [INAUDIBLE] screen. You go up to VR, and now  you're rendering to extremely high resolution screen [INAUDIBLE]. So it's-- 

It's a little bit [INAUDIBLE] 

Yeah, and 90 frames a second. So it's a little different really knowing-- I would start optimizing a non-VR game just to learn graphics in general. And then that way, when you go into VR, you can really say, OK, I know the basic of where I can cut and make these optimizations. 

There will be some great tools coming out. We're going be producing something that's, hopefully, going to have VR [INAUDIBLE] to be able to take a look at the performance. And to actually see similar [INAUDIBLE] as you would optimizing and [INAUDIBLE]. 

Awesome. Thanks, everyone, appreciate it. 

[APPLAUSE]