Chris Roberts on DirectX 12, Vulkan, & the Impact on Star Citizen

By Published September 29, 2015 at 8:00 am

Chris Roberts / GamersNexus DirectX 12 & Vulkan Interview Transcript

Please note that this transcript was created for internal use. We transcribe all interviews for article and editorial purposes and normally do not release them. Some filler words have been removed and some phrases have been simplified for ease of following the discussion; a direct, word-for-word transcription -- especially when it involves off-the-cuff technical discussion with Roberts -- would be very difficult to read. It is still all direct quotes, but filler words have been removed.

None of the content on this website may be copied in its entirety to any other page or form of media. This transcript is excepted from this rule. You may post this transcript (and only the transcript) in its entirety on web forums, with credit given to GamersNexus, but you must link to this article and/or source video interview alongside the transcript. Thank you for working with us on this! It's a lot of work to do this stuff.


GamersNexus: I'm not sure what David sent you, but I was hoping to talk more about the tech stuff – Dx 12 and Vulkan, if you know anything about that.

Chris Roberts: A little bit. I think our roadmap is Dx12 first, so that's kind of what our focus is. But the refactoring the low-end of the engine [for Dx12] will [also] work for Vulkan. They have similar engines, similar multi-core, multi-threading, multi-job paradigms. It's not just adding more jobs, it's also about refactoring some of the pipeline, how you deal with the data, how you organize your resources so you can be more parallel, which is how you get the real power of Dx12 or Vulkan. You can take a Dx11 renderer and make it Dx12 pretty quickly. You're not going to get the benefit of Dx12 or the Vulkan stuff until you do more fundamental refactoring.

That's what we're doing – we're saying, 'we're gonna do it right so that we'll really get the performance gains.' That's one of the things that the German office is leading on, because we've got some of the engineers who built the engine in the first place and were involved in the various Dx9 and Dx11 implementations of CryEngine.

GamersNexus: How difficult is it to integrate with Dx12 as a dev?

Chris Roberts: It depends on what you're doing. It's pretty easy [to integrate Dx12] if you do it the same way you did with Dx11, but you're not going to get the full power. The issue is that most game engines were not really written with a massively parallel architecture in mind, and that's fundamentally what you need to do to really get the best benefit out of the next-generation of graphics APIs. [That nex generation] is just that you can be feeding lots of stuff at the same time to the graphics card and you're not bottlenecked by just one thread.

So, typically, the old CryEngine has 1 thread for rendering, 1 thread for main game, and 1 thread for physics, and that worked fairly well back in the Xbox 360 days and there's been slight scaling of it for PC use. The engine's moved more toward a job approach as opposed to a thread approach. So a job approach is [when] you say, 'here's a task, bam,' and kick it off to the job manager. The job manager manages hundreds or thousands of these amongst all the processor threads, as available. That sort of requires thinking of your tasks differently – compartmentalizing it and making sure it's not dependent on other data.

There's been some jobification of CryEngine over the past few years, but we're taking it further because we know we're building for a high-end PC, so we have more threads available with more power than you typically do on a next-generation console. Part of that is a big task, because the renderer in CryEngine was pretty much built with the conception of one thread: a bunch of stuff gets put on the render pipeline, then it gets rendered-out. It assumes it's all rendered in the same space, area, et cetera, and so we need to compartmentalize that better and do better management of the individual resources so it's not one monolithic render pipeline.

That's the fundamental, big work that we're embarking on, and I think that's something that is pretty fundamental to an engine, and they're not always constructed with that in mind.

Even UE4, which is a bit newer than CryEngine – originally, the way it was structured, [it] was very much along the CryEngine paradigm, with the same sort of delineation of threads. I haven't looked at the [UE4] code recently, but that's what it was [like] quite a while ago. I think, fundamentally, there is some definite work that has to happen on the low-level in all game engines to really push Dx12. It's easy to do the demo like Square Enix did with Final Fantasy, but that's just pushing raw poly – look at the rig it was on, look at the graphics cards it was on. You could probably do the same with Dx11, that's just brute force. To really see the benefit of dx12, it's going to be more about doing that lower-level refactoring – then you'll be able to get some pretty interesting performance, even on some PCs that aren't quite as powerful.

GN: For Star Citizen, the type of stuff you're doing would probably directly benefit from newer APIs...

CR: Draw calls, like everyone will tell you – you can only push so much through one pipe, and that's the thing you get with Dx12 or Vulkan. If you factor your engine correctly, you're not so bottlenecked by draw calls, you can push 10x or 100x draw calls through in the same amount of time. So that's obviously a big one.

