Дополнение B. Архитектура WSLg

Когда мы приступили к поиску поддержки приложений с графическим интерфейсом в WSL, мы быстро определили что мы желаем поддерживать как приложения X11, так и приложения Wayland. Почти все приложения, о которых нас спрашивали наши пользователи для их запуска в WSL были на основе X11, однако поскольку само сообщество рабочего стола Linux двигалось в сторону Wayland, мы ощутили, что его также важно сопровождать. Мы бы не желали чтобы Linux в Windows остался в прошлом, ограничившись приложениями X11, и для WSLg оказалось бы помехой сдвиг к Wayland.

Для нас также было важным собрать среду настольных приложений Linux, которая бы близко следовала стандартам. Мы бы желали чтобы приложения запускались как есть, без необходимости в изменениях. Нам бы не хотелось чтобы приложениям Linux приходилось бы приспосабливаться или менять их поведение для запуска изнутри WSLg, мы бы желали чтобы WSLg тщательно следовал всем стандартам рабочего стола Linux, поэтому всё сводилось к тому чтобы она просто работала. Мы рассматривали это как беспроигрышный вариант. Это делает возможным избегать фрагментации и означает лучшую совместимость приложений, что делает пользователей более счастливыми. Возможно мы что- то напутали, или сделали это в паре мест 😊…, если вы столкнётесь с этим, будьте добры не обходить этого, дайте нам знать, открыв проблему в проекте WSLg GitHub с тем, чтобы мы исправили бы её.

Мы также желаем чтобы WSLg был проектом с открытым исходным кодом и гарантировал бы что всё взаимодействие между Linux, исполняющемся в своей виртуальной машине WSL2 и самим хостом Windows следовали бы документированным стандартам, либо определялись в коде с открытыми исходниками, доступными с обеих сторон их канала взаимодействия. Никакие секретные приправы не допустимы. Мы бы желали предоставить возможность разработчикам в этом сообществе повозиться с WSLg, если они того пожелают. В нашем проекте WSLg в GitHub имеется обзор архитектуры и подробные сведения о том, как приступать к созданию и запуску частных версий WSLg.

Относительно взаимодействия с пользователями, мы бы желали предложить практику унифицированного и интегрированного рабочего стола. Некую практику, которая позволяла бы приложениям Linux и Windows сосуществовать бок о бок, в едином унифицированном рабочем столе, в котором приложения работали бы предсказуемым образом. Имеется множество решений, которые предлагают опыт стиля работы рабочего стола настольного компьютера. Мы бы хотели чтобы WSLg ощущался бесшовным, уходил бы в фоновый режим, позволяя разработчикам сосредотачиваться на их заданиях, применяя любые приложения Linux или Windows, которые им подходят лучше всего, причём без каких бы то ни было проблем. Предварительный просмотр предлагает достаточно хорошую практику, но всё же обладает определёнными ограничениями, которые способны отвлекать. Например, предварительное представление по- прежнему применяет перемещение и изменение размера окна на стороне сервера, что приводит к операциям перемещения и изменения размеров, которые не выглядят настолько плавными, как это имеет место для собственных, что также не даёт возможности привязки окон Linux к краям мониторов или настраиваемой области привязки. Нас это тоже раздражает 😊. Мы продолжим со временем улучшать практику и снижать зазор в поведении или производительности между поведением приложений Linux и Windows, при этом гарантируя, что мы продолжим разрабатывать эти решения в соответствии со своими основополагающими принципами.

Мы приняли решение собрать WSLg в качестве первого Wayland рабочего стола Linux и для поддержки приложений X11 через хостинг сервера XWayland, создаваемый для этой цели сообщество xorg.

Самым большим вопросом для нас было: с чего начинать сборку компоновщика Wayland? Будем ли мы писать некий новый компоновщик с нуля? Будем ли мы делать удалённый протокол Wayland поверх своего хоста и запускать совершенно новый компоновщик в самом Windows? Или же мы должны собирать его поверх и вносить свой вклад в уже имеющийся проект?

