Віддалене екранне відображення

Нещодавно у моїй дослідницькій лабораторії був доданий сервер із графічною картою NVIDIA, яку ми хотіли б використовувати для наукових обчислень. Оскільки це не робоча станція, нам доведеться запускати свою роботу віддалено, через ssh-з'єднання. Більшість наших додатків вимагають зробити opengl-рендерінг на екрані екрана, а потім зробити аналіз зображення на результат у CUDA.

Моє первинне розслідування свідчить про те, що перенаправлення X11 - це погана ідея, оскільки візуалізація opengl відбуватиметься на клієнтській машині (а точніше на сервері X11 - яка заплутана конвенція про іменування!) І зазнаватиме мережевих вузьких місць при надсиланні наших масових текстур. Нам ніколи не потрібно буде відображати вихід, тому здається, що пересилання X11 не повинно бути необхідним, але Opengl потребує $ DISPLAY, щоб встановити щось дійсне, або наші програми не працюватимуть. Я впевнений, що існують ферми рендерингу, які це роблять, але як це здійснюється? Я думаю, що це, мабуть, проста конфігурація X11, але я занадто незнайомий з ним, щоб знати, з чого почати.

Ми працюємо на сервері Ubuntu 10.04, без встановлених gdm, gnome тощо. Однак пакет xserver-xorg встановлений.

Минув час, коли я задав це питання, тому я подумав згадати рішення, яке ми в кінцевому підсумку використали.

Викрадення локального екрана X

Зрештою, я просто запустив віддалені програми opengl на локальному екрані X сервера. На машині було запущено серверне видання Ubuntu, і він не запускав xserver за замовчуванням, тому мені довелося налаштувати xserver для запуску при запуску (я щойно встановив пакет Ubuntu-настільний Ubuntu, убивши комара кувалдою), а потім надав собі доступ до екрана X, використовуючи ці команди як корінь: "експортувати DISPLAY =: 0,0; xhost + local:". Тоді я міг би сш в машину, викликати "експортувати DISPLAY =: 0,0", а потім запустити свої програми opengl як звичайні. Кожен, хто сидів на віддаленій машині, побачив би спливаюче вікно і дивився, як моя програма працює, але у нас немає підключеного монітора, тому це не було проблемою.

Важливо використовувати певну форму екранного відображення, оскільки читання пікселів безпосередньо з екранного кольорового буфера може спричинити отримання сміття, якщо вікно затьмариться іншим вікном. Оскільки ви не бачите екран X, важко дізнатися, чи це сталося. Позаекранна візуалізація (наприклад, об'єкти Framebuffer (fbo) або pbuffers) не має цієї проблеми.

Викрадення локальної Xscreen сервера не є ідеальним рішенням, тому ось декілька альтернатив, які я знайшов на цьому шляху:

Віртуальні кадри

Xvfb - це варіант, але це не спрацювало для мене, оскільки OpenGL не користувався перевагою апаратного прискорення, а об'єкти фреймбуфера не підтримувались, що необхідно для взаємодії CUDA з OpenGL. Тим не менш, це може бути корисним варіантом, коли викрадення локального екрану неприйнятне або коли користувач не може отримати привілеї xhost.

VirtualGL

З веб-сайту VirtualGL:

VirtualGL - це пакет з відкритим кодом, який надає будь-якому програмному забезпеченню віддаленого дисплея Unix або Linux можливість запускати програми OpenGL з повним прискоренням апаратного 3D.

Це саме те, що я хочу, і це виглядає дуже перспективно, але у мене не було часу, щоб розібратися з новою залежністю бібліотеки, тому я не перевірив її. Думаю, що це ідеальне рішення, коли я можу його скласти, встановити та налаштувати. Це те, що VirtualBox та деякі сервери VNC використовують для підтримки 3D-прискореного обладнання.

ви можете запустити на машині буфер віртуального кадру vfb, він схожий на манекен X11. Ми запускали додатки, які HAD відкривали Xwindow, на який ми ніколи не дивилися, і просто встановлювали vfb та експортували $ DISPLAY до цього - начебто екрану на кліпі HTH