For us, we actually do some stuff already – we've got some tech we worked on that also get around the draw calls, so we've got some specific character shaders that are using a very different approach to how you would texture characters, which is more [of a] material lookup, so you apply a shader – we don't actually bake textures onto the characters anymore. We have our base character, then we delineate in a 3D program the areas that would be Material One, Material Two, three, four, so if there's only four different materials on that character, there'd be one draw call and then it's an index lookup from a material into a much higher resolution PBR material, so you can have really high texel density and really scale.

You can get right up on it with a camera and it's not going to break down. For us, that's the kind of tech we've been doing for characters and smaller props to allow us to have the fidelity so you can get super up-close, but also sort of how the world has as many assets and the scope we have.

This tech has various blending and dirt on the material levels. It's kind of a next-generation approach to character shading, we're seeing parts of it being done in The Order 1886 and the UE4 Infiltrator demo, I think, used some of these techniques. No one's taking it quite as far as we're doing on the character [shading], because we take it all the way through. We're still doing some R&D, but we've actively been looking at stuff that defeats the draw call issue rather than just relying on a shift to Dx12.

GN: Have you already prioritized support for Dx12? Have you already started working on it?

CR: We're in process. It's part of one of the tasks of the engine group right now, so it's actually something we've commenced on and are working on. We're doing it the right way, versus just changing a couple API calls and saying 'we've got Dx12,' so it won't be ready until next year, but we're actively working on it. We work pretty closely with AMD and it's one of the things that is a big deal to them and would be a big deal for nVidia, too. We really want to try to utilize more of the power of today's graphics cards, so it's that, it's also on the compute side where there's a whole bunch of stuff that we're starting to lay onto compute, allowing us to do pretty cool stuff, like voxels and stuff like that.

GN: Is Vulkan of interest to you?

CR: Oh, totally. It totally is. From my standpoint, we would like to use Dx12 as well as OpenGL Next, Vulkan – we want to support Unix. Our servers run on Unix, so our codebase works on Unix as well as straight Windows, but the problem we have is we don't have a graphics driver yet – there's an OpenGL implementation that was recently released with CryEngine, but it's pretty early, pretty slow. Then the other problem is we've done quite a lot of customization already to the render pipeline, so a lot of the stuff – it's not a simple plug-n-play, basically. For us, we have this debate about --- if we only had Dx12, would we go back and support Dx11 now? I think our tendency would be to more focus on the next level of OpenGL, but that would be after Dx12.

GN: Of course, Dx11 is still supported – you're not abandoning that.

CR: Yeah. Dx11 is fully supported. You need Dx11 or above. We're not gonna abandon it, so we're gonna make sure it performs pretty well on Dx11, then with Dx12 it steps it up. Some of the refactoring will help no matter what with Dx11, because just being better at organizing your resources and data and jobifying it. Even though you may still be bottlenecked on the draw call issue, there's plenty of other stuff that can be parallized on the engine as well.

GN: What's the news with Star Citizen? Anything you want to say to backers?

CR: We have Citizen Con in a couple of weeks. We're going to show some stuff that hopefully people will like; I think they will. We're going to show some other tech stuff that has more to do with Squadron 42. The multicrew that we demoed back at gamescom is moving along quite nicely, so that's something we're pretty confident of being able to share with people towards the end of October.

I think people will actually have a lot of fun because it's a big level – and it's not an empty level, there's lots of things to do, so it's a bit of a playground. I'm actually looking forward to people getting out there, getting in their ships, and flying around and getting into trouble with each other, against each other, countering AI – it's the very, very, very beginning stages of what the actual Persistent Universe in space will feel like, so it's not a limited combat arena map. I'm pretty interested to see the community get into that cool stuff that I'm sure I'll see it in videos.

The early stage of that will hopefully get people excited and remind them why they backed Star Citizen and, even though it's taking longer than everyone would like it to take, that it's worth it.

GN: Thanks for your time!

« Prev Next

Last modified on September 29, 2015 at 8:00 am
Steve Burke

Steve started GamersNexus back when it was just a cool name, and now it's grown into an expansive website with an overwhelming amount of features. He recalls his first difficult decision with GN's direction: "I didn't know whether or not I wanted 'Gamers' to have a possessive apostrophe -- I mean, grammatically it should, but I didn't like it in the name. It was ugly. I also had people who were typing apostrophes into the address bar - sigh. It made sense to just leave it as 'Gamers.'"

First world problems, Steve. First world problems.

We moderate comments on a ~24~48 hour cycle. There will be some delay after submitting a comment.


  VigLink badge