performance - 为什么绘制调用很昂贵?

标签 performance optimization graphics 3d gpu

假设纹理、顶点和着色器数据已经在显卡上,则不需要向显卡发送太多数据。有几个字节来标识数据,大概是一个 4x4 矩阵,以及一些其他的参数。

那么所有的开销从哪里来呢?这些操作是否需要与 GPU 进行某种握手?

为什么发送包含一堆小模型(在 CPU 上计算)的单个网格通常比发送顶点 ID 和变换矩阵更快? (第二个选项看起来应该发送较少的数据,除非模型小于 4x4 矩阵)

最佳答案

首先,我假设“绘制调用”是指告诉 GPU 将一组特定顶点渲染为具有特定状态(着色器、混合状态等)的三角形的命令。

绘制调用不一定很昂贵。在旧版本的 Direct3D 中,许多调用需要上下文切换,这成本很高,但在新版本中并非如此。

减少绘制调用的主要原因是图形硬件转换和渲染三角形的速度比您提交三角形的速度快得多。如果您每次调用时提交几个三角形,您将完全受到以下约束: CPU 和 GPU 大部分时间都处于空闲状态。 CPU 将无法足够快地为 GPU 提供数据。

使用两个三角形进行一次绘制调用很便宜,但如果每次调用提交的数据太少,您将没有足够的 CPU 时间来向 GPU 提交尽可能多的几何图形。

进行绘制调用会产生一些实际成本,它需要设置一堆状态(要使用哪组顶点,要使用什么着色器等等),并且状态更改在硬件方面都会产生成本(更新一堆寄存器)和驱动程序端(验证和转换设置状态的调用)。

但是绘制调用的主要成本仅在每次调用提交的数据太少时才适用,因为这会导致您受到 CPU 限制,并阻止您充分利用硬件。

正如 Josh 所说,绘制调用也会导致命令缓冲区被刷新,但根据我的经验,这通常发生在调用 SwapBuffers 时,而不是提交几何图形时。视频驱动程序通常会尝试尽可能多地缓冲(有时是几帧!),以尽可能多地从 GPU 中挤出并行性。

您应该阅读 nVidia 演示文稿 Batch Batch Batch! ,它相当旧,但完全涵盖了这个主题。

关于performance - 为什么绘制调用很昂贵?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4853856/

相关文章:

java - 优化MySQL更新查询

java - 图形加载缓慢或什至无法加载

java - 带有缓冲区策略的 OS X 上的 JFrame 禁用圆角

performance - 合并加入笛卡尔

tensorflow - Adam 优化器真的是 RMSprop 加动量吗?如果是,为什么它没有动量参数?

c# - 在 C# 中保存字典 <String, Int32> - 序列化?

clang/gcc 可以优化链表树吗?

使用 ggplot2 重现以下基本图

performance - glBitmap问题

wpf - RichTextBox的格式慢