NVIDIA sends word this morning that the company has posted their first DirectX 12 Ultimate-compliant driver. Published as version 451.48 – the first driver out of NVIDIA’s new Release 450 driver branch – the new driver is the first release from the company to explicitly support the latest iteration of DirectX 12, enabling support for features such as DXR 1.1 ray tracing and tier 2 variable rate shading. As well, this driver also enables support for hardware accelerated GPU scheduling.

As a quick refresher, DirectX 12 Ultimate is Microsoft’s latest iteration of the DirectX 12 graphics API, with Microsoft using it to synchronize the state of the API between current-generation PCs and the forthcoming Xbox Series X console, as well as to set a well-defined feature baseline for future game development. Based around the capabilities of current generation GPUs (namely: NVIDIA Turing) and the Xbox Series X’s AMD RDNA2-derrived GPU, DirectX 12 Ultimate introduces several new GPU features under a new feature tier (12_2). This includes an updated version of DirectX’s ray tracing API, DXR 1.1, as well as tier 2 variable rate shading, mesh shaders, and sampler feedback. The software groundwork for this has been laid in the latest version of Windows 10, version 2004, and now is being enabled in GPU drivers for the first time.

DirectX 12 Feature Levels
(DX12 Ult.)
12_1 12_0
GPU Architectures
(Introduced as of)
NVIDIA: Turing
Intel: Xe?
NVIDIA: Maxwell 2
AMD: Vega
Intel: Gen9
NVIDIA: Maxwell 2
AMD: Hawaii
Intel: Gen9
Ray Tracing
(DXR 1.1)
Yes No No
Variable Rate Shading
(Tier 2)
Yes No No
Mesh Shaders Yes No No
Sampler Feedback Yes No No
Conservative Rasterization Yes Yes No
Raster Order Views Yes Yes No
Tiled Resources
(Tier 2)
Yes Yes Yes
Bindless Resources
(Tier 2)
Yes Yes Yes
Typed UAV Load Yes Yes Yes

In the case of NVIDIA’s recent video cards, the underlying Turing architecture has supported these features since the very beginning. However, their use has been partially restricted to games relying on NVIDIA’s proprietary feature extensions, due to a lack of standardized API support. Overall it’s taken most of the last two years to get the complete feature set added to DirectX, and while NVIDIA isn’t hesitating to use this moment to proclaim their GPU superiority as the first vendor to ship DirectX 12 Ultimate support, to some degree it’s definitely vindication of the investment the company put in to baking these features into Turing.

In any case, enabling DirectX 12 Ultimate support is an important step for the company, though one that’s mostly about laying the groundwork for game developers, and ultimately, future games. At this point no previously-announced games have confirmed that they’ll be using DX12U, though this is just a matter of time, especially with the Xbox Series X launching in a few months.

Perhaps the more interesting aspect of this driver release, though only tangential to DirectX 12 Ultimate support, is that NVIDIA is enabling support for hardware accelerated GPU scheduling. This mysterious feature was added to the Windows display driver stack with WDDM 2.7 (shipping in Win10 2004), and as alluded to by the name, it allows GPUs to more directly manage their VRAM. Traditionally Windows itself has done a lot of the VRAM management for GPUs, so this is a distinctive change in matters.

At a high level, NVIDIA is claiming that hardware accelerated GPU scheduling should offer minor improvements to the user experience, largely by reducing latency and improving performance thanks to more efficient video memory handling. I would not expect anything too significant here – otherwise NVIDIA would be heavily promoting the performance gains – but it’s something to keep an eye out for. Meanwhile, absent any other details, I find it interesting that NVIDIA lumps video playback in here as a beneficiary as well, since video playback is rarely an issue these days. At any rate, the video memory handling changes are being instituted at a low level, so hardware scheduling is not only for DirectX games and the Windows desktop, but also for Vulkan and OpenGL games as well.

Speaking of Vulkan, the open source API is also getting some attention with this driver release. 451.48 is the first GeForce driver with support for Vulkan 1.2, the latest version of that API. An important housekeeping update for Vulkan, 1.2 is promoting a number of previously optional feature extensions into the core Vulkan API, such as Timeline Semaphores, as well as improved cross portability support by adding full support for HLSL (i.e. DirectX) shaders within Vulkan.

