Таки про сетевую прозрачность...

Так а в чём претензия тогда? Что этого ещё никто не сделал? Ну как бы извините, всё и сразу никто не обещал. Дай денег, всё сделаем.

фатальный был что у нас нет удаленного десктопа, ну так удаленный десктоп внезапно не только скринкаст с аудиопотоком

Ненене, тред был про «сетевую прозрачность» и наезд на вяленого.

у нас есть spice

windows remote desktop - это не просто протокол обмена. это комбайн, как systemd.

Я ною, что выкинули всё высокоуровневое кроме условного fb. Оно всё местами устарело, но оно есть. А нового такого уровня не будет. Возможно, если как-то с андроида втянут, как втянули великолепную skia.

В смысле рисование примитивами? В линуксе этот поезд уже очень давно уплыл. Тулкиты рисуют самостоятельно, приложения рисуют самостоятельно, все рисуют самостоятельно. Чтобы это было по-другому, надо в одночасье заменить примерно всё. Такого не произойдёт. Если завтра придумают Wayland-штрих с рисованием примитивами, им всё равно никто не будет пользоваться.

Или что ещё высокоуровневое?

Я не знаю технических подробностей, но там все завязано на менеджер сессий. Для винды нет разницы, локальная графическая сессия, или удаленная. Менеджер сессий управляет консолью, и если надо может подключать или отключать от неё пользовательские сессии.

Сам протокол RDP это подобие VNC, но с на воротами, вроде передачи звука и проброса принтеров, usb и т.п. Да, RDP умеет в несколько мониторов, хотя в виндовом клиенте это не реализовано. И да, в режиме удаленной сессии (не screen sharing) локальное и удаленное количество мониторов никак не связаны, в теории можно подключить к машине с одним локальным моником удалённую сессию на несколько мониторов. Но это уже извращения, которые требуют танцев с бубном и из коробки не работают.

так где не шибко тормозящая сетевая прозрачность? Извинения принимаются ;) пойду переопределю период «сразу» в 10*N лет

ЗЫ не принимай близко к сердцу, еще немного времени и ты сам станешь еще тем циником

Сетевая прозрачность (свойство протокола) есть по сути только у X11. А RDP, VNC это просто пересылка картинок по сути. Есть, правда, расширение RDP, которое 2D может ускорять, используя тот же механизм, как и X11 (вот ссылка, которую я давно постил: Представили концепт сетевой прозрачности для Wayland (комментарий)). Сетевая прозрачность - это X11, x2go (тот же X11, но только сжатие+кеширование+теневой X-сервер). На медленных каналах x2go будет очень быстр.

Waypipe же. Я тут уже проводил наблюдение какое-то время назад.

Shadow, intelfx говорит, что у нас есть spice:) может, тебе его задействовать?:)

Я не уверен, что кто-то вообще пытался подружить spice и Wayland. Мы же тут теоретизируем насчёт архитектурных проблем. На практике ничего юзабельного нет, я сразу об этом сказал.

а, ок

я бегло посмотрел, да часть хотелок покроет, но

waypipe - Man Page

A transparent proxy for Wayland applications

ну Ё, прокси, фатальный недостаток вайленд не решил

Прости не удержался, можешь называть меня жабой :)))

Ну запускай waypipe на отдельном порту рядом с композитором, какие проблемы. Назовём «модуль поддержки сетевой прозрачности», лол. А в libwayland-client встроим автозапуск клиентской части.

Да проблем то нет, просто сотрясания воздуха под UP очередного проекта умиляют

сотрясания воздуха под UP очередного проекта

Мм?

Не, я согласен, что это немного не то. Ну а как ты собрался делать истинную сетевую прозрачность в протоколе, построенном поверх общей памяти и fd passing. Какой-то прокси нужен. А у нас тут юниксвей®©™, так что…

ну так не надо тогда заявлять фичу как главный недостаток старого решения :) никто не будет тогда смеяться, когда фича так и останется не реализованной

Немного изучив вопрос и погоняв в домашней локалке vino, xrdp и x11vnc, обнаружил фатальный недостаток ненужных композиторов: они все люто тормозят

Вообще, тут бы хорошо спарить с VirtualGL, чтобы использовать GPU на машине, чтобы аппаратно ускорять отрисовку и потом уже все отрендеренное гнать по сетке по VNC. Я такого не пробовал (задачи такой не было), я вообще композитными WM не пользуюсь. Есть, например, TurboVNC, который написал разработчиками VirtualGL. Есть TigerVNC. Все это не пробовал. Но вот если заставить композитор отрисовываться через VirtualGL, то все может стать повеселее по скорости. Обычно, правда, VGL рекомендуется использовать для отдельных 3D приложений, а не целого композитора.

