【问题标题】:Slow OpenGL context access on Ubuntu 12.4Ubuntu 12.4 上缓慢的 OpenGL 上下文访问
【发布时间】:2013-12-31 13:27:31
【问题描述】:

我有一个访问 OpenGL 上下文的应用程序。我在 2 个操作系统上运行它:

1.Kubuntu 13.4

2.Ubuntu 12.4

我遇到了以下问题:在 OS 1 上设置上下文大约需要 60 毫秒,而在 OS 2 上需要 10 倍以上。两个操作系统都使用驱动程序版本 319 的 Nvidia GPU。看起来也像 OpenGL API 调用OS 2 通常较慢。上下文在屏幕外。目前我不知道是什么原因造成的。我的问题是这种开销的可能来源是什么?X11 设置?或者可能是操作系统级别的东西?

另一个区别是 OS 1 使用 Nvidia GTX680,而 OS2 使用 Nvidia GRID K1 卡。另外,OS2 驻留在服务器上,延迟测试在该机器上本地运行。

更新:

这是导致大部分开销的部分:

typedef GLXContext (*glXCreateContextAttribsARBProc)(Display*, GLXFBConfig, GLXContext, Bool, const int*);
typedef Bool (*glXMakeContextCurrentARBProc)(Display*, GLXDrawable, GLXDrawable, GLXContext);
static glXCreateContextAttribsARBProc glXCreateContextAttribsARB = 0;
static glXMakeContextCurrentARBProc glXMakeContextCurrentARB = 0;

int main(int argc, const char* argv[]){
    static int visual_attribs[] = {
            None
    };
    int context_attribs[] = {
            GLX_CONTEXT_MAJOR_VERSION_ARB, 3,
            GLX_CONTEXT_MINOR_VERSION_ARB, 0,
            None
    };

    Display* dpy = XOpenDisplay(0);
    int fbcount = 0;
    GLXFBConfig* fbc = NULL;
    GLXContext ctx;
    GLXPbuffer pbuf;

    /* open display */
    if ( ! (dpy = XOpenDisplay(0)) ){
            fprintf(stderr, "Failed to open display\n");
            exit(1);
    }

    /* get framebuffer configs, any is usable (might want to add proper attribs) */
    if ( !(fbc = glXChooseFBConfig(dpy, DefaultScreen(dpy), visual_attribs, &fbcount) ) ){
            fprintf(stderr, "Failed to get FBConfig\n");
            exit(1);
    }

    /* get the required extensions */
    glXCreateContextAttribsARB = (glXCreateContextAttribsARBProc)glXGetProcAddressARB( (const GLubyte *) "glXCreateContextAttribsARB");
    glXMakeContextCurrentARB = (glXMakeContextCurrentARBProc)glXGetProcAddressARB( (const GLubyte *) "glXMakeContextCurrent");
    if ( !(glXCreateContextAttribsARB && glXMakeContextCurrentARB) ){
            fprintf(stderr, "missing support for GLX_ARB_create_context\n");
            XFree(fbc);
            exit(1);
    }

    /* create a context using glXCreateContextAttribsARB */
    if ( !( ctx = glXCreateContextAttribsARB(dpy, fbc[0], 0, True, context_attribs)) ){
            fprintf(stderr, "Failed to create opengl context\n");
            XFree(fbc);
            exit(1);
    }

    /* create temporary pbuffer */
    int pbuffer_attribs[] = {
            GLX_PBUFFER_WIDTH, 800,
            GLX_PBUFFER_HEIGHT, 600,
            None
    };
    pbuf = glXCreatePbuffer(dpy, fbc[0], pbuffer_attribs);

    XFree(fbc);
    XSync(dpy, False);

    /* try to make it the current context */
    if ( !glXMakeContextCurrent(dpy, pbuf, pbuf, ctx) ){
            /* some drivers does not support context without default framebuffer, so fallback on
             * using the default window.
             */
            if ( !glXMakeContextCurrent(dpy, DefaultRootWindow(dpy), DefaultRootWindow(dpy), ctx) ){
                    fprintf(stderr, "failed to make current\n");
                    exit(1);
            }
    }

    /* try it out */
    printf("vendor: %s\n", (const char*)glGetString(GL_VENDOR));

    return 0;
}

