现代硬件在保持实时性的同时，一个场景中可以到达多少个多边形，以及如何到达那里？

在某些方面，这是一个相当基本的问题，但很多人（包括我自己）并不真正知道答案。GPU制造商通常会引用非常高的数字，各种游戏引擎声称支持的多边形数量之间的差异通常跨越多个数量级，然后仍然严重依赖于许多变量。

我知道这是一个广泛的，几乎是开放性的问题，对此我深表歉意，我只是认为这仍然是一个有价值的问题。

我认为，实时是超越交互的一切，这已被普遍接受。交互式被定义为“响应输入，但动画看起来很锯齿，因此不流畅”。
因此，实时将取决于一个人需要代表的运动速度。电影院的投影速度为24 FPS，在许多情况下都足够实时。

然后，通过检查自己可以轻松验证一台机器可以处理多少个多边形。只需创建一个VBO补丁作为简单测试和FPS计数器，许多DirectX或OpenGL示例将为您提供此基准的理想测试平台。

您会发现是否有高端图形卡可以实时显示约100万个多边形。但是，正如您所说，引擎不会轻易获得支持，因为现实世界中的场景数据会导致大量与多边形计数无关的性能消耗。

你有：

• 填充率
  • 纹理采样
  • ROP输出
• 打电话
• 渲染目标开关
• 缓冲区更新（统一或其他）
• 透支
• 着色器复杂度
• 管道复杂度（使用了任何反馈？迭代几何阴影？遮挡？）
• 与CPU同步点（像素回读？）
• 多边形丰富度

根据特定图形卡的弱点和强点，这些点中的一个或另一个将成为瓶颈。并不是您可以肯定地说“那就是那个”。

编辑：

我想补充一点，就是不能使用一张特定卡的GFlops规格图并将其线性映射到多边形推入容量。由于多边形处理必须经过图形管道中的顺序瓶颈，因此在此进行了详细说明：https : //fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR：在原始组装之前，顶点必须适合小的缓存，这本来是顺序的东西（顶点缓冲区的顺序很重要）。

如果将GeForce 7800（9岁？）与今年的980进行比较，似乎每秒可以执行的操作数量增加了1000倍。但是您可以打赌，多边形的推入速度不会快一千倍（按这种简单的度量标准，每秒推入大约2000亿个）。

编辑2：

要回答“如何优化引擎”这个问题，例如“不要在状态切换和其他开销方面失去太多效率”。
这个问题和引擎本身一样古老。并且随着历史的发展变得越来越复杂。

实际上，在现实世界中，典型的场景数据将包含许多材质，许多纹理，许多不同的着色器，许多渲染目标和通道以及许多顶点缓冲区等。我使用过的一种引擎处理数据包的概念：

一个数据包可以通过一个绘制调用呈现。
它包含以下标识符：

• 顶点缓冲区
• 索引缓冲区
• 相机（提供通过和渲染目标）
• 材质ID（提供着色器，纹理和UBO）
• 眼距
• 可见

因此，每一帧的第一步是使用具有优先考虑可见性的运算符的排序功能在数据包列表上进行快速排序，然后依次进行传递，材质，几何形状和距离。

优先绘制接近的物体以最大化早期Z剔除。
通行证是固定步骤，因此我们只能尊重他们。
在渲染目标之后，状态切换是最昂贵的事情。

即使在不同的材质ID之间，也可以使用启发式标准进行子排序，以减少着色器更改的数量（在材质状态切换操作中最昂贵），其次是纹理绑定更改。

完成所有这些排序之后，如果认为必要，可以应用大型纹理，虚拟纹理和无属性渲染（链接）。

关于引擎API，还有一件常见的事情是推迟发出客户端所需的状态设置命令。如果客户端请求“设置相机0”，则最好仅存储此请求，如果以后客户端调用“设置相机1”，但在两者之间没有其他命令，则引擎可以检测到第一个命令的无用性并将其丢弃。这是冗余消除，这可以通过使用“完全保留”的范例来实现。与“立即”范例相反，后者只是本地API的包装，并按客户端代码的顺序正确地发出命令。（例如：virtrev）

最后，对于现代硬件，一个非常昂贵的（开发）的，但潜在的非常有价值的步骤是将API切换为metal / mantle / vulkan / DX12风格，并手工准备渲染命令。

准备渲染命令的引擎将创建一个缓冲区，该缓冲区包含一个“命令列表”，该列表在每一帧均被覆盖。

通常有一个框架“预算”的概念，游戏可以负担。您需要在16毫秒内完成所有操作，因此您可以清楚地划分GPU时间：“ lightpre pass通过2 ms”，“ material pass通过4 ms”，“间接照明6 ms”，“后处理4 ms” ...