Linux与macOS,相同硬件

时间:2017-05-03 21:24:03

标签: linux macos performance opengl gpu

我正在构建一个OpenGL应用程序。它对OpenGL唯一不方便的是它使用了一些(5个或更多)相当大(2000x2000和更大)的纹理。其余的是相当默认的现代OpenGL 3.3内容(FBO,VBO,IBO,VOA,着色器等)。因为这些纹理太大,并且需要一些超过8位的位深度,所以我使用GL_R11F_G11F_B10F内部像素格式来减少内存(但是,将其更改为简单的东西,没有帮助(参见下图))。

现在,问题就在于:完全相同的代码,运行在Windows,Linux和macOS上(我使用SDL作为抽象层)。 Linux和macOS在同一硬件(我2011年末的MacBook Pro 13“,Intel HD Graphics 3000 @ 1280x800),相同的编译器(clang -O3 -mavx)之间的性能差异是巨大的。在macOS上我的帧时间大约是30ms到80ms。然而,在Linux上,这是一个惊人的1ms到4ms。同样,同样的笔记本电脑,只是在不同的操作系统重新启动。将应用程序窗口缩小到大约600x400,在macOS上将帧时间降低到13ms。 ,似乎像素着色器/光栅化是瓶颈(我的着色器确实非常复杂)。

我必须说我过去在macOS上有更好的帧时间(大约13ms到20ms)。因此,在发现这一点之后,我真的很怀疑,Apple可能会通过系统更新“降低”英特尔HD Graphics 3000的图形驱动程序,以推动客户购买新产品。我必须说我一直在考虑买一台新的笔记本电脑,但自从我发现这件事后,突然出现了令人厌恶的情绪。

现在的问题是:您认为这里会发生什么?越野车司机?苹果故意让事情变慢?驱动程序中包含未经优化的GLSL编译器?或者在应用程序中我的OpenGL代码中有一些不好的做法?驱动程序是否常常支持非8位纹理格式?

我只是讨厌在Linux中使用该应用程序非常棒,在macOS中使用非常令人愉快。硬件能够做得更好。

根据@BDL的要求进行一些测试:

  • 在每个维度上将纹理大小减少4倍(因此内存减少16倍,使我们的纹理大约为500x500),不会影响帧时间。
  • 使用GL_RGB8或GL_SRGB8作为内部格式不会影响帧时间。
  • 减少很多着色器的复杂性确实有帮助:在片段着色器中丢弃大量计算时,我可以将其降低到8ms。

我明天会尝试使用glsl着色器优化器:https://github.com/aras-p/glsl-optimizer 希望这有点帮助。

2 个答案:

答案 0 :(得分:2)

您使用什么方法来测量帧渲染时间?在我关于各种OpenGL实现的时序行为的实验中,Mesa / Intel HD驱动程序具有最难以解释的时序行为。

适用于MacOS X的英特尔高清显卡驱动程序是一个完全不同的代码库(零源代码重叠!),由一个完全不同的开发团队(主要是Apple人员AFAIK)编写。

请记住,OpenGL采用异步执行模型,对缓冲区交换调用的确切时间没有硬性规范。在Linux上,AMD和NVidia OpenGL几乎都有…SwapBuffers阻塞,直到V-Sync(如果启用了V-Sync)。但是我发现Mesa / Intel实现将…SwapBuffers视为另一个排队命令,只有命令队列填满并且调用最终只能在缓冲区交换后执行(如同)清除后台缓冲区。)

简而言之,我找到了唯一可靠的方法,通过在 glClear之后…SwapBuffers调用正确的来实际测量帧渲染直到演示时间(即清除下一次迭代中的下一帧)并测量从渲染开始到异常放置glClear调用之后的时间。

无论如何,通过查询对象可以更好地测量纯渲染时间(没有演示部分)。

答案 1 :(得分:-2)

由于我们无法访问您的代码,因此通常很难在堆栈溢出问题上找到问题的根源但是您可以尝试以下几种方法:

  • 将驱动程序更新为操作系统支持的最新版本。
  • 打开图形调试器并检查缓冲区大小,纹理大小,RAM使用情况,内存使用情况等。

可能只是需要在OSX和Linux之间解决一些时序问题,您还可以使用SDL获取指向原始窗口资源的指针并以此方式解决问题。