NVIDIA Corporation (NVDA) Earnings Call Transcript & Summary

Hello, and welcome back to Level Up with NVIDIA this month. I'm Richard, you well know, and we have a special guest this month. His name is Evan Hart. Evan, do you want to have a go around and introduce yourself and then tell everybody what is you do?

Sure. I'm an engineer working on our NvRTX branch, just general Unreal Engine issues for NVIDIA. And I spend a lot of time working on improving lighting within NVIDIA. And that's what I was kind of hoping to talk to you guys all about -- a bit about today.

Sounds good. Yes, today, we'll just be touching a bit about NvRTX -- RTXDI and NvRTX. What are some of the advantages of it, how it works, why you should change of it. and we'll have a Q&A as well, as we always do, after everything is over. So with that, I'll leave it to you, Evan. Do you want to share some slides that you prepared.

Yes. I've got a few slides here to just kind of give you guys an idea of what I'm talking about. So let's talk a little bit about NvRTX and the RTXDI component that we've implemented for it. So I'm going to start off with some screenshots just showing you where we're going. This is the cyber [ ROM ] and demo that our team has worked on. And in particular, this is a case where we remastered it to utilize the RTXDI capabilities from NvRTX alongside DLSS rave reconstruction. And we had this as sort of one of our featured demos that we use to show off the initial rollout of DLSSR. Additionally, if you need more lights, well, here, we've got the amusement park scene that we've been doing some work on internally. And here, you can see that we've got thousands of lights in the scene, all casting shadows fully dynamically. So this is obviously something that you can't do today in UE5, but with NvRTX, this is something that you can accomplish. So what are our goals behind NvRTX if you're unfamiliar with our branch. Well, we aim to provide major quality enhancements for UE5 while maintaining workflow and content compatibility. So we don't want you doing a ton of extra stuff just to make NvRTX work for you. Also, we offer forward-looking technology like the multilight shadow capabilities that I've just been talking about with RTXDI. So how does this all -- so what are we offering here? Well, the RTXDI stuff that I've already talked about, some Lumen scalabilities that I'll get into that is related to the RTXDI stuff. And then additionally, we have state of the art execution reordering capabilities that allow us to optimize many of the ray tracing effects that you may want to use as well as denoising. That means both the DLSS reconstruction or those that have access to the SDK as well as our NRD denoiser set. Plus we've got several more different things that NvRTX has on offer that we're not going to touch on today. So what is RTXDI in NvRTX? Well, RTXDI is the -- an acronym for ray traced direct illumination. And this is actually an implementation of ReSTIR. So this is temporal and spatial reuse of Monte Carlo lighting evaluation, which allows it to emulate direct lighting component of path tracing. This means that shadows are going to be evaluated via ray tracing, and they're going to be completely sampled in the same way that Monte Carlo path tracing operates. So we support UE5 native shading, which means that it uses the standard UE5 materials and the standard UE5 lights to do all this stuff. But we scale towards massively complex lighting environments because we have dynamic lights basically costing the same as static lights within the environment, so no need to bake down light maps or anything like that. And then we have special optimizations that we've added in this branch and engine to reduce the overhead of dynamic lights. So you may know that moving a dozen lights that you're seeing in UE can become expensive just from the software overhead perspective, and we've done work to reduce that overhead. And finally, all these lights are treated completely identically. So it's not a matter of, oh, we have special code for direct lights. We have a special codes for spotlights. They're really all operating the same, whether they're static, dynamic, et cetera, as long as they're going through the same RTXDI path. Importantly, though, we also extended this to Lumen to enable consistency across scenes because it doesn't do us a whole lot of good to render with 1,000 lights in a scene if Lumen can't handle 1,000 lights because we need to be able to -- lighting doesn't just affect your direct lighting capabilities, it affects everything else at the same rate. So it's important to note that the core technology that we're talking about here is used for the path-tracing implementation within Cyberpunk. So it's a sort of a core foundation piece of what people call a real-time path tracing. So to give a better explanation of what we're talking about, standard lighting, every pixel must evaluate each light, or at least all the lights within range of that pixel. But what does that look like? Well, if we have a pixel on a surface within normal, we have a bunch of lights, it has to be able to evaluate all these different lights to be able to illuminate itself. Now obviously, if we're talking about a large number of lights, this becomes a pretty expensive thing to do. Additionally area lights are needing to have sort of samples from across lights. So you can also -- you can frequently think of area lights as being sort of millions of individual light samples spread across an area. And that's ultimately what they end up looking like. But importantly, we can have shadows in the scene, and we have blockers blocking off certain rays of light, and we have to be able to deal with this correctly. So we have to account for occlusion within these lights. Now when we're talking about sort of the direct lighting cases I showed initially, we start cheating frequently in real-time. And we use something called split integration, where we'll integrate the light and the shadow signal separately. So you'll see a big amount of light coming through from a light, but then maybe the shadow rays don't get sort of evaluated exactly at the same place that the light rays were evaluated. And this leads to what's called a split integral and leads to things not looking quite the same as that they wouldn't realize. So we want to go to Monte Carlo evaluation, which is what path tracers do. We get this really, really noisy image, and this is because we're taking 1 sample on each light to do our illumination. And that looks like this. We've got the surface still. It's got its normal and it's choosing 1 light in the scene and taking a sample from it. So it's basically 1 sample plus light plus a bunch of statistics to sort of average things out. Well, it was really, really noisy. So -- and additionally, we could have potentially selected one of the lights that was being blocked by the shadow occluder, so we would end up with a black pixel in that case. So Monte Carlo evaluation kind made more converged or a smoother image by doing multiple evaluations per pixel to sort of refine things. And that looks ultimately like this. So we shoot a bunch of rays, some of them get occluded and shadowed, and others strike the lights. We're still using multiple rays here plus a bunch of statistics to make it look good. But ultimately, as you can kind of see, we're going to have to keep upping this number of rays and making things more and more expensive as we throw more and more lights in the scene to get the same level of convergence. So this becomes quite expensive. So what we're going for here with ReSTIR is use spatial and temporal sharing of these different rays to approximate hundreds of evaluations and get conversions. So here, you can see an image where we've done the temporal and spatial resampling, and we have a very, very clean image, except along some special boundaries where different materials or the edges of shadows exist. What this looks like is that we will have rays that we're firing towards the lights, but we'll also look at neighboring pixels and determine what they were doing and use the information from that neighboring pixel to make it as if we were firing rays to many more lights from that initial sample. Additionally, we will use temporal evaluation to look at the previous frame and understand what lighting was happening during that frame. And by modulating, basically, the spatial and temporal components together, we get -- as though -- we have sampled hundreds and hundreds of light sources in each single frame. And that allows us to get the more converged image that we were talking about. Then once we apply denoiser, we get a very, very clean image, just like you were getting before, except now we're actually getting a much more correct evaluation of the light sources because of the fact that we have evaluated the exact occlusion along the rays to the exact points on these large light sources to give you a nice soft shadow falloff. Well, I mentioned with the [ Cyberoam ] case before that it's not just about what their direct lighting looks like. We have dozens of lights in the scene, but we have to make them work in Lumen as well. So Lumen offers this thing called a surface cache. And the surface illumination within the surface cache is basically a reduced quality version of the full lighting in the scene and it uses this to control the bounce lighting that you see in global illumination. We can apply the same sampling technologies that we have for the RTXDI case to Lumen as well, and you see we get a noisier version of that same image. But the important part is that while this is a noisier version of that image, if we look at the final evaluation of everything, once we've turned off the direct lighting, you'll see that this version of using the standard fully integrated Lumen lighting, very similar, nearly identical to the one using the sample lighting case. So now we've moved to the ability to grab a handful of samples from up to hundreds or thousands of lights instead of having to per light source for every sample in the scene in the global illumination system iterating over them. So we've improved scaling by multiple factors here.

