seg断层上的OpenGL +过剩

Question

我试图在SSH上运行一个带有X转发的OpenGL+GLUT程序。该程序提供以下错误，然后是seg错误。

Xlib:扩展“NV”在显示"localhost:10.0“时丢失。

这似乎是因为我的“服务器”计算机有一张nvidia卡，然后告诉我的客户端计算机使用这些特定于nvidia的呈现功能，而客户端没有nvidia卡。当然，我在googled上搜索了这个，并发现许多其他人也有类似的问题；然而，我真正看到的唯一解决方案就是尝试(https://superuser.com/questions/196838/opengl-program-not-work-with-x-forwarding)。

$ export LIBGL_ALWAYS_INDIRECT=1   or use any nonzero value

但没起作用。我不关心硬件加速/维护在ssh连接上的出色性能。我只想得到窗口渲染。

Answer 1

首先，使用X11，服务器是产生显示输出的计算机。客户端是利用服务器的显示服务在远程计算机上运行的程序。

您是正确的，因为您的客户机(运行在远程计算机上)是在带有NVidia GPU的机器上执行的。然而，制造麻烦的不是GPU，而是它的驱动程序。Linux (应用程序二进制接口)的主要缺点之一是，驱动程序还负责提供系统的OpenGL；如果您考虑它，这是一个相当糟糕的规范，因为它积极地阻止了不同供应商的多个GPU的驱动程序的安装。(Windows从来没有出现过这样的问题，因为它是ICD OpenGL驱动程序模型)。

无论如何，当您的NVidia GPU的libGL.so连接到不运行NVidia驱动程序的远程X服务器时，将看到某些服务器扩展是不可用的，因此拒绝工作。

你能对此做些什么？

那么，您可以在Mesa3D驱动程序的旁边安装NVidia；大多数NVidia发行版都有相应的机制(Gentoo eselect，Debian )，可以安装一个NVidia提供程序的多个变体，并选择一个作为默认值。

安装了Mesa3D后，您可以使用LD_PRELOAD环境变量预加载Mesa3D libGL.so (它将位于/usr/lib64/opengl/xorg-x11/lib/libGL.so之类的某个位置--使用您的Linux发行版的包管理器工具查找它所在的位置；或者执行find /usr -iname 'libGL.so*'并选择一个目录，其中一个目录不包含nvidia)，而不是系统默认的libGL.so。

另一种可行的方法是使用lxc容器，使用Mesa3D作为默认的OpenGL提供程序来创建辅助系统安装，并且当通过SSH登录到系统时，您会被放入这样的lxc容器中(注意，如果配置正确，则完全有可能使容器仅仅覆盖在基本系统上，其中仍有可能进入裸系统)。

Mesa3D libGL.so将愉快地在远程X会话上工作。但是，请记住，已经为OpenGL-2.1指定了全部的间接操作，但没有进一步指定(例如，对于OpenGL-3的许多功能，后来没有定义GLX操作码)；但是，许多扩展(这也使其成为OpenGL-3核心)定义了GLX操作码，因此，如果您依赖于间接OpenGL，则可能会对这些扩展产生影响。

更新：

在使用扩展和现代OpenGL功能时也要小心。所有必须在运行时使用glXGetProcAddress加载的函数都可能根本不可用。您正在接收的分段错误表明，您可能正在调用一个函数指针(通过GLEW或类似的方式加载)，这是完全不可用的，因此您正在取消引用导致崩溃的无效指针。始终检查，您调用的所有函数和扩展都是实际存在的！