Intel® Xᵉ Super Sampling (Xᵉ SS) API Developer Guide v1.1

Intel® X^e Super Sampling (X^eSS) delivers innovative, framerate-boosting technology, which is supported by Intel® Arc™ graphics cards and other GPU vendors. It upscales with AI deep learning, so offers higher framerates at no cost to image quality. The X^eSS API is for any game developer who wants to optimize image quality and performance.

This developer guide supplements the X^eSS API Reference Guide.

Download the PDF

Introduction

X^e Super Sampling is implemented as a sequence of Microsoft* Direct3D* 12 (DX3D) compute shader passes, executed before the rendering engine's post-processing stage (as described in the section entitled 'TAA and X^eSS'). The rendering engine initializes X^eSS by passing a Direct3D* 12 (D3D12) device, which is being used for the main rendering, and a pointer to a descriptor heap, where X^eSS creates all its internal resource descriptors. X^eSS allocates GPU resources for one of two categories:

• Persistent allocations, such as network weights, and other constant data.
• Temporary allocations, such as network activations.

The game engine can control the location where X^eSS makes its temporary allocations by passing XESS_INIT_FLAG_EXTERNAL_DESCRIPTOR_HEAP initialization flag to xessD3D12Init call and a pointer to an external resource heap in the xessD3D12Execute call. To ensure optimal game performance with XeSS when game engine provides external resource heap, this heap should have HIGH memory residency priority. Persistent allocations are always owned by the X^eSS library.

X^eSS Components

X^eSS is accessible through the X^eSS SDK, which provides a D3D12-based API for integration into a game engine, and includes the following D3D12 components:

• An HLSL-based cross-vendor implementation that runs on any GPU supporting SM 6.4. Hardware acceleration for DP4a or equivalent is recommended.
• An Intel implementation optimized to run on Intel® Arc™ Graphics, and Intel® Iris® Xe Graphics.
• An implementation dispatcher, which loads either the X^eSS runtime shipped with the game, the version provided with the Intel graphics drivers, or the cross-vendor implementation.

Figure 1. X^eSS SDK components for both Intel-specific, and cross-vendor solutions.

Versioning

X^eSS uses major.minor.patch version format, and Numeric 90+ scheme, for development stage builds. The X^eSS version is specified by the 64-bit function [xess_version_t] structure, in which:

• A major version increment indicates a new API, and potentially a break in functionality.
• A minor version increment indicates incremental changes such as optional inputs or flags. This does not change existing functionality.
• A patch version increment may include performance or quality tweaks, or fixes, for known issues. There is no change in the interfaces. Versions beyond 90 are used for development builds to change the interface for the next release.

The X^eSS version is baked into the X^eSS SDK release and can be accessed using the function xessGetVersion. The version is included in the zip file and in the accompanying README, as well as the header of the code samples.

Compatibility

All future Intel graphics driver releases provide compatibility with previous and future X^eSS versions.

Specifically, on Intel platforms the loader will operate according to the following rules:

• The loader will check the compatibility of the X^eSS version installed with the game, and the installed driver on the system.
• If compatible, the loader will use the game title installed version of X^eSS.
• If not compatible, and the driver is newer, the loader will ignore the game title version of X^eSS, and use the version distributed with the driver.

• If not compatible and the driver is older, the loader will return a failure code, and X^eSS will not initialize.

Naming Conventions

The X^eSS API uses the following naming conventions:

• All functions must be prefixed with xess
• All functions must use camel case xessObjectAction convention
• All macros must use all caps XESS_NAME convention
• All structures, enumerations, and other types must follow xess_name_t snake case convention
• All structure members and function parameters must use camel case convention
• All enumerator values must use all caps XESS_ENUM_ETOR_NAME convention
• All handle types must end with handle_t
• All parameter structures must end with params_t
• All property structures must end with properties_t
• All flag enumerations must end with flags_t

TAA and X^eSS

X^eSS is a temporally amortized super-sampling/up-sampling technique that drops in place of the Temporal Anti-Aliasing (TAA) stage in the game renderer, achieving significantly better image quality than current state-of-the-art techniques in games.