Для нас это было совершенно новое пространство и мы чувствовали, что нам требуется точка зрения более мудрых парней из сообщества Linux. Мы не совсем готовы были заявить по всему миру что мы желаем разрешать приложения Linux с графическим интерфейсом в Windows, а потому обратились к нескольким парням, с которыми мы уже работали, и которым доверяли. В особенности мы бы хотели поблагодарить Кеннета Кларка, особенно полезного и деятельного участника сообщества WSL GitHub. Кеннет помог нам создать самый первый прототип проверки концепта, который был показан на //build2020 и который позднее превратился в WSLg. А также Дэниэла Стоуна из Collabora, с которым мы интенсивно работали над D3D12 галлиевым драйвером для проекта Mesa. Проницательность, владение перспективой и обширные знания Дэниэла относительно Wayland сыграли решающую роль в том, чтобы поспособствовать нам правильно разобраться со своим выбором и обеспечить прочную основу для запуска WSLg.

Итак, почему мы решили собирать на Weston?

В его сердцевине мы почувствовали это наилучшим подходом, который позволял нам построение на основе того, что уже было создано сообществом и гарантировать то, что мы обладаем компоновщиком, который был бы максимально совместимым... что может быть лучше для достижения этого, нежели применение официального справочного руководства компоновщика Wayland!

Weston это сердце WSLg. Внешний интерфейс компоновщика Weston, который определяет и реализовывает все разнообразные протоколы Wayland, практически не изменяется вне исправления ошибок или приспособления к новым парадигмам, относящимся к удалённым приложениям. WSLg не добавляет никаких новых или частных протоколов Wayland за пределами Weston, что же касается приложений Wayland (или XWayland для приложений X11), они взаимодействуют с Weston. Один из способов наблюдать это состоит в совместимости приложений... мы достаточно близки в паритете с естественным Weston, работающим с серверной частью drm. Обычно, когда некое приложение корректно работает в натуральном Weston, они также верно работает в WSLg, и наоборот.

Мы чувствуем, что это отличная возможность. По мере того как мы исправляем проблему совместимости прикладных приложений для WSLg и вносим в свой восходящий поток наши исправления, мы способствуем улучшению Weston (и Wayland). Достижение отличной совместимости приложений будет длительным путешествием, но мы ощущаем свою хорошую согласованность с сообществом Wayland, опираясь на эталонный компоновщик проекта Wayland.

Weston уже обладал собственным сервером RDP, который позволял ему взаимодействовать с хостом через стандартный протокол удалённого рабочего стола (RDP, Remote Desktop Protocol) Microsoft при помощи FreeRDP. Нам показалось весьма занимательным расширение уже имеющейся серверной части Weston RDP для обучения её новым приёмам. Что касается Windows, у нас имеется большой опыт применения RDP для удалённых приложений. Мы обладаем Windows Virtual Desktop (WVD), службой мирового масштаба, работающей в Azure и транслирующей приложения Windows пользователям по всему миру. WVD применяет технологию RDP RAIL (Remote Application Integrated Locally, интегрированных локально удалённых приложений) для интеграции таких удалённых приложений в работу с локальным рабочим столом пользователя. А также у нас имеются клиентские технологии Windows, такие как Windows Defender Application Guard как для Edge, так теперь и для Office, которые пользуются ввриантом такой технологии RDP, носящей название VAIL (Virtualized Application Integrated Locally, интегрируемых локально виртуальных приложений), оптимизированной под передачу через границы ВМ вместо сетевого обмена.

Расширение Weston для его обучения удалённому взаимодействию приложений и расширение серверной части RDP под применение как RAIL, так и VAIL, означало что у нас будет общее построенное с нуля решение, с учётом сетевой прозрачности, при этом работающее на протоколе, который уже широко применяется в отрасли и работает в масштабе, всё это звучало достаточно привлекательным.

