GPU Ray Tracing Performance Comparisons [2021-2022]

[trinibwoy]

All this is tangent to my message. Blackboxing data structures has nothing to do with hardware, how it evolves, or which problems it addresses.
It is the first time GPUs use complex data structures like BVH at all. So there is no history here we could look back at.
RT is not the same as rasterization. We talk about a paradigm shift, something entirely new, requiring to traverse trees. Rasterization is brute force O(1) and simple, RT is work efficient O(log n) and more complex.

Yes RT is more complex than rasterization just like 3D was more complex than 2D. It doesn’t change the fundamental dynamic that narrowly focused hardware provides the necessary performance to enable new features which then evolve over time and gain more flexibility.

Until someone actually demonstrates how additional flexibility on the consoles makes up for lack of raw speed it’s all hand wavy speculation. For all we know the more programmable RT paths on current consoles are even slower than brute forcing it.

 

[DavidGraham]

Tell me some examples of 'subpar on console, but fine on PC'. I payed attention only to Exodus and how it runs even on Series S. That's impressive,

Series X has the following limitations compared to PC: No tessellations, lesser draw distance, less accurate shadows, missing screen space reflections on many materials, Variable Rate shading set to 4X, and most importantly, using less RT than the lowest RT option on PC (several objects discarded from the BVH structure, artifacts .. etc), all while upscaling from 1080p in busy scenes.

Series S is even worse.

 

[JoeJ]

Sorry, I don't see that at all.

It's hard to predict the future. Maybe devs will never care to utilize flexibility. Maybe becasue the tracing perf. is just too low, maybe because they focus on different things... I have no glass bowl either.

So far we've had dozens of console RT titles, 1st party or not, and they all showed the same lackluster performance/visual quality compared to even entry level Turing implementations

I don't say flexibility can compensate for tracing performance (which is what you see).
What i say is: We can get better performance, and we can get LOD for details and further optimization.
But it won't be for free. The price is to respect different HW AS formats, requiring mutations and eventually future patches. It's extra work for developers, and it requires openness and collaboration across IHVs.
If we want realtime RT as efficient as possible, HW acceleration makes this more complicated, not easier. This can't be avoided.
I am willing to pay this price. Do you want maxed out RT, or are you happy with compromised results, even defending them?
What do i need to say to make clear we all pull on the same rope here?

 

[trinibwoy]

BVH build / refit is entirely in software on any GPU. Exposing those data structures won't affect tracing performance at all.
Custom built BVH may hurt or help tracing perf., but effect won't be large in either case.

Yeah that’s precisely the point. End of the day you still need to trace rays so even if your BVH management is hyper optimized you still have to deal with tracing speed and consoles have a significant deficit there. The direct result of this is lower resolution RT effects, fewer rays per pixel or lower roughness cutoffs for reflections on consoles.

 

[xz321zx]

...


I dont call for peasants, or claim shills etc etc. I think if we keep that stuff away things wont escalate as easily. Its just hardware, plastic boxes and circuit boards.

"Its just hardware, plastic boxes and circuit boards."

....aaaaand *drumroll*
"fetishism"

an object believed to have supernatural powers, or in particular, a human-made object that has power over others. Essentially, fetishism is the attribution of inherent value, or powers, to an object.

 

[JoeJ]

Just like the argument of compute RT vs hardware RT, which manged to prove how superior the hardware RT approach is: UE5 demo runs barely 1080p60 on a frigging 3090 while doing only a somewhat limited form of GI, contrast that to the implementation of Metro Exodus, which does full GI simulation + reflections, and it runs 1440p90 on the same 3090.

Not sure if i agree, but imo Lumen is not really that great.

We are back to the same circular RT arguments form 3 years ago, hardware RT is not needed

No, i am not!
Three years ago i doubted HW RT is a good idea, because of all that problems coming form hiding most important data structure.
Now i propose to fix those problems, so HW RT becomes useful in context of next gen geometry.

What anybody thinks about software vs. fixed function is completely irrelevant for my current point. We have no reason to disagree on anything, and it's beyond me why we still do.

 

[CarstenS]

