Вступление

Хабр, привет!

Я — Леонид Забурунов, инженер‑программист компании «БФГ» — стартап по разработке системы виртуализации — в отделе разработки систем виртуализации графических ресурсов.

В рамках работы над доставкой рабочего стола для своей системы виртуализации мы наломали немало дров в самых разных направлениях. Одно из таких направлений — протокол SPICE как интереснейший объект для экспериментов. Этой серией статьей мы подводим своеобразный итог своим исследованиям прошлого и делимся с сообществом своими знаниями, частично — наработками. Своего рода дневники разработчиков.

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

1. Разобраться с устройством протокола SPICE в части графики. Это мы делаем прямо сейчас;

2. Разобраться с тем, какими «проводами» всё это хозяйство подключается к ОС Windows. Это мы сделаем в следующей части цикла;

3. Разобраться с тем, что мы можем сделать для более плавной картинки и понижения битрейта — читай для более комфортной работы. Это и все следующие пункты мы будем делать ещё дальше, начиная с третьей части;

4. Написать анонсированный стриминговый агент. Точнее, его минимальную реализацию.

5. Зафиксировать итоги работы и обсудить, что можно было бы сделать на следующих этапах для приближения к стадии Enterprise‑решения.

Что ж, начинаем погружение в бездну…

А зачем нам вообще разбираться в SPICE и стриминге?

Забегу далеко вперёд специально для тех, кто глубоко в теме и хочет сперва ответить на вопрос, ради чего ковыряться палкой в сабже и устраивать сыр‑бор.

Недавно я в личных целях развернул локальную виртуальную машину на Windows 10. Настроил всё через virt‑manager, подключился через remote‑viewer. Это стандартный сетап для виртуализации со SPICE: virt‑manager создаёт libvirt‑конфиг для запуска машины через QEMU (с libspice‑server.so), а remote‑viewer вызывает spice‑gtk — каноническую реализацию SPICE‑клиента — как виджет из библиотеки libspice‑gtk-3.0.so, а вокруг дорисовывает минимальный UI.

Из праздного интереса попробовал простейшие задачи: порисовать в Paint, поработать в PowerShell, помедитировать в реестре. Пока исполнял перечисленные экзерсисы, понадобилось зайти на ютуб и открыть туториал. Открываю видео и вижу чудесную картину:

Ещё раз. Настроил всё по инструкции, подключился стандартным клиентом — и не работает видео. А не работает оно потому, что клиент дропает все фреймы стрима — это я позже узнал в логах. И дело тут не в видео: скролл терминала приводил к тому же результату. Оно просто не работает. А если видеокодек переставить с MJPEG на H.264, так и вообще на старте видео ВМ крашится. Шеф, всё пропало.

В части стриминга SPICE продвинулся скудно — при том, что всё необходимое для работы в протоколе уже имеется, только допиливай. Ну а про часть с QXL я буду рассказывать в этой и следующих статьях — там всё печально. SPICE оказался в сложной ситуации и стал забытой технологией древности. С одной стороны притесняют корпоративные протоколы, которые ушли далеко вперёд: Citrix ICA/HDX, VMWare PCoIP/Blast, Microsoft RDP, AnyDesk, ParSec, другие. С другой подкрались альтернативные открытые протоколы: VNC, FreeRDP, X2GO, X11 Forwarding (да, я причислил сюда и это; да, спорно), другие. SPICE — хороший боевой протокол со своей областью применимости, в репозиториях есть множество интересных инженерных решений — и всё это оказалось перечёркнуто нежеланием Red Hat развивать проект дальше. Оно, конечно, во многом обосновано, но в своё время я посчитал это незаслуженным и пошёл разбираться.

Ну и, в конце концов, как ещё развиваться, если не идти в том направлении, где поля непаханные?

Доставка рабочего стола средствами SPICE: задумка

Протокол SPICE — тема очень большая. Поскольку серверная часть работает в связке с QEMU/KVM, а клиентская написана на GTK+ 3.0 (экосистема GNOME), мы сразу же затрагиваем очень большую часть мира Linux.

