## Intro 给显存里塞满了8个g的大贴图，显卡风扇发出不堪重负的尖锐叫声。 没过多久，驱动像融化的黄油一样滑出了我的电脑。我不得不对着黑屏思考了几分钟 做图形怎么这么难啊qwq 我要AI！ ## 传统的图形开发工作流 一般来说，涉及到图形相关的代码，就会出现两部分我们需要关心的 1. CPU上的代码 - 这部分代码主要用于加载资源，为绘制设置状态 2. GPU上的代码 - 这部分代码主要用于绘制图形 CPU上的代码用任何带有Debugger的ide就行了，打个断点，看一看为什么出错，寄存器里是什么值.... 对于GPU上的代码就是一团乱了，因为根本没有可靠的实时手段去知道在显卡上到底发生了什么事情...除了最后画出来的东西以外 对此聪明的图形程序们想出了几种对策： 第一种是Hook图形API，在每次API call前检测当前状态是否合法，进而在出现问题之前先发现问题 在这个思路下我们得到了现代图形api的ValidationLayer 第二种思路依然是Hook图形API，但并非用来做校验，而是用于记录一帧内的事件。只要把事件信息收集的够全，我们就可以重建这一帧，然后把每个api call的输入和输出模拟出来，进而找到问题所在。 在这个思路下我们得到了RenderDoc，NSight，还有XCode Graphics Debugger 这两种工具我会交叉使用，前者用于寻找API调用的错误，后者则用于观察数据流向和数据计算结果。 ## RenderDoc: Behind Scene 要用RenderDoc抓帧，首先得用RenderDoc启动程序（废话） 按下Capture Frame按键，RenderDoc就会把下一帧从上一次PresentToSwapchain到下一次PresentToSwapchain之间所有的操作截取下来。 RenderDoc在启动程序的时候，会在一开始把自己的hook dll注入到程序里，hook会自动劫持graphic api call。 那renderDoc是怎么通知程序进行截帧呢？一个TCP链接，然后发送一个截帧指令，接着hook dll会把东西保存下来，供renderDoc UI分析 Cool，但是知道这些有什么帮助么？ ## 迈出第一步 根据以上的分析，我们知道了，要让renderDoc抓帧的关键是注入一个dll 那假如我们[主动给程序加载这个DLL](https://github.com/feiqi3/Renderer/blob/master/src/renderdoc/renderdoc_inject.cpp)呢？ 然后...雾草，成功了？  接着只要去renderDoc的File->Attach to running instance 就会发现  我的程序能被RenderDoc附加上了！ 所以，只要RenderDoc的dll加载成功，他就会自动在后台启动一个RenderDoc服务器，然后可以供其他人链接然后抓帧！ 设想一下这个场景 美术：小飞看一下这里为什么有个亮点啊，好奇怪，今天制作人看了不太满意 我：怎么复现啊，我去查一下 美术：只有在xxx版本的release版本上能重现！进入关卡xxx的xxx地方对着xxx触发xxx就能看到了 我：可是我这没有环境，引擎+客户编一次release我这要三个小时啊，明天再说吧＞︿＜ 美术：你们引擎组真fw啊，我要告到制作人！换引擎！换引擎！ 现在 美术：小飞看一下这里为什么有个亮点啊 我：把你的内网IP发一下我截一帧查查看ヾ(≧▽≦*)o 美术：你们引擎组真厉害！击落UE不在话下啊（误 ## RenderDoc MCP 实际上RenderDoc有个专门给程序员使用的api接口在这： [RenderDocAPI](https://github.com/baldurk/renderdoc/tree/v1.x/renderdoc/api) 有了它我们能在程序里主动发起一些操作..或者是得到在外部操控RenderDoc的能力 由此我们就能做一个RenderDoc MCP 网上许多现成的仓库只是支持启动程序，然后延迟数帧，再截帧 完全做不到发现问题就立马定位嘛！ 于是我改了一下，这是我的[RenderDocMCP](https://github.com/feiqi3/renderdoc-mcp)，这个改版支持Attach到目标程序上，并且相比之前暴漏了更多的管线状态，可以更好地debug！ 现在我可以在发现问题的时候立即调用AI工具进行分析，寻找Bug 太爽了！   ## Ending 虽然这个渲染器现在还很简陋但是半年后就会是一个MMD渲染器了...我说的！