В очередной раз перебирая «железо» своего ретрокомпьютера, о котором я уже писал на SE7ENе, я заменил видеокарту и запустил Quake 2. Ради эксперимента переключился на программный рендеринг (Software rendering) и поймал себя на мысли: досадно, что современные игры лишены такой гибкости. А может, всё-таки нет?
Быстрый поиск подтвердил: возможности для этого есть, причем вполне доступные. Ниже представлен обзор четырех популярных инструментов, которые позволяют запускать ресурсоемкие 3D-приложения даже на серверах, где напрочь отсутствуют GPU с поддержкой OpenGL или Vulkan.
Что кроется за требованием «нужен GPU»?
Если упростить до предела: ключевым компонентом любой системы визуализации графики является растеризатор. Его работа заключается в преобразовании 2D-геометрии в растровую сетку, готовую к наложению текстур, освещению и выводу на дисплей. Ранние 3D-ускорители вроде 3dfx Voodoo 2 занимались исключительно этим, разгружая центральный процессор, который по-прежнему отвечал за трансформацию объектов.
До эпохи массовых ускорителей игроделы были вынуждены писать собственные программные растеризаторы для CPU. Перенос этих вычислений в кремний значительно упростил разработку, породив многообразие API, таких как Glide, DirectX и Vulkan.
Сегодня аппаратная растеризация стала стандартом де-факто для любых настольных и мобильных систем. Впрочем, история знает и неудачные попытки, например, Intel Larrabee, делавший ставку на программную реализацию — этот опыт наглядно показал нежизнеспособность подобных решений для массового рынка.
Итог: приложению, «требующему» GPU, на самом деле нужен лишь корректный программный интерфейс. Если графическое API возвращает адекватные ответы, системе не принципиально, «железо» ли это или программный драйвер, выполняющий вычисления на центральном процессоре (пусть и с меньшей скоростью).
Почему серверы часто «безглазы»
Для серверного оборудования отсутствие видеокарты — стандарт. Конечно, базовые функции вроде вывода BIOS/UEFI или консоли восстановления обеспечиваются простейшими BMC/AST-чипами, но запуск чего-то сложнее текстового интерфейса превращается в квест. Типичная виртуальная машина отлично справляется с многотысячным трафиком и базами данных, но пасует перед любым софтом, запрашивающим OpenGL.
Исторически серверному ПО графические возможности были не нужны, а выделенный GPU считался источником лишнего энергопотребления и точкой отказа. Однако реалии изменились: сегодня на сервере могут быть критичны браузеры для автотестов, инструменты с поддержкой WebGL/WebGPU, графические движки или Electron-приложения. Всем им подавай аппаратное ускорение.
Выбор обычно невелик: либо закупать дорогостоящие видеокарты, либо внедрять программные эмуляторы, имитирующие работу кремниевого графического адаптера.
SwiftShader (Vulkan)
Разработанный канадской компанией TransGaming в 2005 году, SwiftShader изначально был нацелен на геймеров, которым не хватало мощности или бюджета на покупку видеокарт. Он позволял запускать 3D-проекты даже на «печатных машинках».
На тот момент это был один из самых быстрых решений, обгонявший Microsoft Direct3D Reference Rasterizer почти в 50 раз. Он отлично работал на любом x86-процессоре с поддержкой Intel SSE и поддерживал все ОС, начиная с Windows 98. Через Cedega была доступна и поддержка Linux.
Позднее SwiftShader сменил специализацию, став fallback-механизмом для Chrome. Если драйвер видеокарты давал сбой, браузер автоматически переключался на программный рендеринг через SwiftShader.
Сегодня проект перешел под крыло Google и стал open-source, доступным на GitHub. Стоит учесть, что в новых версиях Chrome (130+) поддержка WebGL fallback официально признана устаревшей. Чтобы опробовать его самостоятельно, проще всего найти готовые библиотеки в папке установленного Chrome:
C:\Program Files\Google\Chrome\Application\[version]\
Вам понадобятся три файла:
-
vulkan-1.dll — загрузчик, связывающий приложение с графическим API. Он «опрашивает» систему на предмет доступных драйверов и направляет запросы по нужному адресу.
-
vk_swiftshader.dll — непосредственно драйвер, эмулирующий работу GPU на мощностях CPU, включая JIT-компиляцию шейдеров.
-
vk_swiftshader_icd.json — манифест, который помогает загрузчику распознать программный драйвер.
Копирование этих файлов в папку с приложением или в системную директорию (System32) часто решает проблему отсутствия GPU.
llvmpipe (OpenGL)
В отличие от SwiftShader, llvmpipe является частью проекта Mesa и считается эталоном программного рендеринга для Linux.
Его архитектура базируется на слое Gallium3D. Вместо написания драйверов с нуля, разработчики создали унифицированный интерфейс. Llvmpipe использует LLVM для генерации промежуточного представления (IR) и последующей JIT-компиляции «на лету» в машинный код процессора. Важное преимущество — встроенная поддержка параллелизма (до 32 потоков), что позволяет эффективно использовать многоядерные CPU для рендеринга.
lavapipe (Vulkan)
Еще один представитель экосистемы Mesa — lavapipe, выступающий в роли Vulkan-фронтенда для Gallium. Фактически, растеризацию здесь все равно выполняет llvmpipe. Драйвер честно сообщает системе, что он является типом устройства VK_PHYSICAL_DEVICE_TYPE_CPU, но при этом предоставляет всю необходимую функциональность.
Долгое время пользователи сталкивались с предупреждением «not a conformant vulkan implementation», если в системе не было найдено физического GPU, но с 2022 года lavapipe прошел сертификацию Khronos CTS и стал полностью официальным решением. В большинстве современных дистрибутивов он поставляется в составе пакета mesa-vulkan-drivers.
WARP
На десерт — решение от Microsoft: WARP (Windows Advanced Rasterization Platform), получившее название в честь технологий из Star Trek. Принцип работы тот же: JIT-компиляция в код x86 и распараллеливание по ядрам.
WARP не предназначен для гейминга, его стихия — серверный рендеринг, автоматизированное тестирование и проверка графических интерфейсов. Это неотъемлемая часть Direct3D. По производительности со времен Windows 7 его сравнивают с базовой интегрированной графикой, чего вполне достаточно для офлайн-рендеринга или генерации превью.
Заключение
История циклична: давний «костыль» из Quake 2, позволивший запускать игры без ускорителей, сегодня превратился в мощный инженерный инструмент. Программный рендеринг — это надежный помощник для DevOps-инженеров, сталкивающихся с приложениями, внезапно возжелавшими графический контекст.
Ну а для энтузиастов это отличный шанс попробовать запустить какой-нибудь Crysis на серверном «железе», которое для этого совершенно не создавалось. Запасайтесь терпением и оперативной памятью — шоу будет захватывающим.
_large.png "5G от «Билайна»: масштабное расширение зоны тест-драйва по всей России")
