Як ефективно використовувати 3D через віддалене з'єднання?

У мене є один слабкий ПК (клієнт), але з прийнятною 3D-продуктивністю, і один сильний ПК (сервер), який повинен бути здатний запускати додаток за допомогою OpenGL двічі, тобто один раз локально та один раз віддалено для клієнта. В даний час я ssh -Xвпадаю в нього, але консольний вихід клієнта констатує використання програмного забезпечення, і я отримую лише 3 кадри в секунду (кадрів в секунду). Власне, шифрування ssh не потрібно, оскільки це в локальній мережі, але це вже те, що я вже знаю для віддалених додатків ...

Отже, як можна підвищити продуктивність клієнта? Мої ідеї є

• використовувати апаратне прискорення, але серверне чи клієнтське та як?
• використовувати щось інше, ніж ssh

Я знаю, що в повній роздільній здатності та без складного стиснення локальна мережа 100 Мбіт / с не зробить більше кадрів в секунду, але це віконне додаток приблизно. 800x450, тому теоретично до 12 кадрів в секунду (при 24 бітах / пікселі) повинно бути можливим за допомогою нестиснених графічних даних. І, можливо, можливо щось краще, використовуючи власний графічний процесор клієнта або розумне стиснення.

-

редагування Виявляється, що я хочу - це в основному локальна версія того, що, наприклад, пропонує onlive та gaikai . Чи є щось подібне для Linux (і, можливо, безкоштовно)?

-

edit2 VirtualGL виглядає як найкраще рішення (хоча наразі це не працює для мене), але мені цікаво, чи можливо зробити апаратне рендеринг для клієнта?

Ви можете перевірити, що VirtualGL разом із TurboVNC повинен забезпечити вам 20 кадрів в секунду при 1280x1024 на 100 Мбіт ( див. Вікіпедію ).

Зауважте, що це може працювати не з усіма програмами, це залежить від того, як вони використовують OpenGL.

Це давнє питання, але воно все ще актуальне. Покрокове керівництво про те, як налаштувати та усунути неполадки X11 3D-рендерінга віддаленого додатку на локальному обладнанні: прискорення апаратного забезпечення OpenGL через віддалене з'єднання x11 ssh

У статті в якості прикладу використовується гра Chromium BSU. Він працює з 5-8 FPS з візуалізацією програмного забезпечення за замовчуванням через SSH-з'єднання, 30 FPS при непрямому апаратному візуалізації та> 30 FPS з незашифрованим підключенням TCP X11. Зауважте, що він працює лише для деяких програм.

Короткий підсумок статті

Непряме візуалізація та підключення TCP відключені в конфігурації сервера X11 за замовчуванням. +iglx and -listen tcpпараметри їх дозволяють. Існує також LIBGL_ALWAYS_INDIRECT=1змінна, яка примушує непряме відображення на клієнті X11.

Це може бути правдою, якщо у вас є два настільних ПК. Але якщо у вас вдома є старий ноутбук WiFi, який можна використовувати будь-де (наприклад, Ti5600 з Ubuntu 10.04 як ваш клієнт, і настільний ПК з платою GTX разом із запасним маршрутизатором Wi-Fi, то віддалений клієнт OpenGL здається непоганою ідеєю.

Проблема полягає в отриманні віддаленого (серверного) контексту OpenGL. Ви можете запустити ssh -X на своєму клієнті. Але якщо ви запустите glxinfo у віддаленій системі, ви отримаєте свого локального клієнта, який поверне вас туди, де ви почали. Ви можете встановити змінну середовища DISPLAY на цей віддалений хост, і ви можете використовувати цей екран як другий монітор, який все ще не допомагає.

Ще одне рішення - написати настільні програми, щоб вони могли використовувати віддалений контекст GLX:

http://arrayfire.com/remote-off-screen-rendering-with-opengl/