Про графические API

learnopengl.com

Не, прослоек у Вулкана как раз таки меньше. То что сейчас через Вулкан делает клиентский код, в OpenGL за него делал за кулисами драйвер. Например, управлял всякими синхронизациями, аллокациями GPU памяти и т. д.

Официальная документация? А вообще, изучаю вот это. Это как раз перевод вышеназванного https://learnopengl.com

С одной стороны это конечно хорошо, всё таки низкоуровневый доступ. А с другой стороны, вспоминаем сишку, на которой написание безопасного считывания текста с клавиатуры требует нетривиальных знаний языка. А под прослойками имелись в виду обёртки над API.

OpenGL был очень толстой прослойкой в драйвере (над конкретной реализацией в кремнии). Vulkan тонкая прослойка в драйвере, а дальше ты уже сам решаешь какой толщины и какую прослойку использовать в своём приложении (можно очень толстую в виде готового движка, можно умеренной толщины в виде какого-нибудь WebGPU, можно юзать голый Vulkan).

Проблемы у OpenGL две:

- Прослойка толстая, а производителей GPU много (не забывай, что помимо десктопов есть ещё мобилки), а ещё у каждого производителя много разных моделей GPU (и у них бывают очень разные архитектуры). А чем толще прослойка, тем больше человекочасов на неё нужно. Соответственно, каждый драйвер реализовывал OpenGL со своими багами и фичами и создавал большую головную боль авторам приложений когда они выходили за рамки базового «нарисовать цветной треугольник». С Vulkan есть надежда, что из-за уменьшенной толщины прослойки драйвера будут содержать меньше багов и отклонений от стандарта, а разработчики смогут вложить больше человекочасов в driver-agnostic движки. Ну и так или иначе баг в движке проще поправить, чем баг в драйвере, потому что исходники движка часто доступны (даже если по EULA), а исходники драйвера почти никогда.

- У OpenGL много legacy решений из эпохи Fixed Function Pipeline и одноядерных CPU.

Возможно, Vulkan слишком тонкая прослойка, об этом до сих пор ведуться дебаты и его конкуренты всё же более высокоуровневые (что как бы намекает). Но OpenGL был точно слишком толстой прослойкой, которая не отражала ни современные архитектуры GPU, ни современные потребности разработчиков.

исходники драйвера почти никогда

Mesa же, по сути основной драйвер для нас. AMDGPU тоже открытый.

Ну и немного не по теме, но почему нет вулкана для старых GPU? Хотя бы в составе той же месы. По идее, раз он является тонкой прослойкой, то написать вулканодрайвер не сложно. Мне почему-то кажется, что железо, которое в состоянии запускать OpenGL 4.5, вполне может работать и с вулканом.

Помимо Intel/AMD на Mesa есть ещё Nvidia.

Также помимо Linux есть ещё Windows и Mac OS X, где Mesa нету. При этом Windows доминирует в гейминге.

Наконец, на мобилках (Android) Mesa или что-то проприретарное?

Vulkan родился именно как попытка причесать драйвера под все ОС и вендров.

И где искать?

https://github.com/OpenXRay/xray-16 и тыщщи других форков.

как пользователю мне глубоко плевать на внутренние детали

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

Определись.

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

Также помимо Linux есть ещё Windows и Mac OS X, где Mesa нету. При этом Windows доминирует в гейминге.

Насколько я знаю, AMD на Windows за основу использует тоже AMDGPU, только конкретная реализация всё-таки закрыта. А на андройдах вообще не пойми что, там лютая смесь блобов и открытого кода.

С развитием GPGPU всё меньше поведения видюшки «зашивается» в микрокод / прошивку. Соответственно всё больше программируемых стадий. Всё больше возможностей запрограммировать рендеринг так, как ты этого хочешь. Так что тут не то чтобы низкоуровневость — OpenGL ведь тоже не модельками оперировал, а всё теми же буфферами, текстурами и шейдерами.. скорее больше всего стало можно (и нужно) кастомизировать.

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

Наконец, на мобилках (Android) Mesa или что-то проприретарное?

OpenGL ES 3.0

Это API доступный пользователю, вопрос что там под капотом. А под капотом там толстая проприретарная прослойка конкретного вендора под конкретный чип. Скорее всего с багами и UB.

Также помимо Linux есть ещё Windows и Mac OS X, где Mesa нету. При этом Windows доминирует в гейминге.

Лично не пробовал, но MESA должна быть и там, и там.

думал может че поприкольнее было

