GPU Ray Tracing Performance Comparisons [2021-2022]

[manux]

I wonder how much you can optimize RT for Rdna2, or Ampere, on PC where direct x/rt is limiting what you can do anyway... Invisible RT is not an optimisation...

I don't believe dxr is limiting optimizations too much. Mainly the BVH building/optimization is black box. That is anyway very hw specific. I doubt anyone sane would want to write their own BVH implementations for every hw if alternative is that it just works and gpu vendor does this optimization for you(for free). It's different on console exclusives though.

You can for example check presentation below and consider how much tricks developer figured out when implementing RT for shadows only. Something like metro exodus enhanced edition likely has much more extensive optimization and design in engine to support RT efficiently.

https://twitter.com/x/status/1318267819243483138

Where I think it gets messy is considering that amd reuses tmu's and compute for RT whereas nvidia has independent accelerator. This leads to situation where ray tracing in nvidia HW can be treated similar to async compute where as amd cannot. In essence nvidia hw can fill bubbles with RT whereas in amd hw one wants to find out slots where tmu/compute goes unused and fit the RT load there.

 

[Rootax]

I remember devs saying how much dxr was limited (even compared to the one on xbox), so...

 

[manux]

I remember devs saying how much dxr was limited (even compared to the one on xbox), so...

The part that is limited is also super hw dependent. It would be enormous effort to tackle that black box called BVH building and traversal today. If you check that modern warfare presentation for example there is a ton of better avenues to optimize versus opening up the BVH black box.

Part of the limitation can be also hw itself. RT is pretty new and close to fixed function still. Likely in future we will see more flexible hw and API but that time is not yet.

edit. Another way of saying same is that pushing even more work for developers would make ray trace adoption go even slower. It makes sense to start with easier high level API and once that is exhausted seek lower level api. Yet another way of saying same is we had so high hopes for dx12 and then we found out it's a rare developer that can do real good quality dx12 implementation across all hw.

Biggest optimization one can do today is to figure out which rays are most important and cast only them. Another one is how to reuse results from previous frames. Both items are doable with DXR.

 

[DavidGraham]

TPU Ray Tracing Test for Resident Evil 8, the 3090 is 20% faster than 6900XT.

https://www.techpowerup.com/review/resident-evil-8-village-benchmark-test-performance/6.html

 

[techuse]

Much better and more reasonable use than the majority of Nvidia sponsored implementations.

 

[P_EQUALS_NP]

hi, I may be a humble compiler dev, but I still don't understand why Microsoft defined the DXR BVH to be so transparent? they could have have defined a fixed radix factor for the tree and a maximum tree depth for the supported hardware. from my understanding, this would lead absolutely insane speed ups vs a black box driver call, and with only 1 fixed parameter supported a large array of hardware?

 

[Remij]

Much better and more reasonable use than the majority of Nvidia sponsored implementations.

Huh?

 

[Dictator]

Much better and more reasonable use than the majority of Nvidia sponsored implementations.

Have you seen the quality? Not sure if I would say that if you see the quality of the reflections

 

[Tarkin1977]

TPU Ray Tracing Test for Resident Evil 8, the 3090 is 20% faster than 6900XT.

https://www.techpowerup.com/review/resident-evil-8-village-benchmark-test-performance/6.html

14% according to Computerbase

 

[Lurkmass]

Have you seen the quality? Not sure if I would say that if you see the quality of the reflections

The results might be somewhat ambiguous without knowing the developers true intentions. What if the developers intended for materials to have a more glossy surface rather than a mirror like reflection ? In the case of the former, we can get plausible outcomes by just tracing either 1 or 2 rays per quad (4 pixels) as shown in here. Full-rate ray tracing is only an absolute necessity when we need to resolve detailed reflections for mirrors ...

When we're thinking about "reflection quality", the clarity of our reflections doesn't necessarily have to be limited by the amount of rays we trace since material properties like roughness comes in to play as well ...

 

[Dictator]

The results might be somewhat ambiguous without knowing the developers true intentions. What if the developers intended for materials to have a more glossy surface rather than a mirror like reflection ? In the case of the former, we can get plausible outcomes by just tracing either 1 or 2 rays per quad (4 pixels) as shown in here. Full-rate ray tracing is only an absolute necessity when we need to resolve detailed reflections for mirrors ...

When we're thinking about "reflection quality", the clarity of our reflections doesn't necessarily have to be limited by the amount of rays we trace since material properties like roughness comes in to play as well ...

It is about the intense pixelisation pattern in all reflections in the game, as well as the instability of the denoiser - whether the reflection is mirror like or diffuse due to the material. They made sure everything was very cheap for sure and it shows - unfortunately there is not a good way to increase quality at all to avoid the issues - the highest settings are like the low of another game.

 

