Raytracing on AMD’s RDNA 2/3, and Nvidia’s Turing and Pascal

https://chipsandcheese.com/2023/03/22/raytracing-on-amds-rdna-2-3-and-nvidias-turing-and-pascal/

100 31 3 years ago

pixelesque• 3 years ago

I suspect the reason the author is seeing very shallow trees for Nvidia might be because the lower levels are done fully behind the scenes:

https://forums.developer.nvidia.com/t/extracting-bvh-from-op...

As someone who deals with BVHs a lot for ray intersection, I find it pretty difficult to believe that leaf nodes with that number of primitives will be anywhere near performant, even with fast dedicated hardware like the RT cores.

It's true that the Nvidia cards have better intersection performance than ray/box tests, but I don't believe it's in the 100x ratio range which I suspect would be needed if the BVHs were that shallow and leaf nodes that large.

frogblast2• 3 years ago

I strongly suspect the reason Nvidia trees are so shallow is that NSight simply isn't showing the actual tree structure, probably because Nvidia considers that proprietary. It appears to just list all the leafs of a tree in a big flat list. But there definitely is a tree in there.

Arrath• 3 years ago

I'm very curious to see it unrolled down to its actual structure.

kevingadd• 3 years ago

Perhaps the rest of it isn't a tree and is some other optimized data structure? Like some sort of spatial hash or sort

sounds• 3 years ago

Since cache hit ratios are so central to fast GPU code, the tree structure doesn't have to be exotic, likely the secret sauce is how it performs in the caches.

graffix• 3 years ago

At work I inherited a raytracer codebase with a severe memory bloat problem on terrains. The size of terrain BLASes is precisely what one would expect from a bog-standard BVH with branch factor 2, so I'm sure you're right.

This is on Turing. Nvidia would've been motivated to de-risk the introduction of RTX by making boring choices. You may well see different results on later archs.

TinkersW• 3 years ago

Isn't wide BVH how embree works, 1 ray vs SIMD width boxes.. maybe Nvidia is simply doing the same thing but with the wider GPU SIMD(32 I believe).

berkut• 3 years ago

Yes, but normally 4- or 8-wide is the norm: the wider you go the more sorting you have to do to traverse things in order or find the nearest hit which has an overhead (hardware may help with this, but it's still an overhead).

Previous indications from Nvidia about their BVHs don't seem to show anything about very shallow trees for any of the BVH algorithms that OptiX supports (scroll to bottom for reverse visualisation of a BVH hierarchy on top of the Stanford Bunny model): https://drive.google.com/file/d/1B5fNRFwv2LsGlCBJ8oKYRiiDUtL...

matthewfcarlson• 3 years ago

I've often wondered why Nvidia cards are generally so much better at rendering scenes in Blender's cycles renderer (a raytracing engine). The benchmarks on Blender's website are really telling (https://opendata.blender.org/benchmarks/query/?group_by=devi...) by the fact that the only non Nvidia entry on the first page is the AMD 2X EPYC 9654 96-Core.

This really lays out the decisions that Nvidia made compared to AMD and how their approach tends to hide some of the shortcoming of GPUs (latency and utilization).

zokier• 3 years ago

That is more of a software (ecosystem) thing. Nvidias CUDA and OptiX are well beyond anything AMD has to offer. In Cycles case, I believe that on Nvidia it is taking good advantage of RT cores while on AMD they are completely unused which has predictable effect on performance. Even ignoring the RT cores I suspect the Nvidia code path is likely far more optimized than AMD one

https://www.phoronix.com/news/AMD-HIP-RT-Blender-3.5-Plans

dotnet002• 3 years ago

Plus on AMD's side we have their inability to commit to fully supporting any specific system long term, limiting open source interest in doing things for them.

ladberg• 3 years ago

Would love to see a more in-depth article on BVH construction itself! I'm decently familiar with the main concepts but have no clue what the current SOTA looks like (is that even public info?).

BVH construction is my favorite question to ask in interviews because there's no single best solution and it mostly relies on mathy heuristics to get a decent tree. You can also always devote more time to making a more optimal tree but there's a tradeoff where it'll eventually take more time than it saves in raytracing.

frogblast2• 3 years ago

This is the best I've found that covers recent developments:

https://meistdan.github.io/publications/bvh_star/paper.pdf

sylware• 3 years ago

I did not get into the real details yet, but mesa radv pulls that horrible glslang due to some shaders related to acceleration structures.

Personnaly, I am a dev, then I patch to compile out all that (and all the tracers at the same time) since ray tracing has currently a ridiculous ratio benefits/technical costs.

This defeats the very purpose of vulkan spirv: getting rid of those horrible high level shader compilers from the driver stack and keep them contained at the application level.

It seems beyond clumsy, but as I said, I need to get into the details of "why" those shaders in the first place, and then why they are not written directly in RDNA assembly or SPIR-V assembly (that would require an "assembler" coded in simple and plain C).

TazeTSchnitzel• 3 years ago

Generating a ray tracing acceleration structure is very complex, who'd want to implement that in assembly language?

br1• 3 years ago

Interesting that card/drivers customize so much of ray tracing, like rasterization in pre vulkan/metal/d3d12 or even fixed function gpu days.

shmerl5• 3 years ago

Ray tracing on Linux for CP2077 with 7900 XTX is still barely usable, but it's getting better.

I'd say RDNA 3 is not really giving useful ray tracing on for example 2560x1440 unless you use upscaling to speed it up. May be in a few GPU generations ray tracing will become usable with native resolutions.

newZWhoDis• 3 years ago

It’s more than usable today on Nvidia

shmerl5• 3 years ago

I doubt it, unless you use upscaling there as well. I'd take higher framerate without RT at native resolution over RT with upscaling.

Raytracing on AMD’s RDNA 2/3, and Nvidia’s Turing and Pascal

Related Stories