Сердце и душа WSLg это компоновщик Weston. Это стандартный компоновщик Weston с интенсивно расширенным сервером RDP, новой оболочкой RAIL/ VAIL и различными исправлениями ошибок там и тут. В настоящий момент мы собираем эти компоненты из зеркала проекта и в то же время работаем над своим обратным вкладом в соответствующие проекты восходящего потока. Наша цель состоит в том, чтобы в конечном итоге собирать WSLg из истинных компонентов восходящего потока, что превратит WSLg великолепной и простой производственной средой желающих покопаться с Wayland и Weston.

Мы расширили основу RDP множеством способов. Мы добавили поддержку удалённого взаимодействия при помощи протоколов RAIL и VAIL (также именуемого GrfxRedirection) Теперь основа RDP может удалённо работать с отдельными окнами, а не со всем рабочим столом. Разница между RAIL и VAIL заключается в том, что RAIL копирует пиксельное содержимое окна через транспорт RDP и оптимизирован для сервера RDP (WSLg) и клиента RDP (в самом хосте) подключаемых через сеть. VAIL очень похож на RAIL, однако оптимизирован для транспортировки через границу виртуальной машины. Во избежание дорогостоящего копирования пикселей через транспортный протокол RDP VAIL применяет совместную для хоста и гостевой виртуальной машины память. В рамках сборки WSLg мы превращаем протокол VAIL/ GfxRedirection общедоступным.

Дополнительно к удалённому взаимодействию с приложениями мы также расширили основу RDP на поддержку конфигураций со множеством мониторов, включая поддержку масштабирования DPI для каждого монитора. Масштабирование DPI пользуется сочетанием собственной поддержки естественной поддержки Wayland для множителя масштаба, изначально сопровождаемого Wayland и масштабирования на стороне клиента RDP для не поддерживаемого множителя масштабирования. Это обеспечивает всегда правильное масштабирование приложения Linux в зависимости от выбранных в настройках пользовательского интерфейса Windows предпочтений. Мы добавили поддержку буфера обмена с тем, чтобы можно было бы вырезать/ вставлять (copy/ past) текст HTML и растровые данные между приложениями Linux и Windows. Перетаскивание (Drug and drop) в настоящее время не поддерживаются.

Мы добавили поддержку как для аудио ввода, так и для аудио вывода. Под аудио мы остановились на сервере PulseAudio. Мы написали небольшие подключаемые модули приёмника (sink) и источника для импульсов, которые перетасовывают аудио данные между серверами PulseAudio и RDP, так что аудио потоки могут интегрироваться в транспорт RDP в локальном или удалённом клиенте.

WSLGd это небольшое, подобное демону приложение, которое является самым первым процессом, запускаемым в среде WSLg и который запускает Weston, Pulse, устанавливает подключение RDP к своему хосту, затем отслеживает их и повторно запускает их при каждом их крушении или остановке работы.

Мы написали небольшой подключаемый модуль RDP, который имеет дело с интеграцией WSLg в меню start (Пуск) Windows. Часть этого подключаемого модуля внутри Weston перечисляет установленные в дистро вашего пользователя приложения, просматривая файлы рабочего стола. Она отправляет этот список приложений, совместно с командной строкой для их запуска, а также иконки для их представления, в свою часть хоста, которая добавляет эти приложения в имеющееся меню Start (Пуск) Windows. Выполняется отслеживание нескольких местоположений файлов стандартного рабочего стола. Когда пользователь устанавливает или деинсталлирует некое приложение в своём дистро Linux, такая операция отражается спустя несколько секунд в его хосте Windows.

Наконец, мы расширили FreeRDP на поддержку новых протоколов и исправили несколько проблем совместимости при взаимодействии с mstsc. Weston уже применял FreeRDP для своей поддержки RDP и мы не видели никакой необходимости перехода на иное решение, предпочитая вместо этого внести ряд улучшений в FreeRDP, которые также можно применять и в ином контексте помимо WSLg.