Finally, while tangential to today’s driver release, NVIDIA has posted an interesting note on its customer support portal regarding Windows GPU selection that’s worth making note of. In short, Windows 10 2004 has done away with the “Run with graphics processor” contextual menu option within NVIDIA’s drivers, which prior to now has been a shortcut method of forcing which GPU an application runs on it an Optimus system. In fact, it looks like control over this has been removed from NVIDIA’s drivers entirely. As noted in the support document, controlling which GPU is used is now handled through Windows itself, which means laptop users will need to get used to going into the Windows Settings panel to make any changes.

As always, you can find the full details on NVIDIA’s new GeForce driver, as well as the associated release notes, over on NVIDIA’s driver download page.

Source: NVIDIA



View All Comments

  • eddman - Wednesday, June 24, 2020 - link

    If current RTX games (which use DXR 1.0 + nvidia's extensions) were to be updated to support DXR 1.1, does it mean their ray-tracing options can be enabled on RDNA2 cards? Reply
  • Yojimbo - Wednesday, June 24, 2020 - link

    RTX is an implementation of DXR, not the other way around. So it depends on the developers. If they implemented DXR in their games then, assuming AMD releases a DXR driver for RDNA2, which they should, the games should run the ray tracing on the AMD software with perhaps some minor tweaks the developers have to make. But if they used code outside DXR to target NVIDIA's RTX more directly then they would need more major rewriting of their code to get it to work on AMD's hardware. Reply
  • brontes - Wednesday, June 24, 2020 - link

    So to be clear, RTX is a superset of DXR? Any idea how "super" it is, in actual practice? Reply
  • Yojimbo - Wednesday, June 24, 2020 - link

    It isn't necessarily a superset. It only has the potential to be. RTX must implement all of DXR but it might include more functionality, or it might include an alternate method of implementing the same functionality. I have no idea if RTX does or does not do that at the moment, only that it's technically possible for them to do it.

    The question is how did the early adopter developers choose to implement the hardware ray tracing acceleration. NVIDIA may have created libraries that exposed some things in a different way. As a non ray-tracing example: NVIDIA inplemented mesh shaders in Turing and they must have created some way for developers to target them. Now the mesh shaders are part of directx 12 ultimate and so there should be a directx api way of using them. Most likely those are two different ways and at least require a change in syntax in the code. but the change could be more significant than that, depending on how the two different groups decided to implement the feature, and how much nvidia knew of the upcoming microsoft implementation when they were making their own. So the functionality is the same but i would assume you could not just take your game targeting NVIDIA's mesh shaders pre-dx12ultra and run them on rdna2, even though rdna2 has the functionality. On the other hand, if your game implemented the mesh shaders through a dxr12ultra api call then it should run on rdna2.
  • nathanddrews - Wednesday, June 24, 2020 - link

    Nice explanation, thanks. Reply
  • rocky12345 - Wednesday, June 24, 2020 - link

    Great way to explain it Thank You. If there was a way to give a up vote here I would have done that as well. Reply
  • catavalon21 - Wednesday, June 24, 2020 - link

    +1 is about as good as it gets around here. Reply
  • Yojimbo - Wednesday, June 24, 2020 - link

    Haha, that graphics preference box tripped me out. I looked away while scrolling the article and looked back and thought something had popped up from my laptop. Then I looked closer and saw that it didn't listed the graphics options that I actually had, so I thought it was some advertisement or spam pop-up from anandtech.com. Then I finally realized that it was an embedded graphic for the article. Reply
  • MyRandomUsername - Wednesday, June 24, 2020 - link

    "WDDM 2.7 [..] allows GPUs to more directly manage their VRAM"

    Hopefully this open ways to fully utilize VRAM applications under Windows 10.
    Since WDDM 2.0 a single vram-heavy app (e.g. Cuda/CG) can only use about 80% VRAM (or more accurately .. 90% of 90%) opposed to >95% (?) in Win7~8.1 ... because reasons.

    See discussions on e.g.: https://forums.developer.nvidia.com/t/windows-10-u...
  • brontes - Wednesday, June 24, 2020 - link

    > NVIDIA is enabling support for hardware accelerated GPU scheduling ... I find it interesting that NVIDIA lumps video playback in here as a beneficiary as well, since video playback is rarely an issue these days

    Isn't this the second part of the multi monitor+different refresh rate fix? Or did the recent wddm update fix that itself?

    I dropped my second monitor for the time being, in part, because having video running on it (60hz) would screw with my main monitor (120hz) and it was super irritating.

Log in

Don't have an account? Sign up now