Переадресация X означает, что все команды рендеринга инкапсулированы в транспортную систему X, переданы на машину с дисплеем и выполнены там.Положительным моментом является то, что удаленному концу вообще не требуется графический процессор. Недостатком является то, что он потребляет (ну, скорее, поглощает) большую полосу пропускания сети.
OpenGL до версии 2.1 определяет коды операций GLX для транспорта X11, поэтому сеть прозрачна.И если вы свободно используете списки отображения и сохраняете объем передаваемых данных небольшим (т. Е. Нет массива вершин на стороне клиента, только несколько текстур), OpenGL-over-GLX-over-X11-over-TCP работает довольно хорошо.
Однако в наши дни более эффективно выполнять удаленную визуализацию и передавать сгенерированное изображение только с использованием высокоэффективного кодека сжатия.Однако обычная пересылка X11 не может этого сделать.Но вы можете сделать это, используя Xpra, поддерживаемый «настоящим» X-сервером, общаясь с реальным графическим процессором.Проблема в том, что вам понадобится этот конкретный X-сервер, чтобы занять графический процессор.
Лучший способ - определить, доступно ли расширение GLX, а если нет, есть ли поблизости графический процессор, и использовать его длявизуализировать в растровое изображение XSHM.Таким образом, Xpra также будет работать на виртуальном сервере фреймбуфера.К сожалению, сделать позже с OpenGL очень сложно реализовать, так как он работает прозрачно через API создания контекста.Это может быть сделано (BT; DT), но на самом деле для такого рода вещей я на самом деле предпочитаю Vulkan, потому что, несмотря на многословие Vulkan, для надежной работы с Vulkan требуется меньше работы, чем с OpenGL.
Возможно (маловероятно), мы увидим какое-то расширение X11 для сжатой передачи растровых изображений, какое-то высокое сжатие XV или подобное.Это, в сочетании с чисто закадровым отображением на GPU (у нас это уже есть), сделало бы систему намного более эффективной.