linux - Linux 与 macOS 中的巨大 OpenGL 性能差异，相同的硬件

Question

关闭。这个问题需要debugging details .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

4年前关闭。




Improve this question




我正在构建一个 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 上，我的帧时间大约是 30 毫秒到 80 毫秒。然而，在 Linux 上，它是惊人的 1 毫秒到 4 毫秒。同样，同一台笔记本电脑，只是在不同的操作系统中重新启动。将应用程序窗口缩小到大约 600x400，在 macOS 上将帧时间降低到 13 毫秒。因此，似乎像素着色器/光栅化是瓶颈(我的着色器确实非常复杂)。

我必须说我过去在 macOS 上有更好的帧时间(大约 13 毫秒到 20 毫秒)。所以，我发现这一点后真的很怀疑，苹果可能通过系统更新故意“降级”Intel HD Graphics 3000的图形驱动程序，以插入客户购买新产品。我必须说，我一直在考虑购买一台新的笔记本电脑，但自从我发现这一点后，突然产生了厌恶感。

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

我只是讨厌该应用程序在 Linux 中使用起来非常棒，而在 macOS 中却令人不快。硬件能够做得更好。

@BDL 要求的一些测试:

在每个维度上将纹理的大小减少 4 倍(因此内存减少 16 倍，留下大约 500x500 的纹理)，不会影响帧时间。

使用 GL_RGB8 或 GL_SRGB8 作为内部格式不会影响帧时间。

降低大量着色器复杂性确实有帮助:在片段着色器中删除大量计算时，我可以将其平均降低到 8 毫秒。

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

Answer 1

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

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

请记住，OpenGL 采用异步执行模型，并且没有关于缓冲区交换调用的确切时间的硬性规范。在 Linux 上，AMD 和 NVidia OpenGL 几乎都有 …SwapBuffers阻塞直到垂直同步(如果垂直同步已启用)。但是我发现 Mesa/Intel 实现可以处理 …SwapBuffers就像另一个排队的命令一样，真正的块只会在命令队列被填满并且调用最终只能在缓冲区交换后才能执行(如清除后台缓冲区)时发生。

长话短说，我找到了唯一可靠的方法，通过放置 glClear 来实际测量帧渲染直到呈现¹ 次立即调用 …SwapBuffers (即清除将在下一次迭代中出现的下一帧)并测量从渲染开始到异常放置之后的时间 glClear称呼。

无论如何，通过查询对象更好地测量纯呈现时间(不包括表示部分)。