В марте прошлого года многие зарубежные вендоры заявили о приостановке поставок и технической поддержки для российских предприятий. Для нашей компании данное событие не стало неожиданным. Последние два десятилетия усилия предприятия были направлены на освоение и воспроизводство обширного пласта технологий разработки и развития ОС без участия иностранного капитала и специалистов.

Рассматривать этот опыт можно с разных сторон. В статье рассмотрим процесс становления технологической независимости на примере отдельно взятой подсистемы ОС «Нейтрино».

Этап первый ‒ системообразующий

Первые исследования в части графических технологий мы начали задолго до первого выпуска сертифицированной ОС «Нейтрино» или ее включения в реестр отечественного ПО. С середины 90х одна из сфер деятельности нашей компании включала сопровождение канадской системы QNX на территории РФ и СНГ. Смена поколений программного продукта и появление QNX Neutrino RTOS шли параллельно с установлением партнерских связей и приобретением прав на самостоятельные разработки в этой сфере. Таков бэкграунд появления обсуждаемой ОС, приобретший свои исходные очертания к 2005 году. На жаргоне этот процесс соответствует термину «форк».

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

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

Зато были тонны багов, узких мест и афтершоков от обоснованного, но запоздалого разделения графической и оконной подсистем. Но об этом будет рассказано далее.

Второй этап ‒ аналитический

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

Разработка первого достаточно простого графического драйвера была завершена в 2010 году. Им стал драйвер для XGI Volari Z9s. Нужно признаться, что получилось так себе. Примечательно, что первая сертифицированная версия «Нейтрино» была выпущена лишь годом позже.

Анализ архитектуры начинался со среды рабочего стола Photon (см. Desktop Environment, DE). Она разрабатывалась как развитие одноименного компонента QNX4, являясь достаточно удачным для своего времени минималистичным встраиваемым окружением. В то время Photon исполнял роль графической подсистемы, будучи монолитным модулем. Сейчас он не является частью графической подсистемы, выступая лишь ее клиентом. Однако, вплоть до версии 6.3.2, это было справедливо, и менеджер io-graphics действительно являлся аналогом io-display. Многие до сих пор эти понятия не различают, что является глубочайшим заблуждением. Для нас же Photon является стабилизированным легаси, на котором основано огромное число внедрений у заказчиков. Хотя это оконное окружение уже не является единственным в ОС «Нейтрино», но его сохранение остается принципиально важным.

Размежевание графики и DE было выполнено ещё до нашего активного участия в проектировании архитектуры и не прошло бесследно, породив массу багов разной степени критичности. Последствия этого процесса мы разгребали следующее десятилетие в своем продукте, а иностранные коллеги просто выкинули Photon к следующему релизу (6.6.0). К глубочайшему изумлению всех своих международных потребителей, часть из которых долгое время обращалась к нам за поддержкой и бэкпортированием наших наработок и драйверов в QNX.

Другой важной особенностью Photon является совмещение в себе функций DE и оконного окружения (см. Windowing System, WS). Первый аспект характеризует интерфейсные задачи пользователя, второй связан с обслуживанием ресурсов окон приложений и их декорированием и композицией. Тесная интеграция подобного рода на практике имеет как плюсы, так и минусы. С одной стороны такой подход позволяет сохранять функциональность встраиваемой, а размер минимальным. С другой стороны, архитектурное упрощение, которое было востребовано десятилетия назад и в актуальных конфигурациях, безразличных к производительности графики, становится ограничителем в развитии подсистемы. Это важно учитывать при дальнейшем чтении материала. Для сравнения, на следующей схеме приведена упрощенная (без ряда связей и компонентов) архитектура графической подсистемы условного дистрибутива Linux.

Следует обратить внимание на то, что драйверное обеспечение разбито на несколько взаимосвязанных модулей разного уровня. В данном аспекте можно говорить о существовании отдельных конвейеров 2D и 3D акселерации.

К выпуску «Нейтрино» редакции 2013 для операционной системы был разработан первый драйвер с аппаратной 3D-акселерацией, поддерживающий актуальные семейства графических контроллеров AMD Radeon GPU. В основу лег порт проекта с открытым кодом Mesa. Кроме, собственно, поддержки оборудования, важнейшим результатом стало понимание того, как устроен программный 3D стек на различных уровнях. Параллельно по доступным источникам и официальной документации разработаны драйвера для Intel HD Graphics с 2D-акселерацией.

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

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

Этап третий ‒ проектирование и эксперименты

Доминирующим принципом на этом шаге становится «non nocere» (лат. «не навреди»), поскольку новое не должно ломать старое. А там, где это невозможно, должно быть предложено полноценное переходное решение.

