If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/doitsujin/dxvk shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 2d ago
• 10 active contributors
• Zlib licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 80% of recent commits
• ⚠ Non-standard license (Zlib) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live doitsujin/dxvk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/doitsujin/dxvk.

What it runs against: a local clone of doitsujin/dxvk — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in doitsujin/dxvk | Confirms the artifact applies here, not a fork | | 2 | License is still Zlib | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of doitsujin/dxvk. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/doitsujin/dxvk.git
#   cd dxvk
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of doitsujin/dxvk and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "doitsujin/dxvk(\\.git)?\\b" \\
  && ok "origin remote is doitsujin/dxvk" \\
  || miss "origin remote is not doitsujin/dxvk (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Zlib)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Zlib\"" package.json 2>/dev/null) \\
  && ok "license is Zlib" \\
  || miss "license drift — was Zlib at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/d3d11/d3d11_device.cpp" \\
  && ok "src/d3d11/d3d11_device.cpp" \\
  || miss "missing critical file: src/d3d11/d3d11_device.cpp"
test -f "src/d3d11/d3d11_context.cpp" \\
  && ok "src/d3d11/d3d11_context.cpp" \\
  || miss "missing critical file: src/d3d11/d3d11_context.cpp"
test -f "src/d3d10/d3d10_device.cpp" \\
  && ok "src/d3d10/d3d10_device.cpp" \\
  || miss "missing critical file: src/d3d10/d3d10_device.cpp"
test -f "meson.build" \\
  && ok "meson.build" \\
  || miss "missing critical file: meson.build"
test -f "src/d3d11/d3d11_cmd.h" \\
  && ok "src/d3d11/d3d11_cmd.h" \\
  || miss "missing critical file: src/d3d11/d3d11_cmd.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/doitsujin/dxvk"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

DXVK is a Vulkan-based translation layer that converts Direct3D 8/9/10/11 API calls into Vulkan, enabling Windows games and applications to run natively on Linux via Wine without requiring DirectX. It translates graphics workloads from D3D's immediate-mode API to Vulkan's lower-level GPU abstraction, handling shader compilation, state management, and resource binding across four major DirectX versions. Monolithic C++ codebase organized by D3D version: src/d3d8/, src/d3d10/, src/d3d11/ each contain device implementations, shaders, state objects, and command buffers. Common infrastructure lives in src/dxvk/ (core Vulkan wrappers). Build uses Meson with cross-platform targets. Native WSI support in include/native/wsi/ handles SDL2/SDL3/GLFW window integration.

Linux gamers and application developers who want to run Windows games/apps via Wine, and systems integrators (Steam Play, Lutris, Bottles) who distribute gaming environments. Contributors are graphics engineers familiar with GPU drivers, Vulkan, and DirectX internals.

DXVK is production-mature and actively developed. It has been in active development for 8+ years with regular releases on the GitHub releases page, automated CI/CD via GitHub Actions (test-build-windows.yml, artifacts.yml), and extensive real-world usage through Steam Play Proton. The codebase is substantial (6.5M lines of C++) and widely deployed, making it suitable for production use in gaming contexts.

Single-maintainer (doitsujin) creates potential continuity risk, though the project is sufficiently mature that community forks exist. Heavy dependency on Vulkan driver quality and correctness means bugs in GPU drivers can cause application failures that are difficult to debug. The project integrates with Wine/Proton ecosystems which have their own breaking changes; compatibility requires ongoing maintenance across multiple DirectX versions and GPU vendors.

The repo is actively maintained with recent commits. Development focuses are visible in the GitHub Actions workflows (artifacts.yml generates development builds from master branch). The presence of test-build-windows.yml and release automation suggests ongoing compatibility testing. Recent additions like native WSI support (native_sdl3.h) indicate feature expansion beyond core D3D translation.

Clone and build using Meson: git clone https://github.com/doitsujin/dxvk.git && cd dxvk && meson setup build && meson compile -C build. For 64-bit: meson setup build --cross-file build-win64.txt (requires MinGW toolchain). Builds produce DLLs that install into Wine prefix: cp build/src/*.dll $WINEPREFIX/drive_c/windows/system32.