Я буду очень ёмко описывать те части протокола, которые имеют отношение к теме — настолько ёмко, насколько нахожу возможным. Историю разработки пропущу — как и общие моменты архитектуры. Если вам интересен SPICE как таковой, можно изучить оригинальную документацию протокола: она не блещет полнотой и (местами) актуальностью, но то что есть — написано качественно. Подробные разборы протокола — не только в части графики — существуют и на Хабре, см. серию статей. Уверен, что есть много других заслуживающих внимание материалов. Ну и приглашаю в комментарии, само собой.

Итак, QEMU/KVM. Поддержка SPICE реализована в QEMU и переключается опцией сборки. В качестве аргументов запуска QEMU можно указать множество параметров, которые влияют на работу SPICE‑сервера и на клиентскую сессию.

Когда виртуальная машина стартует, инициализация SPICE и выставление настроек происходит по методам из специального интерфейса spice‑server.h: тут тебе и настройки TLS, и кодеки, и все остальные доступные настройки. Если в ВМ выбран видеоадаптер QXL, то настраивается и он (в соответствии с версией протокола адаптера). «Если» — потому что можно выбрать и другой, в том числе дубовый фреймбуффер VGA, который превратит SPICE в ещё одну реализацию VNC.

QXL — это паравиртуальный адаптер. Слово «паравиртуальный» можно определять несколько по‑разному, я же дам своё видение, которое не замкнуто на самом QXL: паравиртуальный адаптер — это устройство, отображающееся в виртуальной машине как настоящее «железное» (с поддержкой актуальных API), но на деле являющееся интерфейсным слоем, передающим эти команды далее в гипервизор для исполнения на реальном железе. В случае с QXL это означает следующую задумку: вместо того, чтобы исполнять графические команды GDI/X11/OpenGL/choose‑your‑fighter софтварным рендерингом (по определению медленным и унылым), эти команды просто прокидываются дальше — туда, где есть рендеринг аппаратный, — а затем оттуда же прилетает результат. Эта мысль выгодно отличает SPICE от более примитивных подходов к проблеме в стиле remote framebuffer (так, например, устроен VNC), где по задумке по каналу гуляют только пиксели (сжатые через кодек, конечно).

Ладно, к QXL мы ещё вернёмся. Сейчас я хочу остановиться на доставке рабочего стола в принципе; осторожно погрузимся в проблематику протоколов удалённого доступа…

Потоки данных при удалённой работе

В процессе работы с виртуальной машиной вы совершаете действия, которые приводят к изменению на дисплее:

• Передвинули мышь — появилась всплывающая подсказка. Это должно отобразиться на экране.

• Нажали кнопку мыши — окно перешло в состояние фокуса и сменило цвет рамки. Это должно отобразиться на экране.

• Нажали кнопку на клавиатуре — приложение отреагировало или же запустилось какое‑либо системное действие. Это должно…что? Правильно — отобразиться на экране!

В случае с физическим компьютером эти изменения внутри вашей ОС посчитались и из неё же ушли на видеовыход монитора. А в рассматриваемом нами случае всё иначе: результат должен отобразиться хрен знает где на удалённом дисплее, соединённом с дата‑центром по каналу связи произвольного качества — и вполне возможно, что именно канал связи будет главным препятствием для работы.

Вы когда‑нибудь задумывались о том, какое количество данных проходит внутри Вашего рабочего компьютера, например, при просмотре видео? Какую пропускную способность мы бы заняли, если бы нам потребовалось копировать данные с экрана?

Вопрос совершенно не праздный, поскольку я собираюсь в конце представить агент захвата экрана для SPICE. Было бы хорошо, если бы этот агент не забивал всё соединение и не препятствовал работе как минимум остальных SPICE‑каналов, как максимум — остальных ваших приложений.

Ну, давайте считать — и считать для плохого случая, потому что оптимистичные сценарии себя быстро исчерпывают. Вот у вас FullHD монитор — это 1920×1080, или что‑то около 2 миллионов пикселей. Современные дисплеи имеют де‑факто стандарт глубины цвета 8-бит, картинка отдаётся в формате RGBA, по 8 бит на канал, 32 бита на пиксель. Или 4 байта. 2 миллиона пикселей на 4 байта — 8 мегабайт. Каждый кадр. Монитор 60 Гц — и получаем 480 мегабайт в секунду.