Рассмотренный в данном абзаце процесс 2014-2016 годов, на первый взгляд, с заявленной темой не связан, однако, это не так. При поддержке коллег из АО «МЦСТ» в этот временной период осуществлена интеграция компилятора LCC в интересах штатного функционирования ОС «Нейтрино» на процессорах «Эльбрус», что позволило выполнить полноценное портирование на одноименную архитектуру. Стоит отдельно подчеркнуть тот факт, что QNX Neutrino RTOS никогда на этих устройствах не работала, однако, противоположное мнение время от времени ошибочно озвучивается различных в статьях и обзорах. Справедливости ради, наши заказчики действительно ставили единичные эксперименты по запуску «Нейтрино» в режиме бинарной трансляции процессором инструкций ассемблера x86, но без особого вау-эффекта.

Именно эта веха в дальнейшем приведёт нас к появлению второго сопровождаемого 3D-стека.

Следующий номерной релиз дистрибутива (редакция 2016) ретроспективно отождествляется как с существенными успехами, так и с одним досадным промахом. К первым можно отнести:

• Расширение состава драйверного обеспечения с 2D-акселерацией , включая драйвера для ARM, PowerPC и Эльбрус-специфичных устройств, контроллеров Intel (семейства Haswell и ValleyView) и Silicon Motion.

• Рефакторинг, стабилизация и исправление ошибок графической подсистемы и интерфейсной библиотеки GF. Добавление ряда новых интерфейсов, которые уже не обладали обратной совместимостью с предшественником.

• Реализация первой для нас поддержки стандарта гетерогенных вычислений (OpenCL) на базе графических контроллеров AMD Radeon.

Теперь о провалах. В том же релизе была предпринята попытка реализовать аппаратную 3D-акселерацию на контроллерах Intel и даже успешно завершена. На тот момент в составе Mesa имелось 2 подходящих драйвера: разрабатываемый Intel драйвер i965 на старой архитектуре DRI и разрабатываемый open-source сообществом драйвер ILO на новой архитектуре Gallium. Поскольку к тому моменту имелся успешный опыт портирования и глубокой адаптации Gallium-драйвера, выбор пал на ILO, roadmap-ы которого внушали надежду. Дополнительным фактором в пользу этого выбора оказались результаты первичного анализа архитектуры DRI-драйверов. Выяснилось, что они уж слишком сильно привязаны к оконной подсистеме Linux. Закатали рукава и сделали, но в процессе тестирования оказалось, что в уже готовом драйвере содержатся глубокие архитектурные проблемы, заложенные разработчиками, и даже стандарт поддерживается не полностью. А потом и комьюнити внезапно решило выкинуть ILO из кодовой базы. Пояснять наши мысли на этот счет, думаю, не требуется.

В дистрибутив в итоге вошли лишь обновленные драйвера, а соответствующие сборки Mesa предоставлялись лишь избранным заказчикам и только для экспериментальных нужд, причем, если заказчик четко осознал в процессе переговоров, что тащить это в продакшн не стоит. Куча ресурсов оказалась потрачена "на корзину". Но негативный опыт – тоже опыт и в будущем мы сделали следующий заход на 3D акселерацию для Intel HD GPU.

К следующему номерному релизу – 2018 – были не только обновлены драйвера, касающиеся поддержки более новых семейств устройств (в частности, поддержка контроллеров Skylake и последующих), но также определены глобальные вектора развития продукта и начаты работы по реализации, а именно:

• обеспечение графической подсистемы функцией аппаратной композиции разнородных окружений (Photon, OpenGL, native Qt, …);

• переход на модульную архитектуру драйверного обеспечения;

• создание слоя абстракции для возможности запуска драйверов ядра Linux без полного перепортирования;

• расширение перечня поддерживаемых 3D-стеков.

Композиция. Окружение Photon, как уже отмечалось, требовало существенных усилий для учета и исправления имеющихся архитектурных недостатков. Одним из них является невозможность вынести ресурсы «окна» на аппаратный уровень. Частично этот вопрос уже решался появлением фреймворка Qt, но этого оказалось недостаточно, поскольку глобальное обслуживание окон оставалось полностью программным. В этой связи было принято решение вынести функции WS на уровень графической подсистемы, чего не было в оригинальной архитектуре.

К этому моменту у нас появилась возможность пощупать 2D/3D акселераторы Vivante GC*, которые есть в том числе в составе Freescale i.Mx6 (ныне NXP i.Mx6) , Эльбрус-1С+ и некоторых устройств ФГУ ФНЦ НИИСИ РАН. В имеющихся материалах обнаружился код совместимости с отсутствующим у нас композитным окружением Screen (в его пользу в QNX отказались от Photon). А его историческая близость к общему предку позволила нам решиться на эксперимент с непредсказуемым результатом ‒ разработку с нуля собственного оконного композитора, интегрированного в графическую подсистему, имея представление лишь о его публичных хэдерах. Бонусом выступило наличие в ванильном репозитории Qt правок для данного API, которые можно было бы переиспользовать с минимумом затрат.

