Экспорт приложения дисплея

для моей работы мы ищем приложение, которое позволяет нам отображать экспорт. Спецификации:

  • клиенты используют систему Windows/Linux
  • сервер представляет собой кластер Linux Red-Hat 6
  • на стороне сервера есть приложения на основе OpenGL. они должны работать быстро на клиенте, по крайней мере, насколько это возможно
  • GPU находятся на стороне сервера. Пользователи открывают сеанс визуализации в кластере, который выделяет определенные узлы с GPU.

На данный момент мы используем TurboVNC (с vnc-клиентом под названием «vncviewer» и защищенным ssh-туннелем) и virtualGL на сервере для запуска приложений OpenGL (типа paraview) с помощью команды «vglrun name_application».

Может ли кто-нибудь дать мне советы для альтернативных решений?

Я видел решение XDCMP, но оно не защищено. Мы не можем использовать переадресацию ssh X, потому что это медленно.

Кстати, какова пропорция для отображения экспорта между ресурсами, выделяемыми клиентом, и ресурсами, выделяемыми сервером?

TurboVNC, похоже, выделяет больше ресурсов на сервере: означает ли это, что клиент не управляет обработкой графики и получает только необработанные данные с сервера, которые отображаются на стороне клиента?

Тогда этого не будет, если я сделаю «ssh -X»? (это должен быть клиент, который локально обрабатывает OpenGL)

Любое разъяснение было бы здорово,

Спасибо


person youpilat13    schedule 04.05.2014    source источник


Ответы (1)


Как долго вы готовы ждать, чтобы запустить это в производство?

Прямо сейчас графический стек Linux построен на Xorg. И у Xorg есть неудобный недостаток: вы не можете запускать чисто внеэкранные X-серверы, использующие GPU. Если вы можете жить только с одним пользователем, использующим графический процессор, а графический процессор содержит VT, вы можете захотеть изучить Xpra, который вы начинаете с конфигурацией X-сервера, использующей графический процессор вместо драйвера dummy.

Если вы готовы подождать еще два года (будем надеяться), все драйверы будут полностью поддерживать KMS и интерфейсы ядра DRM; как бы мне не нравились некоторые аспекты Wayland, это также огромный переломный момент, который оказывает сильное давление на NVidia, чтобы, наконец, обойти и использовать «стандартные» API. Уже сейчас вы можете использовать libgbm для создания чисто внеэкранных контекстов рендеринга OpenGL с графическими процессорами, которые его поддерживают, и без запущенного сервера отображения; то есть графические процессоры с драйверами с открытым исходным кодом в дереве Mesa3D (Intel и AMD, однако пока только OpenGL-3, а не OpenCL). Дайте ему еще 2 года, и API и инструменты стабилизируются, и вы сможете удобно использовать их в производстве.

person datenwolf    schedule 04.05.2014
comment
Приложения OpenGL также прекрасно работают с xpra: xpra.org/trac/wiki/Usage/OpenGL И вы можете использовать GPU с фиктивным драйвером через vglrun - person totaam; 01.07.2015
comment
@totaam: я знаю, BT; DT, но стабильность этого сильно зависит от каждого выпуска Xpra. В последние несколько месяцев я фактически прибегал к использованию вместо этого x11vnc, несмотря на его ужасные требования к пропускной способности. Проблема с VirtualGL заключается в том, что он не поддерживает самые современные функции, которые (к сожалению для меня) мне нужны в самом приложения, с которыми я выполняю удаленные операции. - person datenwolf; 01.07.2015
comment
не знаю о каких-либо серьезных проблемах с xpra, поэтому вряд ли они будут исправлены! - похоже, что ваши проблемы связаны с vgl, а не с xpra? вы сообщили о них там? - person totaam; 02.07.2015
comment
@totaam: Проблемы полностью связаны с Xpra, например: невозможно даже установить стабильное соединение с некоторыми версиями, и X-сервер (процесс Xpra xvfb) немедленно перезагружается при удалении клиента. Глубоко не проанализировал его и, следовательно, еще не сделал отчета. - person datenwolf; 02.07.2015
comment
ах, хорошо - звучит как дистрибутив или конфигурация, так как никто никогда не сообщал о таких проблемах - person totaam; 02.07.2015