开发工具调试器图形学GPU【免费下载链接】renderdocRenderDoc is a stand-alone graphics debugging tool.项目地址https://gitcode.com/gh_mirrors/re/renderdoc点击查看免费下载本指南面向 RenderDoc 的贡献者与二次开发者系统说明在为 RenderDoc 提交功能或修改时应当如何测试与验证。文章以官方贡献文档 docs/CONTRIBUTING/Testing.md 为骨架结合仓库中真实的自动化测试基础设施util/test 目录下的测试框架、demo 程序与 190 条测试用例讲解测试现状、测试思路、自动化测试的运行方式以及如何新增一条测试。一、官方文档对测试的定位当前仍是ad-hoc验证为主官方 Testing.md 明确说明了当前测试策略的现状目前任何特性和变更的测试基本是即兴ad-hoc的。我一直在开发一套正式的测试套件用于同时测试 API 捕获/重放支持以及分析功能。翻译成实操要点就是两条改动后务必回归验证在提交修改之前围绕你改动所涉及的区域做针对性测试test any changes you make around the area that youve tested。例如你改了 Vulkan 驱动的捕获逻辑就应该跑一遍 Vulkan 相关的 demo 和捕获流程。PR 阶段听从维护者建议如果维护者对测试有特别建议通常会在 Pull Request 中直接提出按建议补测即可。这条文档撰写于测试套件尚未成型的阶段属于过渡期指引。但从当前仓库的目录结构看文档中提到的proper test suite已经落地为 util/test 目录下的一套完整、可运行的自动化测试体系。因此今天的贡献者实际上拥有两条测试路径轻量的针对性手测ad-hoc与完整的自动化测试套件util/test/run_tests.py。二、理解测试套件的整体架构自动化测试体系位于仓库根目录下的 util/test主要由四部分组成组成部分路径职责测试入口util/test/run_tests.py命令行入口解析参数、调度测试、汇总结果测试框架util/test/rdtestPython 测试框架用例基类、日志、图像比较、远端服务等demo 程序util/test/demos一组自包含的小型 API 使用示例按图形 API 分目录D3D11、D3D12、GL、Vulkan测试用例util/test/tests190 条 Python 测试用例与 demo 一一对应从源码结构看整套系统的工作流是demo 负责制造可复现的图形场景如绘制一个简单三角形、创建各类纹理、触发特定的资源生命周期场景并在运行时被 RenderDoc 注入捕获测试用例负责回放分析打开捕获文件通过renderdocPython 模块rd驱动重放校验管线状态、着色器输出、像素拾取值、网格数据等是否符合预期测试框架负责调度与报告每个用例在独立子进程中执行防止崩溃拖垮整轮测试失败时把 RenderDoc 日志、截图差异等产物写入 artifacts 目录。2.1 用例基类rdtest.TestCase所有测试用例继承自 util/test/rdtest/testcase.py 中的TestCase基类。核心设计是两种互补的写法实现get_capture()check_capture()前者负责运行 demo 并产生捕获文件后者负责对捕获内容做断言。默认的run()方法会依次调用两者见 testcase.py#L745-L762直接实现run()完全自定义流程适合需要自己打开多个捕获文件的复杂用例。基类内置了大量断言工具例如check_triangle()在输出缓冲区多个位置拾取像素验证前景/背景颜色是否符合预期testcase.py#L633-L666check_pixel_value()像素拾取值比较支持按纹理格式自动放宽 epsilon8-bit 纹理用1/255、16-bit 用1/16384check_mesh_data()/check_task_data()把重放得到的 VS 输出网格数据与参考数据逐顶点、逐属性比对debug_vertex()/debug_pixel()/debug_thread()分别对顶点、像素、计算线程执行着色器调试并把单步跟踪状态与预期逐指令比对。以最简单的用例 Vulkan/VK_Simple_Triangle.py 为例可以看到一个典型用例的完整形态声明demos_test_name指向同名 demo在check_capture()中取最后一个 action、把事件定位到该 action、用check_triangle()验证三角形渲染结果再通过get_postvs()拿到顶点着色器输出与预期的gl_Position、vertOut等参考值做精确比对。2.2 demo 程序测试的素材工厂demo 程序是测试能否成立的前提——绝大多数测试依赖它生成捕获文件。它位于 util/test/demos按 API 组织d3d11/、d3d12/、gl/、vk/各有一个*_test.cpp入口和大量按场景拆分的 demo如vk_draw_zoo.cpp、d3d12_rtas_zoo.cpp、gl_texture_zoo.cpp等。按 util/test/README.md 的说明demos 的构建方式如下Windows直接打开 util/test/demos.sln 编译无外部依赖Linux / Applecmake -Bbuild -Hdemos make -C buildLinux 需要libX11、libxcb、libX11-xcb构建支持 GL 的 RenderDoc 本来就需要这些。需要特别注意一个软依赖如果 demos 没有链接 shaderc运行时会调用外部的glslc把着色器编译为 SPIR-V找不到glslc时部分测试会被自动禁用目前只有 Windows 支持链接 shaderc在$VULKAN_SDK环境变量指向的目录下自动查找。三、针对性手测贡献者日常的回归验证方式在提交修改前官方文档要求你围绕改动区域做验证。结合仓库结构可以给出具体的操作建议改了捕获/注入逻辑用 renderdoccmd 或 qrenderdoc 对本地自有的测试程序做捕获重点验证目标 API 下的帧捕获、资源枚举是否正常改了重放或分析逻辑运行相关 API 的测试用例见下节自动化测试或直接打开已有捕获文件在 qrenderdoc 中人工检查管线状态、纹理查看器、网格查看器、着色器调试等面板改了 shader 分析重点跑 shader debug 类用例Shader_Debug_Zoo、Shader_ISA、Shader_Editing以及Pixel_History、Mesh_Zoo等分析类用例测试用例自身的维护如果你修改的功能已有对应测试务必保证该测试仍然通过如果测试用例本身不适用在 PR 中说明理由。同时建议遵守 README 中的告诫不要制造uber-demo尽量让每个 demo 只做一件简单的事这样测试失败时可以快速定位到具体特性。四、运行自动化测试套件4.1 前置条件按 util/test/README.md 的说明使用与构建 RenderDoc 时相同的 Python 版本Windows 仓库自带 python 3.6 左右Windows 上 Python 的位数必须与 RenderDoc 构建一致64 位构建对应 64 位 PythonLinux/Apple 需要把demos_x64所在目录加入PATH或用--demos-binary显式指定路径先按上文构建好 demos 程序。4.2 常用参数运行run_tests.py的常用参数如下详见 run_tests.py 参数解析部分参数作用--renderdoc path指定 renderdoc 库路径会修改 OS 库搜索路径Windows 下同时加入 DLL 搜索目录--pyrenderdoc path指定renderdocPython 模块路径如 Windows 下的x64/Development/pymodules-l/--list仅列出可用测试并退出-t/--test_include regexp只运行名称匹配该正则的测试默认.*全部运行-x/--test_exclude regexp排除名称匹配该正则的测试-j/--parallel N用 N 个进程并行运行测试0或1表示串行--test-timeout 秒单个测试无输出时的超时时间默认 90 秒--data path参考数据目录默认脚本旁的data/--artifacts path输出产物目录默认artifacts/运行前会被清空--temp path临时工作目录默认tmp/运行前会被清空--data-extra path额外参考数据目录大型捕获不入库默认data_extra/--demos-binary path指定已构建的 demos 二进制路径--demos-timeout 秒期望 demos 运行完成的超时时间--adb-device 设备在指定的 ADB 设备上运行测试此时--demos-binary应为 demo 的 APK--debugger调试模式测试在当前进程内运行异常不被框架捕获便于断点调试注意README 与源码都明确提示tmp/与artifacts/目录在运行开始时会被整体清空runner.py 中的清理逻辑不要在其中存放任何重要数据。一个典型的 Linux 运行示例python3 util/test/run_tests.py \ --renderdoc /path/to/librenderdoc.so \ --pyrenderdoc /path/to/pymodules \ --demos-binary /path/to/demos_x64 \ -t VK_Simple_Triangle|GL_Simple_Triangle \ -j 4Windows 示例对应 README 中的用法python run_tests.py --renderdoc path\to\renderdoc\x64\Development ^ --pyrenderdoc path\to\renderdoc\x64\Development\pymodules4.3 结果解读运行结束后artifacts/目录中会生成自包含的结果日志output.log.html它本质是纯文本日志但内嵌了 JavaScript 与样式testresults.css、testresults.js用浏览器打开即可获得可读性良好的报告所有依赖及图像对比产物都放在同一目录下因此整个 artifacts 目录可以独立带走查看。从 runner.py 的实现可以看到几处值得了解的行为进程隔离每个测试默认在独立子进程中运行--internal_run_test内部参数这样测试崩溃不会拖垮整轮运行runner.py#L65-L79自动处理 Vulkan layer 注册如果检测到 Vulkan layer 未注册会尝试自动注册Windows 下必要时通过 UAC 提权runner.py#L289-L329跳过机制测试会先调用check_support()demo 未编译进二进制、平台不支持等情况会被标记为 skip 并记录原因而不是失败runner.py#L359-L380汇总输出结束时打印通过/失败/跳过统计若存在失败用例则以退出码 1 结束runner.py#L461-L479。五、如何新增一条测试5.1 编写 demo如果功能需要新的捕获场景在 util/test/demos 对应 API 目录下新建或复制一个现有 demo例如复制vk_template.cpp只实现一个简单的场景。若需要主程序注册该 demo请参考main.cpp与同目录其他*_test.cpp的注册方式。5.2 编写测试用例在 util/test/tests 对应 API 目录下新建同名 Python 用例复制现有用例并修改校验逻辑。README 的建议是demos 项目中包含辅助库最好的起步方式就是复制一个现有测试再按需修改避免 uber-demo尽量只做一件简单的事。测试用例通常与 demo 一一对应同样可以复制现有用例并加入自己的检查。用例骨架以VK_Simple_Triangle为模板import renderdoc as rd import rdtest class VK_My_Feature(rdtest.TestCase): demos_test_name VK_My_Feature # 对应 demos 中的测试名 demos_frame_cap 5 # 捕获帧数上限 demos_frame_count 1 # 要捕获的帧数 def check_capture(self): # 打开捕获后用 self.controller 驱动重放并断言 # 例如 self.check_triangle(...)、self.check_pixel_value(...) pass5.3 新增参考图像仅当需要图像比对时README 给出了新增参考图像的明确流程首次不带参考图像运行框架会输出将要用于比对的图像用pngcrush处理该图像确保保留 RGBA 输出以减小仓库体积放入参考数据目录供后续比对。需要图像比对的典型场景如check_final_backbuffer()它把最后一个 action 的 backbuffer 保存为 PNG与参考图逐像素比对testcase.py#L830-L847。5.4 运行与验证用-t正则只跑你的新用例如-t VK_My_Feature确认通过后再跑一次该 API 目录下的相关用例如-t VK_确认没有破坏既有功能。六、测试套件覆盖的能力范围当前仓库的测试体系已具备相当完整的覆盖面可作为贡献者判断改动应跑到哪些测试的参考四套图形 APID3D11、D3D12、OpenGL、Vulkan各自拥有独立测试目录util/test/tests/D3D11、D3D12、GL、Vulkan捕获/重放基础能力空捕获Empty_Capture、泄漏检查Leak_Check、资源生命周期Resource_Lifetimes、帧 0 校验Frame0等分析功能像素历史Pixel_History、网格数据Mesh_Zoo、纹理/缓冲区Texture_Zoo、Buffer_Truncation、丢弃操作Discard_Zoo、覆盖层Overlay_Test等着色器调试Shader_Debug_Zoo、Shader_ISA、Shader_Editing、Shader_Linkage_Zoo等配合debug_vertex/debug_pixel做指令级单步比对较新的图形特性D3D12 的 Mesh Shader、VRS、光线追踪资源RTASVulkan 的 Dynamic Rendering、Descriptor Buffer、Ray Query 等。七、小结贡献者的测试清单综合官方文档与仓库现状提交修改前建议按以下清单自检手测改动区域围绕你修改的代码路径做一次真实捕获与重放验证跑相关自动化用例用-t正则选中与你改动相关的测试目录如D3D12_、GL_、VK_、GL_Shader_Debug等确保没有回归新功能配套测试涉及新功能时按第五章流程补充 demo 与用例参考图像用 pngcrush 压缩后入库关注 PR 反馈维护者对测试若有额外要求会在 PR 中提出按建议补充即可。通过针对性手测 自动化测试套件的组合即使是变更范围横跨多个图形 API 的功能也能在提交前获得足够可信的验证结果。赞分享开发工具调试器图形学GPU【免费下载链接】renderdocRenderDoc is a stand-alone graphics debugging tool.项目地址https://gitcode.com/gh_mirrors/re/renderdoc点击查看免费下载相关推荐Gitpod 手动测试套件Ruruku 测试计划完全指南从发布验证到全功能回归Gitpod 手动测试套件Ruruku 测试计划完全指南从发布验证到全功能回归 Gitpod 在 dev/manual tests/ 目录下维护了一套基于开发工具后端云原生自动化测试Qwen3-1.7B-FP8功能与性能测试套件自动化测试Qwen3 1.7B FP8功能与性能测试套件 引言 在大语言模型Large Language ModelLLM部署和应用的实践中自动化测试大模型深度学习10分钟上手Whisper自动化测试从单元测试到性能验证全指南10分钟上手Whisper自动化测试从单元测试到性能验证全指南 你是否还在为语音识别模型的测试效率低下而烦恼是否遇到过模型升级后兼容性问题难以排查的情况本人工智能语音音频本地部署桌面应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考