VirtualGL

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Неподтвержденные материалы могут быть оспорены и удалены. Найти источники:  "VirtualGL" – новости  · газеты  · книги  · ученый  · JSTOR ( февраль 2015 г. ) ( Узнайте, как и когда удалять это сообщение )

VirtualGL ( VGL ) — это программный пакет с открытым исходным кодом , который перенаправляет команды 3D-рендеринга из приложений Unix и Linux OpenGL на аппаратное обеспечение 3D-ускорителя на выделенном сервере и отправляет отрендеренный вывод на ( тонкий ) клиент, расположенный в другом месте сети. ^[1] На стороне сервера VirtualGL состоит из библиотеки, которая обрабатывает перенаправление, и программы-оболочки, которая инструктирует приложения использовать эту библиотеку. Клиенты могут подключаться к серверу либо с помощью удаленного соединения X11 , либо с помощью прокси-сервера X11, такого как сервер Virtual Network Computing (VNC). В случае соединения X11 также необходимо некоторое клиентское программное обеспечение VirtualGL для получения отрендеренного графического вывода отдельно от потока X11. В случае соединения VNC не требуется никакого специального клиентского программного обеспечения, кроме самого клиента VNC.

Производительность приложений OpenGL можно значительно улучшить, визуализируя графику на выделенных аппаратных ускорителях, которые обычно присутствуют в GPU . GPU стали настолько распространенными, что приложения стали полагаться на них для приемлемой производительности. Но VNC и другие среды тонких клиентов для Unix и Linux не имеют доступа к такому оборудованию на стороне сервера. Поэтому они либо вообще не поддерживают приложения OpenGL , либо прибегают к более медленным методам, таким как визуализация на клиенте или в программном обеспечении на сервере.

Удаленное отображение 3D-приложений с аппаратным ускорением традиционно требовало использования «косвенного рендеринга». Косвенный рендеринг использует расширение GLX для X Window System («X11» или «X») для инкапсуляции команд OpenGL внутри потока протокола X11 и отправки их из приложения на дисплей X. Традиционно приложение запускается на удаленном сервере приложений, а дисплей X запускается на рабочем столе пользователя. В этом сценарии все команды OpenGL выполняются настольным компьютером пользователя, поэтому этот компьютер должен иметь быстрый ускоритель 3D-графики. Это ограничивает тип компьютера, который может удаленно отображать 3D-приложение с использованием этого метода.

Косвенный рендеринг может работать хорошо, если сеть достаточно быстра ( например, Gigabit Ethernet ), если приложение динамически не изменяет геометрию отображаемого объекта, если приложение использует списки отображения и если приложение не использует много текстурного отображения . Однако многие приложения OpenGL не соответствуют этим критериям. Чтобы еще больше усложнить ситуацию, некоторые расширения OpenGL не работают в среде косвенного рендеринга. Некоторые из этих расширений требуют возможности прямого доступа к оборудованию 3D-графики и, таким образом, никогда не могут работать косвенно. В других случаях дисплей X пользователя может не обеспечивать явной поддержки необходимого расширения OpenGL, или расширение может полагаться на определенную конфигурацию оборудования, которая отсутствует на настольном компьютере пользователя.

Выполнение рендеринга OpenGL на сервере приложений обходит проблемы, вызванные косвенным рендерингом, поскольку приложение теперь имеет быстрый и прямой путь к оборудованию 3D-рендеринга. Если 3D-рендеринг происходит на сервере приложений, то только полученные 2D-изображения должны быть отправлены клиенту. Изображения могут быть доставлены с той же частотой кадров независимо от того, насколько большими были 3D-данные, которые использовались для их создания, поэтому выполнение 3D-рендеринга на сервере приложений фактически преобразует проблему производительности 3D в проблему производительности 2D. Затем проблема становится в том, как передавать 1-2 мегапикселя данных изображения по сети с интерактивной частотой кадров, но товарные технологии ( HDTV , например) уже решают эту проблему.

