Возможно, кто-то из читателей помнит мою серию публикаций о графической библиотеке OpenSceneGraph. Уже на тот момент, в общем-то было понятно, что использование OpenSceneGraph в 2018 году мало оправдано из-за того, что OpenGL, на котором основан OpenSceneGraph потихоньку сдает свои позиции. В феврале 2016 года орган по стандартизации OpenGL Khronos group, выпускают приемника OpenGL - Vulkan API версии 1.0. Производители оборудования в общем-то почти сразу стали добавлять в драйверы своей аппаратуры поддержку нового API. По крайней мере, актуальная на тот момент GeForce GTX 970 уже имела таковую поддержку (про более старые серии аппаратуры ничего сказать не могу).

Не смотря на то, что OpenSceneGraph таки получил поддержку OpenGL 3.x (и ваш покорный слуга собирал его с таковой поддержкой), разработчикам этой библиотеки стало понятно, что огромное количество внутренних проблем OpenGL делает его поддержку бесперспективной. Поэтому, в конце мая 2018 года стартовала разработка новой графической библиотеки VulkanSceneGraph, ориентированной исключительной на Vulkan API. 13 ноября 2022 года состоялся официальный релиз VulkanSceneGraph-1.0, а совсем недавно, 31 августа 2023 выпустили VulkanSceneGraph-1.0.9.

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

Vulkan API - достоинства и недостатки

Vulkan является еще более низкоуровневым API, чем OpenGL, даже в своей версии 3.x и выше. Он предоставляет очень низкий уровень абстракции над оборудованием, давая разработчику контроль над настройкой огромного числа параметров рендеринга, выделением памяти, позволяя гибко управлять потоком данных, предаваемым в графический процессор.

Vulkan создает низкую нагрузку на центральный процессор, ориентируясь в большей степени на возможности GPU, там где это требуется. Из коробки имеется многопоточность как при исполнении кода на CPU и уже тем более на GPU, со встроенными в API примитивами синхронизации.

Достоинством нового API является его кроссплатформенность - Vulkan поддерживается платформами Android, Linux, BSD Unix, QNX, Haiku, Nintendo Switch, Raspberry Pi, Stadia, Fuchsia, Tizen и Windows 7, 8, 10 и 11. Монополистская политика Apple, выразившаяся в отказе от стандартов Khoronos group, не создала особых препятствий для проникновения Vulkan и на платформы macOS и iOS, так как был создан слой совместимости между Vulkan и Metal API, позволяющий работать приложениям на Vulkan на этой платформе с минимальными накладными расходами.

Поддержка новейших аппаратных функций, таких как трассировка лучей и сеточные шейдеры, так же является преимуществом нового API.

Vulkan API обеспечивает доступ к графическим средствам GPU, так и к его вычислительным средствам, на новом, современном уровне совмещая в себе функциональность OpenGL и OpenCL.

Несомненным же его недостатком является высокий порог вхождения. Разработчик приложений на Vulkan, сталкивается не только с необходимостью учета массы настроек и самостоятельной организации управления процессом рендеринга, но так же, вытекающим из вышеперечисленного объемом кода - среднестатистический пример отрисовки треугольника на Vulkan API содержит от 1000 до 1500 строк кода.

Графический API высокого уровня - минимализм против универсальности

Если говорить о современных графических движках, например Unity и Unreal, то они, обладают значительной специализацией, направленной преимущественно на создание игр. При этом они содержат многочисленные уровни абстракции, дабы обеспечить поддержку нескольких API низкого уровня: Direct3D, Metal, OpenGL и теперь еще и Vulkan. Такая архитектура ведет как к огромному объему кода, так и архитектурных компромиссов неизбежно возникающих в процессе скрещивания поддержки нескольких API.

В противоположность этому подходу, OpenSceneGraph, а в большей степени теперь и VulkanSceneGraph, предоставляют разработчику минимальный набор функций, решающих общие задачи разработки графического приложения. По сути, VulkanSceneGraph инкапсулирует низкоуровневые вызовы Vulkan API, создавая максимально приближенный к ним по структуре и выполняемым функциям тонкий слой абстракции, оперирующий сходными с ними концепциями и типами данных. Значит какой высокоуровневый API будет максимально приближен к аппаратуре. Этот подход, в случае кроссплатформенного Vulkan не приведет к потере переносимости кода, хотя при использовании платформозависимого API мог бы подобные проблемы породить.