На картинке выше вы могли заметить такую новую вещь, которую мы называем системным дистро. Вы можете представлять себе такой системный дистро как заключённую в контейнер среду Linux, в которой мы запускаем Weston с дружественным ПОи проектируем различные серверные сокеты обратно в дистро своего пользователя. Этот пользовательский дистро настроен по умолчанию на ссылки к серверам для поддержки X11, Wayland и аудио.

Мы решили для WSLg следовать таким подходом поскольку он делает для нас возможным изоляцию WSLg от своего дистро пользователя. Мы можем обслуживать его независимо от соответствующего дистро пользователя и позволяет нам предлагать согласованную практику применения для различных дистрибутивов Linux. По мере представления нами WSLg, мы ожидаем его частого обновления в ближайшие месяцы, ибо мы продолжаем добавлять новые функциональные возможности, улучшать производительность, совершенствовать практику использования и исправлять проблемы совместимости приложений. Для желающих повозиться с самим системным дистро мы предлагаем механизмы, позволяющие пользователям запускать частные версии (см. нашу страницу вкладов в WSLg).

Для своего системного дистро мы приняли решение применять CBL-Mariner для размещения WSLg. CBL-Mariner это обладающий малым весом и персонализированный дистрибутив Linux, сопровождаемый нашей Системной группой Linux и позволяет нам осуществлять централизованную поддержку своей среды по различным частям Microsoft и гарантировать что мы остаёмся современными и над уязвимостями безопасности или прочими важными исправлениями которые нам необходимо подхватывать. До сих пор CBL-Mariner сосредотачивался на выхолощенных {без ядра} рабочих нагрузках контейнерного типа, запускаемых в Azure или периферийных продуктах или службах. В тесном сотрудничестве с командой CBL-Marinerмы публиковали различные относящиеся к пользовательскому интерфейсу пакеты в официальном repo RPM CBL-Mariner для включения WSLg.

Если вы желаете ознакомиться более подробно с деталями относительно архитектуры WSLg или заглянуть в его исходный код и собирать его самостоятельно, посетите, пожалуйста страницу проекта WSLg в GitHub.

Ранее мы анонсировали поддержку для виртуальных графичексих процессоров в WSL, которые позволяют популярным вычислительным API достигать внутри WSL почти натуральной производительности. Это некое дополнение к собственной основе DirectML для TensorFlow от Microsoft, которая допускает обучение AI (ИИ) в WSL поверх широкого набора оборудования.

Дополнительно к vGPU мы работали с сообществом Mesa над привнесением некого нового d3d12 драйвера gallium для Mesa и только что мы анонсировали доступность этой работы в Windows, привносящей поддержку для аппаратного ускорения OpenGL и OpenCL для ПК Windows на основе ARM, которые ранее были лишены такой поддержки.

Поддержка Linux для нового драйвера Mesa d3d12 была восходящим потоком для Mesa несколько недель тому назад и выступает частью официального выпуска Mesa 21.0. Именно это явилось кульминацией длинного путешествия и сделало доступным аппаратное ускорение приложений OpenGL в WSLg.

Важно отметить, что WSLg не обладает зависимостью к доступности vGPU или ускоренного OpenGL. WSLg отлично работает для 2d приложений как с ускорением OpenGL, так и без него. Однако если вы пытаетесь запускать более сложные 3D приложения, такие как Blender или Gazebo, вы получите намного улучшенную практику выполнения в системах с поддерживающими WDDMv3.0 графическими процессорами, которые поставляются со стандартной поддержкой vGPU WSL и будут автоматически зажигать такое OpenGL ускорение через Mesa.

Вы можете обнаружить представление драйверов WDDMv3ю0 от каждого из наших партнёров при помощи приводимых ниже ссылок. Эти драйверы в конечном счёте будут поставляться Обновлением Windows совместно с новой системой, когда будет выпущена новая версия Windows.

