RDNA 2 Ray Tracing

Yeah, but there might be just not enough storage, depending on the game.
But then we could at least build 'nearby' BVH during startup or as a background task, and manage a cache on disk to avoid constant rebuilds of the same models as they pop in and out.

Yes, but this maximizes incoherence.
For GI we we can avoid this. Examples would be DDGI probes, where we have many rays originating from the same probe center. So i thought you think about doing the same but making the emitter a center, instead the receiver.

 

Then i did a good job
Ofcourse DXR needs refining, just as any other new technology that came recently. I think it will be ok, just as any other 'great/huge' new feature out there now. All these combined should help alot in improving on the 'lack' of generational jumps these days.

 

I'm kind of surprised there are no hardware based numerical integrators, it should be one of the more decisive cases where hardware just beats software by some orders. Lets say we can get sums out of texture fetches instead of averages/filtered, and then we can get masked sums (either by another texture, or a polynomial/spherical discreet function), and then we get hierarchical texture sums (in the mips), and then we extend it to 3D textures and the true fun with voxel hierarchy integration starts.
This would solve more lighting equation performance and precision problems than what's brought up currently. What's being done now on GPUs is a 4 decade old technique, and you can predict how this goes fairly well, just looking at offline raytracing tech history. It would also raise productivity of programmers instantly, as all the MoBlur, DoF, Bloom, SSS and myriad of effects, which are sum-based, suddenly would be a couple of lines large instead of 4k code blobs.

 

Nice idea. Personally i see two applications, one is building env map probes for GI, the other is fluid simulations. But in both cases it would only help me if it works with fragments of texture living in LDS memory.

 

Some reverse engineering on RDNA2 raytracing implementation:

https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/wikis/RDNA2-hardware-BVH
https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/wikis/Raytracing
https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK/commit/4f2442c13eec0e8cb4feeef1185861ae99a13a9d

Putting this altogether, could these raytracing hit tokens represent a stack ? It would potentially implicate that AMD are exposing explicit functionality with their AGS driver extension to store the stack information into the LDS memory for non-inline ray tracing ...

 

One thing he forgot in his rejection of stackless is, that he can interleave custom data with the node-data, so after each node there's unlimited private space until the next node, where he can put the parent-pointer. Just pretend the private space is also nodes and ommit the linear ids occupied by them (e.g. just use node_ids divisible by 2, 3, 4, 5 and so on).

Edit: Intel presented short stacks at HPG'19, that is pretty amazing: https://www.embree.org/papers/2019-HPG-ShortStack.pdf

 

A problem is that the nodes have to be 64-byte aligned, so if you add data after the fp16-box node you essentially get a 128 byte structure. Might as well use the fp32-box node then. (assuming no performance difference in processing of fp16/fp32 in the RT hardware). Of course you could put them in a second array to avoid alignment, but then you have data in multiple cachelines which is going to be hard on the memory hierarchy

 

19 clocks? It's 15 clocks in my case.