1

对于我的工作，我们正在寻找一个允许我们进行导出显示的应用程序。规格为：

  • 客户端使用 Windows/Linux 系统
  • 服务器是一个 linux Red-Hat 6 集群
  • 服务器端有基于 OpenGL 的应用程序。它们必须在客户端上运行得很快，至少尽可能快
  • GPU在服务器端。用户在集群上打开一个可视化会话，该会话使用 GPU 分配特定节点。

目前，我们在服务器上使用 TurboVNC（带有一个名为“vncviewer”并由 ssh 隧道保护的 vnc 客户端）和 virtualGL 来使用“vglrun name_application”命令启动 OpenGL 应用程序（类型 paraview）。

有人可以给我一些替代解决方案的建议吗？

我看到了 XDCMP 解决方案，但它不是安全的。我们不能使用 ssh X 转发，因为它的工具很慢。

顺便问一下，客户端分配的资源和服务器分配的资源之间的导出显示比例是多少？

TurboVNC 似乎在服务器上分配了更多资源：这是否意味着客户端不管理图形处理，只从服务器接收原始数据，这些数据显示在客户端？

那么，当我执行“ssh -X”时不会出现这种情况？（这应该是在本地处理 OpenGL 处理的客户端）

任何澄清都会很棒，

谢谢

4

1 回答 1

1

您愿意等待多长时间才能将其投入生产？

现在 Linux 图形堆栈是围绕 Xorg 构建的。Xorg 有一个不方便的缺点，即您不能运行使用 GPU 的纯屏幕外 X 服务器。如果您只能与一个使用 GPU 的用户和持有 VT 的 GPU 一起生活，那么您可能想要研究Xpra从使用 GPU 而不是dummy驱动程序的 X 服务器配置开始。

如果您愿意再等两年（希望如此），所有驱动程序都将完全支持 KMS 和 DRM 内核接口；尽管我不喜欢 Wayland 的某些方面，但它也是一个巨大的游戏规则改变者，它给 NVidia 带来了很大的同行压力，以最终绕过并使用“标准”API。现在，您已经可以使用libgbm支持它且不运行显示服务器的 GPU 创建纯粹的屏幕外 OpenGL 渲染上下文；即在 Mesa3D 树中具有开源驱动程序的 GPU（英特尔和AMD，但目前只有 OpenGL-3，没有 OpenCL）。再过 2 年，API 和工具就会稳定下来，您可以在生产中方便地使用它。

于 2014-05-04T11:55:22.260 回答