GPU Ray Tracing Performance Comparisons [2021-2022]

[JoeJ]

And if your argument is that "PC DXR is an ugly brutforce-hack" you will be very sad the longer time goes by if you think DXR performance on PC is going to not increase (even if we play to your "bruteforce argument").

That's not my argument, no.
And as said, increasing DXR perf., even if for both build and traversal, has nothing to do with my argument and won't fix the issues.
Even a 5090 won't be adle to rebuild all UE5 geometry per frame. Period.
So either you side my requests, or you are happy with low detail proxies for raytracing, still causing unnecessary building costs. It's that simple.

 

[PSman1700]

Even a 5090 won't be adle to rebuild all UE5 geometry per frame.

So wont your PS5.

 

[HLJ]

That's not my argument, no.
And as said, increasing DXR perf., even if for both build and traversal, has nothing to do with my argument and won't fix the issues.
Even a 5090 won't be adle to rebuild all UE5 geometry per frame. Period.

So before we can do a perfect universe simulator (Specifically in UE5) with same fidelity as real universe...RT is a wash is what I read you write.

So either you side my requests, or you are happy with low detail proxies for raytracing, still causing unnecessary building costs. It's that simple.

I would not be happy with console I.Q., hence I game on PC.
Some people do not have a problem with lesser I.Q. no problem.

Are you still claiming better RT on consoles....because if so, I am done with you...as I work in the real world, not "fantasy-what-if-with-demands-for-UE5-to-set-arbitary-goals."

 

[HLJ]

So wont your PS5.

It struggles already to day on lesser settings/I.Q than the PC...someone is not living in the real world...

 

[PSman1700]

It struggles already to day on lesser settings/I.Q than the PC...someone is not living in the real world...

And thats the thing, its all theoretical assumptions. Consoles generally have always enjoyed a lower level API access/closer to the metal, nothing really knew and probably applies to ray tracing aswell. The best use-case is to then look at real world examples of whats happening, usually like for like comparisons, ie AMD rdna2 dGPU vs the PS5 version doing ray tracing.
What we there then see is ray tracing actually running better on the amd dGPU part as opposed to the console version. If software is holding back RDNA2 on pc so much, then why is it performing better than the PS5?

Ampere is totally playing in a league of its own, to no real surprise, on a different architecture etc etc.

 

[JoeJ]

Your guessing, were looking at what we have today, the results. Anyway, whos to say pc RT isnt (going to be) 'flexible'?

Correct. I guess UE5 (dynamic) detail becomes the future standard.
If i'm wrong with that, the limitations still apply, but are no big problem in practice.
If i'm right, maybe still devs are happy with low poly proxies for RT, causing extra runtime building costs, and extra runtime memory costs, missing the advantages of 'scale geometry resultion to what we actually need'.

The latter point is currently the only option. We could do that, don't talk about its shortcomings, and let gamers compensate the losses with paying for better hardware.
IMO that's not acceptable, also because higher HW specs means to sell less games.

 

[Dictator]

Correct. I guess UE5 (dynamic) detail becomes the future standard.
If i'm wrong with that, the limitations still apply, but are no big problem in practice.
If i'm right, maybe still devs are happy with low poly proxies for RT, causing extra runtime building costs, and extra runtime memory costs, missing the advantages of 'scale geometry resultion to what we actually need'.

The latter point is currently the only option. We could do that, don't talk about its shortcomings, and let gamers compensate the losses with paying for better hardware.
IMO that's not acceptable, also because higher HW specs means to sell less games.

Hmm.. Using this logic you should have a very negative stance Visavis AMDs RT implementation and Performance which scales poorly.
Gamers buying AMD consoles or GPUs are paying more for RT performance due to the Lack of acceleration.

I imagine the bigger performance sink in RT currently is not the Lack of specific programmability in the API but the actual cost of shooting, traversing, and shading, and denoising - which is just slower on AMD. I asked a developer who worked on a Premiere game people have lauded for its RT implementation about greater API flexibility - And their response was that they wanted more and faster rays and less time micromanaging and creating optimisation paths.

What is more conducive to production?
Spending time squeezing the rocks with optimisation and platform specific quality reductions or having features work with reliable performance with less pit falls but im a more automated fashion?

 

[JoeJ]

Highly doubt that AMD held itself back due to PS5. Sony had to choose from the AMD inventory they had.

It's not necessarily a 'held beck'. Full RT core take more die area, so there are losses on other ends. If there was such decision, it surely was not easy. They can simulate HW, but they can't predict adoption / utilization in games in detail. They have no glass bowls either.
Notice AMD makes chips on the customers specific requests. Rumors Console makers had influence on RDNA architecture are surely true to some unknown extent.
Mentioning traversal HW in patent means they likely did such simulations / considerations, but ofc. idk.

 