具体来说,一行:

pbuf = glXCreatePbuffer(dpy, fbc[0], pbuffer_attribs);

创建虚拟 pbuffer 的位置是最慢的。如果其余函数调用平均需要 2-4 毫秒,则此调用在 OS 1 上需要 40 毫秒。现在,在 OS2(很慢)上创建 pbuffer 需要 700 毫秒!我希望现在我的问题看起来更清楚了。

【问题讨论】:

  • 为什么不向我们展示实际代码呢?这样我们就可以看到为什么它很慢?由于我们并不神奇地知道这一点,我们需要查看代码,计算机正在运行!
  • 我没有看到任何变化?
  • 顺便说一句,我几乎不相信这段代码有问题,因为它在 Kubuntu 13.4 上运行得非常快
  • 我的问题有什么问题?
  • 人们下载的原因是... 1:没有任何实际问题,正如您所说的,您的程序运行良好! 2:你甚至不会提供你的实际代码,这是最重要的,能够揭穿为什么你的代码会很慢......而且是你的代码很慢,所以你不能只给我们一个链接到其他一些随机代码并说...嗯,这就是我的代码的样子。不!提供您的代码!

标签: linux opengl ubuntu nvidia


【解决方案1】:

绝对确定“OS2”已正确设置驱动程序并且没有退回到 SW OpenGL (Mesa) 渲染? glxgears 在每个系统上报告的帧率是多少?

我注意到 Ubuntu 12.4 是在 2012 年 4 月发布的,而我相信 NVidia 的“GRID”技术直到 GTC 2012 年 5 月才公布,我认为显卡直到 2013 年才出现(参见 relevant Nvidia press releases)。因此,Ubuntu 12.4 随附的 Nvidia 驱动程序似乎不太可能支持网格卡(除非您已经努力使用 Nvidia 的最新驱动程序版本进行升级?)。

您可以在/usr/share/doc/nvidia-glx/README.txt.gz 的附录 A“支持的 NVIDIA GPU 产品”中查看支持的硬件列表(至少我的 Debian 机器上这些有用的信息在那里)。

【讨论】:

  • 肯定 100%,因为我的 OpenGL 使用 CORE 4.4 完全可编程配置文件。它永远不会在 Mesa 或任何 SW 渲染上运行。
  • 有趣。您称其为“GRID 卡”的是哪种型号的卡?我的印象是 GRID 更像是可视化技术的集合(nvidia.com/object/nvidia-grid.html)而不是“一张卡片”;在某些远程 VDI 设置中,您的“OS2”实际上是否也可以通过网络访问?
  • 是的,这是 GRID K1(请参阅 nvidia 上的规范)。OS2 在远程服务器上,但延迟测试是在该服务器上本地完成的。现在我试图了解硬件的差异(像 CPU 模型)可能会导致它或者可能在那里运行的某些进程阻塞 pbuffer init...
  • 嗯......谁知道 Nvidia 为虚拟化这些东西所做的任何魔法会带来什么开销。 700ms 听起来很长;就个人而言,我会考虑编写一个最小的示例并将错误提交给 NV。我会有点怀疑,即使是屏幕外的 pbuffer 也会向您的客户端触发一些网络活动;您可以监控您与wireshark 的连接并查看NV 用于其VDI 的端口上的任何活动吗?您对服务器有多少延迟?
  • \另一个有趣的细节是,在相同的 OS2 上但使用 NVidia Tesla 运行相同的测试不会导致这种开销。
猜你喜欢
  • 2014-01-12
  • 1970-01-01
  • 1970-01-01
  • 2013-11-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多