Can you go back-and-forth between those 2 images again? You're right, I barely noticed the difference between them.

Yes. And to be honest, the difference between them is not even necessarily down to the difference between the sample versus the non-sample, but just due to their slight temporal artifacts in both of them with the way in which to see the sampled.

Okay.

I don't know if you wanted to look at this one again versus sample versus non-sample.

I mean that looks very different.

It is. It's a little more obvious.

Yes, yes. But yes, on the final output, that's really interesting. So -- okay, cool.

That's what I prepared for you guys today. Any questions I can answer for you guys about all this?

Yes. Thanks, Evan. That was, I think, a really good presentation on usually to show exactly what's happening, so appreciate you putting that together.

Absolutely. My first question is about, how would you describe the lighting cost of RTXDI in general? Because people who are lighting artists like myself, like in the past, every next shadow casting, like, you add into the scene, you're increasing lighting costs a lot. It's just-- the cost just keeps going up and up and up sometimes exponentially, right? Like, every light has its own cost associated to it. And it sounds like RTXDI is flattening it or making it more of a fixed cost. But is the goal to make it completely flat? Or I guess, how would do you characterize that?

Yes. So algorithmically, RTXDI cost is pretty much flat. The only reason you would see non-flatness to the scaling with number of lights is simply sort of physical limitations of the hardware, right, where, like, light fit in caches or don't fit in caches, sort of. Maybe you'll have more cache misses if you have more lights -- but that's a very, very second order sort of effect.

Okay. Yes. So another question I have is, I mean, RTXDI can work by itself. It can work with Lumen or not, right? So you don't have to use Lumen if you're using RTXDI. You could just flood your scene with lights. There's probably lots of ways to go. And Lumen has 2 modes. It's got a software mode and the hardware mode. The acceleration we're talking about is really for the hardware mode, correct? I mean, it doesn't -- we're not also accelerating the software mode.

Correct. We are not accelerating the software mode because we need very low overhead occlusion probes for whether the lights are occluded or not. So we rely on hardware ray tracing for that to allow that to happen.