The figure below shows a renderer with TAA. The renderer jitters the camera in every frame to sample different coordinates in screen space. The TAA stage accumulates these samples temporally to produce a super-sampled image. The previously accumulated frame (history) is warped using renderer-generated motion vectors to align it with the current frame before accumulation. Unfortunately, the warped sample history can be mismatched, with respect to the current pixel, due to frame-to-frame changes in visibility, and shading or errors in the motion vector. This typically results in ghosting artifacts. TAA implementations use heuristics such as neighborhood clamping to detect mismatches and reject the history. However, these heuristics often fail, and produce a noticeable amount of ghosting, over-blurring, or flickering.

Figure 2. Flow chart of a typical rendering pipeline with TAA.

X^eSS replaces the TAA stage with a neural-network-based approach, as shown below, with the same set of inputs and outputs as TAA. Please refer to this report for an overview of TAA techniques.

Figure 3. X^eSS inclusion into the rendering pipeline.  

X^eSS Game Setting Recommendations

When integrating X^eSS into your game, make sure you follow these guidelines for your titles so that your users have a consistent experience when modifying X^eSS options.

There are also guidelines for the font, official naming, and descriptions of the X^eSS functionality below.

Naming Conventions for Intel X^e Super Sampling Branding

You should use the approved naming conventions for X^eSS in your settings menus and descriptions. The official font for X^eSS-related communication is IntelOneText-Regular. Please use the official superscripted e in X^eSS, unless the font system does not support superscript, in which case XeSS is acceptable. For the smaller e in X^eSS, you can reduce the font size for just that character to keep the proportions.

Game Graphics Settings Menu /Game Installer/Launcher Settings

Game-title graphics settings should clearly display the X^eSS option name and allow the user to choose the quality/performance level option settings, as follows.

Note: To enable X^eSS, your title needs to disable other upscaling technologies, such as DLSS and FSR, and temporal anti-aliasing (TAA) technologies, to reduce the possibility of any incompatibility issues.

Graphics Preset Default Recommendations

The X^eSS preset selected by default in the game's menu should be based on the target resolution that the user has set. The entries below are the recommended default settings.

Note: All Intel X^e Super Sampling settings should be exposed to a user through a selection menu, if supported, to encourage customization.

Figure 4. Example of game UI with X^eSS settings.

Programming Guidance

Inputs and Outputs

X^eSS requires a minimum set of inputs every frame:

• Jitter
• Input color
• Dilated high-res motion vectors 

In place of the high-res motion vectors, the renderer can provide the motion vectors at the input resolution—along with the depth values:

• Undilated low-res motion vectors
• Depth

In the latter case, motion vectors will be dilated and up sampled inside X^eSS.

Jitter

As a temporal super-sampling technique, X^eSS requires a sub-pixel jitter offset (J_x,J_y) to be applied to the projection matrix every frame. This process essentially produces a new subpixel sample location every frame and guarantees temporal convergence even on static scenes. Jitter offset values should be in the range [-0.5,0.5]. This jitter can be applied by adding a shear transform to the camera projection matrix:

ProjectionMatrix.M[2][0] += Jx * 2.0f / InputWidth
ProjectionMatrix.M[2][1] -= Jy * 2.0f / InputHeight

The jitter applied to the camera results in a displacement of the sample points in the frame, as shown below, where the target image is scaled 2x in width and height. Note that effective jitter is negated with respect to (J_x, J_y), because the projection matrix is applied to geometry, and it corresponds to a negative camera jitter.

Figure 5. Jitter displacement of sample points.

Jitter Sequence

A quasi-random sampling sequence with a good spatial distribution of characteristics is required to get the best quality of X^eSS algorithm (Halton sequence would be a fair choice). The scaling factor should be considered when using such a sequence to modify the length of a repeated pattern. For example: if the game is using Halton sequence of a length eight in native rendering, it must become 8 * scale^2 if used with X^eSS upscaling to ensure a good distribution of samples in the area covered by a single low-resolution pixel. Sometimes, increasing the length even more leads to an additional quality improvement, so we encourage experimentation with the sequence length. Avoid sampling techniques that bias the jitter sample distribution with regard to the input pixel, however. 

Color

