During this week, both GDC (the Game Developers’ Conference) and GTC (the Game Technology Conference) are happing in California, and NVIDIA is out in force. The company's marquee gaming-related announcement today is that, as many have been expecting would happen, NVIDIA is bringing DirectX 12 DXR raytracing support to the company's GeForce 10 series and GeForce 16 series cards.

When Microsoft first announced the DirectX Raytracing API just over a year ago, they set out a plan for essentially two tiers of hardware. The forward-looking plan (and long-term goal) was to get manufacturers to implement hardware features to accelerate raytracing. However in the shorter term, and owing to the fact that the API doesn't say how ray tracing should be implemented, DXR would also allow for software (compute shader) based solutions for GPUs that lack complete hardware acceleration. In fact, Microsoft had been using their own internally-developed fallback layer to allow them to develop the API and test against it internally, but past that they left it up to hardware vendors if they wanted to develop their own mechanisms for supporting DXR on pre-raytracing GPUs.

NVIDIA for their part has decided to go ahead with this, announcing that they will support DXR on many of their GeForce 10 (Pascal) and GeForce 16 (Turing GTX) series video cards. Specifically, the GeForce GTX 1060 6GB and higher, as well as the new GTX 1660 series video cards.

Now, as you might expect, raytracing performance on these cards is going to be much (much) slower than it is on NVIDIA's RTX series cards, all of which have hardware raytracing support via NVIDIA's RTX backend. NVIDIA's official numbers are that the RTX cards are 2-3x faster than the GTX cards, however this is going to be workload-dependent. Ultimately it's the game and the settings used that will determine just how much of an additional workload raytracing will place on a GTX card.

The inclusion of DXR support on these cards is functional – that is to say, its inclusion isn't merely for baseline featureset compatibility, ala FP64 support on these same parts – but it's very much in a lower league in terms of performance. And given just how performance-intensive raytracing is on RTX cards, it remains to be seen just how useful the feature will be on cards lacking the RTX hardware. Scaling down image quality will help to stabilize performance, for example, but then at that point will the image quality gains be worth it?

Under the hood, NVIDIA is implementing support for DXR via compute shaders run on the CUDA cores. In this area the recent GeForce GTX 16 series cards, which are based on the Turing architecture sans RTX hardware, have a small leg up. Turing includes separate INT32 cores (rather than tying them to the FP32 cores), so like other compute shader workloads on these cards, it's possible to pick up some performance by simultaneously executing FP32 and INT32 instructions. It won't make up for the lack of RTX hardware, but it at least gives the recent cards an extra push. Otherwise, Pascal cards will be the slowest in this respect, as their compute shader-based path has the highest overhead of all of these solutions.


This list of cards includes mobile equivalents

One interesting side effect is that because DXR support is handled at the driver level, the addition of DXR support is supposed to be transparent to current DXR-enabled games. That means developers won't need to issue updates to get DXR working on these GTX cards. However it goes without saying that because of the performance differences, they likely will want to anyhow, if only to provide settings suitable for video cards lacking raytracing hardware.

NVIDIA's own guidance is that GTX cards should expect to run low-quality effects. Users/developers will also want to avoid the most costly effects such as global illumination, and stick to "cheaper" effects like material-specfic reflections.

Diving into the numbers a bit more, in one example, NVIDIA showed a representative frame of Metro Exodus using DXR for global illumination. The top graph shows a Pascal GPU, with only FP32 compute, having a long render time in the middle for the effects. The middle bar, showing an RTX 2080 but could equally be a GTX 1660 Ti, shows FP32 and INT32 compute working together during the RT portion of the workload and speeding the process up. The final bar shows the effect of adding RT cores to the mix, and tensor cores at the end.

Ultimately the release of DXR support for NVIDIA's non-RTX cards shouldn't be taken as too surprising – on top of the fact that the API was initially demoed on pre-RTX Volta hardware, NVIDIA was strongly hinting as early as last year that this would happen. So by and large this is NVIDIA fulfilling earlier goals. Still, it will be interesting to see whether DXR actually sees any use on the company's GTX cards, or if the overall performance is simply too slow to bother. The performance hit in current games certainly favors the latter outcome, but it's going to be developers that make or break it in the long run.

Meanwhile, gamers will get to find out for themselves with NVIDIA's DXR-enabled driver release, which is expected to come out next month.

Source: NVIDIA

POST A COMMENT

38 Comments

View All Comments

  • azrael- - Tuesday, March 19, 2019 - link

    Meanwhile everyone else is talking about CryTek's Neon Noir raytracing demo. You know... the one rendered on a Vega 56 without dedicated RT hardware.

    https://www.youtube.com/watch?v=1nqhkDm2_Tw
    Reply
  • CiccioB - Tuesday, March 19, 2019 - link

    Everyone else are those that just discovered that raytracing is possible without dedicated units.
    There is lately a WOW effects on the ignorant masses!
    You know, it has always been possible to do raytracing. You do not even need a GPU to do that.
    The problem is not the feasibility of the process, the problem are the performances.
    That's the same thing that is being said here: you can do RT effects, but without dedicated units the performance can be up to 1/10th of those with those units.
    Reply
  • shing3232 - Tuesday, March 19, 2019 - link

    That demo get decent performance from a VEGA56. Reply
  • edzieba - Tuesday, March 19, 2019 - link

    It also used a lot of the performance optimisations for RT bumped all the way up to 11 to he point of artefacting. Look around the 1:18 mark at the spinning mirrors with ghosting artefacts from temporal filtering. Looks to be about 7 frames visible at once, so RT framerate easily could be 1/6 or less the raster render rate (i.e. 30FPS display rate, 5FPS render rate for RT reflections). Reply
  • SirPerro - Tuesday, March 19, 2019 - link

    People could mine cryptocurrencies with a "decent performance" until they discovered specialized hardware basically redefined "decent performance".

    Same happens with AI training. Yeah performance was "decent" until stopped being decent. And once high-end GPUs and TPUs are in the game, suddenly the baseline and the use cases completely change the landscape.

    No matter the performance of that demo, a correct implementation in hardware would completely crush it.
    Reply
  • bigvlada - Tuesday, March 19, 2019 - link

    Ordinary people got the ability to play with raytracing in 1986 with Turbosilver (later known as Imagine) on vanilla 512kb Amiga 500 using the Sculpt 3D program.

    Nothing new under the sun, a while ago ignorant masses were being persuaded that 3D gaming is only possible on Voodoo cards. Power VR Rendition Verite 1000 and nVidia Riva 128 showed them how wrong they were.
    Reply
  • bigvlada - Tuesday, March 19, 2019 - link

    Edit: Sculpt 3D appeared in 1987. Reply
  • blppt - Wednesday, March 20, 2019 - link

    The Riva 128 had some really bad rendering issues IIRC. It might have delivered slightly higher framerates than the equivalent Voodoo of the time, but those graphical anomalies....

    (I had both a RIva 128 and a Voodoo 1 and then 2)
    Reply
  • ET - Tuesday, March 19, 2019 - link

    Looks to me like the 2080+RT+DLSS means that it's all rendered at a lower resolution. (Standard DLSS does this, and all the non-RT work seems compressed.) That would make the comparison to the other architectures a lot less meaningful. Reply
  • PeachNCream - Tuesday, March 19, 2019 - link

    Great! Now I can run the two ray-tracing titles that will come out between now and the end of 2020 on Pascal at 640x480! Where do I go to sign up for that great stuff? Reply

Log in

Don't have an account? Sign up now