Right. But that makes sense because RTXDI itself is a hardware ray-tracing technology. So if you're using RTXDI, you'd want to be in hardware ray-traced Lumen mode as well.

Yes.

Yes. I guess another question I would have is with RTXDI the goal of the technology is, as I understand, is basically twofold. It's path trace quality, direct lighting and very high light counts, preferably in the thousands or basically as high as we can make it. And RTXDI is a technology. I mean, it starts as an SDK and moves into the Unreal Engine. So you were talking about this before that in some ways, it's adapted to the Unreal Engine. It's not the pure SDK or, like, necessarily every feature of the SDK. There's some work that has to happen as it moves into Unreal.

Yes. It's very much a bespoke implementation of the SDK in that Unreal has material types, light types that the SDK doesn't understand. And also, there are things that the SDK does that just don't exist within unreal. So it's very much a customized implementation to fit exactly what Unreal needs.

Right. Right. Yes, of course, some Unreal has custom material types and so forth that RTXDI has to have understanding for, right? Like, it needs to be compatible with the various material domains that unreal has and so forth.

Exactly.

Yes. RTXDI is -- it works with hardware ray traced Lumen to -- and we're expanding what hardware ray-traced Lumen can do as far as its capability. Like it can -- we can have a much higher light counts with RTXDI. Lumen can scale up with that so that we can get into thousands of lights and things like this. Is -- it looks like based on some of the slides you showed, we're not just trying -- and I want to get this correct. I want to really understand this. We're not just trying to expand the like the total number of lights that Lumen can process successfully in real-time frame rate. We're also improving some quality aspects to Lumen GI as well. Is that the sum total of it? It's basically those sort of, like, 2 metrics, like improve the quality of Lumen, improve the total light count or is there more to it than that?

Yes. So Lumen mostly benefits from the enhanced light count. Lumen does potentially benefit a bit from the more sample nature rather than the split integral nature that we're able to do. So we are able to more accurately control sort of how much of a light is blocked. And this will make more difference for things like if you had a light material function, or let's say, you had a texture on a rec light. The integration that we're going to do with the RTXDI style enhancements to Lumen, it will -- by doing the Monte Carlo sampling, it will get you towards the ground truth whereas the built-in Lumen typically relies on the split intervals, where it can break down under some circumstances, especially for things like those.

Yes. Those are the questions I have. What have you got, Zach?

Just some kind of more straightforward questions for people out there who may not be aware, but just to confirm that, is RTXDI DXR compliant?

Yes, it is completely DXR compliant as implemented within Unreal Engine. We do not rely on any sort of special NVIDIA features to make it work. We do use DXR 1.1 presently, some capabilities from DXR 1.1 and that we were actually DXR 1.0 until just a few weeks ago. And we added some DXR 1.1 stuff to basically improve specular lighting within the RTXDI implementation.

Got it. And effectively, it means it runs anywhere that hardware ray tracing is available.

Yes. It will run basically anywhere hardware ray tracing is available. The code, as it's written in Unreal, is written directly against Unreal's shader language, which is effectively DirectX HLSL, but there are some variants with it. And the Unreal Engine will actually cross compile that shader code. And the -- because it's written in the Unreal shader language, that cross compilation can potentially work on other platforms that we've never even worked with. There's nothing specific even to DirectX.

I see.

That's a Vulkan, theoretically, like…

The Unreal…

I know that -- that work might be ongoing as far as Unreal goes, right? Like, it's…

Yes. Unreal is still doing some Vulkan work. So I'm not ready to say that it'll support everything with Vulkan today. I think light function -- light material functions may not work for Vulkan if wrong, but -- yes.

What about older hardware? Is RTX designed to work on the 20 series, for example?

It completely works on the 20 series.

Yes. I mean, it's -- I mean this has been my understanding, too, right? It's really anywhere hardware ray tracing can work or can also theoretically work.

Anywhere that supports a DXR-compatible system should be able to support the code as it exists today.

Okay. Great. Yes. So Evan had brought up the amusement park scene and how we're working on pushing, like, thousands of lights into the scene. So I have it here running in Unreal 5.2. So I'll switch over to that, and we can talk about it. Okay. Can you see everything okay?

Yes, we can.

Cool. Cool. Yes, so -- yes, this is a very high light count seen. I'll back out a little bit. As you can see, there are also a lot of just general details going on here. You can see that there's a play space with some foliage in the distance. It's all shadow casting. This is, of course, using RTXDI and the -- well, I'll just -- I'll play it so we can see it in a literal sense. And yes, you can see that the -- I mean, there are a ton of dynamic shadow casting lights here. All lights in the scene are retraced in shadow casting.

How many lights do we have in here? I think -- is it like you say, like, 1,000?