Таких цифр на реальных сетевых каналах вы не найдёте, здесь вам не тут локальная PCIE‑шина. И это важно усвоить тем, кто не привык погружаться в детали удалённого доступа: интернет — слабое звено, поэтому львиную долю эффективности протокола составляют эффективность передачи данных и минимизация задержек.

Способов сжать данные, передаваемые в виде изображения или видео, довольно много. Именно с видео всё достаточно понятно: можно взять H264 и всё. Я сейчас не хочу сказать, что кроме H264 не существует кодеков. Я к тому, что технология сжатия видео в сущности одна, а выбираем мы зачастую не технологию, а тип лицензирования. В любом современном видеокодеке активно используются энтропийное кодирование, межкадровую разницу, манипуляции с цветовым представлением и другие приёмы. Если интересно подробнее — отсылаю к хорошей вводной статье про H264.

А вот с изолированными изображениями интереснее. Разницу между соседними кадрами никто не учитывает, однако разные типы данных на дисплее требуют разных подходов. Для отображения текста важнее чёткость символов, для отображения фото — визуальная целостность. Во многих случаях выигрышным оказывается комбинированный подход. Например, RDP использует несколько кодеков под разные задачи. Кроме того, в зависимости от ситуации можно использовать сжатие без потерь (lossless) или же с потерями (lossy). Конечно, хочется видеть идеальную картинку, но в реальных условиях (и уж тем более на слабых каналах) это неосуществимо.

Текстовые данные на экране, как правило, очень хорошо поддаются сжатию — буквы одного цвета, фон другого. И специализированные кодеки этим пользуются как предварительным знанием — картинка имеет небогатую цветовую палитру, никаких преобразований Фурье нам не нужно, только индексы на пикселях расставь. Это по сути архивация данных через хэш‑таблицы. Если есть сложности с пониманием этого момента — посмотрите на широкоизвестный формат PNG. Разумеется, самые крутые кодеки используют и другие приёмы.

Но UI‑ориентирванный кодек — это быстро по скорости, но прожорливо по пропускной способности сети. Это не недостаток, это закон физики: UI по свойствам изображения имеет мало общего с насыщенной иллюстрацией. В последнем случае визуальной резкостью приходится пожертвовать, потому что тогда изображение экрана рискует занять существенную часть канала и стать источником лагов.

И тогда на сцену выходят кодеки для изображений. Более того, большинство изображений, которое мы используем в повседневной жизни, уже и так сжато через JPEG (и скорее всего это не Lossless JPEG).

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

Когда вы качаете с торрента двух‑трёхчасовой экшн‑фильм в H265, он весит не 200 гигабайт, а 5–6: техники работы с межкадровым движением в наше время отрабатывают очень хорошо. Но это потому, что фильм обычно идёт в 24 или 30 кадров в секунду — если вы, конечно, не Илья Найшуллер. Если вы попробуете взять тот же фильм (или, например, фотосессию) и в случайном порядке переставить его кадры, то результат будет весить уже во много раз больше. Не говоря уж о качестве содержания...

Всё это ни разу не магия, а выверенное применение инженерных решений. Благослови прогресс.

Сжатие данных в протоколе SPICE

SPICE поступает примерно так же. Если говорить про lossless, то выбор богатый: есть самописный кодек QUIC (не путать с одноимённым сетевым протоколом от Google!), который может замылить текст, но хорошо справляется с фото на экране; есть сжатие через самописную реализацию LZSS, через самописный LZ с глобальным словарём или же через LZ4 (на удивление, не самописный). Технологий здесь было опробовано массово, а с учётом того, что написано всё это было лет 20–25 назад, когда люди нейросетей не нюхали и дубиной размахивали, самостоятельность реализации не удивляет. Любой из этих кодеков можно выбрать на старте виртуальной машины, а для сложных сценариев есть комбинированный подход — автоматическое переключение между QUIC и LZ (или GLZ), производимое на основе эвристического анализа свойств изображения на дисплее.

