Компания BMW открыла исходные тексты проекта RAMSES (https://at.projects.genivi.org/wiki/display/DIRO/RAMSES) (Rendering Architecture for Multi-Screen EnvironmentS), в рамках которого подготовлена распределённая система отрисовки 3D-контента, сфокусированная на обеспечении высокой эффективности с позиции потребления ресурсов при использовании на встраиваемых системах и пропускной способности при трансляции вывода по сети. Код написан на языке C++ и распространяется (https://github.com/GENIVI/ramses) под лицензией MPL 2.0 (Mozilla Public License).
Проект разработан в процессе оптимизации отрисовки контента в автомобильных информационной развлекательных системах, содержащих несколько экранов. RAMSES представляет собой прослойку, позволяющую применить клиент-серверную модель для отрисовки, при которой один процесс формирует 3D-контент, а другой занимается его отрисовкой. При этом процесс отрисовки может выполняться на другом устройстве или в виртуальном
окружении.
Более того, один вещающий процесс может передавать содержимое на несколько процессов отрисовки (отображение на разных экранах), несколько процессов отрисовки могут вещать через один процесс отрисовки (работа с несколькими приложениями на одном экране) или смешивая оба варианта (работа с несколькими приложениями на нескольких экранах). В итоге формируется своеобразный дисплейный кластер, в которых входит набор имеющихся экранов и вычислительных устройств, которые работают как единая экосистема, пори том, что в состав кластера могут входить устройства на базе разных платформ и операционных систем (Wayland, X11, WGL, Integrity OS).RAMSES предоставляет обвязку вокруг существующих реализаций OpenGL, позволяющую применять предлагаемую модель распределённой отрисовки для любых OpenGL-приложений. Поддерживается работа с различными версиями OpenGL (OpenGL ES 3.0+, OpenGL 4.2, 4.5 и т.п.), что позволяет использовать одну кодовую базу на различных платформах, предоставляющих разные версии OpenGL. Минимальным обрабатываемым элементом контента является сцена. Например, мультимедийный проигрыватель может сформировать две сцены - одну с основным интерфейсом для мультимедийного экрана, а другую со списком песен для отображения на приборной панели. Сцены от разных приложений могут совмещаться на одном экрана, например, в вышеприведённом примере список песен может быть совмещён с интерфейсом приборной панели.
RAMSES также предоставляет собственный низкоуровневый API, близкий к OpenGL. Данный API инкапсулирует и упаковывает команды и ресурсы OpenGL для минимизации трафика между клиентом и сервером, что позволяет передавать высококачественный 3D-контент поверх обычных сетей для отображения без задержек и разрывов. Для ускорения загрузки и запуска данные сцен и связанных с ними ресурсов (текстуры, шейдеры и т.п.) также могут быть сериализированы в файлы и прокэшированы на стороне, отвечающей за отображение.
URL: https://news.ycombinator.com/item?id=19216568
Новость: https://www.opennet.dev/opennews/art.shtml?num=50196
Теперь видеофермы докупил, по сети подключил, сидишь, играешь.
На тонком клиенте.
хм, красиво описано. Интересно, на базе этой штуки можно что-то наподобие сетевых возможностей иксов организовать?
Тоже заинтересовало.
В иксах это никогда не работало хорошо. Чтобы это работало хорошо, нужно пересылать не команды отрисовки, а пожатый видеопоток, желательно современным кодеком. А для этого уже есть отдельные решения.
> А для этого уже есть отдельные решения.Какие, если не секрет?
Microsoft RemoteFX.
RemoteFX is a set of protocols for Microsoft's Remote Desktop Protocol (RDP) that are used to remotely deliver Windows virtual desktops over a local area networkСпасибо, поржал. А серьёзно? (vnc не предлагать по вполне известным причинам)
а серьезно - опенсорсные жопоручки ни на что подобное не способны даже при наличии открытого протокола (ага, она открытая) и существующей реализации для удобной отладки.недавняя история с дырами в rdesktop говорит что даже клиента-то нормально написать - нерешаемая задача. А редхатобиэм за них этого делать не планирует.
таким образом еще одна крупная веха на пути продолба полимеров давным-давно преодолена.
Remote Desktop Protocol (RDP) is a __proprietary__ protocol developed by Microsoft.Вы уже второй раз лажаетесь. Это специально?
о, викичитателей подвалило.
XPRA - может даже GPU использовать для сжатия видеопотока.
В иксах это работало лучше чем где либо, но только при построении интерфейса из виджетов X-сервера, от чего все современные графические фреймворки отказались. В т.ч. была возможность передачи команд OpenGL по сети (indirect rendering), но её забросили на версии OpenGL 1.6, кажется.
Да, лет десять назад у нас GL на тонком клиенте с нвидией в ALTSP бегал вовсю...PS: спасибо led@ как непосредственно причастному за поправку.
PPS: не, таки нвидией.
s/нвидией/ATI/
> s/нвидией/ATI/Не, атишки были на тех compaq sff, а тогда ты свою машинку на nforce грузил по сети с того же терминал-сервера. Вспомнил. :-)
Работало, просто вы не застали. Тогда, когда отрисовка ограничивалась иксовыми примитивами.
у microsoft в rdp были похожие сложности - правда, они не писали программ, "передающих положение курсора мышки 200 раз в секунду". Но они написали расширение remoteFX для эффективного проброса битмэпов и видеостримов, а опенсосеры прососали lbx и доломали opengl - в это же самое время (под мудрым руководством редхатобиэма с одной стороны, и наследников ДНКазы с другой, все более и более готовясь для десктопа). Про то что X-сессию без костылей и подпорок нельзя подхватить заново после обрыва соединения, я уж молчу, традиция, освящена прошловековой давностью.но корпорация зла не перепутай, кто!
>Про то что X-сессию без костылей и подпорок нельзя подхватить заново после обрыва соединенияА почему нельзя и что считать подпоркой? Xlib канул в лета уже давно. X11 forwarding это всего лишь трансляция протокола по сети. А X Window System это не терминальный сервер а всего лишь графическая подсистема.
Все остальное вопрос реализации, можно городить самим прослойку с запуском сессий на стороне сервера по тому же ssh, можно пользоваться коммерческими продуктами. Опыт последних говорит о крайне слабом спросе, как следствие умирание или забивание на поддержку/развитие. Пример того же NX где все резко застопорилось на клиенте, а халявщики из категории "а мы все можем сделать сами, сила опенсорс и все такое" забыли написать своего клиента, но при этом подпортили поляну для NoMachine.
Про rdp не надо так радужно, основным драйвером успешного развития там изначально был Citrix и их протокол ICA. Это позволило MS продавать недоделанный продукт и спокойно доводить его до ума.
Клиенты rdesktop и freerdp не имеют никакого отношения хотелкам индивидов "дайте мне RemoteFX на хаялву", как впрочем и мохнатой лапе RedHat, и развивались самостоятельно под потребности а не ради идеи. И спеки на rdp появились на много позже, причем покрывали они далеко не все. Это сейчас легко говорить смотрите все опубликовано когда уже никто толком этим и не занимается )
> А почему нельзя и что считать подпоркой? Xlib канул в лета уже давно.а. Ну понятен.
поэтому уже и без разницы, что там в xorg понапридумывают. Остался только rdp.
> Клиенты rdesktop и freerdp не имеют никакого отношения хотелкам индивидов "дайте мне RemoteFX на
> хаялву"им бы пока untrusted input научиться валидировать. В freerdp какая-то поддержка remotefx, если что, есть, но я не их целевая аудитория - "не такие как все" и "чтоб за лицензию не платить", я просто запущу mstsc.
у меня нет такой хотелки, это у вас она.
А у меня была хотелка нормального юникса на сервере и на рабочем столе, но не времен 1970го года, у меня для него нет задач. Увы, не в этой вселенной.
Пожатый видеопоток означает, что тебе придётся рендерить дважды -- один раз на клиенте, второй раз на сервере. Тебе придётся иметь GPU и там, и здесь. Фу.Команды отрисовки гораздо приятнее в этом смысле, на клиенте ты обсчитываешь геометрию, но не отрисовку. Проблема с X'ами в том, что они были спроектированы во времена VGA видеокарт, и им надо было придумывать какую-то абстракцию уровнем выше чем VGA, для того чтобы открыть её клиенту. И тут X'ы пролетели, они не смогли угадать хорошего уровня абстракции. Всё кончилось тем, что мы имеем сегодня: скажем шрифты отрисовываются на клиенте и засылаются битмапами.
А если в этот ramses renderer ещё засунуть возможность рендерить подмножество html, чтобы не надо было бы на стороне клиента превращать html в команды отрисовки, достаточно было бы преобразовать его в то подмножество, которое ramses понимает, дык вообще будет офигенно. Может быть только заменить текстовый способ кодирования для html на бинарный, сохранив текстовое представление его только для отладочных целей (чтоб как в лиспе: текстовое и бинарное представления объектов плавно и прозрачно перетекают друг в друга). Спор gtk vs qt уйдёт в историю, олдфаги будут сидя на завалинке с бутылочкой пива вспоминать "а помнишь, во времена нашей молодости, были такие штуки как графические тулкиты? Как щаз помню, беру я компилятор c++ и выпиливаю им интерфейс..."
Да! И ещё потом выкинуть окаменевшие *getty из системы. Написать systemd-ramsesd, который будет выполнять функции agetty, создавать терминалы, которые ради бэквард-совместимости будут vt100, но какой-нибудь простенькой esc-последовательностью, будут превращаться в html-терминалы, где приложение, вызывая printf, зашвыривает в терминал текст, который интерпретируется как html дописываемый в конец. Плюс какие-нибудь специальные теги, для того, чтобы отправлять команды модификации уже выведенных на экран DOM-элементов. Плюс ещё теги для того, чтобы создавать sub-терминалы, чтобы можно было бы создав такой sub-терминал, форкнуться, сделать в child'е терминал контролирующим, и затем exec("bash -c "/usr/bin/emacs").Только придётся из ядра выдрать vt.c и кучу другого хлама, и реализовать это в юзерспейс демоне. Но ядру это только на пользу пойдёт, ему давно пора худеть.
И после этого выкинуть из системы Xorg, Wayland и прочую лабуду, и вернутся обратно в терминал, работать с _консольными_ приложениями.
Electron будет не нужен.
> И тут X'ы пролетели, они не смогли угадать хорошего уровня абстракции.они еще много чего не смогли - например, угадать что единственные приличные шрифты нам подарит (через мусорный бачок, конечно) microsoft, а адоб как обычно пойдет лесом.
> Всё кончилось тем, что мы имеем сегодня: скажем шрифты отрисовываются на клиенте и засылаются
> битмапами.потому что ttf оказался немножко неподходящим для xfs (кто еще помнит такой?) а не потому что нельзя на сервере - можно. Шрифтов только нет.
та же самая история и с графическими тулкитами посерьезнее athena widgets - все они в первую очередь ориентированы на винду, во вторую - тоже на винду, и в третью - на мак.
А в этом вашем линуксе - ну, как нибудь, по остаточному принципу, а, во, битмэпы же есть, ну ща отрисуем.
Ну и вот позицию мышки будем перезапрашивать 200 раз в секунду - а чо, в винде же ж работает (еще бы, курсор виртуальный и дальше локалхоста эти перезапросы не уедут).А из native у нас один motif, да и тот времен все тех же vga, когда и битмэпы не казались чем-то особенно плохим.
> та же самая история и с графическими тулкитами посерьезнее athena widgetsГм, прямо стесняюсь спросить за gtk (даже первый).
PS: и даже по сравнению с xaw3d.
На картинке Iron Maiden. Ностальгия