[PSman1700]

Rumors Console makers had influence on RDNA architecture are surely true to some unknown extent.

And this single comment renders the rest of all your findings very unreliable imo. I mean comon, not that crap again.... seriously.
AMD's ray tracing venture started later, they design their products and MS/Sony have the option to costumize things somewhat, and thats about it.

It's not necessarily a 'held beck'.

AMD is behind in the RT game, and its sure that hasnt got anything to do with Sony. AMD would never, ever hold themselfs back against their competitors just because sony wanted a weaker solution somehow.
If Sony could stuff a 6800XT GPU with full rdna2/IC features, they would (much more capable RT performance), if they could stuff a 3070 in there at the same heat/die/bom etc, they certainly would.
It is what it is, they are partnered with AMD and had to choose the best for their console in there, perhaps some customizations have been made for the specific console.

 

[JoeJ]

Hmm.. Using this logic you should have a very negative stance Visavis AMDs RT implementation and Performance which scales poorly.

Very hard question. On one hand i like AMDs option to have programmable traversal, because it might help with solving LOD.
On the other hand, i see no other benefit of programmable traversal, and fixed function is much faster.
If i had to decide now, i would take the fixed function approach. But this means closing doors to other ideas we might not know about yet.

I imagine the bigger performance sink in RT currently is not the Lack of specific programmability in the API but the actual cost of shooting, traversing, and shading, and denoising - which is just slower on AMD.

Let's refine this:
Shooting + traversing is one thing, and the only one where AMD / NV HW differs.
Shading and denoising is entirely general purpose CU / SM work. I doubt AMD has a disadvantage here. In the past, general compute perf was alwasy better on AMd, up to GCN vs. Pascal. No experience after that. But AMD looses no space for full RT cores / tensors, so i expect they have the edge here.
Also, look at offline raytracer results. RTX on often gives only a speedup of 2 vs. RTX off. Which tells us a thing accelerating the traceRay function helps less with net performance than we would expect. Just saying.
Ofc. all this ignores out current topic of BVH building costs.

I asked a developer who worked on a Premiere game people have lauded for its RT implementation about greater API flexibility - And their response was that they wanted more and faster rays and less time micromanaging and creating optimisation paths.

In short: They want the easy path. Offloading all problems to IHVs, which worked well for decades.
Sadly, we can no longer do this once we tackle hard problems such as LOD, which is both about decreasing power and increasing detail. So we need to go there, sooner or later. And if we want to compete Epic, it's sooner.
Notice the work here is mostly on the tools side. It will affect content creation workflows and costs in both good and bad ways. The extra work on runtime engine like supporting multiple vendor BVH formats is not really relevant in comparison. And the revolution won't happen in one day.
So i really talk about long term goals, but currently it's not possible to plan this well, due to uncertainties related to RT. This is a form of 'holding back' developers, while not visible to end users any time soon.

 

[Ethatron]

I asked a developer who worked on a Premiere game people have lauded for its RT implementation about greater API flexibility - And their response was that they wanted more and faster rays and less time micromanaging and creating optimisation paths.

I, as a developer, also want an infinite fast magic holo-device working with Tachyons.
The hardware is fixed, it's deployed, it can't be remotely reprogrammed, is is what it is. And dealing with that is the bread and butter of a considerable portion of employment. The software on the other side isn't fixed. The same way JoeJ is bitching about the RT API, people in that line of work are bitching about OpenGL or Vulkan or OpenCL or CUDA or DirectML or DirectX or any other abstraction.
I've considerable time spend with consoles, and bitching about e.g. GNM or AGC is the rarest of occurences, it'S rather satisfying and frees my mindspace for the real problems. Not being able to deliver on performance and at the same time knowing you leave performance or capability unutilized because of the software concept is stressful. If the stress vents itself in an API rant, then this is perfectly fine and acceptable and doesn't deserve chastisement.
Please, remind yourself that there are many points of views, and many different foci. And the experiences are different and shape different opinions and cause different levels of stress. These people are exposing themself to this also to please you guys.

So, please, if there is a divergence of opinion, or an imperfection of language, or whatever, just let it stand, and be respectful. Thank you.

 

[HLJ]

By these arguments...DirectX was a failure.
How "bad" was DX1 compared to DX12U?
Apply the same "fuzzy" logic to DXR...potato, potato...

Some people need perspective.

 

[CarstenS]

