CPU与GPU的几何变换

我注意到,许多3D程序通常做vector/matrix计算以及CPU上的几何变换。 有没有人发现将这些计算转移到GPU上的顶点着色器的优势?

一般来说:网格转换是在GPU上完成的。 您将转换matrix发送到GPU,着色器将其应用到网格的所有顶点。

使用GPU来计算matrix本身是一个不同的问题,在GPU上实际上是比较慢的,因为存在如此多的存储值,这些值在帧之间变化,这对于帮助确定最终变换matrix是必需的。 将这些数据发送到CPU和GPU的速度很慢。 而且,在CPU上,计算只进行一次,而在GPU上,它们将针对每个顶点完成。

许多几何转换可以在非GPU处理器上完成,但是必须考虑目标平台。 您的里程将根据您定位的平台以及该平台的瓶颈而有所不同。

一个考虑因素是生成几何体的设备与渲染几何体的设备之间的总线带宽。

在典型的现代个人电脑系统中,CPU位于PCIe总线的一侧(http://en.wikipedia.org/wiki/PCI_Express),而GPU则位于另一侧。 您可以将每帧生成的数据从CPU传输到GPU(反之亦然)的唯一方法是通过此总线。 这意味着,你可以受限于这辆巴士的转移速度。 如果您的目标平台具有16条通道的PCIe 2.x,则具有8GB / s的带宽。 实际上,通过PCIe传输的效率并不是100%,因为在传输过程中会消耗一些带宽。 根据您的传输大小,您可能会损失5-10%的带宽,只是每个数据包开销。

例如。 给定一个运行带有16条通道的PCIe 2.x的PC平台,可以为每个帧生成多less数据以供给GPU? 假设您希望以60fps的速度运行,则对于PCIe 2.x,这意味着每帧8GB / 60 = 136MB。 乘以一些(估计的)90%的因子来解决驱动器通信开销和PCIe传输协议开销,每帧可产生大约120Mb的数据,而不受PCIe 2.x带宽的限制。

还有一个问题需要回答:在目标CPU的1/60秒内,这个120Mb数据的产生是否会很容易实现? 记住你必须在你的CPU上执行许多其他的游戏任务,你可能会花时间去生成转换后的数据。 就纯ALU吞吐量而言,这可能会限制您的CPU。 在CPU到sysmem总线方面,你也可以受到带宽的限制(这个变化在最近的CPU上大概在8.5GB / s左右)。

好的,那么什么因素使得在GPU上更可行呢? 一个因素是GPU内存带宽,即GPU与本地video内存之间的带宽。 在当代中档GPU上,这种显存带宽可高达200GB / s(是的,这是PCIe 2.x带宽的25倍)。 另一个因素是GPU是大规模并行的,拥有数百个ALU,并且能够通过一次运行数千个线程来隐藏存储器访问延迟。

所有这些因素都可以促成将更多工作推向GPU的明显胜利,而YMMV又取决于您的目标平台。

你是什​​么意思的“网格转换”? 由几组matrix转换几何? 现在大多数游戏都会让GPU处理简单的转换,蒙皮等。而且大多数游戏都将使用顶点着色器来完成。 在某些平台上,你可能没有着色器,或者在CPU上做这些事情还有其他的好处。 例如,在PS3上,您可以通过让SPU处理剥皮和转换来减轻RSX的负担。 如果您正在进行多路照明,那么在CPU上进行剥皮可能是有利的,因为您只需执行一次并提交要绘制的每个渲染通道的结果。 所以也有例外,但是一般来说大多数游戏都是在GPU和着色器上做这些事情的。

还是你的意思是有点像一些vectormath的GPU? 现在我们有通用GPU,可以通过像CUDA这样的系统运行相当通用的C代码。 有可能利用这个重vectormath,我知道有这样做的程序。 我个人没有任何经验。

有些情况下GPU上渲染的所有东西都可能是有意义的,但是你不能在着色器中设置常量,除了在绘制调用之前的CPU侧之外,没有其他的设置。

即使你可以用GPU自定义初始化程序来计算你的常量,比如骨骼变换matrix,你可能也不想这样做。 GPU在并行执行方面非常出色,但是时钟速度要慢得多。

由于子节点依赖父节点,但是变换网格中的所有顶点是因为顶点计算彼此独立,所以变换层次结构并不是简单的可并行化。

一般规则是:

  • 串行处理:CPU
  • 并行处理:GPU