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

We were recently joined by Cloud Imperium Games' Chris Roberts, known best for space sim Star Citizen, to discuss DirectX 12, Vulkan (OpenGL Next), and game engine pipelines. This content has been split into two pieces: This content and the second video & article, which will discuss game engine architecture and engineering solutions to development problems. The second piece will go live on Friday this week.

A truncated video can be found below. The remainder of the discussion goes live alongside the Friday content. Note that, unlike most our previous interviews with Roberts, this was conducted over Skype – that means occasional connectivity problems and reduced overall video quality, but the content is still strong. Highlights are in the below editorial content.

For editorial purposes, we went through the process of transcribing the interview and then built our content around that transcript. We know that the Star Citizen community likes its direct transcripts, so we've cleaned-up our own (messy) transcription and have published it on the second page of this article.

Other Star Citizen Content:

• Chris Roberts & Richard Garriott Discuss Zero G Physics
• Star Citizen Technology Drill-Down & Multi-crew
• Chris Roberts Talks Deep Space Exploration & Star Citizen’s 'FedEx' Equivalent
• Chris Roberts on Instancing, Zoning, Player Counts, & Technological Hurdles

How do New APIs (DX12, Vulkan) Benefit a Game like Star Citizen?

DirectX 12, as we show in our draw call benchmark, has the potential to massively benefit lower-end CPUs by limiting draw call overhead. A draw call is an action in which the CPU directly communicates with the GPU (“draw this object”). As geometric complexity increases, draw call count skyrockets and begins heavily loading the CPU with commands communicated to the GPU. The phrase “closer to the metal” represents the developer's ability to program at a closer level to the hardware, eliminating API overhead and “middlemen.”

Going forward, we'll see an interesting shift in game software optimization – engine developers (with assistance from nVidia and AMD) will be responsible for low-level engine tuning, potentially shifting some of the burden away from game developers. CIG sees the advantage of lower-level engine knowledge and has hired-on original CryEngine engine architects, to include developers of Far Cry and Crysis 1.

Speaking to Vulkan and DirectX 12 support, Roberts tells us that “the roadmap is Dx12 first,” further educating us on the process behind the process of supporting a new API:

“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.”

Both Dx12 and Vulkan, formerly “OpenGL Next,” benefit games of large-scale nature by improving lower-end hardware performance. For the time being, games will still be split between Dx11 and Dx12 support, so we may not see the full effect of migration for a while yet. Asking Roberts about this, the CIG CEO confirmed for us that pipeline tuning for Dx12 would still yield performance gains for Dx11 users – users on older Windows installs and hardware:

“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.”

API Impact on Shaders, Renderers, & Graphics Pipeline

We've established that draw calls are the most immediate benefactor of the API shift – for both Dx12 and Vulkan – but we still need to define how that impacts the game's development and art deployment. Asking Roberts about the direct benefit of an API migration, we were told:

“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.”

The team's “tech to get around draw calls” will benefit DirectX 11 users, mitigating some of the impact on processing by geometric complexity. As for the shader approach, the methodology enables greater scalability of the game's graphics, allowing close camera positioning without degradation of character texturing. This is an issue seen in many games – recently, we commented on texture degradation in the Dreadnought demo – and is difficult to resolve without pushing high-resolution, large textures into the buffer. Roberts expanded on the approach:

“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.”

Building a Game for DX12 & Modernizing the Engine Thread Assignment

Curious about the lower-level implementations performed by the team, as mentioned above, we asked Roberts how difficult Dx12 is to integrate as a developer. Roberts indicated that there's more than one method for implementation, with some as simple as “just changing calls” and others demanding low-level engine refactoring. The CIG team opted for the latter, hoping to achieve the “full power” of Dx12 by updating CryEngine's thread utilization.

“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.”

Reducing data dependencies has been a part of the CryEngine restructure. Since our earliest interview with Chris Roberts, a 2012 discussion on technology and computer hardware, we've known that Star Citizen is slated to utilize high-end PCs. I distinctly recall the conversation when Roberts told me “I've got six cores, eight cores – I want to use them!” That hasn't changed in the three years since:

“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.”

What Features do the New APIs Permit in Star Citizen?

We discussed DirectX feature levels in our GTX 950 review, discussing items like conservative rasterization (Dx 12_1) and varying feature level support across older hardware. DirectX has historically introduced some level of optimizations for specific graphics functions, like the lighting updates made in Dx10 and Dx11. We asked how the Star Citizen team hopes to utilize DirectX 12 to better enable certain graphics functions, learning that CIG is looking most closely at fluid simulation.

Fluid simulation in video games can mean a number of different things – like in CFD, it's not always what we think of as fluids (liquid). For video games, fluid simulation can include rendering of voluminous smoke, wind and air representation, and the obvious simulation of water or liquid. Roberts explained CIG's plans:

“There's plenty of cool stuff [coming up]. We're focusing a lot of our efforts and work on things like fluid sims that we could use for gas clouds, background COMPUTE stuff to allow us to do voxelization of asteroids, and then there's a bunch of GPU tessellation stuff that we've actually been planning for our planetary stuff. We may be able to deliver some of this earlier than I thought we would on a procedural planet level. We'll see what happens with that, but we may actually do something that I thought would be stage 2 with stage 1 of the PU, which would be pretty awesome.”

Vulkan in Star Citizen

Roberts, never afraid to shy away from going deeper into tech, was also keen to discuss Vulkan and its future potential. Vulkan is still a ways out and has been beaten to market by DirectX 12, which means that the team is prioritizing Dx12 first in the roadmap, but they haven't ruled-out Vulkan implementation. The Khronos Group's unique market positioning has its OpenGL API in nearly all mobile smart phones, on Linux, and – to a less competitive degree with Dx 11 – on Windows. OpenGL Next, now known as “Vulkan,” has consumed AMD's Mantle API and aims to achieve many of the same goals as Dx12, but with cross-platform delivery. This makes Vulkan an interesting API for gamers, especially with the ever-forthcoming Linux gaming revolution – something Valve is now backing.

I asked Roberts, quite simply, if Vulkan is of interest to his team.

“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.”

I figured I'd offer a chance to clarify any concerns before they arose, noting that “Of course, Dx11 is still supported –.” Roberts saw the opportunity and jumped in, “Yeah. Dx11 is fully supported. We're not going to abandon it, so we're going to make sure [the game] performs pretty well on Dx11, then with Dx12 it steps up.”

What's New with Star Citizen?

We can't talk to the CIG team without looking more closely at forthcoming plans. The DirectX and Vulkan content ends here, but we've got some interesting (and educational) game engine architecture content that's getting published on Friday. Until then, we asked CIG Chairman Chris Roberts about what's going on with Star Citizen in the immediate future.

“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.”

Check back on Friday for more content from this interview. Be sure to subscribe to the YouTube channel to receive all of our Star Citizen (and hardware) content updates. Questions posted below or tweeted at us will be considered for the next interview round, though no guarantees on those – we normally go in with a big list and only address a few (but offer great depth on each question).

As always, keep in mind that Star Citizen is an in-development title and not yet released in full. The team building the game is undoubtedly competent and talented, but we always recommend heavily researching any title prior to pre-release investment.

Page 2 for transcript.

(Like this content? Help support us on Patreon).

- Steve “Lelldorianx” Burke.

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!