Это я всё говорил про сжатие без потерь. Для сжатия c потерями используется старый‑добрый JPEG. В документации это обозначено как WAN optimization. По задумке авторов (надо сказать, весьма здравой), lossless‑сжатия будет достаточно для локальных сетей, но при использовании в сетях на большие расстояния потребуются дополнительные ухищрения. С учётом того, насколько жаден в вопросах гарантии доставки сетевой протокол TCP, который используется в SPICE безальтернативно, на издержки транспортного слоя может уйти слишком много ресурса — и без дополнительного сжатия трафика нам не обойтись.

Вообще говоря, оптимизация под плохие каналы связи — это тема не на одну диссертацию. Если Вы когда‑либо видели, каким образом Citrix умудряется работать на канале со скоростью меньше мегабита, вопросов у вас больше не останется — только челюсть подбирать. И дело там не только в JPEG, в ход пойдут все доступные средства. Поговоривают, что ранние версии Citrix даже подменяли виндовые DLL‑библиотеки…

Но вернёмся к препарированному SPICE и к JPEG. Управляется он с помощью отдельного параметра QEMU по следующей схеме:

• Можно отключить совсем (off);

• Можно держать включённым всегда (always);

• Можно настроить на принятие решения об активации непосредственно во время пользовательской сессии (auto). Звучит заманчиво, но работает очень просто: если замер скорости на старте сессии показал меньше 10 Мбит/с, то включаем. С постоянным качеством. И всё, дальше не дёргаемся. Сильно лучше двух предыдущих вариантов, но для энтерпрайза никуда не годится. В этом отношении SPICE сильно недоработан, огромный потенциал во многом не реализован.

А ещё там для тех же целей добавлен zlib… Ладно, пора остановиться.

Короче говоря, количество и объём инженерных решений, использованных для того, чтобы можно было лампово сидеть за удалённым рабочим столом в SPICE‑клиенте, неподготовленного человека могут поразить. Но и это ещё не всё…

Графические команды QXL

А вот теперь вернёмся конкретно к QXL. Большую часть предыдущих разделов я посвятил работе с готовыми битмапами. Ещё предусмотрен вариант, где вместо битмапы посылается сырая графическая команда, и битмапа рендерится сразу на клиенте.

Из того, что мы успели обсудить, можно сделать вывод, что SPICE+QXL — это удалённый графический сервер! Да, попахивает X11 Forwarding или VirtualGL. Это не уникальная идея, но проверенная и гарантированно работающая: вместо того, чтобы присылать пиксели, я лучше расскажу, как эти пиксели получить. В межчеловеческой коммуникации такой подход не годится (эйчары комиссуют за плохие soft skills), зато для межмашинной — очень даже!

Вот какие команды мы обнаруживаем в протоколе:

enum {
  QXL_DRAW_NOP,
  QXL_DRAW_FILL,
  QXL_DRAW_OPAQUE,
  QXL_DRAW_COPY,
  QXL_COPY_BITS,
  QXL_DRAW_BLEND,
  QXL_DRAW_BLACKNESS,
  QXL_DRAW_WHITENESS,
  QXL_DRAW_INVERS,
  QXL_DRAW_ROP3,
  QXL_DRAW_STROKE,
  QXL_DRAW_TEXT,
  QXL_DRAW_TRANSPARENT,
  QXL_DRAW_ALPHA_BLEND,
  QXL_DRAW_COMPOSITE
};

Пойдём по порядку:

1. QXL_DRAW_NOP — обычный no operation. Скорее как служебное значение

2. QXL_DRAW_FILL — заливка (одним цветом, градиентом и так далее). Параметры — область и кисть с параметрами заливки.

3. QXL_DRAW_OPAQUE — применение битмапы с модификацией. Параметры — битмапа, область (в т. ч. можно изменить масштаб), тип логической операции и кисть как второй операнд.

4. QXL_DRAW_COPY — применение битмапы. Параметры — битмапа и область.

