我听说更少的绘图调用 = 更快 隐含的教训是将尽可能多的顶点数据打包到尽可能少的数组中,以最大限度地减少绘图调用的数量。
我正在考虑在 OpenGL 之上编写一个渲染框架,将所有顶点数据打包到少量数组中,并在几个绘图调用中绘制整个场景。
我的问题是,如果在一次调用中进行大量绘图(例如 glDrawElements),这是否真的会更快结束?
我还听说,如果您尝试通过一次调用绘制太大的顶点数组,它将溢出缓存并且最终不会变得更快。
我听说更少的绘图调用 = 更快 隐含的教训是将尽可能多的顶点数据打包到尽可能少的数组中,以最大限度地减少绘图调用的数量。
我正在考虑在 OpenGL 之上编写一个渲染框架,将所有顶点数据打包到少量数组中,并在几个绘图调用中绘制整个场景。
我的问题是,如果在一次调用中进行大量绘图(例如 glDrawElements),这是否真的会更快结束?
我还听说,如果您尝试通过一次调用绘制太大的顶点数组,它将溢出缓存并且最终不会变得更快。
这篇文章对你很有用:http ://www.nvidia.de/docs/IO/8230/BatchBatchBatch.pdf
恕我直言,您最好针对状态变化进行优化。即最小化您必须切换着色器或纹理等的次数。这些是“真正的”昂贵的操作。
但是关于你的问题。从大顶点缓冲区渲染大量顶点(根据我的经验)总是比从多个较小顶点渲染要快。
我不确定“缓存溢出”的事情。据我所知,顶点获取单元直接从 GPU 内存中获取顶点(嗯,有一个顶点缓存,但它只存储大约 16 个顶点)。您可能遇到的唯一溢出是 VRAM 用完,此时您会遇到更大的问题。
大顶点缓冲区的唯一另一个问题是驱动程序将无法在内存中移动它们。如果您的顶点缓冲区是静态的,这不是问题,但在“动态”更改数据时,您可能会看到性能较差。