VirtualGL использует "разветвление GLX" для выполнения рендеринга OpenGL на сервере приложений. Приложения Unix и Linux OpenGL обычно отправляют как команды GLX, так и обычные команды X11 на один и тот же X-дисплей. Команды GLX используются для привязки контекстов рендеринга OpenGL к определенному окну X, получения списка форматов пикселей, поддерживаемых X-дисплеем, и т. д. VirtualGL использует функцию в Unix и Linux, которая позволяет "предварительно загружать" библиотеку в приложение, эффективно перехватывая (AKA "вставляя") определенные вызовы функций, которые приложение обычно делает для общих библиотек, с которыми оно связано. После предварительной загрузки VirtualGL в приложение Unix или Linux OpenGL, он перехватывает вызовы функций GLX из приложения и перезаписывает их таким образом, что соответствующие команды GLX отправляются на X-дисплей сервера приложений ("3D X-сервер"), к которому, предположительно, подключен аппаратный 3D-ускоритель. Таким образом, VirtualGL предотвращает отправку команд GLX по сети на X-дисплей пользователя или на виртуальный X-дисплей («X-прокси»), такой как VNC, который не поддерживает GLX. В процессе перезаписи вызовов GLX VirtualGL также перенаправляет рендеринг OpenGL в буферы пикселей за пределами экрана («Pbuffers»). Между тем, остальные вызовы функций из приложения, включая обычные команды X11, используемые для отрисовки пользовательского интерфейса приложения, могут проходить через VirtualGL без изменений.

Внутри себя интерпозерный движок VirtualGL также поддерживает карту окон в Pbuffers, сопоставляет визуальные атрибуты между целевым X-дисплеем («2D X-сервер») и 3D X-сервером и выполняет множество других функций хеширования, чтобы гарантировать, что перенаправление GLX будет бесшовным. Но по сути, как только контекст OpenGL установлен на X-дисплее сервера приложений, VirtualGL уходит с дороги и позволяет всем последующим командам OpenGL беспрепятственно проходить к 3D-оборудованию сервера приложений. Таким образом, приложение может автоматически использовать любые функции и расширения OpenGL, предоставляемые оборудованием и драйверами сервера приложений.

Помимо маршалинга команд GLX и управления Pbuffers, VirtualGL также считывает отрисованные пиксели в соответствующее время (обычно с помощью мониторинга glXSwapBuffers()или glFinish()), а затем отрисовывает эти пиксели в окне X приложения с помощью стандартных команд отрисовки изображений X. Поскольку VirtualGL перенаправляет команды GLX от 2D X Server, его можно использовать для добавления ускоренной поддержки 3D к X-прокси (например, VNC), а также для предотвращения косвенного рендеринга OpenGL при использовании удаленного X-дисплея.

Использование VirtualGL совместно с VNC или другим X-прокси позволяет нескольким пользователям одновременно запускать 3D-приложения на одном сервере приложений и нескольким клиентам совместно использовать каждый сеанс. Однако VNC и ему подобные настроены на обработку 2D-приложений с большими областями сплошного цвета, небольшим количеством цветов и небольшим количеством межкадровых различий. 3D-приложения, с другой стороны, генерируют изображения с мелкозернистыми, сложными цветовыми узорами и гораздо меньшей корреляцией между последовательными кадрами. Рабочая нагрузка, создаваемая при рисовании визуализированных изображений из приложения OpenGL в окно X, по сути, та же самая рабочая нагрузка, что и у видеоплеера, а готовое программное обеспечение тонкого клиента обычно не имеет достаточно быстрых кодеков изображений , чтобы справиться с этой рабочей нагрузкой с интерактивной частотой кадров.

VirtualGL решает эту проблему двумя способами:

1. ТурбоVNC
2. Транспорт VGL

TurboVNC и TigerVNC являются ответвлениями TightVNC , которые ускоряют кодирование Tight и JPEG, отчасти за счет использования libjpeg-turbo, SIMD -ускоренной версии libjpeg . Оба проекта предоставляют как VNC-серверы, так и клиентские приложения.