X^eSS accepts both SDR and HDR input colors in any linear color format, for example: DXGI_FORMAT_R16G16B16A16_FLOAT, DXGI_FORMAT_R11G11B10_FLOAT, DXGI_FORMAT_R8G8B8A8_UNORM, etc. The input colors are expected to be in the scRGB color space, which is scene-referred—i.e., the color values represent luminance levels. A value of (1.0,1.0,1.0) encodes D65 white at 80 nits and represents the maximum luminance for SDR displays. The color values can exceed (1.0,1.0,1.0) for HDR content.

If the input color values have not been adjusted for the exposure, or if the input color values are scaled differently from the sRGB space, a separate scale value can be provided in the following ways:

• If no exposure value is available, X^eSS can calculate it when the XESS_INIT_FLAG_ENABLE_AUTOEXPOSURE flag is used at initialization. Note that use of this flag will cause a measurable performance impact.
• When the XESS_INIT_FLAG_ENABLE_AUTOEXPOSURE flag is not provided, an input exposure scale value can be provided, or an exposure scale texture which can be updated by the GPU.

These scale values are applied to the input as shown below:

if (autoexposure)
{
	scale = XeSSCalculatedExposure(…)
}
else if (useExposureScaleTexture)
{
scale = exposureScaleTexture.Load(int3(0, 0, 0)).x
}
else
{
  scale = inputScale
	 }
    inputColor *= scale

The output is in the same color space as the input. It can be any three or linear color format similar to the input. If a scale value is applied to the input, as shown above, the inverse of this scale is applied to the output color. X^eSS maintains an internal history state to perform temporal accumulation of incoming samples. That means the history should be dropped if the scene or view suddenly changes. This is achieved by setting the historyReset flag in xess_xxx_execute_params_t.

Motion Vectors

Motion vectors specify the screen-space motion in pixels from the previous frame to the current frame. X^eSS accepts motion vectors in the format DXGI_FORMAT_R16G16_FLOAT, where the R channel encodes the motion in x, and the G in y. The motion vectors do not include motion induced by the camera jitter. Motion vectors can be low-res (default), or high-res (XESS_INIT_FLAG_HIGH_RES_MV). Low-res motion vectors are represented by a 2D texture at the input resolution, whereas high-res motion vectors are represented by a 2D texture at the target resolution.

In the case of high-res motion vectors, the velocity component resulting from camera animations is computed at the target resolution in a deferred pass, using the camera transformation and depth values. However, the velocity component related to particles and object animations is typically computed at the input resolution and stored in the G-Buffer. This velocity component is upsampled and combined with the camera velocity to produce the texture for high-res motion vectors. X^eSS also expects the high-res motion vectors to be dilated. For example, the motion vectors represent the motion of the foremost surface in a small neighborhood of input pixels (such as 3 * 3). High-res motion vectors can be computed in a separate pass by the user.

Low-res motion vectors are not dilated, and directly represent the velocity sampled at each jittered pixel position. X^eSS internally up-samples motion vectors to the target grid and uses the depth texture to dilate them. The figure below shows the same motion specified with low-res and high-res motion vectors.

Figure 6. Convention for specifying the low-res and high-res motion vector to X^eSS.

Some game engines only render objects into the gbuffer, and quickly compute the camera velocity in the TAA shader. In such cases, an additional pass is required before X^eSS execution to merge object and camera velocities and generate a flattened velocity buffer. In such scenarios, high-res motion vectors might be a better choice, as the flattening pass can be executed at the target resolution.

Depth

If X^eSS is used with low-res motion vectors, it also requires a depth texture for velocity dilation. Any depth format, such as D32_FLOAT or D24_UNORM, is supported. By default, X^eSS assumes that smaller depth values are closer to the camera. However, several game engines use inverted depth, and this can be enabled by setting XESS_INIT_FLAG_INVERTED_DEPTH.

Responsive Pixel Mask

You could provide a responsive pixel mask with a mask value of 1 to force X^eSS to ignore information from previous frames. Although X^eSS is a generalized technique that should handle a wide range of rendering scenarios, there may be rare cases where objects without valid motion vectors may produce artifacts, for example particles. In such cases, a responsive pixel mask can be set for these objects. Any texture format can be used for the mask, as long as the mask value is in the R channel.

Resource States

X^eSS expects all input textures to be in the state D3D12_RESOURCE_STATE_NON_PIXEL_SHADER_RESOURCE, and the output texture to be in the state D3D12_RESOURCE_STATE_UNORDERED_ACCESS.

