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/baldurk/renderdoc 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.

GO — Healthy across the board

• Last commit 3d ago
• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 50% of recent commits

_{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 baldurk/renderdoc repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/baldurk/renderdoc.

What it runs against: a local clone of baldurk/renderdoc — 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 baldurk/renderdoc | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch v1.x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of baldurk/renderdoc. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/baldurk/renderdoc.git
#   cd renderdoc
#
# 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 baldurk/renderdoc and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "docs/CONTRIBUTING/Compiling.md" \\
  && ok "docs/CONTRIBUTING/Compiling.md" \\
  || miss "missing critical file: docs/CONTRIBUTING/Compiling.md"
test -f "docs/CONTRIBUTING/Code-Explanation.md" \\
  && ok "docs/CONTRIBUTING/Code-Explanation.md" \\
  || miss "missing critical file: docs/CONTRIBUTING/Code-Explanation.md"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
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/baldurk/renderdoc"
  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).

RenderDoc is a frame-capture based graphics debugger that intercepts and records GPU draw calls, enabling post-mortem analysis of rendering pipelines. It supports Vulkan, D3D11, D3D12, OpenGL, and OpenGL ES on Windows, Linux, Android, and Nintendo Switch, allowing developers to inspect shaders, textures, buffers, and execution state at any point in a captured frame. Monolithic C++ codebase (~60MB) with layered architecture: core capture/replay engine in renderdoc/ (handling frame serialization and GPU state tracking), separate API implementations for each graphics API (Vulkan, D3D11, D3D12, OpenGL), a Qt-based UI in separate directories, Python bindings via SWIG (renderdoc.i), and CMake-based cross-platform build system. Configuration and build control via top-level CMakeLists.txt.

Graphics programmers, game developers, and engine maintainers who need to debug rendering issues in their own applications by inspecting GPU state, shader execution, and draw call sequences without modifying application code.

Highly mature: production-ready with 20+ years of active development, comprehensive CI/CD pipeline (GitHub Actions in .github/workflows/ci.yml), extensive documentation in docs/ covering all major APIs, and an MIT license indicating stability. The project maintains nightly and stable builds with a symbol server, typical of professional graphics tools.

Low risk: single-maintainer (baldurk) but with a large user base and established community (Discord, IRC, forums). CI is comprehensive. Main risks are the single-point-of-failure maintainer model and the complexity of maintaining API compatibility across 5 graphics APIs and 4 platforms; however, no signs of abandonment or major breaking changes in recent activity.

No specific recent changes visible in provided file list, but the repo maintains v1.x branch with nightly builds, active CI pipeline, and community engagement channels (Discord, IRC). The .github/workflows/ci.yml and build infrastructure suggest continuous integration and release cycles.

git clone https://github.com/baldurk/renderdoc.git
cd renderdoc
# See docs/CONTRIBUTING/Compiling.md for platform-specific build steps
# Requires CMake, C++17 compiler, and platform-specific graphics headers
cmake -B build -S .
cmake --build build

Daily commands:

# After building, run the UI application or headless replay via CLI
./bin/renderdoc  # Launch UI (platform-dependent location)
# For detailed build: see docs/CONTRIBUTING/Compiling.md for CMake options
cmake -B build -DCMAKE_BUILD_TYPE=Release -S .
cmake --build build --parallel $(nproc)

• CMakeLists.txt — Root build configuration that orchestrates compilation for all supported graphics APIs (Vulkan, D3D11, D3D12, OpenGL) and platforms (Windows, Linux, Android).
• README.md — Project overview defining RenderDoc's scope as a frame-capture graphics debugger and establishing that it's for debugging your own programs only.
• docs/CONTRIBUTING/Compiling.md — Essential guide for setting up the build environment and understanding dependency requirements across multiple platforms and APIs.
• docs/CONTRIBUTING/Code-Explanation.md — Architecture and design patterns documentation explaining how the codebase is organized and how graphics interception works.
• .github/workflows/ci.yml — Continuous integration pipeline defining automated testing and build verification for all supported platforms and graphics APIs.
• docs/behind_scenes/how_works.rst — Technical deep-dive into RenderDoc's capture and replay mechanism, explaining the core interception and replay loop.

