DOCSEARCHbyAlgolia
Submit Docs

RenderDoc Documentation

repository·v1.x·Indexed 27 days ago

https://github.com/baldurk/renderdoc

An open-source, frame-capture based graphics debugger for inspecting APIs such as Vulkan, D3D, and OpenGL. This documentation covers installation across Windows, Linux, and Android, building from source, and utilizing third-party components like SWIG, ToolWindowManager, and interceptor-lib. It also includes guides for generating documentation via Sphinx and improving PyCharm code completion for RenderDoc Python modules.

Tokens
78.1K
Snippets
70
Records
524
Agent score
94%

What's inside RenderDoc

  2. Overview of Python stubs generation

    v1.x
    The stubs_generation directory contains a specialized tool used to generate Python stubs for binary modules. This tool is a modified version of the stub generator found in the intellij-community repository. It is specifically designed to parse RST (reStructuredText) documentation and generate typed Python helpers that are optimized for the RenderDoc environment.

  3. Overview of ToolWindowManager

    v1.x

    ToolWindowManager is a Qt-based tool window manager designed to provide docking functionality for Qt projects. It serves as an alternative to the built-in QDockWidget system, offering enhanced customizability and extensibility. This specific version is a fork optimized for RenderDoc, featuring improvements such as:

    • Customizability: Support for arbitrary data tagged with saved states, callbacks to intercept window closing, and controls for tab reordering or floating windows.
    • Nested Support: Fixes allowing for multiple nested ToolWindowManagers.
    • Improved UX: Preview overlays for drop locations and the use of hotspot icons/locations to determine drop sites.
    • Window Management: Ability to drag and drop entire floating windows together.

  4. Overview of SWIG (Simplified Wrapper and Interface Generator)

    v1.x
    SWIG is a compiler that integrates C and C++ with various programming languages (including Python, Java, C#, Go, Lua, and more). It reads annotated C/C++ header files and generates wrapper (glue) code to make C/C++ libraries available to the target language or to extend C/C++ programs with scripting capabilities. It can also export its parse tree into XML or Lisp s-expressions.

  6. Intercept library function calls with plthook

    v1.x

    plthook is a utility library used to hook function calls issued by specific object files (executables or libraries) without modifying the target library itself.

    To use it, include plthook.c (or plthook_win32.c for Windows) and plthook.h in your source tree. You must implement a wrapper function that performs your desired logic (e.g., logging) and then calls the original function, and then use the plthook_open and plthook_replace APIs to install the hook.

  7. Access Vulkan Pipeline State via the renderdoc Python API

    v1.x
    The renderdoc module provides the VKState class and associated classes to interface with the underlying Vulkan pipeline state. This API allows for programmatic inspection and manipulation of Vulkan-specific pipeline components, including shaders, vertex inputs, rasterization states, and blending. For high-level usage instructions, refer to the main Python API documentation.

  8. Supported Graphics APIs and Platforms

    v1.x

    RenderDoc supports the following graphics APIs across various operating systems:

    • Vulkan: Support for Vulkan 1.4 on Windows, Linux, and Android. Supports Vertex, Pixel, Mesh, and Compute shader debugging. Uses VK_EXT_debug_utils or VK_EXT_debug_marker for event markers and object naming.
    • D3D11: Support up to D3D11.4 on Windows Vista and above. Supports Vertex, Pixel, and Compute shader debugging. Uses standard D3D interfaces (e.g., ID3DUserDefinedAnnotation) for debug markers.
    • D3D12: Support up to D3D12.9 on Windows 10 and above (and D3D12On7 on Windows 7). Supports Vertex, Pixel, and Compute shader debugging. Uses SetMarker/BeginEvent/EndEvent functions on command lists or queues for debug markers.
    • OpenGL & OpenGL ES:
      • OpenGL: Core profile 3.2 - 4.6 on Windows and Linux.
      • OpenGL ES: 2.0 - 3.2 on Linux, Windows, and Android.
      • Uses standard/vendor extensions and KHR_debug object labels for event hierarchies and naming.

    Note on Portability: Captures have limited portability between different hardware due to hardware-specific feature usage, but are portable between different OSes if the hardware is sufficiently comparable.

  9. Features of Sphinx Paramlinks

    v1.x

    Parameter Linking

    • :param: directives within Sphinx function/method descriptions are given a paragraph link, allowing them to be linked to externally.
    • The :paramref: role provides a way to reference specific parameters.

    Searchability

    • Paramlinks are added to the master index and the list of domain objects, making them searchable via the searchindex.js system.

  10. Understand the RenderDoc Capture Process

    v1.x

    RenderDoc captures frames by acting as a 'man-in-the-middle' between the application and the graphics API (e.g., D3D11).

    How it works:

    1. Injection & Hooking: RenderDoc injects a DLL into the target process and hooks API entry points (such as D3D11CreateDevice and CreateDXGIFactory for D3D11).
    2. Background Capture State: The driver operates in a background state, serializing resource creation, deletion, and certain data-upload calls into a chunk-based in-memory representation.
    3. Active Capturing: When a capture is triggered, the driver enters an active state at the start of the next frame. Every API call is serialized in order, along with initial contents and states.
    4. Serialization: Once the frame completes, the frame capture is serialized to disk along with any referenced in-memory resource data. By default, unreferenced resources are excluded from the capture to save space.

  11. Understand Remote Replay Context Behavior

    v1.x

    When working in a remote replay context, several behaviors change compared to local mode:

    • File Browsing: The file and directory browsing in the Capture/Attach window is relative to the remote filesystem, not your local machine.
    • Environment Variables: Variables are inherited from the remote server's environment, not the local host.
    • Capture Files: By default, capture files are stored on the target system. They are only copied to your local machine when you explicitly Save the file to a local path.
    • Cleanup: If you do not use a 'Run Command' and the connection is lost, temporary captures on the remote machine may 'leak' (remain on the remote disk without an owner). You can clean these up by re-connecting to that host's context.

  12. Access D3D12 Pipeline State via renderdoc Python API

    v1.x
    The renderdoc module provides a Python API to interface with the underlying D3D12 pipeline state. The primary entry point for D3D12-specific state information is the D3D12State class. This API allows developers to inspect and interact with various pipeline stages including Vertex Input, Shaders, Root Signatures, Rasterizer, and Output Merger states.