Going back two decades, we had two generations of fixed function hardware TnL, before some more configurability was introduced and full programmability came even later. Maybe it will be the same with RT. A few generations with limited functionality just to get developers accustomed to and establish best practices all the while building an installed hw base. Then expanding RT into more flexible approaches while at the same time the compute part might be fast enough so we can do away with hybrid approaches.

 

[HLJ]

Going back two decades, we had two generations of fixed function hardware TnL, before some more configurability was introduced and full programmability came even later. Maybe it will be the same with RT. A few generations with limited functionality just to get developers accustomed to and establish best practices all the while building an installed hw base. Then expanding RT into more flexible approaches while at the same time the compute part might be fast enough so we can do away with hybrid approaches.

That is the way it will go.
Someone just want EVERYTHING yesterday...and totally lack perspective.

DirextX API and GPU's show the way things evolve.
But someone wants to start with DX12U...not DX1...but that is not how reality works...sigh.

 

[troyan]

Do not understand the discussion. Developers are free to implement their own raytracing since years.

 

[trinibwoy]

If i had to decide now, i would take the fixed function approach. But this means closing doors to other ideas we might not know about yet.

We understand the theoretical long term benefits of flexibility. The problem is your assertion that current console hardware is "better" while ignoring that it is significantly slower.

How can it be both slower and better at the same time in actual usage?

 

[Scott_Arm]

Do not understand the discussion. Developers are free to implement their own raytracing since years.

I also don't understand the discussion. Are people really against offering more programmable hardware? I see the consoles as having more flexible APIs in the RT space, even if the differences are fairly small. Like if DXR1.2 comes out and allows developers to write some kind of custom traversal, are people going to argue against it? Like, asking people to prove programmability is good is kind of weird.

 

[JoeJ]

Do not understand the discussion. Developers are free to implement their own raytracing since years.

I guess you do understand software RT can not compete HW performance, so that's no satisfying solution.

The problem is your assertion that current console hardware is "better" while ignoring that it is significantly slower.

Current console API is better, not HW. Console perf. being less than high end PC is nothing new and can be scaled as usual. It's not relevant to the API topic at all.

Going back two decades, we had two generations of fixed function hardware TnL, before some more configurability was introduced and full programmability came even later. Maybe it will be the same with RT.

Maybe. But back then there was no other data than textures, vertices, indices. Simple arrays, and when compute came up, modifying those arrays became possible, together with indirect draws.
Now we already have compute (thus 'programmability' is already there), we introduce RT and new related data, but this time the data is hidden. So it's not a repetition of history but just a step backwards, ignoring the things we have learned in mentioned history.
HW is fixed, so there is no reason to hide data which at its lowest level won't change per architecture. Opening it, IHVs can still update their building algorithms and extra data they might store or not.
No losses for anybody. No forced increase in complexity either. Nobody has to build his own BVH if he does not want to, just because it's possible for those who need it.

Good then. Time will tell.

Some people need perspective.

Guess we all do. Take it or leave it, i'm out of this for some while.

 

[iroboto]

I also don't understand the discussion. Are people really against offering more programmable hardware? I see the consoles as having more flexible APIs in the RT space, even if the differences are fairly small. Like if DXR1.2 comes out and allows developers to write some kind of custom traversal, are people going to argue against it? Like, asking people to prove programmability is good is kind of weird.

I don't think people are against customization at the lowest possible of levels. I think the debate is around perspective of what needs to arrive first: faster generic speed, at the cost of customization, or slower generic speed with customization.

As many have stated earlier, hardware TnL is how we started before moving to compute. I mean admittedly, a lot of games still leverage the 3D pipeline even though compute exists. So there is some benefit (to teams) to having a faster fixed function pipeline (as an option) I suspect, even though I believe in fully compute based engines. And in the same path, I believe RT does in fact need to go in the direction of generic compute over time. I think the debate is whether it needs to move there at the starting line, or to go there over time. As @JoeJ ends here, we took our learnings already from compute so why take the step back. I definitely see the argument from both sides, and imo there is no clear winner here that I can see, perhaps it just comes down to preference.

Perhaps it's not for us to debate, this is probably something that IHV may need to chime in. Nvidia knows precisely why they went one route, AMD another, and MS attempting trying to create an API to support all IHVs. I wish Max McCullen was still here, perhaps he could chime in.

 

[troyan]

I also don't understand the discussion. Are people really against offering more programmable hardware? I see the consoles as having more flexible APIs in the RT space, even if the differences are fairly small. Like if DXR1.2 comes out and allows developers to write some kind of custom traversal, are people going to argue against it? Like, asking people to prove programmability is good is kind of weird.

More programmable than the "normal" cores? So a second full programmable co processor just for raytracing?