缓存OpenGL状态仍然有意义吗？

Question

曾经有一段时间，人们说“管理”OpenGL州是有用的(刚刚看到一篇关于它的文章，从2001年开始)。像这样(C++)：

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和操作系统，所以我的个人测试不能有足够的代表性。

编辑:那么像绑定缓冲区，帧缓冲区，纹理，.

Answer 1

仍然(现在是2017年)值得让所有这些检查代码占用周期而不是总是调用驱动程序吗？

你这么说好像这是“值得的”。不是，现在也不是。至少在一般情况下不是。

在以前的情况下，状态缓存是有用的:当您无法直接控制正在发生的事情时。

例如，如果您正在编写一个游戏引擎，那么您对您打算做什么呈现操作以及打算何时进行渲染操作有明确的了解。你知道你所有的网格都将使用面剔除，你让你的艺术家/工具管道来处理这个问题。对于GUI呈现或类似的情况，您可能会关闭筛选，但这将是特定的情况。

相反，如果您正在编写一个通用的呈现系统，其中用户几乎完全控制了网格的性质，状态缓存可能会有所帮助。如果您的代码被告知哪些网格使用面剔除，哪些不使用，那么您就无法控制这类事情。而且，由于较高级别的代码/数据无法直接与OpenGL对话，所以您可以进行一些状态缓存以使事情顺利进行。

因此，如果您控制了事情的呈现方式，如果您控制了数据的广泛性质以及数据的绘制方式，那么就不需要缓存了。你的代码充分地完成了这个任务。在良好的数据驱动设计中，您可以命令数据的呈现，这样您仍然不需要缓存。你只需要一个完全自由轮转的系统，在那里外部世界几乎完全控制所有的国家，很少考虑其状态变化对性能的影响。