OpenSceneGraph, реализующий концепцию так называемого графа сцены, обеспечивал (и обеспечивает) инкапсуляцию конечного автомата OpenGL. Со временем эта библиотека стала спотыкаться о те же проблемы, что присущи самому OpenGL. С появлением на сцене Vulkan API перед разработчиками OpenSceneGraph встала дилемма - адаптировать существующую архитектуру OpenSceneGraph под Vulkan, либо спроектировать новую библиотеку, оперирующую исключительно Vulkan.

Роберт Осфилд, руководитель проекта OpenSceneGraph принял решение создать новый граф сцены, построенный исключительно на Vulkan и опирающийся на возможности, актуального на тот момент стандарта C++17. Центральной задачей стало уменьшение накладных расходов при обработке графа сцены на центральном процессоре. При работе на GPU, Vulkan работает в 10 раз быстрее чем OpenGL. Однако, если обработка кадра на ЦП занимает 10 мс, а OpenGL добавляет еще 5 мс на GPU, то простая замена одного API на другой приведет к уменьшению времени отрисовки кадра до 10,5 мс, что является ускорением лишь на 43%. Желательно было увеличить производительность работы библиотеки на ЦП так же в 10 раз, чтобы раскрыть потенциал Vulkan в полной мере.

Принципы обеспечения производительности VulkanSceneGraph

Функции, предоставляемые современными процессорами, такие как предварительная выборка команд, прогнозирование ветвлений, распараллеливание инструкций крайне чувствительны к тому, как организованы обрабатываемые данные. В связи с этим, подход к организации данных объектов графа сцены и управление памятью, выделяемой под них, претерпел, по сравнению с OpenSceneGraph ряд изменений, а именно:

• Максимально возможное уменьшение размеров всех объектов графа сцены. Базовый класс узла графа сцены vsg::Node имеет размер 24 байта, против 208 байт у osg::Node, то есть в кэш процессора может поместиться почти в 10 раз больше объектов.

• VulkanSceneGraph имеет собственный распределитель памяти в куче vsg::Allocator, обеспечивающий выделение собственных блоков памяти под хранение однотипных объектов. Этот подход направлен на уменьшение промахов кэша, при работе с группами однотипных объектов.

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

• Использование собственных умных указателей vsg::ref_ptr<> вместо std::shared_ptr<> и vsg::observer_ptr<> вместо std::weak_ptr<>. Собственные указатели хранят только указатель на управляемый объект, счетчик же ссылок размещается в самом объекте. Это в 2 раза уменьшает объем указателя в сравнении с эквивалентами, предоставляемые стандартной библиотекой C++.

Эти, и ряд других мер, привели к 10-кратному увеличению производительности обработки сцены, в сравнении с OpenSceneGraph.

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

Если коротко, то базовая часть библиотеки состоит из трех проектов, размещенных в аккаунте  vsg-dev на GitHub содержит следующие проекты, которые официально поддерживаются как часть проекта VulkanSceneGraph. Три основных проекта, необходимые большинству разработчиков:

• VulkanSceneGraph — сама библиотека VulkanSceneGraph может использоваться сама по себе для автономных графических приложений. Что касается встраиваемых решений, то это может быть желательным подходом, поскольку сводит к минимуму конечный размер исполняемого файла.

• vsgXchange — ожидается, что пользователи захотят загружать 2D-изображения и 3D-модели различных форматов. Библиотека добавляет поддержку широкого спектра форматов изображений и 3D-моделей, с применением assimp для чтения данных по протоколам http/https с помощью libcurl, а также для чтения/записи/обработки изображений ГИС и DEMS с помощью дополнительной интеграции с GDAL.

• vsgExamples — коллекция из 61 пример (по состоянию на 31 августа 2023 г.) написанных для помощи в тестировании функций VulkanSceneGraph по мере его разработки, а так же в качестве учебного пособия для новых пользователей.