Currently, about 1,100, but we're building this with a UI where you can increase and decrease the total light count. And I would point out, just ignore the frame rate because I'm recording this, so that's going to knock down the frame a little bit. I'm also playing an editor that further knocks down the frame rate. Our goal for the scene is going to be outside the editor in an optimized -- like, shipping build is going to be minimum 60 fps before we put frame generation on it and preferably more like 90 FPS. So we'll need to see where that lands, but the performance on it should be very high.

I know some people are probably going to say I've seen this before somewhere and that is true. This used to be a much smaller map and scene and the team has been, including Richard's, they're working hard on expanding it a little bit. And I'm sure people are going to ask if they're going to be body to get their hands on this as a demo. And I don't know, Richard, maybe you'd probably be better to ask about that.

No, that's absolutely the plan. Yes, we are, right now, using the DLSS -- what you're seeing here is RTXDI with the DLSS 3.5. Frame generation is not currently active, but ray reconstruction and super resolution are. So it's -- in order to get really good performance with this many lights, you need lots of things to work in tandem. You need a technology like RTXDI to do very high light counts. And the NvRTX branch has, like I was saying or Evan was describing optimizations to Lumen and so forth that really help to make this doable. But ray reconstruction is also important. So that's one of the sort of limiting factors in getting this out. We want to make sure that ray reconstruction is fully ready for the public probably before we release the scene, so that's generally the thinking. And you can see that it provides, like, very high stable quality on the images, like it's -- even with this many lights going on in the scene, just -- it denoises them all and handles it really well. I can just -- I mean, just for fun, I can turn on and off some of the individual features, like if I disable a ray reconstruction, see what a much noisier image this is, right? Sort of you get a look behind the pixels, how it's -- there aren't enough rays being fired into the scene to capture every pixel, every single frame. And so you get this sort of scattering noise pattern with this many lights and this much geometric complexity. I mean, keep in mind, too, we're looking at Nanite-heavy scene with tens of millions of triangles. So if I put rays ray reconstruction back on, it really helps to clean up that final result. And this, too, is a ray tracing-heavy scene. Like, every kind of rate tracing is being employed here, reflections in the puddles. There's ray trace translucency and reflections happening in the glass…

Is there ray-tracing ambient occlusion going on as well?

No. That's being -- that's an interesting detail. When you -- sorry, when you use Lumen, Lumen uses distance fields to do AO and that's even in a hardware ray-trace setting. So this is using a hardware ray traced Lumen right now. So it's -- the global illumination is hardware ray-traced, the reflections are hardware ray traced. The AO is handled by distance fields. But the interesting thing about distance fields is that they're basically a form of, like, approximated software ray tracing, right? So we don't get completely away from ray tracing, even distance fields being used. It's still -- it's not exactly -- like I said, it's not exactly ray tracing, but it's like an approximated lighter version of it. It's an interesting topic. It may be a good idea for us to -- in completing, like, more of a real-time path rays look to, like, sort of insert, like, path trace quality indirect shadows into the final result. But I would say that, that particular detail is sort of, like, an ongoing area of research. It's not completely settled yet. I would actually point out that ray traced ambient occlusion, which was -- it's still an Unreal 5, but it's part of the deprecated path and it's more prominent than Unreal 4. Ray traced ambient occlusion itself is not a completely physically accurate form of ambient occlusion. Like, technically, none of the ambient occlusion methods, none of the real-time ambient inclusion methods are. If we want to achieve, like, physical accuracy. We would want, like, basically a real-time path-traced indirect lighting, and we're not there yet. But if that's the goal, then something along those lines is what we'd want to do. I know that's long-winded answer, too. Sorry about that.

Good information for people to know. And I'm sure a lot of them are thinking about -- it looks like there's a volumetric fog in there.

The volumetric -- I mean, this is using like all of the NvRTX rendering effects. I mean, even the there's Niagara particles that are going on here that are shadowcasting. But the foliage is ray-traced and taking advantage of features in our NvRTX branch for that. Yes, and there's volumetric fog shadows here as well. And you can see here, like there is -- it's got high-quality translucent, reflective Lumen surfaces for things like this glass here. So yes, it's -- there's a lot happening in the frame.

I think some people will probably be asking is -- our last had been on recovered caustics, if caustics is used in this particular scene, but I think the answer is no.

Yes, correct. The answer is yes, not yet. And keep in mind, this is still under development. So some of the assets, as you can see there, a gray box. And so it's not completely final art wise, but yes, we -- and yes, getting to that -- let me set the simulate mode here. This is always fun.

And also the fireworks, those are -- are those counted as individual lights as well?

Yes. Like, on the ferris wheel here, for example, where you can see how many dynamic lights are associated with just that 1 asset. A really important feature here that we're working on is animated lights, right? There are a lot of moving lights of each one of these assets here. And if all your lights are just placed, if I select these guys, you can see all the shadowcasting ray-traced lights that are associated with them. If your lights are like this, and they're just holding still. This is like your -- even if the light is set to movable, this is, like, your most performant kind of light, right, because it's not actually transforming through space. It's not moving around. But when they're physically transforming like this and moving, there's a bunch of additional CPU calculations that are going on. Evan touched on this a little bit. So it's really important we have optimizations in the NvRTX branch that make moving animated lights much more performant at run time. Because without that, we wouldn't be able to do an asset like this with all of these moving and transforming lights and keep it running above 30 frame per second, right? We just -- everything would just get bogged down. It wouldn't matter what kind of GPU you have in the system because it's a straight up CPU bottleneck. You can see all the area lights associated with just this 1 thing. So I think actually, the fences are fun to light.