Quite telling whenever a 2060 needs to be used to gauge ps5 rt abilities. And even in that case id say the 2060 has the option to give superior results, see DF Doom Eternal pc (2060) vs ps5 analysis. 2060 is a 6.4TF gpu launched more than 3 years before the ps5.

Might wanna check the dates...

 

[CarstenS]

I'm not a game developer but the last 30 years of 3D graphic hardware proved you are wrong. Over and over, it's the same story, for every feature, hardware acceleration enables what was/is impossible to do in realtime by software (with maybe the exception of S3D broken Savage2000 T&L)
It's always like that:
1- Software is too slow
2- dedicated Hardware acceleration comes to enable it
3- depending on the feature, dedicated Hardware moves to general compute block, when the overall processing power increases enough to absorb the performance penalty.

It's never the other way around. Never

One could argue, that once upton a time, there were Video features running on the shader core, which went back into dedicated hw-blocks. But in general, I tend to agree here.

 

[DavidGraham]

But it won't be for free. The price is to respect different HW AS formats, requiring mutations and eventually future patches. It's extra work for developers,

On that note, the developers of Metro Exodus has this to say about their console implementation, it's a headache to keep up with the SDK changes.

due to the specific way we utilize Ray Tracing on consoles, we are tied to exact formats for the acceleration structures in our BVH: formats that were changing with almost every SDK release. Constant reverse-engineering became an inherent part of the work-cycle.

They also overestimated the RT capabilities of the consoles, they later adjusted and halved their ray per pixel count.

The first frames running on actual devkits revealed that we had been somewhat overly optimistic in our initial estimations of the expected Ray Tracing performance. That was not really an issue though as denoiser’s frontend (it’s temporal accumulation component) had already been made scalable, allowing for any resolution input while still running at full resolution itself. We halved per-pixel ray-count ..

https://www.4a-games.com.mt/4a-dna/...upgrade-for-playstation-5-and-xbox-series-x-s

 

[CarstenS]

Although i use VK myself, i do not check for updates that often, but there are no real differences to DX12. No extension to expose AMDs intersection instructions, and nothing to expose BVH either.
AFAIK, AMD has some other work to do, e.g. RT on Linux does not work at all yet. And i assume NV would prefer to keep things black boxed, so adding more HW specialization / changing BVH data structure remains easy.

That's a shame. Being able to demonstrate superior features would greatly help their timely adoption. So, in a way I understand Nvidia, if they're planning to evolve and abstract their RT core to an extent, but AMD, if it has an advantage, they should be eager to show it.

 

[DavidGraham]

One could argue, that once upton a time, there were Video features running on the shader core, which went back into dedicated hw-blocks.

Yeah, that's an interesting point, worth pondering the reasons why this happened .. maybe the dedicated blocks were so cheap?

 

[JoeJ]

Yes RT is more complex than rasterization just like 3D was more complex than 2D. It doesn’t change the fundamental dynamic that narrowly focused hardware provides the necessary performance to enable new features which then evolve over time and gain more flexibility.

Once more: My requests are tangent to the argument of HW acceleration. I talk about data, not the processing of it.
This is my data, and i want to access, modify, and generate it.
A driver can not do this, until we all would converge on just one best for all needs LOD solution.

I don't care how the traceRay function is implemented, which is what HW acceleration is about. And i do not request traversal shaders, because this would disable HW acceleration of said function. Also i do not request 'programmability' of anything.
It's just about data.

 

[JoeJ]

Series X has the following limitations compared to PC: No tessellations, lesser draw distance, less accurate shadows, missing screen space reflections on many materials, Variable Rate shading set to 4X, and most importantly, using less RT than the lowest RT option on PC (several objects discarded from the BVH structure, artifacts .. etc), all while upscaling from 1080p in busy scenes.

Series S is even worse.

Yeah that’s precisely the point. End of the day you still need to trace rays so even if your BVH management is hyper optimized you still have to deal with tracing speed and consoles have a significant deficit there. The direct result of this is lower resolution RT effects, fewer rays per pixel or lower roughness cutoffs for reflections on consoles.

