Вы хотите рендерить приложение удаленно и просто передавать результат на ваш узел.
Одним из решений может быть использование virtualgl (возможно, с turbovnc для простоты):
https://cdn.rawgit.com/VirtualGL/virtualgl/2.5/doc/index.html
https://cdn.rawgit.com/TurboVNC/turbovnc/2.0.x/doc/index.html
В основном вы хотите установить virtualgl, установить turbovnc, и следовать процедуре в https://cdn.rawgit.com/TurboVNC/turbovnc/2.0.x/doc/index.html#hd009 :
Процедура
Follow the procedure described in Chapter 6 for starting a TurboVNC session and connecting to it.
Open a new terminal inside the TurboVNC desktop.
In the same terminal window, open a Secure Shell (SSH) session into the VirtualGL server:
/opt/VirtualGL/bin/vglconnect {user}@{server}
Replace {user} with your username on the VirtualGL server and {server} with the hostname or IP address of that server. Refer to the VirtualGL User’s Guide for additional vglconnect options.
In the SSH session, set the VGL_COMPRESS environment variable to rgb
Passing an argument of -c rgb to vglrun achieves the same effect.
In the SSH session, start a 3D application using VirtualGL:
/opt/VirtualGL/bin/vglrun [vglrun options] {application_executable_or_script} {arguments}
Совершенно другой подход - передать устройство nvidia pci через vm, используя GPU-PASSTHROUGH. Это требует поддержки как биоса, так и ОС хоста IIRC, но позволит вам использовать драйверы nvidia непосредственно в виртуальной машине.
Обратите внимание, что vmware поддерживает nvidia passthrough, похоже, только для продуктов grid, а не для потребительских продуктов geforce.
Несколько ссылок на подобные решения:
https://www.pugetsystems.com/labs/articles/Multi-headed-VMWare-Gaming-Setup-564/
Есть и другие, я просто не уверен, что ваш случай использования подходит для такого подхода.
Интересным аспектом режима управления является то, что вы можете написать фоновый процесс, который слушает реальный процесс tmux. Он получает уведомления о вещи, происходящие в реальном tmux, и затем он может отправить команды. Если вы используете 2 терминалы и запустить обычный сеанс в одном
tmux new -s mysession
и в другом
tmux -C attach -t mysession
затем, когда вы разделяете окна, добавляете новые или закрываете их в обычном tmux вы получите такие строки, как
%layout-change @2 91a8,80x23,0,0[80x11,0,0,5,80x11,0,12,7]
%window-add @3
%window-close @1
в элементе управления tmux, на который вы можете отреагировать, написав программу. Помочь есть библиотека python для использования этот механизм. Смотрите примеры там.
Вы видите те же результаты из tmux -CC
, что и из tmux new-session
, потому что вы не указали команду, поэтому tmux
использует значение по умолчанию, которое равноnew-session
:
command [flags]
This specifies one of a set of commands used to control tmux, as described in the following sections. If no commands are specified, the new-session command is assumed.
Добавление -CC
не меняет этого. Для управления существующей сессией необходимо подключиться к ней в режиме управления:
tmux -C attach
У меня Mac и я использую iTerm2. Насколько я знаю, это единственный эмулятор терминала с интеграцией tmux. Вы начинаете с выполнения tmux -CC
, и iTerm будет контролировать ваш сеанс tmux. Это означает, что вы можете использовать iTerm2 как обычно (CMD -D для разделения окна по вертикали, CMD -SHIFT -D для разделения по горизонтали ). Вы можете использовать мышь для перемещения панелей вместо использования C-b {
. Вам вообще не нужно использовать префикс. У вас также нет проблем с копированием и вставкой, когда вы имеете дело с панелями.
tl;dr Использование tmux -CC
позволяет использовать tmux «по умолчанию» на терминалах, которые его поддерживают. До сих пор я не видел никаких терминалов Linux, поддерживающих его, только iTerm2 на Mac.
Насколько я понимаю, режим управления аналогичен обычному клиенту. Разница в режиме управления. tmux
клиент считывает команду со стандартного ввода и отправляет на сервер tmux
. В обратном направлении клиент в режиме управления получает сообщение от сервера и выводит на стандартный вывод вместо того, чтобы рисовать терминал, как это делает обычный клиент.
tmux
режим управления не предназначен для непосредственного использования. Он меняет поведение tmux
с интерактивного на более похожее на «прокси». Он предназначен для использования при вызове в эмуляторе терминала, поддерживающем эту функцию, таком как iTerm2. К сожалению, в настоящее время нет терминалов Linux, поддерживающих режим управления. (Хотя Терминатор , кажется, делает успехи.)
Это потрясающая функция.
В качестве примера его использования рассмотрим рабочий процесс, включающий ssh
обращение к удаленному серверу. Пока вы работаете на этом сервере, если вы хотите начать другой сеанс, вы должны создать новое ssh
соединение (не сложно, но хлопотно, и незначительное переключение контекста ).
Введите tmux
.
tmux
может создавать несколько удаленных сеансов через одно соединение (, отсюда и «мультиплексор» в названии ), и отображать их на нескольких вкладках и разделенных панелях. Это, безусловно, работает, но я считаю, что комбинации клавиш, необходимые для навигации tmux
, достаточно громоздки, чтобы заставить меня желать чего-то лучшего. Если бы только был способ, чтобы вкладки и разделенные панели на удаленном компьютере были такими же плавными и естественными, как в родном, локальном эмуляторе терминала...
Введите tmux -CC
.
tmux
режим управления позволяет эмулятору терминала, который поддерживает его, управлять сеансом tmux
, выдавая команды непосредственно ему (, см. ответ meuh ). Например, вы можете открыть новую панель/вкладку в удаленном сеансе, но используя те же нажатия клавиш/команды, что и для открытия локальной панели/вкладки, и это будет локальная панель/вкладка., но подключен к вашему удаленному сеансу.