Задача же данной публикации - показать процесс сборки библиотеки под две платформы - GNU/Linux и Windows и написать простейший "Hello, world!", с прицелом на дальнейшее развитие освещения этой темы на данном ресурсе, по мере продвижения автора в деле изучения этой библиотеки.

Сборка под GNU/Linux компилятором gcc

В общем она не составляет особого труда. Не знаю как в других дистрибутивах, но в Arch Linux, библиотеки vsg и vsgXcahnge доступны в пользовательском репозитории AUR, тут и вот тут. Все необходимые зависимости будут подтянуты автоматически. Кроме того, разработчиками предлагается следующий способ установки библиотеки из исходников

Прежде всего настраиваем необходимые переменные окружения

# VulkanSceneGraph
export INSTALL_DIR=~/VSG/Install
export PROJECT_DIR=~/VSG/Projects
export PATH=${PATH}:${INSTALL_DIR}/bin
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${INSTALL_DIR}/lib

# Пути поиска данных для примеров и файлового кэша
export VSG_FILE_PATH=${PROJECT_DIR}/vsgExamples/data
export VSG_FILE_CACHE=${PROJECT_DIR}/vsgFileCache

Установка необходимых зависимостей, например для Debian это выглядит так

# зависимости для сборки VulkanSceneGraph
sudo apt-get install git g++
sudo apt-get install cmake cmake-curses-gui

# установка Vulkan и слоев проверки, альтернатива - установка VulkanSDK с официального сайта
sudo apt-get install libvulkan-dev vulkan-ttols vulkan-validationlayers

# зависимости для vsgXcahnge
sudo apt-get install libassimp-dev libfreetype-dev libopenexr-dev

а для Arch Linux - так

sudo pacman -S git base-devel cmake 
sudo pacman -S vulkan-headers vulkan-validation-layers vulkan-tools 
sudo pacman -S assimp freetype openexr

Далее собственно сборка и установка всего хозяйства в выделенный в домашней директории каталог

mkdir ${PROJECT_DIR}
cd ${PROJECT_DIR}

git clone https://github.com/vsg-dev/VulkanSceneGraph.git
git clone https://github.com/vsg-dev/vsgXchange.git
git clone https://github.com/vsg-dev/vsgExamples.git
git clone https://github.com/vsg-dev/vsgTutorial.git

cd VulkanSceneGraph
cmake . -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR}
make -j 16
make install

cd ../vsgXchange
cmake . -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR}
make -j 16
make install

cd ../vsgExamples
cmake . -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR}
make -j 16
make install

Сборка под Windows компилятором MinGW

Я не буду описывать сборку компилятором MSVS. Во первых - это тривиальный процесс, во вторых я, в своей практике данные компилятор не использую, и всячески избегаю ситуаций, когда он может потребоваться. Скажу лишь, что для сборки необходимо скачать и установить сборку Vulkan SDK с сайта LunarG. После чего, с помощью cmake-gui генерируется файл решения для Visual Studio и уже из этой IDE осуществляется сборка.

В моем случае боль заключалась в том, что Vulkan SDK собран как раз компилятором MSVS, и, хотя VulkanSceneGraph и собирался, реализации функций вулкан статически не включались в libvsg.a и libvsgXchange.a, приводя к их полной неработоспособности.

Попытки собрать Vulkan SDK из исходников приводили меня к тому, что сборка останавливалась, так как в её процессе вдруг начинал требоваться ML - майкрософтовский макроассемблер. В попытках получить работающую сборку именно с помощью mingw, я выдрал нужные мне библиотеки из пакетов MSYS2. Эту сборку я скомпоновал требуемым образом, и выложил вот здесь. Содержимое этого архива нужно распаковать в удобное вам место, и, затем, настроить следующие переменные окружения

Далее, как и в случае с линукс, клонируем репозиторий VulkanSceneGraph. При желании собрать текущую стабильную версию переключаемся на нее

git checkout v1.0.9

Далее я воспользовался компилятором MinGW 11.2 из комплекта Qt 6.3.1, вызвав его сборочную консоль и из нее выполнив

E:\>cd work\3thparty\VSG\build

