无需分析器即可分析图形渲染
如今，我们拥有相当先进的工具来解决渲染问题，允许查看不同的阶段、绘制调用所花费的时间等。但如果没有它们，图形管道在了解内部发生的情况时就相当于一个黑匣子。
假设由于某种原因您没有这样的工具，或者工具非常有限。无论如何，您如何衡量渲染所花费的时间？
我知道一些技巧，例如丢弃绘制调用以查看 CPU 时间、设置 1x1 视口以查看几何体的成本、使用哑片段着色器来突出显示填充率...它们已经很有用，但仅给出了粗略的想法正在发生，并且没有告诉任何关于并行性的级别。
此外，获取每个绘制调用在每个阶段花费的时间似乎很困难，特别是考虑到测量时由于噪声而导致精度不足时。
当你的背包几乎空了而你仍然需要分析你的渲染时，你会使用什么技巧？您的个人瑞士军刀由什么组成？
Nowadays we have pretty advanced tools to iron out rendering, allowing to see the different stages, time taken by draw calls, etc. But without them the graphics pipeline is quite a black box when it comes to understand what is happening inside.
Suppose for some reason you have no such tool, or a very limited one. How would you measure anyway what is taking time in your rendering?
I am aware of tricks like discarding draw calls to see the CPU time, setting a 1x1 viewport to see the cost of geometry, using a dumb fragment shader to highlight the fillrate... They are useful already but only give a rough idea of what is going on, and tell nothing about the level of parallelism.
Also, getting the time spent in each stage per draw call seem to be difficult, especially when taking into account the lack of precision due to the noise when measuring.
What tricks do you use when your backpack is almost empty and you still have to profile your rendering? What is your personal Swiss army knife consisting in?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
帧时间渲染时间
小代码/阶段/等花费的绝对时间。并不那么相关，因为 GPU 驱动程序优化/批处理/并行性/版本使得在没有 GPU 计数器的情况下几乎不可能进行精确的代码测量。 （如果您与供应商库一起使用，您可以获得）
您可以轻松衡量的是每个代码更改的影响。你只会获得相对的影响，而这正是你真正需要的。这只是使用帧渲染时间。
理想情况下，您的目标应该是能够在运行时编辑着色器或管道代码，并有一种直接的方法来检查对整个典型场景的影响，例如比较多个代码路径之间的图形。 （小心静态场景，否则你最终会得到高度优化的静态视图，但动态场景性能较差）
这是瑞士军刀列表：
请注意，场景状态加载/保存/ record 对于很多其他事情都很方便，从调试到撤消/重做到即时重新加载，更不用说保存游戏了。
添加屏幕截图+图像差异，您也可以对图形代码进行单元测试。
如果可以的话，将其添加到您的 CI 服务器中，这样巨大的代码影响就不会被忽视。 （在艺术家签入资产时也有帮助，无需评估渲染影响）
必须阅读相关 CI 图形测试工作：http://aras-p.info/blog/2011/06/17/testing-graphics-code-4-years-later/
Frame time rendering time
Absolute time spent for small code/stage/etc. is not that relevant as GPU driver optimization/batching/parallelism/version makes it nearly impossible to have precise code measure without GPU counters. (which you can get if you use with vendors libs)
What you can measure easily is each single code change impact. You'll only get relative impact, and it's what you really need anyway. And that just using frame rendering time.
Ideally you should aim be able can edit shader or pipeline code during runtime, and have a direct way to check impact over a whole typical scene, like just comparing graphs between several code path. (beware of static scenes, otherwise you'll end with highly optimized static views, but poor dynamic scenes performance)
Here's the swiss army knife list:
Note that scene state load/save/record are handy for a lot of other things, from debugging to undo/redo to on-the-fly reload, not to mention savegames.
Add a screenshot taker + image diff, and you can unit test graphic code too.
If you can, add that to your CI server so that huge code impact doesn't go unnoticed. (helps also artists when they check-in their assets, without evaluating rendering impact)
A must read on that related CI graphic test work is there : http://aras-p.info/blog/2011/06/17/testing-graphics-code-4-years-later/
注意：我正在回答这个问题：“用分析器分析图形渲染”，因为这是我一直在寻找的东西；）
我主要在 Mac 上工作，并且使用多个工具：
您对“突出填充率的哑片段着色器”有何技巧？ （绘制纯色？还是更高级的颜色？）
Note: I'm responding to the question: "Profiling a graphics rendering with a profiler", since that something I was looking for ;)
I'm working mostly on Mac, and I'm using multiple tools:
What's your trick about the "dumb fragment shader to highlight the fillrate" ? (drawing a plain color ? or something more advanced ?)