«Подцепить» Vulkan на билд-ферме CentOS 6

тебе нужна так называемая loader library, libvulkan1. Сырцы можно забрать тут: https://github.com/KhronosGroup/Vulkan-Loader

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

UPD: теперь у них все сырцы лежат отдельно. Еще нужны будут хидеры: https://github.com/KhronosGroup/Vulkan-Headers

а так же могут пригодиться тесты: https://github.com/KhronosGroup/Vulkan-ValidationLayers

Khnazile, а всякие ICD нужны? Или они не участвуют в компилировании?

Я так понимаю, что не нужны. ICD это уже непосредственно драйверы устройств, а для того, чтобы собирать софт нужны только хидеры и loader library.

Спасибо!

я внимательно изучил зависимости libvulkan, и для ее сборки нужны еще хидеры SPIR-V: https://github.com/KhronosGroup/SPIRV-Headers. Логично, что для сборки программ под вулкан они тоже скорее всего нужны.

О, спир-в. Я как-то пытался его собрать (не хедеры, а весь). В старых ночных сборках VC4CL (OpenCL для Raspberry Pi) была зависимость от этой либы (сейчас зависимости нет). И я так и не собрал! В итоге просто обновил Debian 8 на 9.

Хорошо что тут нужны только хедеры.

Остаётся открытым вопрос про ninja-build и meson.

Я никогда раньше софт под вулкан не собирал, только драйверы, и то в автоматическом режиме, где за меня уже подумали... Но вот сейчас начинаю сомневаться в некоторых моментах: возможно для сборки софта по вулкан тебе понадобиться сильно больше всяких штук, чем для сборки драйверов. Например, крайне подозрительно выглядит https://github.com/KhronosGroup/SPIRV-Tools. Там внутри какието утилиты для работы с шейдерами SPRIV, не исключено, что для сборки софта это все нужно. А может для игр и прочего разработаны специальные тулчейны, фиг знает. Я пока уверен только в том, что libvulkan это важный системный компонент, без которого точно вулкан не заработает.

Что касается самого софта для Вулкана, то я посмотрел SPEC-файлы libSDL 2.0.8 и Wine 3.11. Там только vulkan-devel, и всё.

Похоже что самое интересное будет - собрать libvulkan под CentOS. Смотрю SPEC-файл, он какой-то непонятный с первого раза.

https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/vulkan/vulkan...

Там код со старого репозитория, когда Loader и тесты лежали в одной куче. По этому в спеке убирают ненужные файлы и делают какую-то дистроспецифичную магию с путями. Но в целом это так себе пакет, в нормальных пакетах в спеках есть комментарии :)

Я думаю, что при сборке под центось имеет смысл смотреть на спек от федоры.

если хочешь, чтобы твоя софтина под Linux запустилась у как можно бо́льшего количества пользователей

Сделай её востребованной и майнтейнеры сами всё соберут.

компилируй её не в самой последней системе
GCC 8 в репо есть, а в EPEL доступна хренова туча либ на все случаи жизни. Например самый новый Boost

У тебя шизофрения и вторая личность не может договориться с первой?

Часто для сборки требуется свежий cmake

И свежие библиотеки. Прекрати уже заниматься дурью и либо собирай себе свежий софт в свежей системе, либо сиди на старой системе и старом софте.

Сделай её востребованной и майнтейнеры сами всё соберут.

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

Сложность установки в систему прикладного софта, над которым не корпели некие мейнтейнеры, - не фича, а недостаток

либо сиди на старой системе и старом софте.

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

У тебя шизофрения и вторая личность не может договориться с первой?

man software collections. Помимо gcc8 там и clang есть, и python27 и git новый. Шапка серьезно относится к поддержке своих ОС.

> У тебя шизофрения и вторая личность не может договориться с первой?

Привет. Это:

>> компилируй её не в самой последней системе

Не противоречит этому:

>> GCC 8 в репо есть, а в EPEL доступна хренова туча либ на все случаи жизни. Например самый новый Boost

Смотри. CentOS 6. Выпущена в 2010 году. Основная поддержка заканчивается в 2020, а расширенная - в 2023 (расширенная будет только у RHEL). Компилятор GCC 4.4. Но при этом в основном репо доступен GCC 4.8 из CentOS 7, как опциональный компилятор. А в стороннем репо «devtoolset» доступны и более новые, например GCC 8.

Вот эту софтину я собирал именно в старой системе с новым компилятором. Если выполнить strings на неё, и грепнуть gcc, отобразятся почему-то оба: и 4.4, и 8.

Преимущество такой сборки в том, что охватывается очень большой диапазон дистрибутивов Linux (хотя настолько старая билд-ферма чаще всего не рациональна - Ubuntu 12.04 хватит всем). Я не вижу ни одной причины считать неполноценной, например, Ubuntu 10.10 - более того, с новыми тенденциями она ещё и полноценней новых будет.

>> Часто для сборки требуется свежий cmake

> И свежие библиотеки.

EPEL

> Прекрати уже заниматься дурью и либо собирай себе свежий софт в свежей системе, либо сиди на старой системе и старом софте.

«Будь как все и не рыпайся. Кто ты такой вообще?». Не, новый софт в старой системе - это кайф. Доказано виндузятниками, 90% которых пользуется системой или 2001, или 2009 года.