E:\work\3thparty\VSG\build>cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=E:\Apps\VSG-1.0.9 ..\VulkanSceneGraph
-- The CXX compiler identification is GNU 11.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Qt/Qt_6.3.1/Tools/mingw1120_64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Reading 'vsg_...' macros from E:/work/3thparty/VSG/VulkanSceneGraph/cmake/vsgMacros.cmake - look there for documentation
-- Found Vulkan: C:/VulkanSDK/1.3.261.1/lib/libvulkan-1.dll.a (found suitable version "1.3.261", minimum required is "1.1.70.0") found components: glslc glslangValidator
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Performing Test HAVE_CXX_ATOMIC_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMIC_WITHOUT_LIB - Success
-- The following REQUIRED packages have been found:

 * Vulkan (required version >= 1.1.70.0)
 * Threads

-- Configuring done (2.5s)
-- Generating done (0.1s)
-- Build files have been written to: E:/work/3thparty/VSG/build

Выхлоп cmake выглядел очень обнадеживающе, поэтому

E:\work\3thparty\VSG\build>mingw32-make -j20

с долгожданным успехом

Далее, устанавливаем собранную библиотеку по месту обитания

E:\work\3thparty\VSG\build> mingw32-make install

Для сборки vsgXchange, который является адаптером для загрузки различных форматов моделей и изображений в качестве зависимости требуется assimp. Эта библиотека без проблем собирается из консоли mingw, однако, лучше собирать её в варианте статической библиотеки, для статической же компоновки с vsgXchange. На vsgXchange в этой публикации останавливаться не будем - для нашего "Hello, world!" достаточно будет и ядра VSG.

Hello, VulkanSceneGraph!!!

При успешной сборки и установке, правильной настройке окружения код этого примера одинаков для обоих платформ. Для Windows нужно убедиться, что заданы переменные окружения для Vulkan, а также в дополнении к этому - путь к скрипту поиска vsg для системы сборки CMake (вечно под этой виндой всякие проблемы...)

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

#include	"main.h"

//------------------------------------------------------------------------------
//
//------------------------------------------------------------------------------
int main()
{
    // Создаем сцену, загружая модель чайника собственного формата VSG
    auto scene = vsg::read_cast<vsg::Node>("../data/models/teapot.vsgt");

    // Создаем вьювер
    auto viewer = vsg::Viewer::create();

    // Создаем объект, хранящий параметры окна приложения
    auto windowTraits = vsg::WindowTraits::create();
    windowTraits->width = 1024;
    windowTraits->height = 768;
    // Создаем окно приложения
    auto window = vsg::Window::create(windowTraits);
    // СВязываем вьювер с коном приложения
    viewer->addWindow(window);

    double radius = 1.0;
    double nearFarRatio = 0.00001;

    // Задаем начальное направление камеры
    auto lookAt = vsg::LookAt::create(vsg::dvec3(0.0, -radius * 4.5, 0.0),
                                      vsg::dvec3(0.0, 0.0, 0.0),
                                      vsg::dvec3(0.0, 0.0, 1.0));

    // Вычисляем параметры и создаем матрицу перспективной проекции
    double aspectRatio = static_cast<double>(window->extent2D().width) /
                         static_cast<double>(window->extent2D().height);

    auto perspective = vsg::Perspective::create(30.0,
                                                aspectRatio,
                                                nearFarRatio * radius,
                                                radius * 100.0);

    // Создаем камеру
    auto camera = vsg::Camera::create(perspective,
                                      lookAt,
                                      vsg::ViewportState::create(window->extent2D()));

    // Задаем обработчик закрытия окна
    viewer->addEventHandler(vsg::CloseHandler::create(viewer));
    // Задаем обработчик манипулятора камеры
    viewer->addEventHandler(vsg::Trackball::create(camera));

    // Создаем граф команд Vulkan для рендеринга сцены в заданое окно
    // определенной ранее камерой
    auto commandGraph = vsg::createCommandGraphForView(window, camera, scene);
    // Связываем граф команд с вьювером
    viewer->assignRecordAndSubmitTaskAndPresentation({commandGraph});

    // Компилируем объекты Vulkan и передаем данные для рендеринга сцены
    viewer->compile();

    while (viewer->advanceToNextFrame()) // пока возможен переход к новому кадру
    {
        // Передаем события в обработчики, назначенные вьюверу
        viewer->handleEvents();
        // Обновляем граф сцены (добавление/удаление объектов, например)
        viewer->update();
        // Записываем команды в граф сцены и послылаем их в очередь Vulkan
        viewer->recordAndSubmit();
        // Ждем окончания рендеринга и передаем готовый кадр в буфер окна
        viewer->present();
    }

    return 0;
}