[techuse]

Huh?

Performance hit is much more reasonable for the improvements on offer. I find GI a far more useful improvement than shadows or reflections that cut your framerate to 1/2 or 1/3rd like in most Nvidia sponsored implementations.

 

[DavidGraham]

Much better and more reasonable use than the majority of Nvidia sponsored implementations.

Nope, as usual in most AMD sponsored RT titles, the actual RT is balanced so it doesn't embarrass AMD. Not because of image quality reasons.

Reflections are missing half the objects in the game, GI is also limited, and is comparable to the limited UE GI used in several NVIDIA UE4 sponsored titles, however at least in those titles you are getting good RT reflections, and not the low effort found here.

Performance hit is much more reasonable for the improvements on offer

It's not reasonable on AMD hardware still, fps are cut by 1/3 on their hardware despite the effects being cheap.

 

[Lurkmass]

It is about the intense pixelisation pattern in all reflections in the game, as well as the instability of the denoiser - whether the reflection is mirror like or diffuse due to the material. They made sure everything was very cheap for sure and it shows - unfortunately there is not a good way to increase quality at all to avoid the issues - the highest settings are like the low of another game.

If materials were diffuse then we wouldn't need to trace any reflection rays at all because diffuse surfaces naturally have no specular reflections! How can you truly know for certain if the developers aren't setting a relatively high roughness parameter value for their materials ? My argument is that we can't actually know for certain if the output is generated due to the number of rays traced or if it's down to the materials themselves because glossy reflections will inherently have blurry specular reflections ...

When we're using ray tracing for diffuse surfaces, is the 'quality' or the absence of the specular reflections coming down to the property of the material itself or that we're just not tracing enough rays ?

 

[DegustatoR]

Has there been any info released on what this GI even is?

 

[DavidGraham]

My argument is that we can't actually know for certain if the output is generated due to the number of rays traced or if it's down to the materials themselves because glossy reflections will inherently have blurry specular reflections ...

Even on water and glass, reflections are horrible.

 

[Dictator]

Has there been any info released on what this GI even is?

It looks similar to what remedy did with its "near light field diffuse GI" - but with a lot more screen-space re-use. It applies to non-shadow casting and shadow casting lights, not emmissive surfaces or anything. Since it does it to non-shadow casting lights, you can see bounce light bleed through objects rather often.

 

[Lurkmass]

Even on water and glass, reflections are horrible.

Without truly knowing each material's properties, we're virtually left speculating the on developers intent. I haven't seen many water or glass surfaces either in the demo ...

 

[JoeJ]

I remember devs saying how much dxr was limited

AFAIK it was Karis who noticed missing LOD support on DXR announcement. Now we know why he asked. : )

The part that is limited is also super hw dependent. It would be enormous effort to tackle that black box called BVH building and traversal today.

Opening traversal is probably not possible for NV.

But opening BVH is possible, and i don't see why waiting for even more HW architectures to come up should make this opening easier in the future. The earlier it happens, the better.
It is also the main limitation. Currently we are limited to static topology, so the existence of DXR actually prevents or at least restricts progress towards a solution of the LOD problem.
You can argue actual games do well without that, but larger worlds and increasing detail is a trend not going to stop. It is there since video games exist and it defines their evolution to a large degree.

edit. Another way of saying same is that pushing even more work for developers would make ray trace adoption go even slower.

This depends. Having spatial acceleration structure is also useful for occlusion culling, physics or other things. Black box forces to have multiple acceleration structures, increasing not only memory and performance requirements, but also adding more work to the developer, not reducing it.

Biggest optimization one can do today is to figure out which rays are most important and cast only them. Another one is how to reuse results from previous frames. Both items are doable with DXR.

That's obvious optimizations. Their existence does not justify restrictions elsewhere, and what's most important is speculation not fact.

Your points make sense, currently and for most applications. The problem is the current solution is shortsighted. If we had a BVH API, this still remains optional to be used or not. Things can still remain simple, and adoption would not suffer.

 

[iroboto]

hi, I may be a humble compiler dev, but I still don't understand why Microsoft defined the DXR BVH to be so transparent? they could have have defined a fixed radix factor for the tree and a maximum tree depth for the supported hardware. from my understanding, this would lead absolutely insane speed ups vs a black box driver call, and with only 1 fixed parameter supported a large array of hardware?

Probably because they wanted it ultimately to stay in the hands of the IHV to determine what would be best for them. And what may be better today may not necessarily be better for their IHV tomorrow. Though I’m not sure honestly.