So yes, this is -- it's an excessive amount of light to a lot of them. Yes.

I think there are people a good sense of how many lights they could actually put in the scene and how far they can push it.

Yes. When we do release this, I mean, like, our intention is to have it in, like, a fully optimized state for it to be a good example to developers, and you'll be able to get your hands on it, get the source files, take it apart, understand exactly what we did and how to apply some of these techniques and -- to your own team. But at the end of the day, hopefully, you won't have to do very much, right? Like, your -- because we're going to have done all of the optimizations behind the scenes to make something like this possible. And then you'll just be able to take advantage of it. So that's our end goal and yes, I think once we have DLSS 3.5, like, fully out there for Unreal, that will probably be when the scene drops as well.

Awesome. So keep your eye out when this is ready and also with all the features. Just wanted to ease this a little bit, but also showing a good example of RTXDI in action.

Yes, cool.

All right. Well, that was a great informative session. I want to thank you again, Evan, for joining us in -- along -- on a journey of recording fun that Richard and I have every month. But we would be glad if you came on again at some point in the future to discuss more about RTXDI and maybe perhaps even NvRTX as well.

Yes. No, I enjoy coming on with you guys. I am happy to talk to people about stuff we're working on. So we're working on a lot of stuff, but sometimes you're just down in the basement writing code. To be frank, that actually even do a worse job for video and sometimes for coding, too, so.

All right. Great. Well, thank you again, all, for joining us. We'll have some resource links to several different sites as our NvRTX page. Links, somewhere in the description, so please click on that and stick around for our live Q&A.

Awesome.

Thanks, everybody.

Yes. Thank you.

Yes. Thank you. Hello. Welcome to the Q&A. Thanks for joining us. Thank you for all the questions. It's -- we love questions, the more the better. And it looks like you guys have a ton of them. So we're happy to see that. I think to keep things moving, we'll just dive straight into the questions. We've got quite a few that are pretty interesting. So I think I'll start off -- or we'll start off with NvRTX. Is it production-ready? Can someone use it right now today for their development pipelines workflow to deliver and use it in their products?

So yes, I mean, it's a great question. We have definitely had several developers use features that are in the RTX today, and they're welcome to go ahead and use them, and we will definitely take any -- be committed to fixing any issues that they find that we know about. However, I would point out that several of the features in NvRTX are labeled as beta or experimental. So just like in Unreal, there are features that are labeled as experimental and you obviously want to tread more lightly on things like that.

Great. So I guess the answer is yes, but tread lightly.

Yes. It -- take a look at the readme for which features that you're planning on using and evaluate for yourself whether you feel that, that's a more or less, whether you are willing to take that degree of risk, right?

We have a couple of questions about VR. So I think if you answer one, you'll probably answer them all, can NvRTX be used for VR?

Richard, do you want to do this one? Or do you want me to get this one?

Well, I'll start. I mean, I think the short answer is yes, but any ray tracing effect in VR is going to have a performance hit. And you can't -- you need to understand that, like, if you're using an Oculus, you need to be probably on a direct link to a high-end PC. You need to be probably connected to an RTX card and running your VRC in that way. I personally tried this out, and my experience has been as long as you -- to the constraint, the ray tracing effects you're going after, you can expect to get reasonable performance out of it. Like, for example, make use of ray-traced reflections at like a low sample or low bounce count, but then maybe don't use extensive dynamic shadowing as well. So just -- if you target where you're going after, you tend to get good performance out of it. But, like I said, no, you can't run that -- like, on a stand-alone Oculus wirelessly, right? You're probably going to be hard-linked like a 40 series card or something like that.

Yes. I'll just add. You've got -- if you're using -- [indiscernible], you typically have a denoiser running. The denoiser takes 0.5 millisecond or 1 millisecond. You just have to remember that's time coming out of your frame budget, but if you're trying to hit 90, that's 10% of your frame budget or whatever, so be aware and manage your costs and you should be okay.

Yes, that's part of my experience, too. Denoised lights in VR are very tough to keep at a good performance level. I mean, with excessive amounts of area shadow, right? But if you keep your ray-traced lights slice sharp, it's much easier to get a good performance out of VR that way.

Great. Moving along, what GPU are you using, Richard? I know a few people probably have that question. They're always wondering if we have the latest and greatest or they're trying to mimic what everyone has.

I do a lot of demos on lower-end hardware. I was showing the amusement park on a 4090, but it was in 4K and in the editor, so there are a lot of things sort of working against it from a performance standpoint. The scene is designed to be scalable. So it's not going to -- ultimately, it's not going to require a 4090 to run. That was just the most convenient way to show it, like, at a high resolution running in the editor when I did the recording.

