nor will you get good hit rates by looping in random directions through the screen pixels.
If bandwidth consumption is such a concern with deferred shading then forward rendering is always an option and you can combine that approach with deferred texturing if you want to save on overdraw too. No matter how you slice it, both are solved problems while there's no good answer to the memory indirections for ray tracing ...
So what? To trace a ray through the scene encoded in the G-buffer, you will still need to do plenty of dependent texture reads per pixel using the depth, normals, and color render targets. Is it somehow different?
GPUs have texture caches and a varying occupancy model to easily hide this memory latency. Good luck doing this for ray tracing where spilling (rip perf) is common and most architectures have highly sensitive memory hierarchies ...
Don't understand your question. The approach I described will make your RT sampling dense for diffuse reflections (at the cost of cubemap limitations), resulting in coherent memory accesses and good hit rates, the thing you have been complaining about. It won't save you from the need to build a BVH, of course, but that wasn't discussed either.
@Bold Only for the cubemap itself which doesn't solve the elephant in the room itself of needing to render to the dynamic cubemap during runtime which involves using a very expensive BVH to trace rays and shade against ...
I'm not sure if you understand the idea behind GoW Ragnarok's cubemaps which is to have them exactly pre-rendered for quick look ups during RT ... (a cheap static BVH with only 12 triangles)
RT cores are bindless and they are not even part of the graphics pipeline, so they can't have the "tons of states". So, what are the special RT states you're talking about?
There is zero confirmation of your claims about the complexity of the RT hardware. Fantasies aside, the difference in performance per area between the GTX 16 series and the RTX 20 series in pure rasterization was minimal.
Some RT implementations can feature their own specialized HW pipelines just like graphics or compute pipelines. Just because RT pipelines don't look anything like GFX pipelines (world space geometry/screen space pixel shading stages, rasterizer modes, texture sampling modes, special memory, MSAA state etc) were used to doesn't mean there aren't any RT specific HW states otherwise how do you explain the acceleration structure property
restrictions, different RT shader stages, or the
predefined ray-triangle intersection rules ?
If you say there are no special HW states for RT then why does Nvidia encourage graphics programmers to use SER which are only available with ray generation shaders instead of true function calls and have no extension for traversal shaders ? (there shouldn't be any perf difference if there's no special HW, right ?)
This is nonsense. If anything, consoles have the best chances to differentiate themselves from PCs by innovating in RT, since they can easily double down on RT units and custom hardware for BVH, sorting, etc. Consoles were never obligated to have the best perf/area and perf/watt in legacy workloads, unlike PC products, where mass consumers and the press are typically resistant to and skeptical of innovation. Additionally, there is the API, where consoles are far less restricted. So, no, consoles have already cornered themselves as dumbed-down PCs. Innovating in RT is a possible way out.
There's far more HW implementations out there that have competent compute/raster pipelines which continue getting feature advancements like GPU-driven rendering while RT has had no standardized API functionality updates for a long time now ...
Clearly as I pointed out earlier, Epic also wants RT shadows badly. Epic is moving into multiple directions at once.
They want RT yet ironically they keep disabling static meshes with world position offset by default according to their own performance
guide with tons of other performance warnings ...
Now I really can't understand this argument, you wanna avoid the hardware cost of RT+AI by using exotic custom GPU solutions?
I certainly hope this never happens, this will send AMD into an recoverable downward spiral, since this exotic custom GPU solutions won't certainly be from AMD.
In case you didn't know any better, a GPUs warp scheduler can't co-issue tensor core instructions with other instructions on the same sub-partition in same cycle. You're not just turning on some matrix units whenever the you're doing some matrix math but you're also taking down the entire SIMD unit along with it's register file too leaving no capacity to do other compute as well!
Don't make it sound like me being some proponent for divergent graphics architecture design is equivalent to someone having NIH syndrome ... (just reuse things that work well like raster/compute while replacing things that's not working well like RT)
AMD relies on the console makers funding to renew their PC archetictures (they synchronize major PC archs with console archs), without the funding from consoles they won't be able to compete with NVIDIA as they won't be able to do much of hardware upgrades or changes, especillay now as their resources are split between the money making CDNA and their shrinking RDNA. Their PC market share and revenues are in the toilet already and can't provide much of a significant funding. They don't even forecast things to improve on that front in the near future.
Neither AMD nor the console vendors truly have anything to lose at this point by diverging from PC graphics. If they do decide to go the full way of a console "carve out" then AMD will have protected the console market from coverging with PCs for their partners all the while self perpetuating the existence of their graphics business to be able to survive based on that carve out ...
Also exotic hardware means more cost on console makers, since they get a discount from AMD (as AMD uses the money on their PC GPUs as well). That cost will be transmitted to the user.
More costs will also be incurred, console makers now care about putting their games on PC, if consoles use exotic hardware then the cost of porting games will be higher. The cost of making multiplatform games will also be higher as well, since it's highly unlikely that both Microsot and Sony will end up using the same exotic hardware.
PC hardware is
failing to get significantly cheaper overtime so taking custom hardware is their only option left to make bigger technological jumps ...
Of course they're not going to give up on multiplatform development that easily but because of the fact that there's
no parity anymore between PC and console graphics technology means that PC being the definitive experience platform ceases to be either true (missing graphical effects) or become really perverted (upgraded renderer poses as a wall with high hardware requirements) ...
