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.
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"
Direct3D feature levels discussion
- Thread starter DmitryKo
- Start date
DmitryKo
Veteran
Not in Direct3D 12 though.
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.
Last edited:
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 ...
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 ...
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
So no XeSS anymore for Nvidia and AMD users.
Last edited:
I hope someone would implement a generic TAAU plugin for DirectSR.
Yep, as expected. Worth the sacrifice I think.
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.
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.
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.
Last edited:
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.
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.
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.
Last edited:
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.
My understanding is that it enumerates whatever the driver supports and allows the user to choose from that list + the built in FSR.
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.
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.
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.
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.
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