Daily commands: Set environment variable DXVK_HUD=devinfo,fps and run a Windows game via Wine: WINEPREFIX=/path/to/prefix DXVK_HUD=fps wine game.exe. For development: after meson compile -C build, test with DXVK_LOG_LEVEL=debug wine game.exe to see translation logs. No separate dev server; verification done via dxvk.conf configuration and HUD overlay in running applications.

• src/d3d11/d3d11_device.cpp — Core D3D11 device implementation; entry point for all D3D11 API calls and resource creation.
• src/d3d11/d3d11_context.cpp — Immediate context implementation; handles command recording and GPU submission for D3D11 rendering.
• src/d3d10/d3d10_device.cpp — D3D10 device abstraction layer; bridges D3D10 API to underlying Vulkan infrastructure.
• meson.build — Primary build configuration; defines compilation targets for all D3D versions and Vulkan backend.
• src/d3d11/d3d11_cmd.h — Command structure definitions; defines GPU command encoding for all rendering operations.
• dxvk.conf — Runtime configuration defaults; controls DXVK behavior for compatibility and performance tuning.
• README.md — Project overview and installation guide; essential for understanding DXVK's purpose and user-facing setup.

Add D3D11 Device Feature Support

1. Define feature capability enum in d3d11_features.h alongside existing feature flags (src/d3d11/d3d11_features.h)
2. Implement feature detection logic in d3d11_features.cpp based on Vulkan device capabilities (src/d3d11/d3d11_features.cpp)
3. Add feature check in d3d11_device.cpp before exposing API in device creation or CheckFeatureSupport (src/d3d11/d3d11_device.cpp)

Add New Render State Type

1. Create new state class (e.g., d3d11_newstate.h/.cpp) inheriting from ID3D11DeviceChild following existing pattern in d3d11_blend.h (src/d3d11/d3d11_blend.h)
2. Implement Vulkan pipeline state translation in the new state class constructor (src/d3d11/d3d11_blend.cpp)
3. Register factory method in d3d11_device.cpp for CreateNewState() device method (src/d3d11/d3d11_device.cpp)
4. Add state binding in d3d11_context.cpp to apply state during command recording (src/d3d11/d3d11_context.cpp)

Add D3D10 Feature Wrapper

1. Add D3D11 implementation for the feature following D3D11 pattern (src/d3d11/d3d11_device.cpp)
2. Create D3D10 wrapper class in d3d10_device.h delegating to D3D11 device (src/d3d10/d3d10_device.h)
3. Implement wrapper factory method in d3d10_device.cpp calling underlying D3D11 device (src/d3d10/d3d10_device.cpp)

Tune Runtime Behavior via Configuration

1. Add new configuration parameter to dxvk.conf with default value and description (dxvk.conf)
2. Load configuration in d3d11_device.cpp or d3d11_context.cpp during initialization (src/d3d11/d3d11_device.cpp)
3. Apply configuration behavior conditionally throughout rendering pipeline (e.g., d3d11_context.cpp for draw calls) (src/d3d11/d3d11_context.cpp)

• Vulkan — Low-level GPU API with cross-platform support enabling efficient translation of D3D to native graphics commands without emulation overhead
• Wine/WINEPREFIX — Enables Windows binary execution on Linux; DXVK replaces D3D DLLs in Wine to intercept D3D calls and translate them to Vulkan
• Meson Build System — Fast, cross-platform build system suitable for compiling both 32-bit and 64-bit libraries with complex dependencies
• C++ with COM interfaces — Implements Windows COM object model required by D3D APIs; C++ provides performance and type safety for state management

• Direct3D 8, 9, 10, 11 support in single codebase

  • Why: Allows reuse of common Vulkan translation infrastructure; D3D10+ reuse D3D11 implementation
  • Consequence: Added complexity in version abstraction layers; maintenance burden for backward compatibility

• undefined

  • Why: undefined
  • Consequence: undefined

Meson cross-compilation requires MinGW toolchain (gcc-mingw-w64); fails silently if missing. The build produces DLLs that must match Wine architecture (32/64-bit); mixing architectures causes runtime linker errors. DXVK_HUD requires DXVK_LOG_LEVEL=trace/debug to see detailed shader compilation errors—release builds silently fail on shader issues. Vulkan ICD must be installed and discoverable (VK_LAYER_PATH, LIBVULKAN_PATH environment variables); missing driver causes cryptic 'vkCreateInstance failed' errors. Wine prefix must have native DLL overrides explicitly set in winecfg—simply copying DLLs is insufficient.