а эта новая приблуда, с очередным *pipe в названии, разве не это делает? они же отрендеренный видеобуффер композитора как раз и пытаются пересылать. даже еще лучше, без VNC (который я ненавижу). вопрос-то не только в скорости, а то, что это все должно работать с существующими сессиями, авторизацией и вообще... как терминальный сервер.

Да нет же, вся та куча (в том числе забытый xpdf) высокоуровневых прибамбасов - начиная со шрифтов и заканчивая форматом картинок в виде .h инкладов, курсоров и т.п.
Остаётся gtk в GL фреймбуфере, и всё.
Я вообще не погромист, поэтому в чём-то не разбираюсь, но все использующие wayland предлагают мне использовать вместо разработанной оконной среды, которая может огого чего ещё делать на равне с лучшими коммерческими решениями, использовать фреймбуфер, в который на низком уровне рисуют два тулкита... Жесть же. PR именно бесит. Ну и выпиливание из гнома вещей типа metacity, и возможности запилить это обратно.

Нет, это ровно наоборот. VirtualGL, это как X11, только для OpenGL — по сети гоним команды, рендерим на клиенте (который показывает). Waypipe — рендерим на хосте (где приложение запущено), по сети гоним отрендеренные поверхности.

Нет, это ровно наоборот. VirtualGL, это как X11, только для OpenGL — по сети гоним команды, рендерим на клиенте (который показывает).

Не, ты перепутал. Как в X11 - это GLX по сети, то есть команды OpenGL, а VirtualGL - это перехват GLX локально, перенаправление в локальную видимокарту для ускорения, а потом переправка по сети картинками.

А вот напрямую командами OpenGL вот тут человек экспериментировал. В конце решили. В этом случае есть проблемы сегодня, поэтому я не упоминаю этот вариант. В свое время он был возможен, но никто, я так понимаю, десктопы не гонял по Indirect GLX Обычно отдельные приложения 3D. Сбой запуска GL приложения по ssh -X

ну вот и разобрались:)

p.s.

https://mstoeckl.com/notes/gsoc/blog.html новая *pipe-хрень, если ты сначала тред не смотрел.

Да это все понятно. Я для Wayland вообще ничего не советую. А то, что вытаскивать отренденные буферы и гнать их по сети - это и так понятно. Это сейчас и для иксов практически единственная опция. Рендерить локально 3D на VirtualGL и гнать картинки через X11. Сетевая прозрачность сохраняется, но только 3D-изображения (приложения) не по Indirect GLX прет по сети, а картинками.

Не, ты перепутал.

Окей…

<…> VirtualGL - это перехват GLX локально, перенаправление в локальную видимокарту для ускорения, а потом переправка по сети картинками.

Тогда чем это отличается от direct rendering?

Doubt.

Я пока на x11vnc с tightvnc

X11vnc поддерживает turbojpeg кодек.

Видимо, поэтому годится.

Если не нужен физический дисплей, то turbovnc очень быстр, включая 3д. Было видео сравнения virtual gl и turbovnc на quake 3. Turbovnc быстрее.

Спасибо! Пока нужно к реальной сессии было подключаться.

Тогда чем это отличается от direct rendering?

В смысле? VirtualGL не мешает командам OpenGL идти в железо напрямую, как они и шли.

Реальный дисплей на х11 это сильные тормоза, к сожалению. Как на вэйленде не знаю, думаю что так же.

В смысле зачем использовать VirtualGL, если уже есть direct rendering и все им и так пользуются?

А как ты direct rendering на удаленной машине будешь пользоваться? По-моему, мы просто про какие-то разные вещи говорим? Для X11 существует ровно два варианта: либо Indirect GLX и тогда поток команд GLX/OpenGL прет по сети и ускоряется уже на удаленной машине, на ее GPU, либо ты рендеришь OpenGL на стороне X-приложений на железе сервера приложений, а готовые картинки в виде команд X11 (запрос XPutImage, например) ты передаешь на удаленную машину. Второе - это VirtualGL.

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

Ты это как раз пример к утверждению о ненужности сетевой прозрачности. Когда понадобилось выполнить графическую программу на другой машине, ты выбираешь не туннелирование протокола X11, а стриминг готовых картинок. Скоро не останется никого, кто вообще помнил, что это такое, сетевая прозрачность.

Direct rendering — это OpenGL (ну или вообще не OpenGL) в обход X-сервера совсем, то есть приложение напрямую разговаривает с железом на той машине, где оно запущено. Следовательно, direct rendering по определению происходит на стороне сервера приложений, и никакой VirtualGL не нужен.

Разве не так?

steam remote play

