Provide API to quickly check XeFG/XeLL device support

[simco50]

Hi,

Currently the only way to determine whether a device supports XeLL and XeFG seems to be by creating a context (xellD3D12CreateContext and xefgSwapChainD3D12CreateContext) and checking the return value.
This is slow and very inconvenient because we simply want to check support on startup without already allocating resources.
Is there an API to quickly check for feature support, rather than creating a context, which has an unacceptable overhead?

Thanks in advance,
Simon

[mike-intel]

Currently there is no other way to check for support.

What is the main aspect that makes the approach unacceptable? Is it the wall-clock time of the call or something else?

If you could provide a little bit more information about your use case, it will help us plan and prioritize the work. We'll see what we can do to improve the API.

Below I'll shed some light on the idea behind the current API and how it can be used. I hope this will help a little bit.

The motivation behind the current API:

• context creation does minimal resource allocation (more details below)
• context creation is much faster compared to initialization (looking at XeFG, XeLL only has context creation)
• context is cheap to keep around and does not interfere with the application
• hypothetical "is supported" check would do a lot of the same things that context creation is doing

Application can create XeLL context once during startup and destroy it on shutdown. The XeFG case is similar.

Application can create XeFG context during startup and use it later to initialize the swap chain if the user turns on XeSS-FG. However, when switching from XeSS-FG to no FG or some other FG the application would have to destroy the context before recreating the swap chain (perhaps we can improve this scenario). One of the ways to handle this is to always keep an XeFG context around:

void Start()
{
    xefg_supported = (XEFG_SWAPCHAIN_RESULT_SUCCESS == xefgSwapChainD3D12CreateContext(device, &xefg_context));
}

void SwitchToXefgSwapChain()
{
    assert(xefg_supported);
    init_params.pApplicationSwapChain = swap_chain.Detach();
    xefgSwapChainD3D12InitFromSwapChain(xefg_context, command_queue.Get(), &init_params);
    xefgSwapChainD3D12GetSwapChainPtr(xefg_context, IID_PPV_ARGS(&swap_chain));
}

void SwitchToNativeSwapChain()
{
    swap_chain.Reset();
    xefgSwapChainDestroy(xefg_context);
    // recreate the context to maintain "context is available after startup" invariant
    xefg_supported = (XEFG_SWAPCHAIN_RESULT_SUCCESS == xefgSwapChainD3D12CreateContext(device, &xefg_context));
    factory->CreateSwapChainForHwnd(..., &swap_chain);
}

void Exit()
{
    xefgSwapChainDestroy(xefg_context);
}

Some background on what context creation is doing.

Context creation sets up the infrastructure necessary to initialize XeLL/XeFG: it queries adapter information, makes sure we'll be able to compile the shaders, and on Intel it checks if there is a newer version bundled with the driver. The step does create a few D3D objects, but we tried to keep it to a minimum. XeFG does most of the initialization and resource allocation inside xefgSwapChainD3D12InitFrom* (e.g., back buffers and all of the internal GPU buffers are allocated during initialization).

[simco50]

Hi Mike,

Thanks for the swift and detailed reply, much appreciated!

I can see in SuperLuminal that creating an XeLL context allocates a D3D command queue and an XeFG context creates another 2 command queues. This needlessly allocates memory even though the application might not even ever use XeLL/XeFG.
Combine that with XeSS SR and your application creates 4 extra command queues on startup without even using XeSS.

My main use case (and most likely for every other game), is that I simply want to query whether XeSS/XeLL/XeFG is supported so that it can be presented properly in the UI, without allocating any resources.
One approach I took is simply making a context for each feature on startup and destroying them immediately and save whether it succeeded. However, it feels like this could be much faster if it didn't create all those device resources.

Some numbers:

• Loading libxess.dll and creating a context: ~600ms
• Loading libxess_fg.dll and creating a context: ~650ms
• Loading libxell.dll and creating a context: ~120ms

So all combined almost 1.5 seconds to simply check whether the XeSS features are supported.
In simple applications where the startup time is generally fast, this adds a significant amount of time.
The majority of the time seems to be spent loading the DLLs itself and creating command queues. So if the context creation wouldn't create the queues, that would already cut off quite a bit of time.

If this is truly how it's meant to be used, I can see a lot of value in trying to optimize these loading times.
The documentation says that all GPUs with SM6.4 or higher support XeSS/XeLL/XeFG, so would just checking the shader model be sufficient? That way a context can just be created on-demand.

For what it's worth, Nvidia Streamline takes about 2.5 seconds to initialize before even using any of the features, which also seems absurd.

Thanks in advance,
Simon

[mike-intel]

Simon, thank you for the details! We'll prioritize this for the next patch - there are a few things we can do to improve the situation - and we will keep an eye on the startup cost going forward.

[mike-intel]

@simco50 release 2.1.1 improves the DLL load and context creation time for FG - please give it a try.

The numbers will be different between Intel and non-Intel GPUs because on Intel we also check whether driver has an updated version of FG (SR and LL do the same).