Couldn't that cause issues, though? You'd still have to calculate and cull the geometry before determining the shading rate, right? Not only that, but the geometry LOD may not always correlate 1:1 with the texture quality. Some surface could have very simple geometry but require a render output of a high-quality texture, maybe since the object in question could be for decorative purposes and collision between the player isn't really expected, but it's close enough to the viewer in the frame to require a higher resolution for that texture even if the geometry it's mapped over is much lower quality?
So wherever VRS would fall in the pipeline, it can't be that early is my own personal guess. In addition with that, this is just me asking here but, does RT BVH traversal testing utilize the geometry of the model the tests are passed on, or is it literally just a bounding box and that's as far as the collision zone for the object goes for running the traversal test on? I assumed the object geometry would play a factor into that but then again, I'm not really read up on how RT intersection tests work at the technical level beyond some of the basics (or even how AMD in particular does them, though that's an aside).
I think there would be a number of issues with trying to determine shading rate in the GE. Smaller polys don't automatically need lower or higher shading rates, and the same is true for larger polys. Or any poly. You could use a clever primitive shader or mesh shader to generate geometry (from that which was read in) that was more optimal for the rest of the pipeline, but that's about making geometry that's more efficient to process rather than selectively shading pixels that you've already rasterised. At least as far as I can see anyway!
I think the same is likely true of depth. You can use depth to, for example, calculate DOF, and use that to hide lower quality assets (or probably areas of lower res rendering), but again I don't see how the GE would automatically know what you were planning to do with the geometry you were currently processing.
I keep coming back to the idea that the GE is great for making more efficient geometry to render, and it could probably be used to split the screen into quads that rendered at different resolutions (that you could adjust on a per frame basis), but the GE just seems too early to make smart decisions about shading frequency vs rasterisation frequency in a very fine grained manner.
WRT to ray tracing, you normally have the actual geometry of whatever you're RT against in one of the nodes in the BVH tree. You use the BVH tree to locate a relatively small amount of geometry to finally test against, and then get your poly (and through that its texture / material data etc) from there. Unless you don't hit anything and go up into the sky (just use the skybox?), or go out of range (I dunno, skybox? Environment texture? Nothing?).
Acceleration structures are basically about ignoring as much geometry as you can as you trace the ray through the world. This is because testing against geometry is very expensive, but testing against a bounding volume is cheap. The down side is that BVH trees take up more and more memory the more detail and nodes they contain. And even if testing is cheap, it still isn't free.
There are lots of shortcuts / optimisation involved in RT, and the best tradeoffs won't be the same for every game. I think that's why MS (and probably Sony) were talking about making the acceleration structures customisable and exposing them to developers on console.
So it's not cheating as long as you only use your mouth to blow...air.