Yes, Richard, and I'm actually overdue for giving you guys a performance pass over that, too, do a little bit of extra elbow grease on the optimizations because we've added a bunch of features recently. And you add features, sometimes you turn down the performance a little bit accidentally, so.

Right. So features first and then tune it up a little bit. Yes.

Yes. And one thing I'd really kind of like to just point out is that while you're using a 4090, you're using it at a particular set of settings. And that's actually one thing that's really interesting about RTXDI is that we do have scalability settings. And you can actually get a lot of scalability with respect to quality of the shadows that it produces. If you're willing to accept somewhat softer or use somewhat muddier shadow edges, there are quality settings that you can turn back with the RTXDI stuff that offers really interesting scalability when -- like, in the past, it would have been like, okay, well, I ran out of shadowing lights and I'm kind of stuck no matter what.

All right. Moving right along. We have a lot of questions and very little time, so I want to make sure we cover some of these some really good ones. One is about impact on performance of emissive light sources.

Was that question about RTXDI specifically? It must have been, right? RTXDI and emissive. Okay. Sorry, Evan. Go ahead.

Okay. Yes. So just today, the RTXDI implementation in UE does not sample emissives directly. We actually rely on Lumen for that at the moment. We are working towards some updates where we may add some emissive sampling. It's TBD, whether we'll just refine the emissive sampling in the Lumen pass or whether we'll do it in the direct pass because that would require, like, a little bit of artist -- extra artist work to balance where you've got, like, an emissive proxy on top of a light source that you've put in a scene.

Great. Moving along, is there -- the next question is about debugging performance. Is there a way to debug performance-specific issues related to RTXDI?

Good question. I'm pretty good at it. But obviously, I'm a bit of an expert. So typically, what we recommend is if you're trying to debug performance, would be dialing back settings for number of spatial samples you're taking, number of initial samples you're taking. I would actually suggest like trying to say, for instance, turn off the directional light would be one thing you might try, because if you're seeing a bunch of divergence or where we get some divergent branch flow, it can sometimes be happening due to using the Sun inside of the RTXDI code. Yes, I would say that we don't have a lot of great tools for it. We -- I mean, I typically use Nsight to dig fairly deep because a lot of the performance I look at is fairly deep, like down to the instruction level. But yes, changing the settings, like, number of spatial samples and things like that are the things that you do as an end user, typically.

All right. That's very good advice. Actually, from my own part, I tend to just start with stat GPU, like, in the editor. And the thing I want to look at is my lights' cost. Any denoising cost is sort of secondary, right, if you're using NRD or ray reconstruction. You'll see a line for that, where in the stat GPU, where you're denoising has a certain cost associated with it. But if I do a stat GPU in my scene, I see my lights cost is too high, whatever, maybe it's turning at 5 or 6 milliseconds. I know from experience that is an artist working on the scene, that there are certain things I can do to probably tame that lights cost down to something more in line with aiming for. Maybe, like, I have an expectation that I should be able to render hundreds of lights, and it shouldn't cost me anything more than 2 or 3 milliseconds to do all that. So I -- you can step through our GitHub documentation and you can see some of the CVars there. You can also just use the scalability settings built into Unreal, because we tack on -- if you look at the base scalability INI file, we add some CVars right there. So if you just go down like -- from, like, the default Epic scalability down to a high, you have more optimized with your RTXDI lights' cost just by doing that alone. And you may not even notice much of a quality difference, basically. It might produce about the same result. So, yes, usually adjusting in a couple of CVars, like Evans just said, like sampling or maybe the number of reservoirs, taking it down from 2 to 1, just something like that can have a huge impact on that lights' cost. And usually, you don't have to do more than a few CVar tweaks to get it where you need it to.

I'd also point out that profile GPU will give you a nice breakdown of whether what the costs are for, like, initial sampling, temporal feedback and spatial sampling as well if you're trying to dig a little bit deeper with respect to the performance. And 1 tweak that a lot of people forget about or don't think about oftentimes there's a [ cvarr.ray.tracing.samplelighting.mode ] and it defaults to 1. And we have a direct Monte Carlo-only mode called zero that is faster in a low-light count scenario. One of these days, I'll get it properly transitioning to auto turn to that mode when you have fewer than, say, n number of lights to make this a little bit easier for you. But yes, that exists there today.

Okay. So that's a good point. I -- that mode zero is really useful if -- again, just hypothetical scenario, I'm looking at a scene with, like, a, whatever, 5 to 6 millisecond light cost, you switch it to that mode zero. Typically, I mean, I would see that light cost will drop dramatically, because it's actually turning off a bunch of other things in the background. And so that might -- it's lower quality, but it might give me, like, an idea of just by doing that 1 CVar, what my theoretical, like, max speed might be if I tune down a bunch of settings, right? So you could see like 5 or 6 milliseconds become, like, 1 millisecond. And then you're, like, okay -- so maybe I don't want to turn everything off, but just adjusting a couple of values, I can get, like, into the targets zone I'm going for.