Add Support for a New Graphics API

1. Create a new API backend module implementing the capture interface, following the pattern established by existing backends (Vulkan, D3D12, OpenGL) (CMakeLists.txt)
2. Implement command stream interception hooks for the target API's rendering commands (docs/behind_scenes/how_works.rst)
3. Add state reconstruction logic to enable replay of captured commands (docs/how/how_control_replay.rst)
4. Extend the UI event browser to display API-specific command parameters and metadata (docs/how/how_object_details.rst)
5. Add platform-specific injection and hooking mechanisms in CMakeLists.txt for each supported OS (CMakeLists.txt)
6. Update CI/CD pipeline to test the new API backend across Windows, Linux, and Android (.github/workflows/ci.yml)

Add a New Inspection/Analysis Feature

1. Review existing inspection patterns in pixel inspection and shader debugging to understand the query interface (docs/how/how_inspect_pixel.rst)
2. Implement the feature by querying the replay engine's state at specific event points (docs/how/how_control_replay.rst)
3. Add UI panels or overlays through the Qt-based interface following custom visualization patterns (docs/how/how_custom_visualisation.rst)
4. Ensure feature works across all supported graphics APIs by testing with the API abstraction layer (docs/behind_scenes/how_works.rst)

Extend Platform Support (e.g., New Mobile Platform)

1. Add platform detection and conditional compilation flags in CMakeLists.txt for the new platform (CMakeLists.txt)
2. Implement platform-specific DLL/so injection and process launching mechanisms (docs/CONTRIBUTING/Code-Explanation.md)
3. Reference the Android implementation as a template for remote deployment over network if applicable (docs/how/how_android_capture.rst)
4. Add the new platform to the CI/CD matrix for automated testing and releases (.github/workflows/ci.yml)
5. Document platform-specific capture configuration and limitations in the contributing guide (docs/CONTRIBUTING/Compiling.md)

• C++ — High-performance graphics interception and replay requires direct memory manipulation, syscall hooking, and precise timing—C++ provides the control and efficiency needed.
• CMake — Cross-platform build system supporting Windows (MSVC, Clang), Linux (GCC, Clang), and Android (NDK) with conditional compilation for multiple graphics APIs.
• Qt — Native UI toolkit with strong graphics support enables responsive inspection interfaces and custom OpenGL/Vulkan rendering windows on Windows and Linux.
• Vulkan, Direct3D 12, OpenGL, OpenGL ES — Multiple graphics API backends allow debugging on the API the developer is actually using, with unified abstraction for capture and replay.
• Python Extension — Scripting API (as referenced in docs) enables automation of analysis workflows and integration with third-party tools.

• Frame-capture model (not streaming/live)

  • Why: Provides reproducible debugging (same frame replayed identically) and allows heavy post-capture analysis without real-time constraints.
  • Consequence: Captures require significant disk storage (100MB–1GB+ per frame), and debugging is post-mortem rather than live-streaming.

• Single-machine architecture (local UI + local replay engine)

  • Why: Simplifies state management and avoids network latency issues during pixel inspection and shader debugging.
  • Consequence: Limits remote debugging to Android via ADB or manual network setup; enterprise remote debugging not built-in.

• Support only own programs (explicit scope boundary)

  • Why: Focuses development effort and avoids legal/ethical complexity around capturing third-party or commercial applications.
  • Consequence: Cannot be used for debugging games you don't own or reverse-engineering closed-source applications.

• Unified API abstraction layer for Vulkan/D3D/OpenGL

  • Why: Allows feature parity (pixel inspection, shader debug) across all APIs with shared replay engine logic.
  • Consequence: Core engine is somewhat abstracted from each API's specific optimizations; platform-specific features require separate implementation.

• Live/streaming graphics debugging (frame-capture model only)
• Debugging third-party or commercial applications (explicitly restricted to your own programs)
• Real-time performance profiling (focus is post-capture analysis and state inspection)
• Enterprise-grade multi-user remote debugging infrastructure
• Support for legacy graphics APIs (e.g., Direct3D 9, OpenGL 1.x)

