Fix Windows Vulkan build: link dxgi for the DXGI presenter regardless of backend

[awemancba]

Title

Fix Windows Vulkan build: link dxgi for the DXGI presenter regardless of backend

Problem

On Windows, building with -DREXGLUE_USE_D3D12=OFF -DREXGLUE_USE_VULKAN=ON fails at link time:

lld-link: error: undefined symbol: CreateDXGIFactory1
>>> referenced by rexglue-sdk/src/ui/presenter.cpp:1462

The presenter (rexui) uses DXGI for the swapchain on Windows regardless of the graphics backend, but dxgi was only linked in the D3D12 branch of src/graphics/CMakeLists.txt.

Change

if(REXGLUE_USE_VULKAN)
    target_link_libraries(rexgraphics PUBLIC volk::volk glslang::SPIRV GPUOpen::VulkanMemoryAllocator)
    if(WIN32)
        target_link_libraries(rexgraphics PUBLIC dxgi)   # ← added
    endif()
    ...
endif()

Also in this PR

README section "Building with Vulkan on Windows" — configure command, plus notes:

• the SDK output dir (tools/rexglue-sdk/out/win-amd64) is shared between the D3D12 and Vulkan builds, so the Vulkan build overwrites rexruntimerd.dll there;
• a RelWithDebInfo/Release build type is required (without -DNDEBUG, the render-path assertions fire on the interlock path).

Testing

Built and ran on Windows 11 / AMD Radeon RX 6700: Vulkan instance 1.4.341, FMV playback works, 90-minute session stable, clean shutdown.

Files changed

• tools/rexglue-sdk/src/graphics/CMakeLists.txt (+5)
• README.md (+33)

[qodo-code-review]

PR Summary by Qodo

Fix Windows Vulkan link: always link DXGI for the presenter swapchain

🐞 Bug fix 📝 Documentation ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Fix Windows Vulkan link failure by linking DXGI when Vulkan backend is enabled.
• Document Vulkan-on-Windows build command and backend-specific caveats.
• Call out shared SDK output dir and Release/RelWithDebInfo requirement to avoid asserts.

Diagram