TurboVNC был разработан той же командой, что и VirtualGL. В сетях Ethernet 100 Мегабит он может отображать более 50 Мегапикселей/секунду с качеством изображения без видимых потерь. TurboVNC включает в себя дальнейшие оптимизации, которые позволяют ему отображать 10–12 Мегапикселей/секунду по широкополосному каналу 5 Мегабит с заметно меньшим, но пригодным качеством изображения. TurboVNC также расширяет TightVNC, включая двойную буферизацию на стороне клиента и другие функции, ориентированные на 3D-приложения, такие как возможность отправлять копию изображения экрана без потерь в периоды бездействия. ^[2] TurboVNC и VirtualGL используются Техасским передовым вычислительным центром в Техасском университете в Остине, чтобы позволить пользователям TeraGrid удаленно получать доступ к возможностям 3D-рендеринга кластера визуализации Stampede ^[3] .

TigerVNC — это более поздняя версия TightVNC, которая в большинстве случаев обеспечивает производительность, схожую с TurboVNC, но имеет другие цели и функции проекта. ^{[4] [5]}

При использовании VGL Transport VirtualGL сжимает визуализированные 3D-изображения в процессе, используя тот же оптимизированный кодек JPEG, который использует TurboVNC. Затем VirtualGL отправляет сжатые изображения через выделенный сокет TCP в клиентское приложение VirtualGL, работающее на клиентской машине. Клиент VirtualGL отвечает за распаковку изображений и отрисовку пикселей в соответствующее окно X. Между тем, не-OpenGL элементы отображения приложения отправляются по сети с использованием стандартного удаленного протокола X11 и визуализируются на клиентской машине.

Этот подход требует, чтобы на клиентской машине присутствовал X-дисплей, а зависимость от удаленного протокола X11 для выполнения 2D-рендеринга означает, что многие приложения будут работать плохо при использовании VGL Transport в сетях с высокой задержкой. Кроме того, VGL Transport изначально не поддерживает совместную работу (несколько клиентов за сеанс), поскольку изображения передаются на компьютеры пользователей, а не извлекаются. Но использование VGL Transport обеспечивает полностью бесшовную работу приложений, при которой каждое окно приложения соответствует одному окну рабочего стола. VGL Transport также снижает нагрузку на ЦП сервера, поскольку 2D-рендеринг происходит на клиенте, а VGL Transport позволяет использовать расширенные функции OpenGL, такие как стерео с четырехкратной буферизацией .

Разработчики VirtualGL предполагают, что основными пользователями VGL Transport будут владельцы ноутбуков с беспроводным соединением 802.11g или быстрым Ethernet-подключением к серверу приложений.

VirtualGL и TurboVNC были основными компонентами продукта Sun Visualization System от Sun Microsystems , который был прекращен в апреле 2009 года. Два пакета с открытым исходным кодом были объединены с плагином с закрытым исходным кодом , который позволял VirtualGL отправлять сжатые изображения на тонкие клиенты Sun Ray , и другим пакетом с закрытым исходным кодом, который интегрировал VirtualGL с Sun Grid Engine , обеспечивая управление ресурсами и планирование для удаленных 3D-заданий. Комбинация этих пакетов, названная «Sun Shared Visualization», была доступна для бесплатной загрузки. Sun взимала плату за поддержку.

Версия NoMachine v4.xx поддерживает VirtualGL, что позволяет пользователям запускать 3D-приложения в сеансах рабочего стола NoMachine. ^[6]

Версия 2.1 программного обеспечения Scalable Visualization Array от HP включает компоненты, которые интегрируются с VirtualGL и TurboVNC, что позволяет планировать 3D-задания и удаленно отображать их из кластера визуализации. ^[7]

Версия ThinLinc 3.0.0 предназначена для работы в сочетании с VirtualGL. ^[8]

Версия EnginFrame Views v2010 поддерживает VirtualGL как один из вариантов удаленного протокола. ^[9]

Продукты Exceed onDemand и Exceed Freedom от OpenText используют код из VirtualGL для реализации рендеринга на стороне сервера. ^[10]

• Xgl
• AIGLX

• "VirtualGL Background". VirtualGL.org . Получено 20 февраля 2016 г. .
• "Руководство пользователя VirtualGL 2.5". VirtualGL.org . Получено 20 февраля 2016 г. .
• "Руководство пользователя TurboVNC 2.0.1". TurboVNC.org . Получено 20 февраля 2016 г. .

• Официальный сайт VirtualGL
• VirtualGL на SourceForge
• VirtualGL на GitHub
• Официальный сайт TurboVNC
• TurboVNC на SourceForge
• TurboVNC на GitHub