TL;DR Существуют задачи по доставке 3D ускоряемых САПР службы терминалов, за этим и нужно видеоускорение и передача видео через RDP> Теоретически, наверное, можно, но _зачем_?
Представьте себе небольшую мобильную команду работающую над проектом по созданию, например, 3D анимации.
Такие команды обычно пользуются продуктами типа Autodesk Maya, реже 3dsmax и еще реже blender, но уже встречается. Для создания условий в котором мобильный сотрудник по удалёнке работает в таких программах с ноутбука требуется 2 вещи:
1. Терминальный сервер, умеющий использовать графические сопроцессоры для расчётов OpenGL/DirectX
2. Возможность передать видеопоследовательность на клиента.
Естественно, под такие же задачи подойдут все пакеты которые требуют графических вычислений на терминальном сервере. Тут тебе и Chaosgroup Vray, и e-on vue, и задачи по дизайну интерьеров в 3dsmax даже Autocad от этого выигрывает, но я говорю про анимацию, потому что там ну никак не обойтись без нормальной работы с видео.
Важно разделять доставку приложения с терминальника на рабочую станцию и процесс рендеринга. Рендеринг финальной анимации в этом случае не происходит локально, он при этом может быть выгружен вообще на отдельный удалённый кластер сопроцессоров, которые будут готовить релиз сцены для последующего композитинга/монтирования. Я рассказываю именно про организацию рабочего места пользователя, который не может таскать за собой офисную тачку с железом стоимостью поллимона по всему миру. Равно как и иметь вторую такую же в домашнем хозяйстве тоже не вариант. А ведь для текущей разработки в таком софте также требуется аппаратное 3D ускорение для рисования объектов самого редактора. И вот если мы воспользуемся 3D ускорением на сервере, преобразуем это в видеопоследовательность, закодируем её в базовый профиль H264 в реальном времени на том же сопроцессоре и передадим её потоком (естественно по UDP) клиенту, то вот уже толстой аппаратуры на клиенте и не надо.
Если команда собрана из подразделений в разных частях света, то издревле существовал Citrix. Citrix со своим Xenserver и продуктами доставки XenApp и XenDesktop. Можно было поставить кластер на Xen, снабдить ноды дешевыми сопроцессорами типа Nvidia Grid (дешевыми в сравнению с теми, которые используются в кластерах для рендеринга финальных сцен), расставить виртуалки, прокинуть, и весь этот ваш Citrix начинает раздавать вам сессии с поддержкой мультимедиа (видео/аудио) ускоренных аппаратно на виртуальном терминальнике и переданных вам по сети, топологию которой также определяет и контролирует развертывание Citrix. Естественно, всё это работало исторически через RDP. В те времена в MS такого отродясь не было, оно и понятно, ведь изначально развитием RDP занимался Citrix и терминалы делал Citrix, а MS покупал это себе венду. Те кто родился вовремя и застал это всё знают, что вплоть до Server 2008 понятия терминального сервера с доставкой приложений от MS не существовало вовсе, равно как и поддержка драйверов для паравиртуализации была только для ядер Xen. Только во времена vsphere 6.0 подтянулась vmware, а MS выкатил "зайчатки" этого всего в районе Server 2008 R2, которую радостно уничтожил и переписал в Server 2019 по-новой. Тот факт, что 3D ускорение серверами и клиентами в продуктах MS было сделано вне зависимости от формата адаптера и не требовало специального драйвера, компания Nvidia жутко обиделась (в довесок к цене железок Grid она брала пользовательские CAL) и выкатила специальную версию драйвера с "ошибкой 43". Эта ошибка возникает тогда, когда пользователь пытается запустить гостевую VM или аппаратно ускоренную терминальную сессию, поверх консьюмеровской видеокарты (GTX/RTX), типа, покупайте наших слонов (Quadro, Tesla, Grid). Но это уже другая история...
Вендоры железа, кстати, даже бомжовые типа Supermicro всегда предлагают готовый продукт для задачи доставки графически ускоренных терминалов. Ты выбираешь и ставишь один из трёх доступных гипервизоров. KVM в них не входит. Когда я последний раз интересовался, там можно пропедалировать этот функционал, как бы обходя ограничения и подсовывая обычные драйверы будто видюха на хосте, но если нужно это дружить с сессионным терминальником, то это уже финиш. Проще поставить Xen/HyperV. VMware тоже проканает если ставить терминальники Citrix, главное что VMware выбрасила вроде свой сессионный терминальник и больше не развивает его, не путать с Horizon, это VDI, это другое.
И вот что мы имеем в итоге. Пользователь заходит на портал, скачивает или просто запускает ярлычок Autodesk Maya и всё это у него открывается на удалённой машине. Единственное что в этой ситуации может подводить - это сеть. Опять же с тотальным переходом RDP на UDP, возможностью тюнить сетевую топологию под ферму терминалов (можно сделать геораспределенную) и тюнинг кодеков под разные источники данных мы получаем сравнительно хорошо работающее приложение +/- издержки на сеть. Та же Google Stadia для игрулек - это всего-навсего эта технология, ничего нового там не изобрели, просто собрали то что было и подали под новым соусом.
> что-то из разряда почёсывания носа просунув руку через задницу
Вам так кажется, потому что вы в глаза не видели таких задач, они пока не выполнимы на Linux, потому что ни терминалов таких нет, ни софта там такого толком нет. Linux даже не может быть нормальным клиентом служб терминалов и VDI в которых делается GPU проброс. Во всяком случае не через FreeRDP. А про VNC вообще думать забудьте. Под NX вон что-то разрабатывают в этом направлении, но пока что их терминальники этого не могут. Использование KVM на гипервизоре - одна из причин. Опять же тут дело не в технической невозможности виртуализации. Проблема в том, что там надо делать связку запуска безэкранной терминальной сессии с этим аппаратным пробросом в виртуалку и контроль за ресурсами кластера GPU, разделёнными на несколько сессий в рамках нескольких виртуалок терминалов. Это проблема создания отказоусточивого vGPU в кластере виртуализации, когда, например 4 ноды с 4 видюхами в каждой становятся отказоустойчивыми в том числе на уровне vGPU. Тут, справедливости ради, и HyperV - то еще убожество. На этих задачах до сих пор лидирует Xen+Nvidia, но цена там оставляет желать лучшего.
P.S. Меня особо умиляют местные советчики папетов и ансиблов, которые предлагают оркестраторами что-то там делать вместо RDP или сказочники про спасительные веб-приложения, на которые надо это всё переписывать, ну-ну удачи. Adobe и Autodesk вам перепишут некое подмножество функций под вебню и дорого продадут это за подписку так, что эти кластеры терминалов с RDP вам дешевле выйдут, но не более того. Аппаратное ускорение этой вебни в этом случае выносится тоже на клиента, а не на сервер терминалов. Да оно всё равно, в общем случае, доступно в парочке десктопных ОС, Linux не в их числе.