Graphics API headers required: Building requires Vulkan SDK, D3D12 SDK (Windows), and OpenGL headers; missing headers cause cryptic CMake errors. Platform-specific code paths: Capture hooking differs radically between Windows (DLL injection), Linux (LD_PRELOAD), and Android (system integration); changes often require testing on all platforms. Frame capture file format versioning: Serialization format has version numbers that must be incremented for breaking changes (serialise/ directory); old captures become incompatible without migration logic. SWIG binding regeneration: Python bindings are generated from renderdoc.i; modifying public API requires SWIG regeneration, not handled automatically in all build configurations. Single maintainer reviews: All significant changes require baldurk's review; expect slower turnaround on PRs during vacations or high-load periods.

• Frame Capture & Serialization — Understanding how RenderDoc records GPU commands into a replay-able format is core to modifying capture logic, adding new API support, or optimizing file sizes; the serialization format is version-controlled and must maintain backward compatibility.
• GPU Command Interception via API Hooking — RenderDoc's capture works by intercepting graphics API calls at the driver boundary; knowledge of platform-specific hooking (DLL injection on Windows, LD_PRELOAD on Linux) is essential for adding platform support or fixing capture bugs.
• Shader Introspection & Debug Information (SPIR-V, DXBC) — RenderDoc reconstructs shader source and variable names from compiled bytecode (Vulkan's SPIR-V, DirectX's DXBC); changes to shader debugging require understanding intermediate representations and debug symbol formats.
• Replay-Driven Debugging — Unlike real-time debuggers, RenderDoc replays captured frames on-demand with GPU state inspection; this architecture enables post-mortem analysis but requires careful state reconstruction and prevents live modification of draw calls.
• Multi-API Abstraction Layer — RenderDoc maintains a unified UI and format while supporting 5 graphics APIs with different memory models, command structures, and capabilities; understanding the abstraction strategy (e.g., how Vulkan pipelines map to D3D12 PSOs) is crucial for cross-API features.
• Descriptor Binding & Resource State Tracking — RenderDoc must accurately track which textures, buffers, and samplers are bound at each draw call across different binding models (D3D11 state objects, Vulkan descriptor sets, D3D12 heap indexing); bugs here cause phantom bindings or missing resources in inspection.
• Platform-Specific Capture Integration — Each platform (Windows, Linux, Android, Nintendo Switch) requires custom capture initialization, memory management, and display interception; adding platform support demands deep OS knowledge beyond graphics API details.

• GPUOpen-Tools/radeon_gpu_profiler — AMD's complementary GPU profiler; focuses on performance metrics where RenderDoc focuses on frame inspection, often used together for comprehensive graphics debugging.
• google/gapid — Google's GPU inspection tool for Android with similar frame-capture architecture; predecessor inspiration and alternative for mobile graphics debugging.
• baldurk/renderdoc-contrib — Official community extensions repository for RenderDoc custom tools, shaders, and plugins; primary ecosystem for extending RenderDoc functionality.
• KhronosGroup/Vulkan-Tools — Khronos validation layers and tools that integrate with RenderDoc for Vulkan debugging; complementary validation and diagnostics.
• microsoft/PIX — Microsoft's Direct3D profiler and debugger; overlapping Windows/D3D12 use case with different design philosophy (real-time vs. post-mortem capture).

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 CI workflow for Android capture testing

The repo supports Android capture (docs/how/how_android_capture.rst exists) but .github/workflows/ci.yml likely lacks Android-specific testing stages. This is critical since Android is a supported platform but cross-platform testing gaps could allow regressions. A dedicated workflow would validate Android injection, symbol resolution, and frame capture on emulated/real devices.

• [ ] Review current .github/workflows/ci.yml to identify missing Android test stages
• [ ] Create new workflow file .github/workflows/android-ci.yml with steps for: Android SDK setup, emulator launch, RenderDoc injection testing, and frame capture validation
• [ ] Add matrix strategy for multiple Android API levels (28, 31, 33+)
• [ ] Document Android testing prerequisites in docs/CONTRIBUTING/Testing.md

