Finally the ray tracing geekyness starts:

https://blogs.msdn.microsoft.com/directx/2018/03/19/announcing-microsoft-directx-raytracing/

lets collect some interesting articles, I start with:

https://www.remedygames.com/experiments-with-directx-raytracing-in-remedys-northlight-engine/

Honestly I'd like to try it - what I'm skeptical about are dynamic scenes (in my thesis I was doing interactive bidirectional path tracing in CUDA - and it worked well... for static scenes, re-building acceleration structures was simply too big performance hit).

To also add something (and not just spam around) - http://forums.directxtech.com/index.php?topic=5860.0

Has anyone successfully ran it?

I have just Rx 480 (and some older Radeon 290) available at the moment - which is a no-go due to Shader Model 5.0 only support... this might be hint to get up to date with some hardware.

2 hours ago, FreneticPonE said:

Really don't understand why DirectX needs it's own raytracing API in the first place. 

Download the SDK and check out the docs to see the problems that it's solving: http://forums.directxtech.com/index.php?topic=5860.0

Basically, an RT API is a great stress-test for modern compute-based GPUs. You want things like:

• Dispatch calls that can dynamically produce more dispatch calls, recursively
• Dispatches that can pre-empt themselves with calls to a different shader, before resuming.
• Being able to bind an array of compute shaders to a dispatch, and have them refer to each other via pointers.
• Being able to bind many root-parameter sets to a dispatch.
• A very smart scheduler that can queue and coalesce these different shader invocations into large thread groups before executing them.

Current GPU's are almost here, but even with DX12/Vulkan, this kind of stuff is impossible. The API described in the SDK preview is trying to solve these problems.

They're also promising to put a full compute-shader based fallback implementation up on GitHub, which is amazing! ...and then any apps written against this common API will be able to be accelerated further as the HW vendors move more and more of it over to their next generation of front-ends / thread schedulers.

NV already has hardware that can do this stuff, so Intel and AMD are under pressure to catch up with more flexible shader thread scheduling. Also, NV don't like being locked to MS, so you can be certain they will releaseGL and VK extensions soon enough... at which point Khronos will feel the pressure to standardize these features too.

Maybe in the long term, having standard RT API's is a silly idea... but in the short term, this is going to have a very positive effect!

Thanks, both of you!

@Hodgman I've been near ray tracing business (especially GPU one) for some time. For few years (when working on my BSc. and MSc.), and since then as hobbyist. Which is why I'm so interested.

Sadly, I doubt I'll be able to run it anywhere (I'm running only AMD GPUs as of now - having Shader Model 5.0 only - and buying a new card around is not really an option, as everything that could be used is literally sold out around here ... damn those miners!). But maybe in few weeks, when supplies arrive?!

I'm very keen to see RT api though (which is why I'm very interested - and it really won't allow me to sleep today! ... 6 AM and still digging around that code!), we've had some approaches but mostly you either had to write whole traversal + shading kernels, which were huge. (Or storing results in buffers & shade after).

From what is in the presentation by @FreneticPonE the results doesn't really impress me (yet it's hard to compare with anything when all I see are just few slides).

45 minutes ago, Vilem Otte said:

buying a new card around is not really an option, as everything that could be used is literally sold out around here ... damn those miners!). But maybe in few weeks, when supplies arrive?!

Keep in mind that the only GPU at this time which can run all this natively is a $3k MSRP Titan V. Might want to hold off for a bit.

3 hours ago, FreneticPonE said:

Which of course is really noisy so then you get to add denoising overhead on top of that

The denoising is pretty crazy though. I'm assuming RTX sinks at least some support for Morgan's technique into the hardware layer.

I think it's a very promising step in a good direction. There's so many rendering techniques that relay on ray-tracing idea (SSR, GI, SSAO SSVGI, Screen-Space Everything) and a low-level API will help to achieve performance.

I wonder if it could be used to shoot some rays before scene rendering to replace Hi-Z PrePass for the geometry culling. Do you think it could quickly calculate the scene objects visibility?

Finally, of course NV always had been one step forward in terms on new rendering features  They like to put some pressure on others.