XeUnlock

Unlocks the Intel Xe features that ship inside Resident Evil Requiem but were never wired up.

The game bundles all three Intel SDKs — XeSS Super Resolution, XeSS Frame Generation and Xe Low Latency — fully integrated into the render pipeline, with first-class engine classes sitting right next to DLSS and FSR3. Capcom shipped the rendering integration and never shipped the configuration layer. Nothing in the options menu exposes any of it.

XeUnlock is a single REFramework Lua script that calls the engine's own interfaces directly and turns them on.

XeSS Super Resolution	quality selectable at runtime (the game hardcodes the worst mode)
XeSS Frame Generation	enabled — the game's native XeFG, not a translation layer
Xe Low Latency	already active out of the box; no action needed
Any other upscaler	FSR1/2/3, NIS, AASR, GSR2 selectable too

No game files are modified. XeUnlock is a script plus two existing free tools. Nothing is patched, nothing is redistributed, and a game update can't break a binary patch that doesn't exist.

---

Before you read: how this was made

This was built with an LLM — Claude Opus 5, driving Claude Code, across two sessions.

I'm a medical student and a gamer, not a programmer. I wanted XeSS working properly on my Arc card for myself, and I used Claude Code to get there. It ended up working well enough that sharing it seemed better than keeping it private — the Arc modding scene is thin, and this particular door turned out to be unlocked the whole time.

I'm not claiming this is the best or the only solution. Someone who actually writes code for a living could very likely improve on it, or find a cleaner path entirely. Treat the findings here and in Technical findings as a starting point that happens to be verifiable, not as authority.

What I can say is this: everything marked measured in these documents was actually measured in-game, with the numbers taken from logs rather than impressions. Everything that wasn't is marked untested or not diagnosed, and says so plainly. Where an earlier conclusion turned out to be wrong — and several did — the correction is in the text rather than quietly deleted.

If you know better, please do better with it.

---

Why not just use OptiScaler?

OptiScaler is excellent and solves a different problem. It translates — it intercepts DLSS or FSR calls and redirects them to XeSS/XeFG.

Resident Evil Requiem doesn't need translating. It already has libxess.dll, libxess_fg.dll and libxell.dll sitting next to the executable, statically imported, with the full lifecycle implemented. The switch to turn them on is simply missing from the UI.

XeUnlock flips that switch. One less layer, and the frame generation running is the one Capcom's own engine drives.

---

Requirements

Hardware and game

	Tested with
GPU	Intel Arc B580, driver 32.0.101.8991
Display output	2560x1440
Game	Resident Evil Requiem (Steam), re9.exe

Everything below was verified on exactly one machine with the configuration above. Other Arc cards, drivers, resolutions and game builds are untested. If you try it elsewhere, please report back — especially the quality-index table, which is read from the engine and could differ across builds.

Bundled Intel SDKs (already in your game folder)

DLL	Version
libxess.dll	2.0.2.53
libxess_fg.dll	1.2.0.87
libxell.dll	1.2.0.9

You do not download or replace these. They are already there.

Tools you need

1. REFramework — hosts the script.

• Source: github.com/praydog/REFramework-nightly
• Tested build: nightly 01398, commit 88ece6b7f91d36976a124d4a5f886dac2675b0b8
• Installed as dinput8.dll in the game folder

Pin this version. See Special K is loaded in an unsupported way — a change to REFramework's plugin loader can break the setup without warning.

2. Special K — required to eliminate a severe stutter. Not optional.

• Source: github.com/SpecialKO/SpecialK
• Tested release: SK_26_8_12 (SpecialK.7z, 6,160,595 bytes)
• Installed as reframework/plugins/dxgi.dll — not in the game root

---

Installation

1. Install REFramework. Download the nightly, place dinput8.dll next to re9.exe.

2. Install Special K as a REFramework plugin. Download SpecialK.7z, extract SpecialK64.dll, rename it to dxgi.dll, and place it in:

   <game>/reframework/plugins/dxgi.dll
   

   Do not put it in the game root. Placing Special K's DLL next to re9.exe — the normal "local install" — prevents the game from starting at all. See Dead ends.

3. Install the script.

   <game>/reframework/autorun/xeunlock.lua
   

4. Turn off two post-processing effects in the game's graphics menu:

   • Motion Blur → Off
   • Lens Distortion → Off (this also controls chromatic aberration)

   These are required, not preferences. See Required game settings.

5. Launch the game and press Insert to open the REFramework overlay. Expand the XeUnlock node.

Final layout:

<game>/
  re9.exe
  dinput8.dll                       REFramework
  reframework/
    plugins/dxgi.dll                Special K
    autorun/xeunlock.lua            XeUnlock

---

Usage

The panel has three sections.

Step 1 — pick the upscaler

Verify which are available queries the engine. On an Arc B580 the answer was:

Available	Not available
FSR1, FSR2, FSR3, XESS, NIS, AASR, GSR2	None, DLSS, DLAA, MetalFX (both), PSSR, NDSR, DirectSR

Click XESS to select it. Enable upscaling / DISABLE upscaling toggle it entirely.

Your choice persists — the game writes it back to config.ini on exit.

Step 2 — quality

Click Probe level names and the panel fills itself in from the engine. For XeSS:

Index	Name
0	NativeAA
1	UltraQualityPlus
2	UltraQuality
3	Quality
4	Balanced
5	Performance
6	UltraPerformance