Внезапненько. А трафик через стимовский сервак идёт?

Следовательно, direct rendering по определению происходит на стороне сервера приложений, и никакой VirtualGL не нужен.

Напрямую рендерит, но только механизм доступа к пиксельным изображениям другой. VGL работает на уровне X11, GLX и OpenGL. Поэтому работает везде, где вот это вот есть, а не только на Linux. Ну то есть никаких отсылок к DMA-BUF, файловым дескрипторам и т. п. Вот можешь прочитать, как это работает, чтобы мне не пересказывать. Здесь немного совсем, не простыня. Тут есть ответ, зачем VirtualGL, то есть что он делает собственно: https://cdn.rawgit.com/VirtualGL/virtualgl/3.0beta1/doc/index.html#hd003

Да, я уже почитал про VirtualGL.

Напрямую рендерит, но только механизм доступа к пиксельным изображениям другой. VGL работает на уровне X11, GLX и OpenGL. Поэтому работает везде, где вот это вот есть, а не только на Linux. Ну то есть никаких отсылок к DMA-BUF, файловым дескрипторам и т. п.

Ну то есть в (современном) линуксе с DRI и прочими плюшками VirtualGL не нужен, потому что он (линукс) сам по себе именно так и работает по дефолту?

Или всё-таки нет и я чего-то фундаментально не понимаю?

x2go был не плох.

если в LAN, то нет

Да и он изначально рассчитан на LAN

Ну то есть в (современном) линуксе с DRI и прочими плюшками VirtualGL не нужен, потому что он (линукс) сам по себе именно так и работает по дефолту?

Он нужен ровно настолько, насколько нужен Waypipe Server. При любом раскладе нужен сервер. VirtualGL выполняет точно такую же роль. Waypipe, кстати, также занимается парсингом протокола Wayland, чтобы выяснить, что делает приложение с дескрипторами.

Waypipe does not have a full view of the Wayland protocol. It includes a compiled form of the base protocol and several extension protocols, but is not able to parse all messages that the programs it connects send. Fortunately, the Wayland wire protocol is partially self-describing, so Waypipe can parse the messages it needs (those related to resources shared with file descriptors) while ignoring the rest.

То же самое делает VirtualGL, вылавливая по X11 создание/удаление окон, изменение размеров окон и пр., по GLX - создание контекста, glXSwapBuffers и др. функции, по OpenGL, например, смотрит glFlush, glFinish и др. подобные (это моменты, когда VirtualGL должен картинку забрать). Разница только в том, что картинку он берет по-другому, на другом уровне и с другими протоколами работает, поэтому архитектурно такой.

The VirtualGL Faker intercepts and modifies a handful of GLX, OpenGL, X11, and XCB function calls in order to divert OpenGL rendering from the 3D application’s windows into corresponding off-screen buffers, which VGL creates in GPU memory on the application server.

Ну и так же аналогичное:

The waypipe server pretends to be a Wayland compositor,

То же самое и в VGL. Есть локальный для сервера приложений 3D X-сервер для GLX. Остальной X11 (2D) идет на удаленный X-сервер без изменений.

да, спасибо, ты правильно сказал. плюс к этому сложному протоколу еще и готовая сервисная обвязка с интеграцией в сеансы, авторизацию... - т.е. законченное решение (все вместе это называется также, как протокол).

Ну то есть в (современном) линуксе с DRI и прочими плюшками VirtualGL не нужен, потому что он (линукс) сам по себе именно так и работает по дефолту?

К слову, в случае EGL же нет GLX, поэтому для EGL в VirtualGL X-сервер 3D не создается, а указывается DRM device типа

vglrun -d /dev/dri/card0

В случае с GLX это было бы дисплеем ":0.0", например.

Да, я тоже. Помню по учёбе иксовый софт из Солярки в универе у себя на ноуте дома под гентой или убунтой запускал через SSH. Сейчас не знаю, как с этими вялеными прокатило бы или нет.

Никак не прокатило бы. Поколение айфона и андроида «мы не умеем ничего делать руками, руки не нужны, давайте ампутируем всем руки» дорвалось до графического стека и решило «убрать всё ненужное»

Печально.

А че его дружить. SPICE-сервер нормальный только в QEMU, а там хоть вяленого гоняй, хоть малосольного.

2x4.2

Юзал бы VNC.

Поколение старперов типа тебя фантазирует фантазии и не поддерживает иксы, а следующее поколение в гробу видало поддерживать иксы, где все такое нужное, что если сегодня сломать какое-нибудь рисование спиралек, этого уже никто никогдашеньки не заметит.

Ну вот он не только про QEMU же. Я так понимаю, что Spice — это «наш ответ RDP», в довольно общем виде.