He also mentions tracing performance is important. So the real question is does the additional flexibility make up for raw speed.
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.
DXR already supports partial BVH updates. You only need to rebuild the BLAS for deformable or breakable objects. You can also run BVH updates in parallel with other GPU work. So it’s not obvious that additional flexibility will bring huge gains on today’s hardware.
Ten years ago i have proposed the same TLAS / BLAS strategy to people when they said 'Building AS is too expensive, so we can not do raytracing in realtime'. Back then i thought myself this strategy solves the problem in practice.
It's quite ironic it's me again now who hits a wall here. As soon as we add continuous LOD, the two level strategy does no longer work. It's not fine grained enough. We need to edit the leafs of BVH, by either removing them to decrease detail, or adding children to increase detail. With DXR, even changing just one patch of surface from a static model, we need to rebuild the
whole BVH. Refitting is not possible because of the changes on the leafs. Notice refitting up the hierarchy is not even necessary on the static model - we only need to make some changes on the leafs, nothing else.
Rebuilding the whole tree ofc. is no option because horribly inefficient. Thus DXR completely prevents
any form of fine grained LOD, which is a primary open problem in computer graphics.
Just for clarification JoeJ, you are talking about DXR, not about Vulkan RT extensions? Is there something that's keeping IHVs from exposing their additional features there?
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.
They would probably use offline BVH creation too for current Nanite version because this is only static geometry.
The storage cost would be very high. Ideal case would be to have only one AS, shared for both LOD magament and RT. Nanites cluster hierarchy could eventually work, with some changes to ensure it suits RT demands. At runtime, they could so convert this LOD hierarchy into RT BVH, adding some more levels to have only N triangles per leaf instead 100. Adding those levels would be efficient within a single compute workgroup.
So pulling this off is some serious work, but on the long run clearly to way to go.
Show me...because every single game using RT on the consoles have been subpar to the PC implementation.
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, because on PC we do not even have a RT GPU with such low specs.
You do not want to compare Series S vs. RTX 3090, i guess? And even if we did, that's about performance only, not about 'implementation'.
Also, please notice current games have no continuous LOD yet. UE5 is first, and we see it's impossible they could use that same detail for RT. They can only use constant LOD proxies, which in comparison is inefficient, and looses the RT advantage of accuracy. So shadow maps are more accurate than RT in that case.