Index 0 is the best quality, 6 is the most aggressive.

Two things to know:

• The index space is different for every upscaler. XeSS's index 0 is not FSR3's index 0. This is why the panel asks the engine instead of hardcoding a table.
• Quality does not persist. There is no XeSS quality key in config.ini — that absence is the original bug. You reselect it each session.

Step 3 — frame generation

ENABLE XeSS FG turns on native XeFG. Disable FG turns it off.

The MFG buttons (set_GenerateFramesCount) are present but do not work — see Known issues.

---

Required game settings

Motion Blur      → Off
Lens Distortion  → Off

With these enabled, ghosting is severe at higher quality levels. With them off, it disappears completely — at every quality level, with and without frame generation.

This is not an XeSS defect. Temporal upscalers reconstruct the image from motion vectors. Motion blur smears the input and destroys the pixel-to-vector correspondence. Lens distortion and chromatic aberration warp the image in screen space after the vectors were computed, so the upscaler receives a frame that no longer matches the motion it was told about. The more temporal information accumulates — that is, the higher the quality level — the worse it gets.

Corroboration from the SDK itself: via.render.XeSSFrameGenerationInterface exposes set_UseBidirectionalDistortionField. Intel does not add a bidirectional distortion field to a frame generation SDK for no reason — it exists precisely because lens distortion breaks the motion field.

Untested idea: that flag might allow lens distortion to be re-enabled while keeping frame generation clean.

---

Measured results

Intel Arc B580, 2560x1440, fixed scene, standing still:

Configuration	fps
Base, no frame generation	~75
+ XeSS Frame Generation	~125
+ Arc Control 4x MFG override	~204

Multi-frame generation works through Arc Control's override, layered on top of native XeFG. Native XeFG running is the prerequisite, and XeUnlock provides it.

Beware of measuring frame generation with REFramework's re.on_frame — it counts engine frames, not presented frames, and is completely blind to generated frames. Our internal counter read a flat ~75 while the external counter showed 125. Use an external overlay.

Confirmed working combinations

• XeSS upscaling + FSR3 frame generation
• FSR 3.1.5 upscaling + XeSS frame generation

The two layers are genuinely independent — you can mix upscaler and frame generation across vendors in either direction.

---

How it works, and what was learned getting there

The interesting part is in a separate document, because it is reference material rather than instructions:

→ Technical findings

What's in there:

• The via.render.* interfaces are static facades — no instance exists, sdk.hook installs and never fires. The single most important finding, and the one that generalizes furthest beyond this game.
• Most state getters lie — which ones return real values and which return zero forever, measured.
• The 11-second stutter — why it happens, why Special K fixes it, and the log evidence (17 D3D re-hooks → 0).
• Why Special K must be a plugin, not a local install — the three topologies tested, two of which kill the game.
• The root cause in the data layer — the single boolean Capcom shipped switched off.
• Dead ends — proxy DLL substitution, and three other approaches that each cost a game launch.

Known issues

Native MFG does not work

via.render.XeSSFrameGenerationInterface.set_GenerateFramesCount(n) returns success, and reading the value back on a fresh handle still gives 0. Reproduced across three sessions with values 2, 3 and 4.

Two candidate explanations, neither confirmed: get_XeSSInterface() hands out a new wrapper on every call, so the write may go to a temporary; or get_GenerateFramesCount is simply another lying getter and the write does land.

Not a practical blocker — multi-frame generation works through Arc Control's override.

The buttons are left in the panel deliberately. get_DLSSInterface exists on the same facade, and this may behave differently on NVIDIA hardware. If you have a DLSS-capable card, that is worth trying.

Controller hotplug crashes the game

Connecting or disconnecting an Xbox controller while the game is running causes a crash.

To be precise about what this is and is not:

• not using controller and keyboard together — that works
• not switching input modes during play
• is the connect/disconnect event itself, after the game is open

Workaround: connect the controller before launching.

This has not been diagnosed and there is no evidence yet. The session it occurred in exited cleanly and produced no crash.log. Critically, the baseline was never established — it is unknown whether the unmodded game tolerates hotplug.

If you want to investigate: reproduce and capture logs/crash.log plus the REFramework log, then bisect by removing the Special K plugin, then REFramework. The prime suspect is Special K — it hooks XInput (HookSetState=true) and manages controller slots — but that is a guess, not a finding.

Quality resets each session

There is no XeSS quality key in config.ini to persist to. Upscaler choice persists; quality does not.

---

Caveats

One machine. Arc B580, driver 32.0.101.8991, 1440p, one game build. Nothing here has been reproduced elsewhere.

Pin your REFramework version. The Special K plugin arrangement is not a supported integration and can break silently.

Getters lie. If you extend this script, verify by image and framerate, never by reading state back.

The quality index table is read from the engine, not hardcoded. If a game update changes it, the panel follows automatically. Don't hardcode it — an earlier version of this script did, and had the order exactly backwards.

---

Credits

• REFramework by praydog — github.com/praydog/REFramework
• Special K by Kaldaien / SpecialKO — github.com/SpecialKO/SpecialK
• OptiScaler — for the RE Requiem wiki page that pointed at Special K as the stutter fix, and for the plugin-folder instruction that turned out to be the working topology

XeUnlock modifies no game files and redistributes nothing.