VirtualGL+turboVNC

@Shadow и @ls-h что скажете?

Так это virtualGL, причём тут пукан?

При том, что virtualgl может обрабатывать только вызовы opengl.

Хреновый из меня summoner(( sudo cast Shadow, ls-h.

А вот новые (на вулкане) просто не запускаются

Логично, это ведь не virtualVulkan

Вау. Я и забыл про VirtualGL. Вопрос насколько забита сеть и насколько она чувствительна?

Сделал связку из turboVNC и virtualGL по их документам и протестировал первые подвернувшиеся программы.

Вот было бы интересно попробовать скрестить x2go с VirtualGL. Официальных инструкций по этому поводу я не видел на сайте. Но есть сообщения пользователей, которые такое используют: https://lists.x2go.org/pipermail/x2go-user/2018-May/005115.html

Dear X2go-users,

for almost 2 years we are using X2GO with VirtualGL to provides visualization tool on our computing facility and it is very efficient tool. However, we are facing a problem with our current setup that seems related to the number of users connected.

Вот было бы интересно попробовать скрестить x2go с VirtualGL

Но это, скорее всего, не даст улучшения скорости отрисовки самого VirtualGL. Разница может быть только в эффективности доставки отрендеренного изображения к пользователю, сжатие. Но x2go в теории может дать улучшение скорости отрисовки интерфейса программы, а также возможность запускать программу отдельно без всего десктопа.

Протестировал на вайфае, необходимо настроить параметры сжатия, тогда тоже вполне неплохо.

возможность запускать программу отдельно без всего десктопа

Это может и virtualgl, но игры как-то криво отображаются. Если есть достаточно подробный faq по совместному использованию x2go и virtualgl можно попробовать.

Как бы логично, но для пользователя не очевидно, почему одно работает, а другое нет.

Помню, что кто-то делал транслятор вулкан в опенгл.

Тестировал на проводной сети 100 мбит.

А задержки на сети какие?

На проводной 0.3мс, на вайфай 3мс

Как только появится время для нетрадиционных отношений с компом, сразу попробую. Так я не делал ещё, пока справляюсь TeamViewer'ом для жкстренных подключений.

P.S. Тестировал на проводной сети 100 мбит.

Ну это, конечно, не тест. Практически во всех видео говорят, что, мол, во как быстро, а потом оказывается, что тестируют у себя в LAN. А смотреть надо, как работает в реальных условиях. Скажем, через медленный канал с большими задержками, где связь прерывается. Вот это было бы интересное сравнение. Я в свое время потестировал Nomachine NX на 64kbit, запускал GIMP. Хоть и видно было сжатие, что неизбежно, но на этом даже было можно работать.

Гипотетически можно запустить ICD видеодрайвер на стороне клиента и отсылать командные буферы на сервер. Тогда любое 3D приложение будет работать. Не знаю делали ли так в Линуксе.

Если есть достаточно подробный faq по совместному использованию x2go и virtualgl можно попробовать.

Так я и пишу, что официально документации нет. Это просто надо попробовать. То есть запустить приложение через vglrun через x2go. И поглядеть, что получится. Это просто в лоб. Вполне можно ожидать проблем. Но раз кто-то пишет, что использовал такую связку, то что-то должно работать.

Есть еще новая тема x2gokdrive. Это было сделано из-за того, что новые среды типа GNOME 3+ и др. отказываются работать через классический x2go. Поэтому сделано такое решение. То есть полноценный X-сервер на стороне X-клиентов, который по сути передает картинки на удаленную машину. https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start В конце есть слово VirtualGL (What X2Go KDrive already can do). Там еще не все сделали нормально, поэтому наверняка нельзя сказать, что это готов для десктопа.

А смотреть надо, как работает в реальных условиях. Скажем, через медленный канал с большими задержками, где связь прерывается.

Так NX, как и x2go, оба не дружат с задержками.
Когда после keydown, keyup прилетает с задержкой, это приводит либо к срабатыванию keyboard repeat, либо случайным drag’n’drop событиям.

Nomachine/x2go позволил жить с узким каналом, но на канале с задержками, сетевая прозрачность иксов всегда была больше для галочки, чем для реальных дел.

Nomachine/x2go позволил жить с узким каналом, но на канале с задержками, сетевая прозрачность иксов всегда была больше для галочки, чем для реальных дел.

Не надо сказок. Если задержка такая, что кнопки заедать будут, то это вообще всех удаленных решений касается. И прозрачность иксов тут совсем не причина. Если от устройств сигнал приходит непозволительно долго, то тут все вообще решения будут испытвать проблемы. Но вот борьба с routdtrips, которые из-за задержек в сети были основной причиной тормозов, то она как раз в NX сделана.

Не надо сказок.

Это реальная проблема, возникающая в реальных условиях.
То, что все реализации стека сетевой прозрачности в онтопике не смогли её решить, не означает что её нет.

Вот тест на мобильном 4G и OpenVPN https://youtu.be/zWF-abCt3UA Пресет WAN. При записи видео подтормаживаний немного больше. Инетересно, что сама модель выглядит лучше чем текст интерфейса.

Тестировал на проводной сети 100 мбит.

а где мы в природе такие скорости встречаем? если это сеть предприятия, то можно и ногами дойти. проверил бы ты на узких каналах, да с задержками. а так ясен пень, на 100 мбит что угодно будет быстро работать.

turboVNC и virtualGL

а в чем смысл этой связки? что мы передаем по сети? это оптимизация для работы с 3D по сети?

Запустил фрикад через x2go и vglrun в локалке. Видно как происходит обновление картинки, масштабирование идёт с задержкой.

Смотри сообщение выше.

ну и? где график по трафику? где пинг, чтобы задержки оценить? как правильно зубок написал, хреновы ютуберы.

канал нужно не выше 1 MB/s тестить, имхо. 4G дает больше.

я бы еще рядом штатные средства windows RDP сравнил и выяснил, кто быстрее. они что-то хитрое встроили для передачи 3д в последних версиях.

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

https://virtualgl.org/vgldoc/2_1_1/x11transport.png

по сети-то что передает? 3D или jpeg?

Посмотри пожалуйста в документации, там все подробно описано, как и что передается.

ну и? где график по трафику? где пинг, чтобы задержки оценить? как правильно зубок написал, хреновы ютуберы.

Там окно performance info выведено, можешь построить график, разрешаю.

я бы еще рядом штатные средства windows RDP сравнил и выяснил, кто быстрее.

Делай, сравнивай.

Там окно performance info выведено, можешь построить график, разрешаю.

там есть информацию, о которой я спрашиваю?

я бы еще рядом штатные средства windows RDP

В windows RDP текст UI локально рисуется, например, а не пережатыми картинками шлётся. Если я не ошибаюсь, конечно.

Если тебе не хватает информации, поставь turbovnc+virtualgl и получи ее. Заодно и сможешь сравнить со штатными средствами винды. И графики нарисовать - все сам.

Если тебе не хватает информации

ок. не забудь выложить свой суппер-тест на ютуб. без цифр по трафику и latency это хрень полнейшая:(

мой поинт в том, что они очень классно RDP сделали. так сказать референс, от которого можно отталкиваться.

Ютуб всего лишь видеопомойка, чего у тебя подгорело то?

без цифр по трафику и latency это хрень полнейшая:(

Чистый тест мне делать лень: сейчас с телефона до vpn сервера 910кбит/с, задержка 53мс.

Rdp действительно сделан очень хорошо и некоторых фич rdp до сих пор нет на линуксе.

некоторых

да, только не некоторых, а всех. я RDP использовал на каналах с задержкой 250 ms. это большая разница. 50 ms - это ни о чем.

crypt@witch ~ $ ping ya.ru
PING ya.ru (87.250.250.242): 56 data bytes
64 bytes from 87.250.250.242: icmp_seq=0 ttl=51 time=118.661 ms

Вот полноценный тест такой связки: https://turbovnc.org/pmwiki/uploads/About/vglperf21.pdf

да, только не некоторых, а всех

Я сейчас буду придираться к словам.

Изображение показывает, показывает, ВСЕХ уже по определению не может быть. Поэтому я и сказал, что некоторых. При том что vnc решает одну задачу - показ изображения, pulse-audio другую, и так далее.

Запустил фрикад через x2go и vglrun в локалке. Видно как происходит обновление картинки, масштабирование идёт с задержкой.

Думаю, что это из-за того, что применен некий алгоритм доставки изображения, который рубит картинку на кусочки и передает кусочками. Возможно надо покрутить всякие параметры. Например алгоритмы сжатия побыстрее выбрать в настройках клиента. В TurboVNC используется высокоскоростной JPEG (libjpeg-turbo).

UPD. Хм, хотя в nxagent тоже от него зависит:

$ aptitude search ~Rnxagent~i
i A libc6                           - библиотека GNU C: динамически подключаемые
i A libjpeg62-turbo                 - libjpeg-turbo, оптимизированная библиотека
[...]

А мой - что с нынешней концепцией freedesktop.org некуда отталкиваться.

В windows RDP текст UI локально рисуется, например, а не пережатыми картинками шлётся. Если я не ошибаюсь, конечно.

В NX, X11, X2Go так же, в общем-то. Закидываются отдельные глифы в кэш единожды (уже на уровне XRender есть GlyphSet [1]). Потом глифы рисуются в нужных местах уже у клиента локально.

Если я правильно помню, то хранение characters на стороне клиента в RDP реализовано в GDI Acceleration Extensions. Ну, то есть это расширение для GDI. [2] По сути своей то же самое, что и X11.

[1] https://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt:

12. Glyph Rendering

Glyphs are small alpha masks which can be stored in the X server and rendered by referring to them by name. A set of glyphs can be rendered in a single request. Glyphs are positioned by subtracting the x, y elements of the GLYPHINFO from the requested rendering position. The next glyph rendering position is set to the current rendering position plus the off-x and off-y elements. Glyphs are stored in GlyphSets and are named within the GlyphSet with client-specified 32-bit numbers.

[2] https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-RDP...

In addition to defining how to encode common drawing operations, the Remote Desktop Protocol: GDI Acceleration Extension also facilitates the use of caches to store drawing primitives such as bitmaps, color tables, and characters. The effective use of caching techniques helps to reduce wire traffic by ensuring that items used in multiple drawing operations are sent only once from server to client (retransmission of these items for use in conjunction with future drawing operations is not required after the item has been cached on the client).

Возможно надо покрутить всякие параметры. Например алгоритмы сжатия побыстрее выбрать в настройках клиента.

Я использовал дефолтные настройки. Кстати на первом скриншоте я использовал tigervnc в качестве клиента и изображение не разваливалось. И кстати почему-то в x2go сессии совсем не запускался компиз. В vnc он работал без vglrun.

@Shadow и @ls-h что скажете?

Довольно интересно. На днях попробую...

Не знаю делали ли так в Линуксе.

А где вообще делали?

Ну я представляю как это сделать с моим драйвером RadeonGfx. Надо бы попробовать.

Надо бы попробовать.

Запили потом пост, что получилось.

На днях попробую...

Попробовал. Сейчас сижу на 4G, т.к. провайдер интернет сломал. До сервера ещё OpenVPN подключение и он в другом городе, до которого где-то 350 км. Вот такие пинги:

ping -OD 192.168.88.249
PING 192.168.88.249 (192.168.88.249) 56(84) bytes of data.
[1643116784.646702] 64 bytes from 192.168.88.249: icmp_seq=1 ttl=63 time=94.5 ms
[1643116785.606279] 64 bytes from 192.168.88.249: icmp_seq=2 ttl=63 time=52.5 ms
[1643116786.648087] 64 bytes from 192.168.88.249: icmp_seq=3 ttl=63 time=92.6 ms
[1643116787.636787] 64 bytes from 192.168.88.249: icmp_seq=4 ttl=63 time=79.6 ms
[1643116788.646974] 64 bytes from 192.168.88.249: icmp_seq=5 ttl=63 time=88.0 ms
[1643116789.627827] 64 bytes from 192.168.88.249: icmp_seq=6 ttl=63 time=67.7 ms
[1643116790.648396] 64 bytes from 192.168.88.249: icmp_seq=7 ttl=63 time=86.4 ms
[1643116791.592644] 64 bytes from 192.168.88.249: icmp_seq=8 ttl=63 time=29.1 ms
[1643116792.647412] 64 bytes from 192.168.88.249: icmp_seq=9 ttl=63 time=82.6 ms
[1643116793.602183] 64 bytes from 192.168.88.249: icmp_seq=10 ttl=63 time=35.7 ms
[1643116794.647688] 64 bytes from 192.168.88.249: icmp_seq=11 ttl=63 time=80.0 ms
[1643116795.656169] 64 bytes from 192.168.88.249: icmp_seq=12 ttl=63 time=87.3 ms
[1643116796.646085] 64 bytes from 192.168.88.249: icmp_seq=13 ttl=63 time=75.8 ms
[1643116797.689852] 64 bytes from 192.168.88.249: icmp_seq=14 ttl=63 time=118 ms
[1643116798.648584] 64 bytes from 192.168.88.249: icmp_seq=15 ttl=63 time=75.6 ms
[1643116799.687236] 64 bytes from 192.168.88.249: icmp_seq=16 ttl=63 time=113 ms
^C
--- 192.168.88.249 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15022ms
rtt min/avg/max/mdev = 29.119/78.636/118.323/23.093 ms