Also, I've put a link in the chat to NVIDIA Nsight. Just -- if people are interested in checking out, that's kind of our NVIDIA Nsight page that shows a system-wide performance analysis tools and what it offers, so if you're interested, just check that link out. Okay. Moving along, we have another question here. It says, "Are stationary shadowcasting lights treated with the same performance cost as movable shadowcasting lights?"

For RTXDI the answer is yes. It's the same cost. And they -- but they are now competing completely dynamic shadows. I answered on there before, does the engine have some lower cost. And the answer is maybe depending on, like, what your settings are for those static lights. If you have the right settings, I think that they've become effectively dynamic and pay the same general cost. But overall, it's -- they're relatively same cost with RTXDI. But if you still have, like, some baking or stuff going on, then obviously, that can make them cheaper.

Right. The next question is about performance and RTXDI. Is it possible to have lower performance with RTXDI compared to standard, like, say, non-RTXDI lighting if you're not using RTXDI in, say, UE5.2.

Yes, and this is a great question. We've kind of alluded to it a little bit previously. We're basically doing extra work to be able to support multiple lights. And just maintaining the temporal feedback and doing the extra spatial samples costs something. So if you've only got a Son in your scene, yes, turning on full spatiotemporal RTXDI will be a bit slower than just doing shadow rays for the sun. I mentioned mode zero a little bit earlier. That is an alternative that can be used that will be -- recover a lot of that performance. But if you really have just like 1 light, then yes, just falling back to just regular lighting, can be the right decision. And then based on how many lights you have, depending on your system, there's going to be a threshold crossover on what the optimal solution is for you.

Yes. Yes, for sure. Yes, if you're very, very low light count, just a handful of lights, RTXDI may not be a performance win, but it could still actually be a quality win because of the nature of the path rays direct lighting, so there's that to consider. But yes, if you have ambitions to do very high light count scenes, RTXDI will definitely perform faster than any other lighting method.

Yes. You make an interesting point about quality. Like, for instance, if you want to do a textured rec light against an anisotropic material today in UE, the engine, just because of the split interval thing that I mentioned in the presentation, it just can't really deal with that sort of a lighting scenario in real-time. It just makes approximations and sort of leaves it at that. Whereas RTXDI will -- with the spatiotemporal, produce an image that matches path tracing from the direct lighting component. So if you're trying to get that, yes, then you're paying extra costs, but you're getting that extra quality as well. Yes.

Right. And moving along, there's a few questions about 5.3. And when -- what's the time line for it. And do you have projects that can currently use for it. And I guess, you guys want to share if this is ready or not?

Time lines' last week.

Yes. Well, Envirotech's 5.3 came out the last Tuesday, I think, so yes, it's out. What you see here today is out. What we don't have out is the ray reconstruction DLLs. There -- the plug-in framework for DLSS 3.5 is part of that. DLSS 3.5, both the stand-alone plug-in and its integration into NVRTX are there. We're still working on getting ray reconstruction out publicly for the Unreal Engine. It's taking a little bit more time.

There's a couple of questions about ray reconstruction. Sorry, go ahead, Evan.

I was just going to say, I equated a lot to the way DLSS rolled out. It's all about us getting really good experience with, like, a couple of titles to make sure that everything is great and then providing access to more people.

Yes, in the Unreal Engine context, there are still some issues to resolve, but we're -- it's coming down to a handful of bugs. And of course, we want to get the full DLSS 3.5 with ray reconstruction plug-in out to the people -- out to people as quickly as we can. But we don't want to do that before we have it completely ready.

And speaking about that, I put a link in the chat, if you're interested in DLSS or for UE5 ray construction. There is a form that you can fill out for early access for developers, so go check out that link in the queue, in the chat. All right. Moving along, there's a question about, is this a cache system? Or would it work with a time of day system in real-time RTXDI?

Yes. It -- for the time of day, time of day works, it works great. It reconstructs the sky light every frame just based on how the time of day works in the -- in Unreal and it updates everything. So we have -- the temporal pass always is doing, basically, some adjustment for how things have moved. So it won't just keep the old lighting value, it'll update it.

Great. Somebody is asking about caustics. So is -- are there plans for NvRTX caustics in 5.3?

Yes. The caustics branch follows after the latest NvRTX update, usually by a matter of weeks, sometimes a little bit quicker or a little bit longer. It kind of depends on how quickly they can -- that team can integrate the caustics code to the latest NvRTX branch. But typically, the follow-on time is 2 to 3 weeks. So I would expect to see the caustics branch be out soon. I don't have an exact date, but it's coming soon.

It's available for 5.2 in our last webinar that we did. We had one of our engineers, Jackie, who is actually working on caustics, so if you want to watch that video. It's on-demand, and you can find out more about it and that's 5.2.