• API Translation Layer (Thunk Layer) — DXVK's entire purpose is translating D3D API calls to Vulkan equivalents; understanding the thunking pattern is essential to modify D3D interface implementations
• Immediate vs. Deferred Rendering — DXVK converts D3D's immediate-mode API (draw calls execute immediately) to deferred command buffer recording (Vulkan); src/dxvk/dxvk_cmdlist.h implements this conversion
• Descriptor Sets (Vulkan Resource Binding) — Vulkan's descriptor sets replace D3D's texture/sampler binding model; DXVK must pool and allocate descriptor sets efficiently (src/dxvk/dxvk_descriptor.h)
• SPIR-V Shader Compilation — D3D shaders (bytecode format) must compile to SPIR-V for Vulkan; shader compilation errors are a major source of game incompatibilities in DXVK
• COM (Component Object Model) — All D3D interfaces (ID3D11Device, ID3D11DeviceContext) use COM's vtable inheritance; DXVK must implement COM reference counting and interface querying correctly
• Pipeline State Objects (PSO) — Vulkan separates render state (graphics pipeline) and compute state into immutable objects; D3D's mutable state machine must be cached and compiled into PSOs by DXVK (src/dxvk/dxvk_graphics.h)
• Synchronization Primitives (VkSemaphore, VkFence) — DXVK must synchronize GPU work between frames, between D3D context switches, and across Wine process boundaries; incorrect synchronization causes GPU hangs or data races

• lutris/wine — Custom Wine fork that integrates DXVK and other translation layers; primary consumer of DXVK in production gaming
• ValveSoftware/Proton — Valve's Wine-based compatibility layer that bundles DXVK as default D3D implementation for Steam Play on Linux
• wine-mirror/wine — Upstream Wine project that DXVK depends on; DXVK is an alternative to Wine's built-in wined3d Direct3D backend
• KhronosGroup/SPIRV-Cross — SPIR-V shader compilation library used to convert D3D bytecode to platform-agnostic SPIR-V for Vulkan consumption
• doitsujin/dxvk-gplasync — Experimental fork of DXVK exploring GPU-assisted performance synchronization; demonstrates community extensions to core project

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive D3D9 feature parity tests for shader compilation and state management

DXVK supports D3D8/9/10/11 but the repo lacks visible test coverage for D3D9-specific features like fixed-function pipeline emulation, shader constant registers, and render state validation. This is critical since D3D9 is widely used in legacy games. Tests would catch regressions when refactoring shader compilation pipelines across src/d3d9/d3d9_shader.cpp and src/d3d9/d3d9_device.cpp.

• [ ] Create tests/d3d9/ directory with test fixtures for shader compilation
• [ ] Add test cases for fixed-function pipeline state combinations in src/d3d9/
• [ ] Test vertex/pixel shader constant register allocation against Wine/native D3D9 behavior
• [ ] Integrate tests into .github/workflows/test-build-windows.yml with test-build target

Add automated DXGI feature coverage validation with native API comparison

DXVK implements DXGI (src/dxgi/) which is crucial for D3D10/11 initialization, but there's no automated test suite validating DXGI adapter enumeration, output modes, and swap chain creation against actual Vulkan capabilities. This prevents regressions when updating Vulkan feature detection logic and helps catch compatibility issues early.

• [ ] Create tests/dxgi/ directory for DXGI interface tests
• [ ] Add test cases for IDXGIAdapter enumeration, IDXGIOutput mode enumeration (src/dxgi/dxgi_adapter.cpp, src/dxgi/dxgi_output.cpp)
• [ ] Test swap chain creation with various buffer counts and formats against Vulkan surface capabilities
• [ ] Add test workflow step to .github/workflows/ to run DXGI tests on Linux with Vulkan validation layers

Document and add CI validation for native WSI backend implementations (SDL2/SDL3/GLFW)

The codebase includes three window system integration backends in include/native/wsi/ (native_glfw.h, native_sdl2.h, native_sdl3.h) but has no documented test coverage or CI matrix validation that each backend compiles and functions correctly. This creates risk of bit-rot in less-used backends. Adding conditional build tests ensures cross-platform WSI compatibility.

