Anyone know if the raytracing cores on these things can be used to accelerate Shadertoy style raymarching stuff? This technique has been threatening to break through into the mainstream for a while now.
This is basically a rewrite of iq's primitive shadertoy using DXR, with additional, non-SDF objects like metaballs. https://www.shadertoy.com/view/Xds3zN
I'm not sure how much of a speed up you'd get from using this API though. Most of the complex shadertoy shaders are unoptimized and brute-force given the limitations of the environment, and you can render similar scenes without a raytracing API using similar techniques in more efficient ways. The talk on Claybook at GDC 2018 or Alex Evan's Siggraph 2015 talk are good examples of ways to scale procedural sign distance field rendering. They both assume dynamic scenes or user edited content, there are probably other tricks that could be used to accelerate mostly static content.
It could, but to the best of my knowledge the OpenGL(/es) Vulkan extensions for raytracing don't exist yet as standards or implementation. But most of the Shadertoy raymarching scenes could be implemented using the raytracing API and custom intersecting functions.
I'm personally curious about the performance on custom intersections with the new hardware. Shadertoy demos have a lot of flexibility and tend more towards procedural geometry, since polygonal ray intersection is hard. The new hardware raytracing will be highly optimized for polygonal geometry though, since that's the bread and butter of current realtime engines.
Guessing that you'll provide a simple bounding primitive for it to do the ray test against, and then it will fall back on more or less identical shader code to resolve the custom ray intersection.
