开发工具调试器图形学GPU【免费下载链接】renderdocRenderDoc is a stand-alone graphics debugging tool.项目地址https://gitcode.com/gh_mirrors/re/renderdoc点击查看免费下载RenderDoc 内嵌的 Python 环境适合编写脚本和 UI 扩展但远不及专业 IDE 在代码编辑、自动补全与调试方面的能力。RenderDoc 通过生成 Python stub类型桩文件并提供基于 debugpy 的远程调试协议让外部 IDE 既能获得renderdoc/qrenderdoc模块的完整自动补全也能对运行在 RenderDoc UI 内的 Python 代码设置断点、单步调试。本文以 VS Code 为主官方文档认为其与 RenderDoc 集成度最好兼顾 PyCharm逐步讲解配置方法、stub 生成机制与 debugpy 加载原理并给出源码级依据帮助读者建立一套可直接复用的开发调试环境。为什么需要外部 IDE 集成RenderDoc 的 Python 脚本面板内置了基本的编辑与执行能力但它在以下场景中力不从心自动补全缺失renderdoc与qrenderdoc是纯 C 扩展模块Python 解释器无法直接获取其类型签名调试能力缺失RenderDoc UI 内运行的 Python 代码无法像普通 Python 工程那样打断点、步进调试复杂脚本开发涉及 UI 扩展、复杂业务逻辑时缺乏工程化的编辑体验。IDE 集成正是为了解决这三点外部编辑器提供强大的编辑体验自动生成的 stub 文件提供类型提示debugpy 远程调试协议则让外部调试器接管 RenderDoc UI 内部的 Python 线程。VS Code 快速设置6 个步骤官方文档推荐 VS Code 作为首选 IDE。装好 VS Code 后简单编辑即可开箱即用若要完整调试能力与全功能自动补全按以下步骤配置安装扩展安装Pylance与debugpy扩展。这两个扩展会被默认的Python元扩展自动安装因此安装ms-python.python即可。打开设置窗口Ctrl-,进行后续修改。添加 stub 目录到python.analysis.extraPaths打开Extensions → PyLance → Extra Paths设置 ID 为python.analysis.extraPaths填入 RenderDoc 生成的 stub 目录Windows%APPDATA%\qrenderdoc\pystubs\latestLinux~/.local/share/qrenderdoc/pystubs/latest禁用debugpy.debugJustMyCodeExtensions → Python Debugger → Just my code。由于 RenderDoc 的 Python 集成方式特殊VS Code 可能不认为脚本位于某个项目内因此强烈建议关闭该选项否则断点可能无法命中。可选启用task.allowAutomaticTasksFeatures → Tasks → Allow Automatic Tasks设置 ID 为task.allowAutomaticTasks。启用后点击渲染 UI 内的Attach External Debugger按钮时VS Code 会自动连接调试器。调试时启用Breakpoints → User Uncaught Exceptions位于Run and Debug侧边栏底部以便正确捕获 Python 代码中抛出的未捕获异常——否则 RenderDoc 会自己捕获这些异常用于展示导致 VS Code 无法截获。首次安装调试扩展后需要重启 RenderDoc UI扩展才能被发现并加载。随后即可在 Python 脚本面板中使用Attach External Debugger按钮启动调试并享受 VS Code 内完整的自动补全。上述设置在 VS Code 的 settings.json 中对应为{ python.analysis.extraPaths: [ C:\\users\\baldurk\\appdata\\roaming\\qrenderdoc\\pystubs\\latest ], debugpy.debugJustMyCode: false, task.allowAutomaticTasks: on }Python Stubs自动补全的基石为什么需要 stub像 RenderDoc 这样的 C 扩展 Python 模块无法携带对 IDE 自动补全至关重要的类型注解。业界标准替代方案是提供stub 文件用纯 Python 编写、没有实现体、只包含函数签名和类型注解的.pyi文件。IDE 通过分析这些文件获得类型信息而运行时则完全忽略它们。RenderDoc 的 stub 生成与存放位置RenderDoc 会在应用数据目录下自动生成 stub 文件每个版本一份目录外加一个滚动的latest目录Windows%APPDATA%\qrenderdoc\pystubsLinux~/.local/share/qrenderdoc/pystubs目录结构形如pystubs/ ├── v1_22/ # 版本化目录示例v{主版本}_{次版本} └── latest/ # 始终指向当前版本日常开发通常直接使用latest即可如果针对特定 RenderDoc 版本开发则应使用对应版本目录。在源码 PythonContext.cpp 中可以看到版本目录的构造逻辑GetPystubsLocations使用RENDERDOC_VERSION_MAJOR/RENDERDOC_VERSION_MINOR拼接出v%1_%2形式的子目录并同时创建latest子目录返回。stub 的版本管理与生成流程源码级StubsVersion结构体PythonContext.cpp记录了 stub 对应的版本信息主/次版本号以及构建类型稳定版记为stable开发版记为 commit hash。ShouldReplace方法决定是否重建 stub主/次版本号更高时必然重建版本号相同且 commit 一致时不重建已存在stable版本的 stub 时绝不用非稳定版本覆盖版本号相同但 commit 未知时保守地重新生成。实际生成发生在GenerateStubsPythonContext.cpp它从 Qt 资源:/py/stubgen.py中读出内嵌的 stub 生成脚本并编译执行对renderdoc与qrenderdoc两个模块分别调用gen()生成 stub并写入version.txt记录版本信息major/minor/commit 各占一行。生成前会检查当前版本是否比已生成的旧避免无谓的重建。在 IDE 中启用 stubVS Code将 stub 目录加入python.analysis.extraPaths界面路径为Python → Analysis: Extra Paths如第一节所述。其他编辑器查阅对应编辑器文档寻找添加额外 stub 路径用于类型检查与自动补全的配置项。完成配置后任何import renderdoc或import qrenderdoc的脚本都能获得正确的自动补全。Python 调试debugpy 集成原理debugpy 的自动发现与加载RenderDoc 与微软的debugpy库集成——这是一个通用的远程调试工具包允许外部调试器连接并调试运行在 RenderDoc UI 内的 Python 代码。启动时RenderDoc 会按照以下优先级自动查找并加载debugpy见 PythonContext.cpp用户自定义路径配置项Python_DebugPyDir指向的目录需包含__init__.pyVS Code 扩展路径~/.vscode/extensions/ms-python.debugpy*/bundled/libs若有多个版本按排序取最新PyCharm 内置路径Windows 下为C:/Program Files/JetBrains/PyCharm*Linux 下为/opt/pycharm-*实际查找plugins/python-ce/helpers目录下的debugpyWindows 还会查询注册表HKEY_LOCAL_MACHINE\SOFTWARE\JetBrains\PyCharm。加载流程为将 debugpy 目录临时加入sys.path→import debugpy→ 调用debugpy.configure(subProcessFalse)禁止 debugpy 创建子进程→ 调用debugpy.listen(5678, in_process_debug_adapterTrue)监听本地端口5678。加载后 RenderDoc 还会执行一段 monkey-patch规避 debugpy/pydevd 的已知问题源码注释中标注了 upstream issue 2011确保断点续跑与进程终止行为符合 RenderDoc 集成预期。注意如果是从源码自行构建 RenderDoc默认会链接 Python 3.6而该版本不支持调试。此时应自定义构建以使用更新的 Python 版本官方 release 使用 Python 3.8详见 Compiling.md 中关于自定义 Python 版本的说明。调试器就绪后的状态一旦debugpy加载成功调试器即监听本地端口5678。在 VS Code 或其他 IDE 中配置一个远程附加remote attach/ debug server attach调试配置连接到localhost:5678即可。如果 RenderDoc 检测到 VS Code 已安装会提供更便捷的调试入口在 Python 脚本中点击Attach External Debugger按钮RenderDoc 会自动启动 VS Code 并准备好连接调试器所需的环境。若已在 VS Code 中启用Allow Automatic TasksVS Code 启动后会自动连接调试器否则需要手动点击开始调试来建立连接。RenderDoc 启动 VS Code 时会自动创建工作区级的.vscode/launch.json与tasks.json见LaunchDebuggerPythonContext.cpp内容大致为{ version: 0.2.0, configurations: [ { name: Python Debugger: Remote Attach, type: debugpy, request: attach, connect: { host: localhost, port: 5678 } } ] }tasks.json中则注册了一个runOn: folderOpen的任务用于在Allow Automatic Tasks开启时自动执行workbench.action.debug.start实现自动附加。调试工作流与关键注意事项连接谁发起、何时可附加附加由 IDE 侧发起只要 RenderDoc 检测到或已配置好debugpy外部调试器可随时附加到 RenderDoc UI。附加动作必须从 IDE 端开始不能由 RenderDoc 发起——UI 内的 Attach 按钮只是启动 IDE 并可能触发立即附加并非必需。附加后调试全部 Python 代码即使项目只包含一个脚本或一个 UI 扩展附加后外部调试器会调试 RenderDoc 中运行的所有 Python 代码可随时从相关项目重新附加RenderDoc 侧无需任何操作。单例连接RenderDoc 的 Python 调试连接是单例的同一时刻只能有一个 IDE/调试器附加并且只有第一个启动的 UI 实例可被连接。三个关键注意事项务必禁用Just my code由于 RenderDoc Python 集成的工作方式VS Code 可能认为脚本不在项目内。禁用该选项debugpy.debugJustMyCode: false是断点可靠命中的前提。检查User Uncaught Exceptions在Breakpoints中启用该选项否则 RenderDoc 会先捕获异常用于 UI 展示IDE 无法截获。警惕.vscode目录与 path mappingsRenderDoc 默认会创建.vscode/launch.json配置调试但不会覆盖已存在的文件。VS Code 默认的远程附加配置包含 path mappings由于远程附加通常不在同一文件夹上使用这些映射会导致 RenderDoc 调试无法正常工作——强烈建议删除所有 path mappings若已尝试附加失败删除后重启 RenderDoc 与 VS Code。状态确认调试器成功连接后RenderDoc 状态栏会显示调试器已连接。下一步至此你已经拥有了一套完整可用的 Python 开发调试环境。接下来可以查看 Python API 示例其中演示了若干简单任务并展示了renderdoc.ReplayController的用法——这是底层 API 的主要入口也是 RenderDoc 暴露的大部分能力的起点编写更复杂的脚本前阅读 深入主题文档其中包含特定主题的详细解释与注意事项遇到常见问题时查阅 Python API FAQ若需开发 UI 扩展参考 UI 扩展教程以及配套的 ui_extensions.py 与 first_steps.py 示例。赞分享开发工具调试器图形学GPU【免费下载链接】renderdocRenderDoc is a stand-alone graphics debugging tool.项目地址https://gitcode.com/gh_mirrors/re/renderdoc点击查看免费下载相关推荐RenderDoc Python API 完整指南脚本自动化、UI 扩展与 IDE 调试实战RenderDoc Python API 完整指南脚本自动化、UI 扩展与 IDE 调试实战 导读 RenderDoc 将内部 C API 直接封装暴露给开发工具调试器图形学GPUFastAPI 调试指南在 VS Code 与 PyCharm 中断点调试你的应用FastAPI 调试指南在 VS Code 与 PyCharm 中断点调试你的应用 导读 本指南基于 FastAPI 官方教程的 debugging 章节 h后端Web框架API设计DXVK终极调试指南VS Code与RenderDoc深度集成实战DXVK终极调试指南VS Code与RenderDoc深度集成实战 DXVK作为基于Vulkan实现的D3D9/D3D10/D3D11兼容层为Linux/W图形学游戏开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考