构建之间的性能问题

发布于 2024-10-12 07:22:17 字数 468 浏览 5 评论 0原文

我在业余时间开发了一个小型独立游戏,遇到了一个莫名其妙的问题。游戏的某些版本的运行速度会比其他版本随机慢数百帧。例如,当渲染一些文本且没有 3D 场景时,我可以在自己的硬件上达到 1800FPS。添加一个 3D 球体(10k 顶点,像素着色),实现 1700 FPS。再添加两个球体,达到 800 FPS。删除所有球体,实现 1100FPS——尽管代码现在渲染的场景与我之前在 1800FPS 下实现的场景相同,这只是渲染的 FPS 计数器。我尝试重建和清理项目并重新启动编译器。这是在发布模式下,我打开了我能找到的所有优化。关于原因有什么建议吗?

我运行了一个快速配置文件,Visual Studio 似乎认为我 90% 以上的时间都花在 D3D9_43.dll 上,这表明这不是我的应用程序中的错误,但这并不能解释为什么它只在某些构建中出现。

我重新启动了我的机器,它又回到了 1800FPS。我认为这是 DirectX SDK 工具(以及许多其他工具)中的一个错误。打算删除这个问题。

I've been developing a small indie game in my spare time and have run across an inexplicable issue. Some builds of the game will randomly run several hundred frames per second slower than other builds. For example, when rendering some text and no 3D scene, I can achieve 1800FPS on my own hardware. Add one 3D sphere (10k verts, pixel shaded), achieve 1700 FPS. Add two more spheres, achieve 800 FPS. Remove all spheres, achieve 1100FPS- even though the code now renders the same scene as I previously achieved at 1800FPS, which is just the FPS counter being rendered. I've tried rebuilding and cleaning the project and rebooting the compiler. This is in Release mode and I turned on all the optimizations I could find. Any suggestions as to the cause?

I ran a quick profile, and Visual Studio seems to think that over 90% of my time was spent in D3D9_43.dll, suggesting that it's not a bug in my app, which doesn't explain why it manifests in only some builds.

I rebooted my machine and it's back up to 1800FPS. I think it's a bug in the DirectX SDK tools (amongst many others). Going to delete this question.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

转身泪倾城 2024-10-19 07:22:17

我不知道 MSVC 是否这样做,但 GCC 这样做:
当 GCC 无法确定最有可能的分支时,它会掷骰子。

如果 MSVC 这样做,则可能会在每个构建中以一种或另一种方式预测一个重要的分支点,这会产生影响。

您可以通过执行 PGO 构建来解决此问题:配置文件引导优化。这将在运行时检查代码,并使所有分支正确预测。至少,如果您的测试运行是一个好的样本,那么它是正确的。

也就是说,结果通常不会那么引人注目。如果场景中有更多对象并且涉及更多代码,则更改将会更多。

I don't know if MSVC does this, but GCC does:
When GCC cannot determine the most likely branch it throws the dice.

If MSVC does that, it may be that in each build an important branch point is being predicted one way or the other and it makes a difference.

You can fix that by doing a PGO build: profile guided optimization. That will examine the code at run time and it will make all the branches correctly predicted. At least, it will be correct if your test run is a good sample.

That said, the results are not usually so dramatic. If you had more objects on the scene and more code involved the changes would even out more.

贩梦商人 2024-10-19 07:22:17

另一种可能性:CPU 速度缩放。

如果您的程序大部分时间都在 GPU 上执行,则 CPU 使用率可能不会上升到足以使 CPU 全速运行。

尝试将 Windows 电源管理调整为全速而不是平衡,看看是否有任何改变。

Another possibility: CPU speed scaling.

If your program spends most of its time executing on the GPU, CPU usage may not rise high enough to push the CPU into full speed.

Try adjusting Windows power management to full speed instead of balanced, see if it changes anything.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文