Заголовочный файл main.h содержит включения заголовков VSG

#ifndef		MAIN_H
#define		MAIN_H

#include	<vsg/all.h>

#endif

Для сборки этого хозяйства пишем скрипт CMakeLists.txt такого содержания

cmake_minimum_required(VERSION 3.7)

# Задаем имя цели сборки (так будет именоваться исполняемый файл)
set(TARGET hello_world)

# Имя проекта совпадает с именем исполняемого файла
project(${TARGET})

# Путь к какталогу, куда помещается исполняемый файл после сборки
set(EXECUTABLE_OUTPUT_PATH "../../bin")

# Ищем в системе необходимые пакеты
find_package(vsg REQUIRED)

# Включаем в проект файлы исходников и заголовки по маске
file (GLOB INCLUDES "./include/*.h")
file (GLOB SOURCES "./src/*.cpp")

# Указывается, что собирается исполняемый файл с зананным именем
# из заданных файлов исходников
add_executable(${TARGET} ${SOURCES} ${INCLUDES})

# Задается каталог поиска заголовков
target_include_directories(${TARGET} PRIVATE ./include/)
# Задаются библиотеки, компонуемые с исполняемым файлом
target_link_libraries(hello_world vsg::vsg)

Учитывая, что этот пример - часть серии примеров, которые я собираюсь написать в ходе освоения VSG, он включается как подпроект в составной проект, для чего имеется соответствующий CMakeLists.txt в коневой папке с исходниками примеров

# Устанавливаются минимальные требования по версии CMake
cmake_minimum_required(VERSION 3.7)

# Задаем имя основного проекта
project(VSG-lessons)

# Подключаем подпроекты
add_subdirectory(hello_world)

Этот пример доступен открыто в моем репозитории на Gitea.

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

1. Создание графа сцены из оного единственного узла - чайника. Эту модель можно скачать вот тут, она представлена в оригинальном формате VSG *.vsgt. Там же лежат и примитивные другие объекты, используемые в официальных примерах

2. Создается объект viewer - он отвечает, как и в OpenSceneGraph за рендеринг сцены и обработку событий

3. Задаются параметры окна приложения - так же как и в OSG за это отвечает класс WindowTraits, через который настраиваются все параметры отображения сцены на мониторе компьютера

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

5. Настраивается камера, матрица перспективной проекции, определяется область окна в которую будет производится рендеринг.

6. Задаются базовые обработчики закрытия окна и поведения манипулятора камеры

7. Создается конвейер команд Vulkan для отрисовки данной сцены и связывается с вьювером

8. Выполняется компиляция всех объектов Vulkan (в том числе и шейдеров)

9. Организуется главный цикл отрисовки. В OSG этот цикл сводился к вызову viewer->run(), а доступ внутрь него можно было получить через классы обратных вызовов (хотя цикл можно было и развернуть в отдельные вызовы). В VSG же этот цикл развернут в явную последовательность вызовов обработки событий, обновления графа сцены, передачи команд рендеринга в очередь Vulkan и отрисовки готового кадра.

Результат работы этого примера не сильно впечатляет

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

Заключение

Библиотека VulkanSceneGraph является очень молодой, с момента её первого релиза не прошло и года. Однако, её применения, по моему мнению, подкрепленному убеждённостью разработчиков сулит огромные перспективы. По сути это единственное на сегодняшний день открытое решение, дающее возможность использовать мощь Vulkan API используя достаточно универсальную и чрезвычайно компактную графическую библиотеку.

Разговор о VulkanSceneGraph несомненно будет продолжен. Эта статья - пилотная в планируемой мной серии публикаций по данной теме. А пока - благодарю за внимание и...

Продолжение следует..