Resource Formats

X^eSS expects all input textures to be typed. For typeless formats X^eSS performs a conversion according to the following table:

Mip Bias

To preserve texture details at the target resolution, X^eSS requires an additional mip bias of (log2(frac{Input Width}{Target Width})). For example, a mip bias of -1 should be applied for 2x resolution scaling. In certain cases, increasing mip bias even more leads to an additional visual quality improvement; this comes with a potential performance overhead, however, due to increased memory bandwidth requirements, and potentially lower temporal stability resulting in flickering and moire. You are, of course, free to experiment with more or less aggressive texture LOD biases to find the right balance.

Initialization

First create an X^eSS context, as shown below. On Intel GPUs, this step loads the latest Intel-optimized implementation of X^eSS. The returned context handle can then be used for initialization and execution.

xess_context_handle_t context;
xessD3D12CreateContext(pD3D12Device, &context)

Before initializing X^eSS, the user can request a pipeline pre-build process to avoid costly kernel compilation and pipeline creation during initialization.

xessD3D12BuildPipelines(context, NULL, false, initFlags);

The xessD3D12Init function is then called to initialize X^eSS. During initialization, X^eSS can create staging buffers and copy queues to upload weights. These will be destroyed at the end of initialization. The X^eSS storage and layer specializations are determined by the target resolution. Therefore, the target width and height must be set during initialization.

xess_d3d12_init_params_t initParams;
initParams.outputWidth = 3840;
initParams.outputHeight = 2160;
initParams.initFlags = XESS_INIT_FLAG_HIGH_RES_MV;
initParams.pTempStorageHeap = NULL;

xessD3D12Init(&context, &initParams);

X^eSS includes three types of storage:

• Persistent Output-Independent Storage: persistent storage such as weights are internally allocated and uploaded by X^eSS during initialization.
• Persistent Output-Dependent Storage: persistent storage such as internal history texture.
• Temporary Storage: temporary storage only has valid data during the execution of X^eSS.

Allocate temporary storage either internally in a library-managed heap (default), or in a heap provided by the user in the pTempStorageHeap field of the xess_d3d12_init_params_t structure. If you allocate the temporary storage, it can be reused outside of X^eSS execution.

ComPtr<ID3D12Heap> pHeap;
CD3DX12_HEAP_DESC heapDesc(xessProp.tempHeapSize,D3D12_HEAP_TYPE_DEFAULT);

d3dDevice->CreateHeap(&heapDesc, IID_PPV_ARGS(&pHeap));

initParams.tempStorageOffset = 0;
initParams.pTempStorageHeap = pHeap.Get();

xessD3D12Init(&context, &initParams);

You can specify the XESS_INIT_FLAG_EXTERNAL_DESCRIPTOR_HEAP initialization flag to use the external descriptor heap later at the execution stage.

You can also re-initialize X^eSS if there is a change in the target resolution, or any other initialization parameter. However, pending X^eSS command lists must be completed before re-initialization. When temporary X^eSS storage is allocated, it is your responsibility to de-allocate, or reallocate, the heap. Quality preset changes are free, but any other parameters change may lead to longer xessD3D12Init execution times.

Execution

The X^eSS execution function does not involve any GPU workloads, rather it records XeSS commands into the specified command list. The command list is then enqueued by the user. That means it is your responsibility to make sure all input/output resources are alive at the time of the actual GPU execution.

By default, X^eSS creates an internal descriptor heap, but if you have specified XESS_INIT_FLAG_EXTERNAL_DESCRIPTOR_HEAP at the initialization stage, you can pass the pointer to the external descriptor heap and its offset in execution parameters.

If the EXTERNAL_DESCRIPTOR_HEAP flag has been specified in xessD3D12Init parameters, you must create descriptors for the input and output buffers in contiguous locations in the same descriptor heap as the internal descriptors. The external descriptor heap is passed via the pDescriptorHeap field of the xess_d3d12_execute_params_t structure. DescriptorHeapOffset should point to the X^eSS descriptor table.

The resolution of the input image depends on the desired quality setting and target resolution. Call xessGetInputResolution at any point of execution to determine the correct input resolution based on quality setting and target resolution, then provide this input resolution as part the xess_d3d12_execute_params_t structure. Please note that dynamic resolution scaling is not supported by X^eSS.