That was an example too, of that 5.2 cost experience. It took a little bit longer than anticipated. But I believe, I mean, Evan can correct me if I'm wrong on this, NvRTX 5.2 itself took a little bit longer because there were major sort of under-the-hood changes to ray tracing with 5.2 versus 5.1. And so caustic team had to do their integration under the same circumstances, big changes were happening. I don't think it's quite as extensive with 5.3, although maybe I could be wrong about that.

So I'll take some of the blame on 5.2 and 5.3 time lines. 5.2 time line, we had a couple of challenges with -- because we wanted to really get some new DLSS technology out there, sort of simultaneously launch it. And there was just, like, some sort of unfortunate timing conflicts on getting everything to line up there. 5.3, I took it on myself to sort of restructure some of the commits and some of the way that the code sort of looks in the within the repo. And so that took us an extra week or 2 to work through. So I don't think it will make life too much more difficult for them. I think it'll actually make it easier because our commits are sort of a little bit more modular now, but maybe something else in the engine could have broken that'll make them a little bit more -- a little harder.

All right. We are actually running out of time. I think we have time for maybe covering 2 more questions. One is -- first question is a lot of these effects are achieved with temporal consideration. Can this handle color-changing lights, like rapidly strobing or strobing to black?

I don't know if you want to include some of your experiences there, Richard. I mean, technically, the code has accommodations for this in the actual RTXDI. And I would say anybody that wants to look into stuff like this, they probably should, in addition to just trying to feature out or whatever, also look at it with denoising on and off just to see whether -- if they encounter any artifact, whether it's just the denoiser and something like ray reconstruction might make it better in the future or not.

I think we also have, like, Niagara lights in the example project, right, Richard?

Yes. Generally, like, fast-moving lights or fast color-changing lights or anything like that, it's going to look best at the ray reconstruction. NRD does -- can do a good job of denoising that. Sometimes you have to tweak it a bit more. With rate reconstruction, there really are no tweaks. It just works really well. And we know it generally produces the best quality. That's why we're trying to get it out to the public as quickly as we can.

Right. We have time for one last. This is a good question. So I wanted to squeeze it in. We answered --it's a 2-parter, but we answered the first part already. The second part is when talking about real-time path tracing, the only path trace -- is the only path trace component direct lighting? And based on what was mentioned, it seems that indirect path trace lighting is not possible in real-time at this moment.

Yes. I'd say -- I'd answer that with some nuance, so the direct lighting that we have, I would say, fully matches what you get from a path trace lighting solution. The indirect lighting that we have, at the moment, matches many aspects of path tracing because we are using the proper Monte Carlo simulation for the indirect lighting cache that Lumen uses. And many path tracers use a lighting cache very-- along these same lines. So it is doing the proper sort of Monte Carlo simulation on those indirect bounces today. And we have updates coming down the -- we're not done. We have updates and improvements that we are actively working on within the GI sphere right now. In fact, I have to get off of this. I'm going to go review some code changes there. So yes, I would describe path tracing as a spectrum, and it gets a little bit fuzzy towards the edges of the spectrum, like, when it becomes path tracing versus when it doesn't. We're following the right math right now for the indirect lighting as well, so.

All right. I did say that was the last one, but there is one more I squeezed in here if you guys are --wanted to answer it.

Sure.

It's quite general. What's the long-term goal for NvRTX?

Well, that's a good question.

Yes. I mean, I can give my take on what the long-term goal is for NvRTX. So my goal is to eventually make my job irrelevant, right? We always look to get as -- I always look to get as many of these features in a sort of place where Epic would be happy to take them on and have them in the main engine and everybody could have access to them despite being the engine by default. It's always a goal of mine personally to try and produce code that either motivates the engine to move forward or produce code that ends up directly in the engine. And we've actually had several features. NvRTX used to have a lot more features than it presently does because Epic integrated many of them from our branch or did -- alter versions. I mean we're still going to want to push the envelope, do interesting things going forward. So, I mean, I don't think we're anywhere near solving the rendering equation perfectly in real-time yet. So, I mean, I think that there's much more for us to do. But I mean, I still do strive to put myself out of business because updating branches and merchant code is no fun for an engineer, right? I want to go do something interesting.

I like this answer. It's a good answer.

And go to wine and country.

Yes, exactly.

All right. Well, thank you for joining us this month. A lot of really good questions. That's something we really like. We like a room for people who like to chat and ask questions. So thank you for that. Next month, we have our final episode of the year with a special guest, don't want to spill the beans. So tune in for some of our promo material that we put out and announcing who that might be. And I want to thank Evan for joining us. And Richard, again as well perhaps we can probably do another episode at NvRTX because of all the questions and popularity that's been kind of hovering around it.

Yes. So there's a lot of things happening, and the UE5 is still evolving and improving, so yes. there's more -- there are going to be more to talk about for sure.

Well, with that, thanks for joining us this month and hope to see you next month.

Thanks, everybody.

Thanks.