graph TD
A["Windows Vulkan build"] --> B["rexgraphics (CMake)"] --> C["rexui presenter"] --> D[("dxgi")]
A --> E["README: Vulkan on Win"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Link DXGI from rexui on WIN32 (regardless of backend)

• ➕ Matches ownership: presenter lives in rexui and is the DXGI user.
• ➕ Avoids duplicating backend conditionals across graphics targets.
• ➕ Ensures future backends still pick up DXGI automatically on Windows.
• ➖ May require auditing that rexui is always part of the final link in every build mode (OBJECT library usage requirements can be subtle).
• ➖ Could add an unconditional Windows dependency to rexui even if some configurations never instantiate the presenter.

2. Link DXGI at the final executable/app target

• ➕ Guaranteed to affect the actual link step that produces simpsons.exe / DLLs.
• ➕ Keeps low-level libs free of platform-specific link directives.
• ➖ Easy to forget for other consumers/tests that link the SDK differently.
• ➖ Spreads platform linkage across top-level targets instead of the library that needs it.

Recommendation: Current approach is acceptable and fixes the immediate Vulkan-on-Windows linker failure with minimal risk. If DXGI usage is truly presenter-owned and backend-independent, consider moving the WIN32 dxgi dependency to rexui (or a dedicated presenter target) to better reflect layering and prevent similar issues when adding/adjusting backends.

Files changed (2) +38 / -0

Bug fix (1) +5 / -0

CMakeLists.txtLink dxgi for Vulkan builds on Windows +5/-0

Link dxgi for Vulkan builds on Windows

• When REXGLUE_USE_VULKAN is enabled on WIN32, adds dxgi to rexgraphics link libraries. This resolves missing CreateDXGIFactory1 by ensuring DXGI is available even when the graphics backend is Vulkan.

tools/rexglue-sdk/src/graphics/CMakeLists.txt

Documentation (1) +33 / -0

README.mdDocument Vulkan backend build workflow on Windows +33/-0

Document Vulkan backend build workflow on Windows

• Adds a new "Building with Vulkan on Windows" section including a PowerShell configure/build command. Documents why DXGI is needed for the presenter, warns about the shared SDK output directory between D3D12 and Vulkan builds, and notes that Release/RelWithDebInfo is required to avoid render-path assertions.

README.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. DXGI dependency mis-attributed 🐞 Bug ⚙ Maintainability

Description

The DXGI symbol (CreateDXGIFactory1) is referenced from rexui’s presenter on Windows, but this PR
adds dxgi linkage under rexgraphics’ Vulkan branch, leaving rexui’s own Windows platform
dependencies still backend-conditional. This spreads a platform dependency across multiple
targets/backends, making the build graph harder to reason about and easier to regress later.

Code

tools/rexglue-sdk/src/graphics/CMakeLists.txt[R133-137]

+    # The presenter (rexui) uses DXGI for the swapchain/display on Windows
+    # regardless of the graphics backend.
+    if(WIN32)
+        target_link_libraries(rexgraphics PUBLIC dxgi)
+    endif()

Evidence

The presenter’s Windows code directly calls CreateDXGIFactory1, so DXGI is a presenter/platform
dependency. However, rexui only links dxgi when D3D12 is enabled, and the PR instead adds dxgi
under the Vulkan block of rexgraphics, which is a different target than where the DXGI callsite
lives.

tools/rexglue-sdk/src/ui/presenter.cpp[1437-1464]
tools/rexglue-sdk/src/ui/CMakeLists.txt[133-161]
tools/rexglue-sdk/src/graphics/CMakeLists.txt[127-137]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CreateDXGIFactory1` is called from `rexui` (the presenter) on Windows, but the PR links `dxgi` from the Vulkan branch of `rexgraphics`. This makes the DXGI dependency non-local to the target that actually needs it, and keeps `rexui`’s Windows DXGI linkage dependent on backend configuration.

### Issue Context
- `Presenter` uses DXGI on Windows regardless of backend.
- `rexui` currently links `dxgi` only in the D3D12 block, not as a general Windows dependency.

### Fix Focus Areas
- tools/rexglue-sdk/src/ui/CMakeLists.txt[133-161]
- tools/rexglue-sdk/src/graphics/CMakeLists.txt[127-137]

### Suggested change
- Add `dxgi` to the `if(WIN32)` platform dependencies of `rexui` (keep `dxguid`/`dxc-headers` under the D3D12 block if they’re D3D12-specific).
- Optionally remove the Vulkan-specific `dxgi` linkage from `rexgraphics` to avoid duplicating responsibility across targets.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-code-review]

1. Dxgi dependency mis-attributed 🐞 Bug ⚙ Maintainability

The DXGI symbol (CreateDXGIFactory1) is referenced from rexui’s presenter on Windows, but this PR
adds dxgi linkage under rexgraphics’ Vulkan branch, leaving rexui’s own Windows platform
dependencies still backend-conditional. This spreads a platform dependency across multiple
targets/backends, making the build graph harder to reason about and easier to regress later.

Agent Prompt

### Issue description
`CreateDXGIFactory1` is called from `rexui` (the presenter) on Windows, but the PR links `dxgi` from the Vulkan branch of `rexgraphics`. This makes the DXGI dependency non-local to the target that actually needs it, and keeps `rexui`’s Windows DXGI linkage dependent on backend configuration.

### Issue Context
- `Presenter` uses DXGI on Windows regardless of backend.
- `rexui` currently links `dxgi` only in the D3D12 block, not as a general Windows dependency.

### Fix Focus Areas
- tools/rexglue-sdk/src/ui/CMakeLists.txt[133-161]
- tools/rexglue-sdk/src/graphics/CMakeLists.txt[127-137]

### Suggested change
- Add `dxgi` to the `if(WIN32)` platform dependencies of `rexui` (keep `dxguid`/`dxc-headers` under the D3D12 block if they’re D3D12-specific).
- Optionally remove the Vulkan-specific `dxgi` linkage from `rexgraphics` to avoid duplicating responsibility across targets.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[YesterMester]

this looks great thank you for the contribution if the workflow passes I will integrate this into the repo