5. QXL_COPY_BITS — перемещение области уже отрендеренной битмапы (например, для скролла). Параметры — предыдущая область, новая область.

6. QXL_DRAW_BLEND — наложение битмапы на текущее состояние. Параметры — битмапа, область и тип операции.

7. QXL_DRAW_BLACKNESS — заливка области чёрным цветом. Параметры — область.

8. QXL_DRAW_WHITENESS — то же самое, но белым цветом.

9. QXL_DRAW_INVERS — Инверсия всех пикселей (читай — логическая операция «НЕ»). Параметры — область.

10. QXL_DRAW_ROP3 — смешивание битмапы с модификацией (что‑то вроде OPAQUE + COPY). Параметры — Битмапа, область, тип тернарной логической операции и кисть как третий операнд.

11. QXL_DRAW_STROKE — отрисовка контура. Параметры — контур, кисть с параметрами заливки, тип логической операции.

12. QXL_DRAW_TEXT — вывод текста. Параметры — строка, область, две кисти с параметрами заливки (текст и фон), типы логических операций для каждой кисти.

13. QXL_DRAW_TRANSPARENT — применение битмапы с фильтрацией пикселей по значению альфа‑канала. Параметры — битмапа, область, значение для фильтрации.

14. QXL_DRAW_ALPHA_BLEND — наложение битмапы на текущее состояние. Параметры — битмапа, область

15. QXL_DRAW_COMPOSITE — наложение битмапы c маской и матрицей трансформации. Параметры — битмапа, положение стартового пикселя (0; 0), маска, матрица.

Выглядит как руководство к графическому редактору:) И так и есть!

Я много раз сказал про логические операции. Они определены в протоколе вот так:

typedef enum SpiceRopd {
  SPICE_ROPD_INVERS_SRC = (1 << 0),
  SPICE_ROPD_INVERS_BRUSH = (1 << 1),
  SPICE_ROPD_INVERS_DEST = (1 << 2),
  SPICE_ROPD_OP_PUT = (1 << 3), // Считай NOP - источник без изменений
  SPICE_ROPD_OP_OR = (1 << 4),
  SPICE_ROPD_OP_AND = (1 << 5),
  SPICE_ROPD_OP_XOR = (1 << 6),
  SPICE_ROPD_OP_BLACKNESS = (1 << 7),
  SPICE_ROPD_OP_WHITENESS = (1 << 8),
  SPICE_ROPD_OP_INVERS = (1 << 9),
  SPICE_ROPD_INVERS_RES = (1 << 10),
  SPICE_ROPD_MASK = 0x7ff
} SpiceRopd;

Здесь объяснять подробно смысла не вижу. Загляните в учебник по схемотехнике;)

Описанный набор команд достаточно полный, чтобы покрыть много типовых ситуаций, сэкономив время и пропускную способность на передачу готовых данных. И это должно позволить использовать SPICE в жёстких условиях со слабыми и/или нестабильными каналами. Должно…

Реализация команд в QXL‑драйверах

Красиво стелит, как говорится. Но вот суровая реальность: потенциал команд QXL сегодня не используется. Совсем. SPICE — в части работы с дисплеем — выродился в обычный remote framebuffer а‑ля VNC.

Объясняю. Для того, чтобы вся магия заработала, нужен QXL‑драйвер. Драйвер одним концом воткнут в графическую подсистему гостевой ОС, другим — в SPICE‑сервер. Он перехватывает действия гостевой ОС и транслирует на язык, понятный SPICE‑серверу (и заодно SPICE‑клиенту).

В настоящий момент этих драйверов существует три:

1. qxl — для устаревшей графической модели Windows XPDM (о ней будет рассказано в следующей серии);

2. qxl‑wddm‑dod — для актуальной графической модели Windows WDDM (о ней тоже будет рассказано в следующей серии);

3. xf86-video‑qxl — для X‑сессий в Linux.

Чтобы не погружать вас в детали реализации, я срежу углы и поступлю следующим образом: отыщу все использования перечисления QXL_DRAW с помощью команды grep, после чего объясню, что это означает.

Начнём с конца — с драйвера для X11:

