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

> Update RenoDX to the latest version with our easy step by step guide. Learn how to pull commits, update submodules, and rebuild with CMake.

- Repository: [Carlos Lopez/renodx](https://github.com/clshortfuse/renodx)
- Tags: how-to-guide
- Published: 2026-09-06

---

**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.

```bash
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.

```bash
git submodule update --init --recursive

```

The `--recursive` flag ensures nested submodules refresh at all depths. This step is documented in [`docs/CONTRIBUTING.md`](https://github.com/clshortfuse/renodx/blob/main/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.

```powershell

# 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.

```bash
cmake --preset clang-x64

```

Replace `clang-x64` with your preferred preset from [`CMakePresets.json`](https://github.com/clshortfuse/renodx/blob/main/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:

```bash
cmake --build --preset clang-x64-release

```

For development tools that support live inspection:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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.