xess_d3d12_execute_params_t params;
    params.jitterOffsetX    = 0.4375f;
    params.jitterOffsetY    = 0.3579f;

    params.inputWidth = 1920;
    params.inputHeight = 1080;

    // xess records commands into the command list
    xessD3D12Execute(&context, pd3dCommandList, &params);

    // Application may record more commands as needed
    pD3D12GraphicsCommandList->Close();

    // Application submits the command list for GPU execution
    pCommandQueue->ExecuteCommandLists(1, &pCommandLists);

Jitter scale

The function xessSetJitterScale applies a scaling factor to the jitter offset. This might be useful if the application stores jitter in units other than pixels. For example: NDC jitter can be converted to a pixel jitter by setting an appropriate scale.

Velocity scale

The function xessSetVelocityScale applies a scaling factor to the velocity. This might be useful if the application stores velocity in units other than pixels. For example, a normalized viewport velocity can be converted to pixel velocity by setting an appropriate scale.

Debug and Logging Capabilities

Logging Callback

The X^eSS SDK provides an API to set logging callback. Use function xessSetLoggingCallback to define a function to be called in the following circumstances:

• Callback can be called from different threads.
• Callback can be called simultaneously from several threads.
• Message pointer only valid inside function and may be invalid right after return call.

• Message is a null-terminated utf-8 string.

Input Dump Functionality

X^eSS SDK provides an API to dump SDK inputs, outputs and history state. To dump inputs, the application should call function xessStartDump. Due to internal implementation, SDK can dump fewer frames than provided in frame_count fie field of the _dump_parameters_t structure.

Recommended Practices

Visual Quality

We recommend you run X^eSS in the beginning of the post-processing chain, before the tone-mapping. Execution after tone-mapping is possible in certain scenarios; however, this mode is experimental, and good quality is not guaranteed.

The following considerations should be considered to maximize image quality:

• Use high-, or ultra-high-, quality setting for screen-space ambient occlusion (SSAO) and shadows.
• Turn off any techniques for shading-rate reduction and rendering resolution scaling, such as variable rate shading (VRS), adaptive shading, checkerboard rendering, dither, etc.
• Avoid using quarter-resolution effects before X^eSS upscaling.
• Do not rely on X^eSS for any kind of denoising; noisy signal significantly hurts reconstruction quality.
• Use fp16 precision for the color buffer in scene linear HDR space.
• Use fp16 precision for the velocity buffer.
• Adjust mip bias to maximize image quality and keep overhead under control.

• Provide an appropriate scene exposure value. Correct exposure is essential to minimize ghosting of moving objects, blurriness, and precise brightness reconstruction.

Driver Verification

For the best performance and quality, install the latest driver. To facilitate this, after initialization with xessD3D12CreateContext, call function xessIsOptimalDriver to verify the driver installed will provide the best possible experience. If XESS_RESULT_WARNING_OLD_DRIVER is returned from this function, an advisory message or notice should be displayed to the user recommending they install a newer driver.  XESS_RESULT_WARNING_OLD_DRIVER is not a fatal error, and the user should be allowed to continue.

Debugging Tips

Motion Vectors Debugging

If X^eSS is producing an aliased or shaky image, it is worth concentrating on static scene debugging:

• Emulate zero time-delta between frames in the engine to maintain a fully static scene.
• Set 0 motion vector scale to exclude potential issues with motion vectors.
• Significantly increase the length of a repeated jitter pattern.

X^eSS should produce high-quality, super sampled images. If this does not happen, there might be problems with jitter sequence or the input textures' contents; otherwise, the problem is most likely in the decoding of motion vectors. Make sure that motion vectors buffer contents correspond to currently set units (NDC or pixels), and axis directions are correct. Try playing with plus or minus 1 motion vectors scale factors to align coordinate axis appropriately.

Jitter Offset Debugging

If the static scene does not look good, try playing with plus or minus 1 jitter offset scaling to appropriately align the coordinate axis. Make sure jitter does not fall off outside of [-0.5, 0.5] bounds.

Additional Resources

• Survey of temporal anti-aliasing techniques
• Intel® Arc™ landing page
• Intel® X^e Super Sampling Plugin for Unreal* Engine on GitHub
• DirectX download page