Direct3D feature levels discussion

[DegustatoR]

AMD Radeon RDNA2 Navi (RX 6500, 6600, 6700, 6800, 6900 XT)

AMD Radeon Pro W6800 32 GB Review - Does the new workstation graphics card beat the NVIDIA Quadro RTX 5000? | igor´sLAB (igorslab.de) Guess they didn't have an A5000 on hand. The card is trading blows with the RTX Quadro 5000 (which is a 2080 Super GPU), and loses big time in DXR tests. I don't...

forum.beyond3d.com

RDNA2 supported rendering/blending to RGB9E5 render targets several years ago. I think this is a far more useful feature as opposed to superfluous things like VRS or "Sampler Feedback"

If you check the XLS with format support here you'll notice that Nvidia supports this format as far back as "Small Turing" - which is ~2 years prior to RDNA2.

 

[DmitryKo]

DNA2 supported rendering/blending to RGB9E5 render targets several years ago

Not in Direct3D 12 though.

If you check the XLS with format support here you'll notice that Nvidia supports this format as far back as "Small Turing" - which is ~2 years prior to RDNA2.

Even though the DXGI_FORMAT_R9G9B9E5_SHAREDEXP format is required (not optional) in Direct3D 12, its default capabilities did not include render target and UAV (virtual memory descriptors) - these are only required starting with Direct3D Agility SDK 1.614, and swap chain (front buffer) capability is not yet implemented.

 

[Lurkmass]

If you check the XLS with format support here you'll notice that Nvidia supports this format as far back as "Small Turing" - which is ~2 years prior to RDNA2.

That's not it since DXGI_FORMAT_R9G9B9E5_SHAREDEXP reports false for "Render Target" and "Blend ops" ...

Even today in Vulkan, the format E5B9G9R9_UFLOAT_PACK32 still reports unsupported for the "COLOR_ATTACHMENT and "COLOR_ATTACHMENT_BLEND" flags with the RTX 4090 ...

Not in Direct3D 12 though.

That's because D3D12 didn't expose the functionality in the past and it doesn't have a sane extension system either. The hardware ALWAYS had this capability integrated from the start ...

 

[DegustatoR]

DirectSR Preview Available Now - DirectX Developer Blog

In the evolving landscape of Super Resolution (SR), GPU hardware vendors have set the stage with their respective technologies – AMD FidelityFX™ Super Resolution, Intel XeSS, and NVIDIA DLSS Super Resolution. These cutting-edge solutions elevate the gaming experience by boosting frame rates...

devblogs.microsoft.com

Today, DirectSR is shipping with built-in support for AMD FidelityFX™ Super Resolution (FSR) 2.2, along with driver level support for both Intel XeSS and NVIDIA DLSS Super Resolution. This flexibility ensures DirectSR supports a diverse set of hardware environments, while still providing the optionality and quality that gamers enjoy today. But most exciting, this API allows users to select between the available upscalers at runtime depending on their underlying hardware.

So no XeSS anymore for Nvidia and AMD users.

 

[TopSpoiler]

I hope someone would implement a generic TAAU plugin for DirectSR.

 

[trinibwoy]

So no XeSS anymore for Nvidia and AMD users.

Yep, as expected. Worth the sacrifice I think.

 

[MfA]

Bit weird to not allow third parties to offer extensions. Probably NVIDIA throwing its weight around.

 

[MfA]

I hope someone would implement a generic TAAU plugin for DirectSR.

Would need to hook the DLL.

I'd rather someone tried to hack something like ExtraSS, without a G-buffer you need to extract lighting/shadowing yourself (like NVIDIA does with it's two step motion estimation) but could still be done.

 

[trinibwoy]

Bit weird to not allow third parties to offer extensions. Probably NVIDIA throwing its weight around.

Does DirectX accommodate IHV extensions? How would they work?

DirectSR already comes with FSR out the box so they’re clearly open to bundling where it makes sense.

 

[Kobata]

Does DirectX accommodate IHV extensions? How would they work?

DirectSR already comes with FSR out the box so they’re clearly open to bundling where it makes sense.

There's a GPU driver interface (using D3D12 metacommands) to add 'native' extensions, and the spec defines a second interface for other extensions (the example given being running upscaling using a separate NPU), but has no way of actually loading said extensions, and a note that they're intended to only ever be provided by going through Microsoft.

 

[MfA]

How would they work?

