void CStateManager::setCulling(bool enabled)
{
if (m_culling != enabled)
{
m_culling = enabled;
if (m_culling)
glEnable(GL_CULL_FACE);
else
glDisable(GL_CULL_FACE);
}
}
我可以看到,在OpenGL服务器与OpenGL客户端不在同一个地方的情况下,这可能仍然有用。但在我的“游戏”引擎中肯定不是这样,所以让我们假设OpenGL客户端总是和OpenGL服务器在同一台机器上。
它是否仍然(现在是2017年)值得让所有这些检查代码占用周期而不是总是调用驱动程序?
可以说我自己应该对它进行分析,但我认为结果并不重要,因为有太多不同的图形适配器,驱动程序,CPU,操作系统,我的个人测试不够具有代表性。 / p>
编辑:关于绑定缓冲区,帧缓冲区,纹理等等......
答案 0 :(得分:3)
它是否仍然(现在是2017年)值得让所有这些检查代码占用周期而不是总是调用驱动程序?
你说好像曾经“值得”。它不是,它仍然不是。至少,不在 general 。
状态缓存在以前的情况下非常有用:当您无法直接控制正在发生的事情时。
例如,如果您正在编写游戏引擎,那么您对已打算执行的渲染操作以及何时打算执行这些操作有扎实的了解。你知道你的所有网格都将使用面部剔除,你可以让你的艺术家/工具管道相应地处理它。您可能会关闭GUI渲染的面部剔除或类似的东西,但那些将是特定情况。
相比之下,如果您正在编写一个通用渲染系统,用户几乎可以完全控制网格的性质,那么状态缓存可能会有所帮助。如果你的代码被告知哪些网格使用面部剔除而哪些没有,那么你就无法控制那种东西了。而且由于更高级别的代码/数据无法直接与OpenGL通信,因此您可以执行一些状态缓存来平滑事物。
因此,如果您掌控事物的渲染方式,如果您控制数据的广泛性和绘制方式,那么您就不需要缓存。您的代码可以充分发挥作用。在良好的数据驱动设计中,您可以订购数据呈现,这样您仍然不需要缓存。你只需要一个完全自由转动的系统,外部世界几乎完全控制所有状态,并且很少考虑其状态变化对性能的影响。