Support NeoGAF

[Masterofchapter]

Avatar: Frontiers of Pandora - the big developer tech interview

Digital Foundry's Alex Battaglia interviews Massive's Nikolay Stefanov and Oleksandr Koshlo about Avatar: Frontiers of Pandora and the Snowdrop engine.

www.eurogamer.net

 

[Portugeezer]

I'll wait for video.

 

[Tripolygon]

Interesting read. Some highlights.

Oleksandr Koshlo: We have a custom solution for the BVH on consoles. Since we are not relying on their APIs, we pre-build the bottom-level BVH for meshes offline to get higher quality. Then we built our own custom solution for the BVH in a way that allows us to build the top-level BVH on the CPU - whereas with DXR and existing APIs, the way you do this is that you send all of your instances to the GPU, and the GPU creates an acceleration structure. We rely on caching a lot, and we only rebuild things that have changed. This allows us to actually efficiently build the top level on the CPU and saves us some GPU time on that.

Oleksandr Koshlo: It's actually a lot of things. We use async compute a lot. We love it. We only ship DX12 on PC so we don't actually have platform differences in terms of things using async. The volumetrics are completely running on async; the probe ray tracing and lighting is running on async as well. While the g-buffer tracing part runs on the graphics queue, the probe tracing part runs on async. The GPU culling also runs on async compute, and a bunch of other smaller things as well, so it's loaded quite well.

Nikolay Stefanov: We are using FSR on consoles for upscaling and temporal anti- aliasing, same as on PC. By default, I think you've probably noticed that it's FSR. On PC, we also support DLSS. We're also working with Intel to support the latest version of XeSS, which is going to come as an update - hopefully soon.

Oleksandr Koshlo: We do ship with mesh shading on consoles. So, there are two things that contribute to the high density of our geometry in the world. One is the GPU geometry pipeline, which is new to Avatar, and it supports our procedural placement pipeline. So this brings a lot of geometry instances and we use the GPU to cull them away, to only render what is on the screen. And then we also chunk geometry into what we call meshlets, and we use native hardware features like primitive shading and mesh shading to then render them on screen. We use an additional culling pass to discard the meshes that aren't on screen. These things really improve performance for geometry rendering.

 

[shamoomoo]

I might be interpreting Koshlo's response wrong but:

Digital Foundry: One thing I noticed while looking in the config file is that there's VRS (variable rate shading) listed - does the game actually support this?

Oleksandr Koshlo: Yes, it does. I need to check for the setting specifically, but the support is there.

Digital Foundry: Is it used on the Xbox Series consoles?

Nikolay Stefanov: I don't think it is.

Oleksandr Koshlo: I don't think we're using it at this time on the Series consoles.

 

[Denton]

Great interview, lot of detail.

I might be interpreting Koshlo's response wrong but:

The engine supports it, but it is not used on Xbox consoles (and I doubt anywhere else)

 

[Gaiff]

winjer Pretty much what I was talking about.

 

[SlimySnake]

I'll wait for video.

no video.

 

[shamoomoo]

Great interview, lot of detail.


The engine supports it, but it is not used on Xbox consoles (and I doubt anywhere else)

What I'm suggesting is VRS maybe used on the PS5 since Koshlo didn't say VRS wasn't used on consoles,just the Series'.

 

[SlimySnake]

So it uses mesh shaders/primitive shaders on consoles, but on PC just yet. Would love to see the performance uplift when they do add support for it.

 

[Gaiff]

So it uses mesh shaders/primitive shaders on consoles, but on PC just yet. Would love to see the performance uplift when they do add support for it.

Yeah, this part caught my eye. I'm unsure if there are significant performance penalties, however. He does mention that it was challenging to optimize mesh shading and that the vanilla rasterization is still really fast.

Would be interested to know the performance differential. 1%? 5%? 10%? It mustn't be all that huge because the game still performs rather well on PC I believe. Their much larger team also allowed them to use the old vertex shader path, unlike Remedy with Alan Wake II who just ditched it.

Based on this, I'm expecting consoles to have a significant performance advantage over PC-equivalent hardware. Hopefully, Alex can do a side-by-side and we might have some insight as to how much more performant mesh shading is.

Edit: Another interesting aspect.

Oleksandr Koshlo: We have a custom solution for the BVH on consoles. Since we are not relying on their APIs, we pre-build the bottom-level BVH for meshes offline to get higher quality. Then we built our own custom solution for the BVH in a way that allows us to build the top-level BVH on the CPU -whereas with DXR and existing APIs, the way you do this is that you send all of your instances to the GPU, and the GPU creates an acceleration structure. We rely on caching a lot, and we only rebuild things that have changed. This allows us to actually efficiently build the top level on the CPU and saves us some GPU time on that.

The implication here is that the BVH on consoles is entirely run on the CPU (with the bottom-level being rendered "offline") and looking at online benchmarks, this game is very well-optimized on that front. On PC, they use precious GPU rendering time to build the bottom-level BVH and build the top-level on the CPU. Combined with the lack of mesh shader support, it seems the GPUs on PCs do quite a bit more work for the same results on consoles. This is a case of "console optimization" where the fixed hardware for consoles makes it that much easier to develop.

Not expecting the 2070S to keep up with the consoles at all in this game. This might be another case where they perform more in-line with higher-end GPUs like a 2080 Ti/3070.