Title: 3D Graphics Rendering Cookbook: A comprehensive guide to exploring rendering algorithms in modern OpenGL and Vulkan
Author(s): Sergey Kosarevsky, Viktor Latypov
Publisher: Packt Publishing
Year: 2021
ISBN: 1838986197; 9781838986193

Сишку хорошо знаешь?

Опыт нулевой можно сказать, но основы знаю(синтаксис, стандартные функции, частично API POSIX), если надо будет что-то написать буду разбираться по ходу.

Потому что прикладное ПО идет в сторону скорости разработки, а графические API в сторону скорости выполнения.

Именно этим вопросом я и задавался. Чем можно объяснить сей парадокс? Лично я не имею ничего против вулкана(да и против OpenGL тоже), зато терпеть не могу программы на электронах и жабах. Почему весь мир катится в сраное говно, и только графика идет в правильном направлении?

Ну и немного не по теме, но почему нет вулкана для старых GPU?

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6747

=== Alex Deucher has a 2 year old post listing the hard blockers at https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1195087-radeon-r600-gallium3d-nir-backend-continues-advancing?p=1195638#post1195638 21 July 2020, 09:52 PM There are 3 major challenges to supporting vulkan on pre-GCN hardware:

Lack of virtual memory support Lack of memory based resource descriptors Lack of asynchronous compute queues

===

3 years later …

Well, holy crap, this was unexpected https://gitlab.freedesktop.org/Triang3l/mesa/-/tree/Terakan

Но конкретно эта реализация может даже до vulkan 1.0 не дойти ..

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

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

Ты с тостера пишешь? Буквально вчера играл в HiFi Rush (он на анриле) на стим деке - всё ок. Раньше кота играл ещё - всё ок.

OpenGL усложнялся, а Vulkan стал ещё более низкоуровневым, чем OpenGL 4.*.

Потому что это core.

Ну банально. Облегчение труда разраба требует инвестиций, которые могут не отбиться и... зафиксируют выбор возможностей, т.е. ограничат возможности развития API: делая выбор, проектировщик все время отсекает другие возможности. Пример из «несвязанной» области (но связанной по проектированию API, только более простого): были раньше (где-то примерно в 10-х) в моде «humanfriendly» API обмена данными для распределенных сервисов на XML и JSON с авторазбором в DOM и объекты(ORM, сериализация-десериализация), которые подавались как «более лудшая» альтернатива «ужасной» бинарной СORBA... Это все в итоге оказалось небыстро, нефрендли и переусложнено (многие из-за этого бросали изучать XML где-то на неймспейсах, XPATH и XSLT («циклы for в разметке? ЧЗХ...»). Генереный роботами JSON тоже оказался нисколько не читабельнее генереного роботами XML. Поэтому история сделала круг через rest к гуглобуферам — и вернулись к бинарным форматам, а API текстовых парсеров упростили до функций, возвращающих следующий токен, с маркетингом «зато быстро!» В развитии графических API происходит такая же «спиральная диалектика». От недружелюбных буферов с арифметикой указателей и прерываниями к «дружелюбным» фиксированным API, от фиксированных API к шейдерам с буферами за «семантику» которых отвечает программист и далее к «кроссAPIйности» вулканиума + «ситуация, есть N конкурирующих стандартов... Это плохо. Нужно взять все лучше... Ситуация, есть N+1 конкурирующий стандарт».

Ты с тостера пишешь?

Ну не совсем тостер, но железо не самое свежее. А вся мякотка в том, что старые игры, например GTA V работают хорошо, а игры на анриале тормозят. В плане визуала особо улучшений нет, а системные требования выше. Зачем мне новое железо под игры, которые не улучшились? Железо имеет смысл брать под софт только тогда, когда этот софт реально нужен. Я в игры особо не играю, в апгрейде нет смысла. Ну и тем более старые игры работают отлично.

А после вулкана по такой логике снова переизобретут OpenGL 1.0?

«Более лудшэе API» вечно 1.0. Потом по граблям, по которым уже ходили, только на стероидах.

Я про нормальные приложения, а не это вот всё :) Там кресты и сисярп.

нормальные

Нормой считается то, что в преимущественном большинстве.

Так вот веб - это норма. А кресты и сисярп - нет.

Так вот веб - это норма. А кресты и сисярп - нет.

У программистов C++ ответ vs.

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

Если хочется удобно, нужно брать что-то построенное поверх vulkan/opengl: движок, или специализированную библиотеку, или даже реализацию старого opengl.