В терминах Mesa, большинство дистрибутивов сегодня всё ещё основаны на более версии 20.0 и более старых. Мы связались с различными издателями дистрибутивов WSL Linux чтобы убедиться, что обновление Mesa 21.x у них на горизонте и чтобы они обновили определение своего пакета Mesa для сборки и включения нового драйвера d3d12 gallium.

В зависимости от того когда вы читаете эти строки, ускоренный OpenGL в WSLg может сразу зажечься в вашей системе, или не сразу, поскольку вы всё ещё пользуетесь старой версией Mesa. Если вы не хотите ждать пока ваш дистрибутив получит эти изменения, а желаете сразу же попробовать его, вы можете посетить официальный сайт Mesa и собрать частную версию Mesa с такой поддержкой. Как альтернатива, вы вы можете испробовать только что анонсированное представление Ubuntu в сообществе Windows для WSL2. Этот новый дистрибутив Ubuntu собран из новейших компонентов и включает поддержку Mesa 21.0, что позволяет без проблем применять OpenGL с аппаратным ускорением и WSLg сразу после установки. Этот дистрибутив предназначен для опытных пользователей WSL чтобы помочь им в тестировании и отладке грядущих функциональных возможностей и не предназначен для применения в качестве “драйвера на каждый день”, но является отличным способом получить представление об этой функциональности на раннем этапе.

Поскольку мы уверены, что некоторые парни пожелают сравнить естественную версию с версией WSLg приложений, сделаем некое замечание относительно производительности 😊. Для WSLg v1, Mesa взаимодействует с Weston через системную память. Для дискретных графических процессоров это означает, что содержимое выстраиваемого изображения требуется скопировать в системную память прежде чем оно будет представлено компоновщику, чтобы вернуть его обратно в графический процессор в соответствующем клиенте RDP, работающем в Windows. Стоимость этого зависит от кадровой частоты и приложение, работающее со сверхвысокой кадровой частотой получит гораздо большее воздействие нежели приложения, работающие с более разумными кадровыми частотами. Для встроенных графических процессоров такие данные не должны покидать системную память при их перетасовке, однако представляемые через Mesa данные в настоящее время являются синхронными, что означает, что в каждом кадре имеется небольшая раковина (дождаться построения, выпихнуть построенный кадр, запустить следующий кадр), который оказывает воздействие на производительность.

Вот совершенно неофициальный фрагмент производительности, взятый с двух моих ПК, чтобы взглянуть на состояние дел сначала на дискретном графическом процессоре с очень высокой кадровой частотой (наиболее плохой вариант), а затем на встроенном графическом процессоре (наиболее лучший вариант). Это приводится для исполнения рояля Geeks3D GpuTest.

 

Таблица B-1. Geeks3D GpuTest

	Естественный Win32 (Mesa)	WSLg (vGPU – Mesa)	WSLg (программный – Mesa)
NVIDIA RTX 3090 (Да, очень повезло иметь друзей в нужном месте 😊)	540fps	350fps	4fps
MS Surface Book Gen3 (Intel – GPU)	19fps	18fps	1fps

Несмотря на снижение производительности из-за необходимости взаимодействия с системной памятью, результат по- прежнему намного выше чем при программном построении изображений. Устранение разрыва между натуральным приложением Win32 и приложением Linux, запущенном в WSLg - это именно то, что мы желаем улучшить для WSLg v2 и в последующих версиях, но для v1 мы бы хотели сосредоточить свои усилия на практике самого ядра, но при этом обеспечивать хорошую производительность, даже для не натурального варианта.

Мы с нетерпением ждём ваших отзывов относительно WSLg, о том что работает достойно, а может быть и не очень. Если у вас возникнут проблемы или же вы желаете сделать предложение, будьте любезны, откройте некую проблему на официальной странице проекта WSLg.