Совместимость со всеми оригинальными интерфейсами мы не обеспечивали, поскольку целевые конфигурации у нас и у них отличаются. QNX ударился в мобилки и автомобили, а для нашего потребителя характерны иные сценарии встраивания, включая многомониторные и промышленные, на что иностранная реализация совершенно не была заточена. Вот таким образом у нас на балансе появился второй 3D-стек, ранняя версия собственной оконной подсистемы с композицией и пачка необратимых архитектурных изменений в ОС. При этом удалось не сломать совместимость всего этого праздника непослушания с исходными интерфейсами io-display и обеспечить потребителям бесшовный переход. Но на первых порах приходилось и реверс-инжинирить, чтобы понять о чем думали разработчики, когда творили отдельную дичь.

Слой совместимости. Как показал наш неоднократный опыт разработки драйверов «с нуля» – процесс достаточно длительный, измеряемый полугодиями. Пройдя этот путь "от и до" более пяти раз, мы пришли к ровно тем же выводам, что и другие разработчики ОС (пруфы по ссылкам): FreeBSD, NetBSD, VxWorks [VxWorks® 7 Release Notes (SR0540)] и QNX – вполне достижима реализация слоя абстракции для запуска ванильных DRM-совместимых драйверов Linux. В том или ином объеме все перечисленные ОС эксплуатируют ядерный код Linux. В первую очередь потому, что вендоры оборудования охотно коммитят свои наработки лишь в него. Правильность этого решения также подтверждается увлечением отдельных вендоров регулярным переписыванием до неузнаваемости кодовой базы некоторых драйверов.

Исходя из этих предпосылок, была начата разработка и нашего слоя абстракции. Первые практические результаты были получены уже после окончания сертификационных испытаний актуальной редакции ОС – 2020.

Резюмируя все перипетии на этой стадии, сложно точно посчитать сколько было сломано копий.

Текущий этап ‒ настоящее и будущее

В прошлом году окончился процесс получения очередного сертификата на ОС. Из крупных изменений в контексте тематики статьи:

• Произведён переход на универсальный загрузчик драйверов, поскольку число 3D-стеков и дальше будет возрастать.

• Проекты Mesa и LLVM, являясь частью драйверного обеспечения, включены в состав графической подсистемы, и более не являются дополнительными компонентами дистрибутива.

• При первой же возможности вернулись к вопросу 3D-акселерации для контроллеров Intel. Задачу решили путем рефакторинга интерфейсов DRI-драйвера и отучения его слишком сильно любить X11.

• Опубликована официальная интерактивная документация, включающая обширные сведения в части графики.

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

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

На этом, естественно, эволюционное развитие не прекратилось, и уже сейчас закончены или находятся в процессе следующие работы:

• [готово, включено в следующий релиз] Аппаратная поддержка стандарта OpenCL для устройств Vivante и 7-ого поколения графических процессоров Intel (на основе проекта beignet, в узких кругах известного как "бублик"). Вообще, у Intel с OpenCL отношения сложные, но в их "лучших" традициях. Для всех контроллеров, вплоть до седьмого поколения, рекомендуется ныне замороженный бублик, которым занималась Intel China OTC, а вот со следующих поколений следует ориентироваться на Graphics Compute Runtime. Ну а предшествующий проект типично заброшен.

• [готово, включать пока рано] Третий 3D-стек для устройств Mali GPU. Эти компоненты являются уникальными еще и в том смысле, что это наш первый драйвер, который запущен через слой совместимости, а не портирован из ядра Linux или создан «с нуля».

• [готово, не успевает к релизу] Глобальное обновление LLVM и Mesa для всех поддерживаемых устройств и архитектур. Сейчас у нас в лабораторных условиях обкатаны Mesa 22.2.2 и LLVM 13.0.0, но, вполне ожидаемо, бублик с ними не дружит. Продолжаем работать...

• [не готово, ведутся работы] При обновлении Mesa выяснили, что драйвер, который мы некоторое время назад затянули, вендор бросил. Это одновременно и хорошо и плохо. Новые официальные драйвера (Iris и Crocus), наконец-то, на нормальной архитектуре Gallium, а вот наш DRI-драйвер скоро пойдет следом за ILO.

• [не готово, на стадии анализа] Есть основания считать, что будет и четвертый 3D-стек. В этот раз от Imagination.

К сожалению, низкоуровневые системные сервисы можно визуально продемонстрировать только схематически. А поскольку имеющимися в достатке скринами открытых портов Doom3, Quake2, open-source Mafia и HL никого не удивишь ...

.. и не продемонстрируешь на какой они архитектуре и с какими драйверами исполняются, придется ограничиться снимком среды визуального 3D-моделирования разработки наших партнеров:

Данный материал основан на глубокой переработке статьи Эволюционное развитие графических технологий в ЗОСРВ «Нейтрино» // Системы управления и обработки информации. С.-Пб. 2022. Вып. 3(58). С. 68–74. Публикация согласована с редакцией и коллективом авторов.