Just the usual gradual scaling on all ends as expected. That's not the binary limitations i talk about.

 

[PSman1700]

Series X has the following limitations compared to PC: No tessellations, lesser draw distance, less accurate shadows, missing screen space reflections on many materials, Variable Rate shading set to 4X, and most importantly, using less RT than the lowest RT option on PC (several objects discarded from the BVH structure, artifacts .. etc), all while upscaling from 1080p in busy scenes.

Series S is even worse.

What i have been trying to say, other (non RT settings) have to be paired down to enable it to run some reduced quality ray tracing effects. Aside from a much lower resolution overall, ofcourse.

It's hard to predict the future. Maybe devs will never care to utilize flexibility. Maybe becasue the tracing perf. is just too low, maybe because they focus on different things... I have no glass bowl either.

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

What do i need to say to make clear we all pull on the same rope here?

You did state the PC ray tracing wasn't ahead of the consoles, which it cleary is, by heaps and bounds. Even AMD's own pc RDNA2 is ahead.
Shall i say, pc ray tracing in hardware is ahead of console ray tracing. If software will hold it back, thats not what were seeing today atleast, its a wild guess it will in the (near) future,

Might wanna check the dates...

I see, more then two years it is I wrote somewhere else 2018 on this page i think.

 

[CarstenS]

Yeah, that's an interesting point, worth pondering the reasons why this happened .. maybe the dedicated blocks were so cheap?

Power mostly, I guess. Early shader blocks could not even be power or clock gated, AFAIR.

 

[HLJ]

Once more: My requests are tangent to the argument of HW acceleration. I talk about data, not the processing of it.
This is my data, and i want to access, modify, and generate it.
A driver can not do this, until we all would converge on just one best for all needs LOD solution.

I don't care how the traceRay function is implemented, which is what HW acceleration is about. And i do not request traversal shaders, because this would disable HW acceleration of said function. Also i do not request 'programmability' of anything.
It's just about data.

Once again:
How does the "extra flexibility/programmability" translate to the real world?
Nothing shown on the consoles leand any credence to your claims.

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").
The gap between RT on the PC space vs the console is already HUGE.
In 2 years it will be EVEN bigger disparity
In 4 years it will be amusingly bigger disparity.

And you think "flexibility" will magically create parity/advantage for the console...madre mia.

 

[JoeJ]

That's a shame. Being able to demonstrate superior features would greatly help their timely adoption. So, in a way I understand Nvidia, if they're planning to evolve and abstract their RT core to an extent, but AMD, if it has an advantage, they should be eager to show it.

Yeah, for AMD it would be very little work to expose their intersection instruction to compute. After that, one like me could even completely bypass DXR and do some fancy research.
But market share is small, so they know nobody would use those extensions in practice. And their software division is small too. OpenGL support on AMD is still problematic, people say.
And finally, AMD listed optional HW unit for traversal loop in their TMU patent. Maybe Sony / MS preferred the lightweight / flexible approach of intersection instructions over a full RT Core like NVs. So it did not made it into RDNA2, but 3 might get it.
After that, compute traversal + intersection instruction would still work i guess, but rarely makes sense to use due to inferior performance. If it's anyhow like that, the potential higher flexibility on AMD is just temporary and not worth to utilize in practice.

So, focus on exposing BVH should be the focus IMO.
Actually i feel a bit like Edward Snowden, telling people they should claim ownership of their data, while mega corps store and trade it behind their back. Quite freaky...

"fetishism"

It's the first time for me to be engaged in a Glorious PC Masterrace vs. Console Warriors debatte. And i even ignited it myself by accident.

Lesson learned: Never mess with men about their toys

 

[PSman1700]

Maybe Sony / MS preferred the lightweight / flexible approach of intersection instructions over a full RT Core like NVs.

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

 

[Davros]

PC Masterrace

Just like to point out for future reference its "GLORIOUS PC Masterrace" the GLORIOUS is important.....

 

[PSman1700]

Just like to point out for future reference its "GLORIOUS PC Masterrace" the GLORIOUS is important.....

Goes to show what his original problem is, imo.