How to Update RenoDX to the Latest Version: A Step-by-Step Guide

Pull the latest commits, update submodules, run setup-dev-env.ps1 -Update, and rebuild with CMake to update RenoDX to the latest version.

Updating RenoDX requires synchronizing three layers: the source code from the Git repository, external dependencies via submodules, and managed build toolchains. This guide walks through the complete update process based on the official repository structure at clshortfuse/renodx.

Understanding the Update Layers

RenoDX is a DirectX-modding engine that depends on multiple moving parts. Breaking the update into layers prevents version mismatches and build failures.

Layer	Contents	Update Method
Source code	C++ core, HLSL shaders, ReShade add-on projects	git pull and submodule refresh
Managed toolchain	DXC, glslang, Slang binaries in ./bin	setup-dev-env.ps1 -Update
Build artifacts	Compiled add-ons (*.addon64, devkit, MCP bridge)	CMake rebuild

Each layer must be updated in sequence. Skipping the toolchain refresh causes CMake to detect stale compilers; skipping the submodule update leaves external libraries out of sync with the main branch.

Step 1: Pull the Latest Repository State

Start by fetching the newest commits from the upstream repository. The main branch contains the stable release line.

git pull --rebase origin main

This command fast-forwards your local branch to match origin/main without merge commits. If you have local changes, stash them first or resolve rebase conflicts as prompted.

Step 2: Update Git Submodules

RenoDX stores external dependencies under external/ as Git submodules. These libraries must be synchronized separately.

git submodule update --init --recursive

The --recursive flag ensures nested submodules refresh at all depths. This step is documented in docs/CONTRIBUTING.md as a required step after pulling.

Step 3: Refresh the Managed Toolchain

The scripts/setup-dev-env.ps1 PowerShell script automates tool management. It reads version requirements from cmake/tool-versions.cmake and downloads matching binaries.

# From the repository root

powershell -ExecutionPolicy Bypass -File .\scripts\setup-dev-env.ps1 -Update

The -Update flag triggers version checks against the matrix defined in cmake/tool-versions.cmake. When newer releases of DXC, glslang, or Slang are available, the script downloads them to ./bin without removing existing installations.

Key implementation details from the source:

• Version matrix lives in cmake/tool-versions.cmake (line 1-30)
• Downloaded tools are cached in ./bin to avoid redundant network requests
• The script never downgrades—existing binaries newer than the matrix minimum are preserved

Step 4: Reconfigure CMake

After updating tools, regenerate the build system so CMake detects new compiler paths.

cmake --preset clang-x64

Replace clang-x64 with your preferred preset from CMakePresets.json. Available presets include:

• clang-x64 — LLVM/Clang toolchain (recommended)
• ninja-x64 — Ninja generator with MSVC
• vs-x64 — Visual Studio 2022 generator

Reconfiguration is necessary because CMake caches absolute paths to tools like DXC. Without this step, the build may reference stale binaries.

Step 5: Rebuild Core and Add-ons

Compile the updated source with your active preset. For release binaries:

cmake --build --preset clang-x64-release

For development tools that support live inspection:

cmake --build --preset clang-x64-debug --target devkit mcp_bridge

Build outputs include:

• renodx.addon64 — Core ReShade add-on
• renodx-devkit.addon64 — Runtime shader inspection tool
• mcp_bridge.exe — Model-context-protocol bridge for external editors

Step 6: Validate with Tests (Optional)

Run the integrated test suite to verify toolchain compatibility:

ctest --preset clang-x64-release

Tests under test/ validate swap-chain upgrades, shader injection, and API wrapping. Failures here typically indicate version mismatches between the source and toolchain.

Step 7: Refresh Distribution Artifacts

If you maintain a local release folder or GitHub Pages deployment, copy the newly built binaries:

cp out/build/clang-x64-release/src/reshadefx/*.addon64 ./dist/

This ensures your distribution matches the updated codebase.

Common Update Patterns

Quick Daily Update

For active development, combine the essential steps:

git pull --rebase origin main
git submodule update --init --recursive
powershell -ExecutionPolicy Bypass -File .\scripts\setup-dev-env.ps1 -Update
cmake --preset clang-x64
cmake --build --preset clang-x64-release

Clean Slate After Long Gaps

If your local copy is significantly behind upstream, use a fresh build directory to avoid stale cache issues:

git pull --rebase origin main
git submodule update --init --recursive
rms -Recurse -Force out/   # Remove old build artifacts

powershell -ExecutionPolicy Bypass -File .\scripts\setup-dev-env.ps1 -Update
cmake --preset clang-x64
cmake --build --preset clang-x64-release

Summary

• Pull source: git pull --rebase origin main synchronizes the repository
• Update dependencies: git submodule update --init --recursive refreshes external libraries
• Refresh tools: setup-dev-env.ps1 -Update downloads new DXC, glslang, and Slang releases
• Rebuild: CMake reconfiguration and build presets regenerate all artifacts
• Validate: ctest confirms the update works correctly

Following this layered approach ensures your RenoDX installation stays current with upstream changes, security patches, and performance improvements.

Frequently Asked Questions

How often should I update RenoDX?

Update when you need new features, bug fixes, or shader improvements. The repository sees active development; checking origin/main weekly or before starting new mod projects keeps your toolchain current. Critical compiler updates in cmake/tool-versions.cmake are announced in commit messages.

What happens if I skip the setup-dev-env.ps1 -Update step?

CMake may fail to detect required tools or use outdated compiler versions. This produces shader compilation errors, particularly with HLSL 2021 features or Slang syntax that newer tool releases support. The build logs will show "DXC not found" or version mismatch warnings before failing.

Can I use a different compiler preset after updating?

Yes. Switch presets by running cmake --preset <new-name> from a clean state. The tool versions in cmake/tool-versions.cmake are preset-agnostic—DXC and glslang work across Clang, MSVC, and Ninja generators. Delete your out/ directory when switching to prevent generator conflicts.

Where are the managed tools stored after running the update script?

All downloaded binaries live in ./bin relative to the repository root. Each tool has a subfolder (e.g., ./bin/dxc/, ./bin/glslang/) with version-tagged directories. The script adds these paths to your environment during CMake configuration via cmake/toolchain/*.cmake files.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}