Add opt-in FSR 4 Native AA on Windows Vulkan #577

Closed

oscarrc91 wants to merge 6 commits from feat/fsr4-native-aa into main

oscarrc91 commented

2026-11-08 12:43:15 +00:00

(Migrated from github.com)

Kokiri Forest's character and foliage edges show pronounced aliasing and shimmer on my RX 9070 XT. This adds an experimental, opt-in FSR 4 Native AA resolve before the HUD, using the scene's existing dimensions. The default renderer and quality settings stay unchanged. Related requests: #305, #67 and #19.

Dependencies for the verified 1440p setup: the fixed-scale refresh from #329 (HOS_FIX_RES=1) and the base-scale option from #578 (HOS_SCENE_NATIVE=1), with fixed Resolution 100%. These are separate proposals; their code is not copied into this PR. Native AA requires matching color, depth and output dimensions. Without #329, a comparison run still rendered 1920x1080 into 2560x1440 and correctly did not initialize FSR. This branch alone is not a verified standalone configuration; please account for the dependencies before merging.

Scope

RX_VK_FSR_NATIVE_AA=1 enables the Windows Vulkan path with single-worker replay. RX_VK_FSR_SHARPNESS=0..1 optionally enables SDK sharpening; the default is 0.
Read the submitted camera through ub_read during ordered replay, match full-size D32 depth, apply viewport jitter and replace the identified final native AA compute resolve before the HUD.
Load the official AMD Vulkan runtime only when requested and require an actual FSR 4.x provider. Missing or unsupported runtimes retain the original resolve. Include five unmodified MIT API headers from FidelityFX SDK 2.4.0 with provenance, but no runtime DLLs.
Include game-free camera/option tests, CI wiring, authored compute shaders and setup/review notes in docs/fsr-native-aa.md. With the new Windows launcher layout, optional AMD DLLs belong beside the actual game and renderer in bin/.

This does not add DLSS, frame generation, internal-resolution changes, texture MIP bias, forced anisotropy, FXAA or personal cache/synchronization defaults.

Validation

Gameplay verified on 2026-11-08: isolated integration of this PR, #578 and the existing #329 commit on upstream 3f5b0aa (source fingerprint 9882ef6b). Windows, RX 9070 XT, driver 32.0.32015.7029, Ryzen 7 7800X3D; Kokiri Forest near Saria, fixed Resolution 100%, sharpening 0.4, frame generation off.
Logs identify FSR 4.1.2 at 2560x1440, with at least 2,520 successful dispatches. Resolve guards require matching color/depth/output sizes; the native network report also shows 2560x1440 input and output. No FSR SDK error, dispatch failure or device-lost entry appeared in the captured log. The player approved the image and stability.
Nineteen gameplay presentation samples had a median of 52.2 FPS (47.4-54.8). This is not a controlled benchmark or an FPS-gain claim.
Camera math and 26 option checks pass. Dynamic-state, draw/descriptor caching, uniform-read, pass-hazard, dispatch-clock and frame-generation regressions pass. Both authored shaders validate for Vulkan 1.2; regenerated SPIR-V matches the embedded headers, and all five API headers match AMD's pinned commit byte-for-byte.
Updated to upstream ddba87c: the isolated Windows Vulkan renderer compiles and links; camera/options, dynamic-state, draw/binding, pass-hazard, frame-generation, upscale-fallback, 3D-view and present-trace checks pass. This later upstream merge has build/regression coverage, not a new gameplay run.

The #329 author/commit is retained in private integration history. Neither public contribution includes its implementation. GitHub Actions for the fork contribution awaits maintainer approval; local results do not imply upstream CI has passed.

Known limits and review targets

Motion vectors are camera-only: independently moving characters, foliage and particles can ghost. There are no reactive or transparency/composition masks. The first context size is retained for the process lifetime; other sizes fall back. Intermediate native AA compute passes still execute. Camera/resolve matching is specific to the supported game build, and gameplay coverage is limited to the starting area and one GPU/driver.

Wider area/menu/cutscene tests, moving-object/disocclusion checks, resize handling and other hardware need validation. Lower resolution percentages are not validated, and #329 documents unresolved issues in those modes. The feature remains off by default. Feedback on this integration point is welcome before expanding it or adding UI/distribution integration.

AI assistance: OpenAI Codex; recorded in commit trailers. No game code, generated game shaders, saves, caches or runtime binaries are included.