Expand shader debugging documentation with API-specific examples

docs/how/how_debug_shader.rst and docs/how/how_shader_debug_info.rst exist but appear to lack concrete, language-specific examples. Given RenderDoc supports GLSL, HLSL, and SPIR-V across multiple APIs (Vulkan, D3D11, D3D12, OpenGL), contributors could add real shader examples with expected debug output for each combination.

• [ ] Create docs/how/shader_debug_examples/ directory
• [ ] Add shader_debug_hlsl_d3d12.rst with annotated HLSL example for D3D12 shader debugging workflow
• [ ] Add shader_debug_glsl_vulkan.rst with GLSL + Vulkan example showing breakpoints and variable inspection
• [ ] Add shader_debug_spirv.rst covering SPIR-V debugging across Vulkan contexts
• [ ] Cross-link examples from main how_debug_shader.rst page

Add CI validation for RenderDoc Python extension API compatibility

docs/how/how_python_extension.rst indicates Python scripting support exists, but there's no visible CI workflow testing Python API stability across versions. This prevents catching breaking changes to the extension API that affect user scripts. A workflow validating Python 3.8+ compatibility and API contracts would improve reliability.

• [ ] Create .github/workflows/python-api-tests.yml that builds RenderDoc and executes sample Python extension scripts
• [ ] Add test scripts in tests/python/ (or equivalent) covering: capture replay, resource inspection, event filtering, and shader editing APIs
• [ ] Matrix across Python 3.8, 3.10, 3.11+ versions
• [ ] Add pre-commit hook validation in docs/CONTRIBUTING/Preparing-Commits.md for Python extension changes

• Add missing unit tests for the serialization layer in renderdoc/serialise/ for edge cases like null pointers, large buffers, and version mismatches; currently only integration tests exist for this critical infrastructure.
• Expand Python API documentation in docs/how/ with concrete examples for common tasks like iterating draw calls and inspecting shader constants; the feature exists but lacks beginner-friendly walk-throughs.
• Implement missing validation in the D3D11 capture path for invalid descriptor binding states; currently RenderDoc silently skips some invalid bindings, making debugging application misuse difficult.

RenderDoc demonstrates a relatively secure baseline with MIT licensing and public visibility. However, the security assessment is limited due to incomplete information. Key concerns include: (1) no dependency manifest files were provided for vulnerability scanning - critical for identifying third-party risks, (2) CI/CD pipeline configuration is not visible for review, (3) custom build scripts require careful scrutiny. The codebase appears to follow good practices (open source, clear contribution guidelines, Code of Conduct), but deeper analysis of build processes, dependency management, and CI/CD security configuration is needed for a comprehensive assessment. Recommend implementing automated dependency scanning and maintaining up-to-date security policies.

• Medium · Missing dependency vulnerability scanning — Repository root / dependency management. No dependency files (package.json, requirements.txt, Cargo.lock, etc.) were provided for analysis. This prevents assessment of known vulnerabilities in third-party libraries used by the project. Fix: Implement automated dependency scanning using tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot to identify and track vulnerable dependencies.
• Low · Limited visibility into CI/CD security configuration — .github/workflows/ci.yml. While GitHub Actions workflows exist (.github/workflows/ci.yml), the content was not provided for analysis. CI/CD pipelines can introduce security risks if misconfigured (e.g., exposed secrets, insecure artifact handling). Fix: Review CI/CD workflows for: (1) exposure of sensitive variables, (2) secure secret management, (3) signed commits, (4) proper access controls, (5) artifact signing.
• Low · Python script in CI/CD workflow — .github/workflows/install-vs-components.py. Custom Python script detected in CI workflow (.github/workflows/install-vs-components.py). Custom build scripts can introduce security risks if they execute untrusted code or have privilege escalation vulnerabilities. Fix: Review the Python script for: (1) input validation, (2) secure subprocess execution, (3) dependency verification, (4) privilege requirements. Consider pinning versions and using approved package repositories.

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.