Above: Star Swarm demo giant fleet
GamesBeat: With Mantle, can you talk about what kind of efficiency you get there? Normally, it would seem like you would gain efficiencies just from a faster graphics chip coming along. You wait for the move from 1Ghz to 1.2Ghz and get faster performance. It sounds like Mantle is giving you better performance for a given graphics chip.
Kipp: Mantle is interesting in a couple of ways in that regard. There are two sides to the performance equation. One is the GPU side and one is the CPU side. If your bottleneck is on the CPU side – typically the driver or something else – if you get a faster graphics card, you’re not going to be able to utilize it to its full potential. On the GPU side, if you can’t do things like asynchronous compute, you can’t necessarily keep the graphics card full the entire time.
Mantle works in two different ways to address those problems. On the CPU side, Mantle has much lower overhead in terms of the way it’s set up, the processing of its commands, the way we send it through. The Mantle driver doesn’t have to work as hard trying to second-guess and potentially make mistakes as the DirectX or OpenGL driver at this point. The other thing it does, because we can configure Mantle to run on as many thread as we want, it’s scalable. If you have a two-core processor, we can design our layer so it effectively works with only that dual core. When you go up to four or six cores, we can capitalize on that and get more benefit from more cores, which has been difficult to capture with DirectX or OpenGL.
AI Weekly
The must-read newsletter for AI and Big Data industry written by Khari Johnson, Kyle Wiggers, and Seth Colaner.
Included with VentureBeat Insider and VentureBeat VIP memberships.
On the GPU side, the graphics core runs through a list of commands, but what will happen is that you can get bubbles within those lists, in terms of whether the rasterizer is busy or the AOUs are busy. There’s a bunch of compute units working within that graphics card. Mantle opens up and allows us to submit commands into that asynchronously, so the GPU can keep itself full the whole time. You don’t have to wait for those in a serial fashion.
GamesBeat: How long ago did you start working on the Star Swarm demo?
Kipp: Star Swarm started out as a benchmark test internally. Then there’s the application that we used to port everything over to Mantle when we began. We’ve been talking to AMD about Mantle for the last year — giving them our input, looking at the documentation. We started implementing the Mantle port in August. It’s been a very quick and wild ride for us. The genesis of the Nitrous engine was DirectX first, trying to get as much out of DirectX as we possibly could. Then we were waiting for Mantle to come along.
We’ve only been working on the Star Swarm demo, in my opinion, for a very short period of time. The main goal of the demo was, from our point of view, to create a technical demonstration, more than an artistic demonstration. It’s to stress-test all the code bits and stress-test Mantle and DirectX. It’s for us to push those APIs and the hardware to what we believe are the limits and see how they respond. Then we can figure out what we need to do next.
When we started working with Mantle, we didn’t know what to expect in terms of performance gains. It wasn’t until we started that we saw how exciting it could be. We didn’t know we would get a 3X or 4X improvement until we tried it.
Above: Star Swarm demo nebula
GamesBeat: The interesting issue is that you now have more moving objects available on the screen than you actually might want to even try to use in a game.
Kipp: That’s always a possibility. In some sense the demo is a little unfair in that the objects we’re drawing are the most expensive objects for us. Say, for instance, each one of the fighters that we had on screen actually had three or four independent wing flaps. Perhaps they had detachable missile pods. That would be less expensive for us to do. Those are all things that tend to add up in terms of draw calls. This is really a stress test. We could take that same amount of complexity and convert that into fewer objects on screen and actually make them more complex.
That’s the goal of Nitrous. You could go for massive amounts of simple things, or you could go for a significant number of things that are highly complex.
GamesBeat: What was some of the difference there as far as how many units you could have on the screen with Mantle and without it?
Kipp: It comes down to the number of batches we need to draw. Off screen, we’re comfortable with 10,000 or 15,000 units. It’s one of those things where, because that’s all CPU-side stuff operating asynchronously and it’s very fast for us, between the number of units in the world and the number of units in view, there’s a possibility for a large disconnect. That’s where part of the difficulty between DirectX and Mantle lies. In a DirectX game, you have to be much more careful about what’s going on there.
In terms of an RTS game or a strategy game, since the player is the level designer, you can’t guarantee how much complexity is going to be on-camera at any given time. In a first-person shooter, it’s much more straightforward to restrict what’s going to happen and to give a planned-out map and play style. With RTS and strategy, the player can wreak havoc on an engine if it’s not flexible. That’s part of where Mantle shines. Since we can’t guarantee what the user’s going to do, it’s hard for us to figure out, “OK, well, we’ll make sure there’s never more than 5,000 draw calls there.”
GamesBeat: What did you wind up with as far as how many ships were on screen?
Kipp: That’s hard to tell. [Laughs] At points in time, it’s easy to get 3,000, 4,000, 5,000 ships on screen.
Above: Star Swarm demo lone spaceship
GamesBeat: As you say, these are not just dots. They’re something that you could zoom in on and see a lot of detail.
Kipp: They have varying levels of detail. It depends on the spaceship and how much time the artists have. I believe there are two cases for LOD. One is the mesh LOD. That happens as they start to drop out. We also have a shading LOD. Because we do what we’re calling object space lighting, we calculate the projected size of each of those objects on screen, and based on that we shade it in a priority manner based on how large they are. We can scale the shading quality at a different frequency than we scale the geometry level or something else.
The big space ships only have one level of detail, just because we didn’t have time to get to that, but all the fighters have at least two, if not three. I’m not sure how many the bombers have. The bombers may have three levels of detail. They’re another example of a more complex object. One of the bombers, the long red one, has a turret on top that activates. The other bulky one has three independent turrets on the back, and those are all calculating their own firing solutions and tracking enemy targets.
Every space ship there has its own unique target list, its own weapon refresh rate, and so on. Those are all data-driven controls on our end. It’s meant to stress every portion of what our engine does, not just the graphics portion.
GamesBeat: What does this remind people of? Is it like a big Star Wars battle or RTS games like Homeworld?
Kipp: A lot of people have mentioned that it reminds them of Homeworld. That was neat. There are certainly a bunch of touchstones for us as far as what we’ve seen in the large-scale Star Wars battles. Certainly it would be neat to do some Battlestar Galactica stuff as well. We can’t do anything like that due to licensing issues. [Laughs] Or necessarily encourage that. I wish we had more time to work on the art, though, because we would love to throw a bunch more spaceships in there.