Kokiri Forest's character and foliage edges show pronounced aliasing and shimmer on my RX 9070 XT. This adds an **experimental, opt-in FSR 4 Native AA resolve** before the HUD, using the scene's existing dimensions. The default renderer and quality settings stay unchanged. Related requests: #305, #67 and #19. **Dependencies for the verified 1440p setup:** the fixed-scale refresh from #329 (`HOS_FIX_RES=1`) and the base-scale option from #578 (`HOS_SCENE_NATIVE=1`), with fixed Resolution 100%. These are separate proposals; their code is not copied into this PR. Native AA requires matching color, depth and output dimensions. Without #329, a comparison run still rendered 1920x1080 into 2560x1440 and correctly did not initialize FSR. This branch alone is not a verified standalone configuration; please account for the dependencies before merging. ### Scope - `RX_VK_FSR_NATIVE_AA=1` enables the Windows Vulkan path with single-worker replay. `RX_VK_FSR_SHARPNESS=0..1` optionally enables SDK sharpening; the default is 0. - Read the submitted camera through `ub_read` during ordered replay, match full-size D32 depth, apply viewport jitter and replace the identified final native AA compute resolve before the HUD. - Load the official AMD Vulkan runtime only when requested and require an actual FSR 4.x provider. Missing or unsupported runtimes retain the original resolve. Include five unmodified MIT API headers from FidelityFX SDK 2.4.0 with provenance, but no runtime DLLs. - Include game-free camera/option tests, CI wiring, authored compute shaders and setup/review notes in `docs/fsr-native-aa.md`. With the new Windows launcher layout, optional AMD DLLs belong beside the actual game and renderer in `bin/`. This does not add DLSS, frame generation, internal-resolution changes, texture MIP bias, forced anisotropy, FXAA or personal cache/synchronization defaults. ### Validation - **Gameplay verified on 2026-11-08:** isolated integration of this PR, #578 and the existing #329 commit on upstream `3f5b0aa` (source fingerprint `9882ef6b`). Windows, RX 9070 XT, driver 32.0.32015.7029, Ryzen 7 7800X3D; Kokiri Forest near Saria, fixed Resolution 100%, sharpening 0.4, frame generation off. - Logs identify **FSR 4.1.2 at 2560x1440**, with at least **2,520 successful dispatches**. Resolve guards require matching color/depth/output sizes; the native network report also shows 2560x1440 input and output. No FSR SDK error, dispatch failure or device-lost entry appeared in the captured log. The player approved the image and stability. - Nineteen gameplay presentation samples had a median of 52.2 FPS (47.4-54.8). This is not a controlled benchmark or an FPS-gain claim. - Camera math and 26 option checks pass. Dynamic-state, draw/descriptor caching, uniform-read, pass-hazard, dispatch-clock and frame-generation regressions pass. Both authored shaders validate for Vulkan 1.2; regenerated SPIR-V matches the embedded headers, and all five API headers match AMD's pinned commit byte-for-byte. - **Updated to upstream `ddba87c`:** the isolated Windows Vulkan renderer compiles and links; camera/options, dynamic-state, draw/binding, pass-hazard, frame-generation, upscale-fallback, 3D-view and present-trace checks pass. This later upstream merge has build/regression coverage, not a new gameplay run. The #329 author/commit is retained in private integration history. Neither public contribution includes its implementation. GitHub Actions for the fork contribution awaits maintainer approval; local results do not imply upstream CI has passed. ### Known limits and review targets Motion vectors are **camera-only**: independently moving characters, foliage and particles can ghost. There are no reactive or transparency/composition masks. The first context size is retained for the process lifetime; other sizes fall back. Intermediate native AA compute passes still execute. Camera/resolve matching is specific to the supported game build, and gameplay coverage is limited to the starting area and one GPU/driver. Wider area/menu/cutscene tests, moving-object/disocclusion checks, resize handling and other hardware need validation. Lower resolution percentages are not validated, and #329 documents unresolved issues in those modes. The feature remains off by default. Feedback on this integration point is welcome before expanding it or adding UI/distribution integration. AI assistance: OpenAI Codex; recorded in commit trailers. No game code, generated game shaders, saves, caches or runtime binaries are included.

Kirkidoo commented

2026-11-08 17:48:15 +00:00

(Migrated from github.com)

FSR 4 starts correctly. The log shows FSR 4.1.2 context ready, Native AA 2560x1440, and the dispatches run with no failures.

Problems I see:

Jumping into water causes lightning-like flashes at the edges of the screen.
Characters such as Link sometimes turn extremely bright for a moment.
Both go away with RX_VK_FSR_NATIVE_AA=0 and the same build and settings.

This may be the camera-only motion vectors you mention in the docs. Happy to test a new version.

Clip (FSR 4 on, jumping into water in Kokiri Forest):
https://github.com/user-attachments/assets/64cc451c-b2eb-4bed-aefd-d30b3ee94887

Tested on an RX 9070 XT, Windows 11. I used v2.0.2 with #329, #578, #593 and this PR, at fixed Resolution 100%, with HOS_FIX_RES=1, HOS_SCENE_NATIVE=1, RX_VK_FSR_NATIVE_AA=1, RX_VK_FSR_SHARPNESS=0.4 and RX_VK_TAAU_KEYS=-. FSR 4 starts correctly. The log shows FSR 4.1.2 context ready, Native AA 2560x1440, and the dispatches run with no failures. Problems I see: Jumping into water causes lightning-like flashes at the edges of the screen. Characters such as Link sometimes turn extremely bright for a moment. Both go away with RX_VK_FSR_NATIVE_AA=0 and the same build and settings. This may be the camera-only motion vectors you mention in the docs. Happy to test a new version. Clip (FSR 4 on, jumping into water in Kokiri Forest): https://github.com/user-attachments/assets/64cc451c-b2eb-4bed-aefd-d30b3ee94887

NotRexed commented

2026-11-09 05:29:46 +00:00

(Migrated from github.com)