Same as the ones from Microsoft, pick one and pass the DirectSR API calls straight through. But you can't pick one at the moment.

PS. extensions is what Microsoft calls DirectSR execution engines not build into the driver.

 

[trinibwoy]

Same as the ones from Microsoft, pick one and pass the DirectSR API calls straight through. But you can't pick one at the moment.

I meant how would the IHVs get their extensions into the DirectSR runtime? The whole point of DirectSR is that devs don’t need to deal with IHV specific libs.

As a user you will see the default FSR option + whatever your graphics card manufacturer offers in their driver. So if AMD wanted to offer XeSS dp4a to their users they could add it to their driver. We shouldn’t expect game devs to be responsible for offering an Intel extension to non-Intel users. That’s already possible today without DirectSR so would defeat the purpose of introducing DirectSR in the first place.

 

[MfA]

You register a new execution engine in the registry, directsr enumerates them for the application and it picks what they fancy, possibly through an user UI choice.

If the application just picks the first available it will generally be the device one, but they don't have to.

Needing to mess with multiple APIs is not the same.

 

[trinibwoy]

You register a new execution engine in the registry, directsr enumerates them for the application and it picks what they fancy, possibly through an user UI choice.

Is “you” the game developer and registry the windows registry on the users PC? That seems cumbersome and unnecessary when they can just directly integrate the extension like they do today without mucking about in the users config.

If the application just picks the first available it will generally be the device one, but they don't have to.

My understanding is that it enumerates whatever the driver supports and allows the user to choose from that list + the built in FSR.

Needing to mess with multiple APIs is not the same.

Not the same but still cleaner than doing the same thing in a roundabout way via the registry and DirectSR. Those are additional hops with no real benefit.

 

[MfA]

Is “you” the game developer and registry the windows registry on the users PC?

The extension installer, on the user's PC.

Lets have every OpenGL and Vulkan driver require separate linking, it's cleaner. They have extensions after all.

 

[Deleted member 2197]

How does Epic's TSR play with DirectSR? Also is Epic IHV upscaling APIs that Unreal engine provides for customized upscaling implementations still available for developers to use?

 

[DegustatoR]

How does Epic's TSR play with DirectSR?

It doesn't. It's an engine side provided option. A developer could still provide those in addition to DirectSR so it is still possible to add XeSS in the "old way". Which is exactly why I think that DirectSR makes the whole landscape worse, not better.

 

[trinibwoy]

The extension installer, on the user's PC.

Lets have every OpenGL and Vulkan driver require separate linking, it's cleaner. They have extensions after all.

Oh that’s an interesting idea. Too many moving parts though. Won’t happen. Also “game ready” versions of each extension will likely remain the domain of IhV drivers.

 

[Deleted member 2197]

A developer could still provide those in addition to DirectSR so it is still possible to add XeSS in the "old way". Which is exactly why I think that DirectSR makes the whole landscape worse, not better.

Yeah. DirectSR is nice that it provides a "default" upscaler but any IHV specific upscaler that currently requires more effort by development team will continue to do so regardless of DirectSR being present.

 

[DegustatoR]

Automatic Super Resolution: The First OS-Integrated AI-Based Super Resolution for Gaming - DirectX Developer Blog

Auto SR automatically enhances select existing games allowing players to effortlessly enjoy stunning visuals and fast framerates on CoPilot+ PCs equipped with a Snapdragon® X processor. DirectSR focuses on next generation games and developers, Together, they create a comprehensive SR solution...

devblogs.microsoft.com

What’s Unique About Auto SR?

Auto SR stands out in two exciting ways: it’s applied automatically and enhances existing games. Like other SR technologies, Auto SR uses AI to improve frame rates and image quality. However, Auto SR focuses on bringing the benefits of super resolution to your existing game library with no manual configurations needed. This makes it ideal for players who prefer a straightforward experience. Simply start your game, and Auto SR instantly enhances it, allowing you to effortlessly enjoy visuals that surpass native 1080p quality with the fast frame rates typically seen at lower resolutions. Auto SR boosts detail and performance on compatible hardware, transforming your gameplay and letting you experience select titles in a new light.

DirectSR and Auto SR create a comprehensive SR solution across Windows devices.

• DirectSR focuses on next generation games and developers, while
• Auto SR enhances existing games, improving the player experience automatically

Together, they provide a powerful combination, offering a fantastic balance of frame rate and visuals to make a vast part of your gaming library look and feel even more incredible.