• [ ] Add build matrix to .github/workflows/test-build-windows.yml for -Dwsi_backend=glfw, -Dwsi_backend=sdl2, -Dwsi_backend=sdl3
• [ ] Create tests/native_wsi/ with simple window creation/event loop tests for each backend
• [ ] Document in README.md the WSI backend selection and testing procedure for contributors
• [ ] Add meson_options.txt validation to ensure only one WSI backend is selected at build time

• Add unit tests for D3D state object validation (src/d3d11/d3d11_depth_stencil.cpp, src/d3d11/d3d11_blend.cpp currently have no test coverage visible in repo)
• Document the Vulkan command buffer recording lifecycle in src/dxvk/dxvk_cmdlist.h with inline examples showing how deferred rendering maps to VkCmdBuffer encoding
• Create meson build configuration for clang-cl toolchain (in addition to gcc-mingw-w64) to reduce cross-compilation friction on macOS developer machines

DXVK demonstrates reasonable security practices as a Vulkan translation layer. The codebase is primarily focused on graphics API translation without obvious critical vulnerabilities like hardcoded credentials, SQL injection, or XSS risks. However, potential concerns include: (1) Integer overflow risks in buffer size calculations, (2) Complex COM object lifetime management with use-after-free potential, (3) Unvalidated shader bytecode processing, and (4) Possible race conditions in multithreaded contexts. The project lacks security documentation and vulnerability disclosure policy. No dependency file was provided for supply chain analysis. Recommendations focus on input validation, safe arithmetic operations, comprehensive testing (especially thread safety testing), and security hardening of shader processing pipelines.

• Medium · Potential Integer Overflow in Buffer Operations — src/d3d11/d3d11_buffer.cpp, src/d3d10/d3d10_buffer.cpp. D3D11 buffer handling files (d3d11_buffer.cpp/h) and D3D10 buffer operations may be vulnerable to integer overflow attacks when calculating buffer sizes, especially when dealing with user-supplied dimensions or stride values. Fix: Implement safe integer arithmetic checks before buffer allocation. Use checked multiplication functions and validate all size calculations against maximum allocation limits.
• Medium · Potential Use-After-Free in Device Context — src/d3d11/d3d11_context.cpp, src/d3d11/d3d11_cmdlist.cpp. D3D11 context handling (d3d11_context.cpp/h) involves complex COM object lifetime management with potential for use-after-free vulnerabilities if device contexts are released prematurely while still referenced by command lists or other objects. Fix: Implement strict reference counting validation, use smart pointers consistently, and add comprehensive lifetime tests. Ensure all object destruction follows proper COM release semantics.
• Medium · Unvalidated Shader Input — src/d3d10/d3d10_shader.h, src/d3d11/ shader-related files. Shader compilation and processing files (d3d10_shader.h, d3d11 shader files) may not properly validate shader bytecode, allowing potentially malformed or malicious shader code to be processed. Fix: Implement comprehensive shader bytecode validation before compilation. Verify shader signatures, instruction sets, and resource bindings against safe limits.
• Low · Missing Input Validation in Native WSI Modules — include/native/wsi/native_glfw.h, include/native/wsi/native_sdl2.h, include/native/wsi/native_sdl3.h. Native windowing system integration modules (native_glfw.h, native_sdl2.h, native_sdl3.h) may not properly validate window handle inputs and callbacks from external libraries. Fix: Add robust input validation for all WSI callbacks. Validate window handles and event data before processing. Implement bounds checking on all external data sources.
• Low · Potential Race Condition in Multithreading Support — src/d3d10/d3d10_multithread.cpp, src/d3d10/d3d10_multithread.h. D3D10 multithread module (d3d10_multithread.cpp/h) implements thread synchronization but may have race conditions in device context state updates when multiple threads access rendering state simultaneously. Fix: Review all critical sections for completeness. Add thread sanitizer testing. Implement double-checked locking patterns where appropriate. Audit all shared state accesses.
• Low · Exposure of Internal Configuration Details — dxvk.conf. The dxvk.conf configuration file may expose internal implementation details and sensitive configuration options in plaintext that could aid attackers in crafting targeted exploits. Fix: Document security implications of each configuration option. Consider implementing configuration validation and warning users about dangerous settings.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.