# Ищем использование графических команд QXL в драйвере для X11
zaburunovleonid@fedora:~/develop$ grep -R "QXL_DRAW_" --include="*.c*" ./xf86-video-qxl/
./xf86-video-qxl/src/qxl_mem.c:    else if (is_drawable && drawable->type == QXL_DRAW_COPY)
./xf86-video-qxl/src/qxl_mem.c:    else if (is_drawable && drawable->type == QXL_DRAW_COMPOSITE)
./xf86-video-qxl/src/qxl_surface.c:    drawable_bo = make_drawable (qxl, surf, QXL_DRAW_FILL, rect);
./xf86-video-qxl/src/qxl_surface.c:    drawable_bo = make_drawable (qxl, surface, QXL_DRAW_COPY, &rect);
./xf86-video-qxl/src/qxl_surface.c:    drawable_bo = make_drawable (qxl, qxl->primary, QXL_DRAW_COPY, &rect);
./xf86-video-qxl/src/qxl_surface.c:     drawable_bo = make_drawable (qxl, dest, QXL_DRAW_COPY, &qrect);
./xf86-video-qxl/src/qxl_surface.c:    drawable_bo = make_drawable (qxl, dest, QXL_DRAW_COMPOSITE, &rect);
./xf86-video-qxl/src/qxl_surface.c:    drawable_bo = make_drawable (qxl, dest, QXL_DRAW_COPY, &rect);

QXL_DRAW_COPY, QXL_DRAW_FILL — базовый минимум. QXL_DRAW_COMPOSITE — уже поинтереснее. Про QXL_COPY_BITS тоже не забываем:

zaburunovleonid@fedora:~/develop$ grep -R "QXL_COPY_BITS" --include="*.c" ./xf86-video-qxl/
./xf86-video-qxl/src/qxl_surface.c:	drawable_bo = make_drawable (qxl, dest, QXL_COPY_BITS, &qrect);

Что мы видим? Если не считать QXL_DRAW_COMPOSITE, то драйвер поддерживает минимальный набор команд — копирование области кадрового буфера и заливка области одним цветом. Не густо. На серьёзные оптимизации пропускной способности рассчитывать не приходится.

Теперь переходим к современному драйверу для Windows:

# Ищем использование графических команд QXL в драйвере WDDM
# (устанавливается по умолчанию с современными версиями virtio-guest-tools)
zaburunovleonid@fedora:~/develop$ grep -R "QXL_DRAW_" --include="*.c*" ./qxl-wddm-dod/*
./qxl-wddm-dod/qxldod/QxlDod.cpp:    if (!(drawable = Drawable(QXL_DRAW_COPY, pRects, NULL, 0))) {
./qxl-wddm-dod/qxldod/QxlDod.cpp:    if (!(drawable = Drawable(QXL_DRAW_FILL, &Rect, NULL, 0)))
# И теперь QXL_COPY_BITS
zaburunovleonid@fedora:~/develop$ grep -R "QXL_COPY_" --include="*.c*" ./qxl-wddm-dod/
./qxl-wddm-dod/qxldod/QxlDod.cpp:    if (!(drawable = Drawable(QXL_COPY_BITS, &rect, NULL, 0))) {

Нужно ещё раз объяснять? Можно сказать, что драйвер не умеет ничего кроме работы в режиме Remote Framebuffer.

Ну и наконец сведём олдскулы и проверим устаревший драйвер для Windows:

# Ищем использование графических команд QXL в драйвере XPDM
# (поддержка прекращена начиная с Windows 8)
zaburunovleonid@fedora:~/develop$ grep -R "QXL_DRAW_" --include="*.c*" ./qxl/*
./qxl/xddm/display/driver.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_STROKE, &area, clip, GetSurfaceId(surf)))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_FILL, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_OPAQUE, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_COPY, &clip_area, NULL, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_COPY, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_BLEND, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_BLACKNESS, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_WHITENESS, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_INVERS, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_ROP3, area, clip, surface_id))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_ALPHA_BLEND, &area, clip, GetSurfaceId(dest)))) {
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_TRANSPARENT, &area, clip, GetSurfaceId(dest)))) { 
./qxl/xddm/display/text.c:    if (!(drawable = Drawable(pdev, QXL_DRAW_TEXT, &area, clip, surface_id))) {
# И теперь QXL_COPY_BITS
zaburunovleonid@fedora:~/develop$ grep -R "QXL_COPY_" --include="*.c*" ./qxl/
./qxl/xddm/display/rop.c:    if (!(drawable = Drawable(pdev, QXL_COPY_BITS, area, clip, surface_id))) {

Вот это да! Весь enum перед глазами пролетел! Вот это пацанский драйвер!

Вывод

И вот мы подошли к кликбейтному выводу, который я разместил в начале. Лучшая поддержка и лучшая оптимизация у QXL‑адаптера присутствует для ОС Windows! Да, для безнадёжно устаревших, но ведь я вас не обманул;)

Ну а для Linux всегда всё было по принципу «SpiceVNC». Шутка. Или нет…

Ну и самое‑то главное: QXL как паравиртуальный адаптер с дисплеем занимает собой вакантное место в списке устройств. Если подходить к вопросу так, как это делается в VNC, то по большому счёту реализовать удалённый доступ можно поверх любого драйвера дисплея. А у нас так не прокатит: либо вставлять в ВМ два видеоадаптера — и QXL, и «настоящую», — и городить свои вариации на тему NVIDIA Optimus, либо оставаться вообще без видеоадаптера. А софтварным OpenGL 3, который даёт QXL, в наше время никого не удивишь. Ну и есть третий вариант: оставить только паравиртуальный адаптер, но другой. Именно так рекомендуют запускать QEMU + SPICE для локальных конфигураций: вместо QXL установить VirGL.

(Забегу вперёд: именно поэтому в нашем будущем стриминговом агенте не будет никакой привязки к драйверам и вся работа будет сосредоточена на уровне API гостевой ОС.)

До кучи я ещё могу отметить, что в ранних версиях SPICE использовал для своих нужд OpenGL Canvas, то есть графические команды транслировались в OpenGL прямиком на клиенте. Но из‑за сложностей в поддержке лет 10 назад это было убрано. Точно такая же участь постигла и специализированный GDI Canvas для Windows. В итоге остался всего один вариант — использовать канвас, реализованный через Cairo и Pixman. Если будете использовать SPICE‑клиент, обратите внимание на нагрузку на CPU — скушать целое ядро при использовании удалённого рабочего стола для этого бэкенда вообще не проблема. Даже «спасибо» не скажет.

Имеем что имеем. Как так вышло в случае с Windows — мы будем разбираться в следующей серии. Про Linux где‑то по ходу цикла тоже сделаю отступление, но это не точно.

Заключение

Что ж, это отличный момент, чтобы закончить. Тема объёмная, затрагивает очень много самых разных областей, в связи с чем рассказ был несколько поверхностным. Однако, в противном случае статья стала бы необъятной.

В данной статье мы познакомились с протоколом SPICE в части работы с дисплеем. Оценили масштаб работы конкретно над SPICE и сложность технологий удалённого доступа в целом. Заметили, что богатство протокола оказалось сброшено с парохода современности. И пока что только задались вопросом «А как так вышло?».

Самое главное, что нужно усвоить — устройство потока графических команд. На стороне гостевой ОС генерируются исходные сигналы, на стороне клиента происходит обновление виджета, а всё что между — транспортная обвязка. Во всяком случае, до тех пор, пока мы не говорим о более сложных случаях по типу стриминга — а этой темы мы пока не касаемся. Но обязательно коснёмся!

В следующих частях мы заглянем с обратной стороны «портала для фреймов»: прицельно рассмотрим архитектуру графической подсистемы ОС Windows. И заодно увидим, на что сделали ставку Qumranet при разработке QXL‑драйвера в те времена, когда SPICE был разработкой внутри стартапа — и почему эта ставка не сработала.

Приглашаю аудиторию в комментарии: готов ответить на вопросы по теме и жажду критических замечаний в адрес содержания и авторского стиля.

До встречи в будущих статьях, счастливо!