Изучение графического программирования - это больше, чем просто изучение API. Речь идет об изучении, как работает графика. Преобразования вершин, модели освещения, методы теней, наложение текстур, отложенный рендеринг и так далее. Они абсолютно не связаны с API, который вы используете для их реализации.
Таким образом, вопрос заключается в следующем: вы хотите узнать, как использовать API? Или вы хотите изучать графику ?
Чтобы работать с графикой с аппаратным ускорением, вы должны научиться использовать API для доступа к этому оборудованию. Но как только вы получаете возможность взаимодействовать с системой, ваше обучение графике перестает фокусироваться на том, что API делает для вас, а вместо этого фокусируется на графических концепциях. Освещение, тени, рельефное отображение и т. Д.
Если ваша цель - изучить графические концепции, то время, которое вы тратите на API, - это время, которое вы не тратите на изучение графических концепций . Как скомпилировать шейдеры не имеет ничего общего с графикой. Также не известно, как отправлять им униформу, как загружать данные вершин в буферы и т. Д. Это инструменты и важные инструменты для работы с графикой.
Но на самом деле они не являются графическими концепциями. Они являются средством для достижения цели.
Это займет много работы и обучения с Vulkan, прежде чем вы сможете достичь точки, где вы готовы начать изучение графических концепций. Передача данных в шейдеры требует явного управления памятью и явной синхронизации доступа. И так далее.
В отличие от этого, достижение OpenGL требует меньше усилий. И да, я говорю о современном шейдерном профиле ядра OpenGL.
Просто сравните, что нужно сделать, чтобы сделать что-то простое, как очистка экрана. В Vulkan это требует, по крайней мере, некоторого понимания большого количества понятий: буферов команд, очередей устройств, объектов памяти, изображений и различных конструкций WSI.
В OpenGL ... это три функции: glClearColor, glClear, и для конкретной платформы замены буферов вызова. Если вы используете более современный OpenGL, вы можете уменьшить его до двух: glClearBufferuivи поменять местами буферы. Вам не нужно знать, что такое фреймбуфер или откуда происходит его изображение. Вы очищаете это и меняете буфер.
Поскольку OpenGL многое скрывает от вас, вам нужно гораздо меньше усилий, чтобы добраться до точки, где вы фактически изучаете графику, а не изучать интерфейс с графическим оборудованием.
Кроме того, OpenGL является (относительно) безопасным API. Обычно выдает ошибки, когда вы делаете что-то не так. Вулкан нет. Хотя существуют слои отладки, которые вы можете использовать, чтобы помочь, ядро Vulkan API почти ничего не скажет, если не возникнет аппаратная ошибка. Если вы делаете что-то не так, вы можете получить мусор рендеринга или сбой графического процессора.
В сочетании со сложностью Vulkan становится очень легко случайно сделать что-то не так. Забыть правильную разметку текстуры можно в одной реализации, но не в другой. Забывание точки синхронизации может иногда работать, но затем внезапно завершается неудачей, казалось бы, без причины. И так далее.
Все это, как говорится, это больше для изучения графики, чем изучение графических методов. В частности, есть одна область, где Вулкан побеждает.
Графическое исполнение .
Чтобы быть программистом в области 3D-графики, обычно требуется некоторое представление о том, как оптимизировать ваш код. И именно здесь OpenGL скрывает информацию и делает что-то за вашей спиной.
Модель памяти OpenGL является синхронной. Реализация может выдавать команды асинхронно, пока пользователь не может определить разницу. Поэтому, если вы визуализируете какое-либо изображение, а затем попытаетесь прочитать его, реализация должна выдать явное событие синхронизации между этими двумя задачами.
Но чтобы достичь производительности в OpenGL, вы должны знать, что реализации делают это, чтобы избежать этого . Вы должны понять, где реализация тайно генерирует события синхронизации, а затем переписать свой код, чтобы избежать их в максимально возможной степени. Но сам API не делает это очевидным; Вы должны получить эти знания откуда-то.
С Vulkan ... вы тот, кто должен выпустить эти события синхронизации. Следовательно, вы должны знать, что оборудование не выполняет команды синхронно. Вы должны знать, когда вам нужно выпустить эти события, и поэтому вы должны знать, что они, вероятно, замедлят вашу программу. Поэтому вы делаете все возможное, чтобы избежать их.
Явный API, такой как Vulkan, заставляет вас принимать решения о производительности. И поэтому, если вы изучите API Vulkan, у вас уже есть хорошее представление о том, что будет медленно, а что быстро.
Если вам нужно выполнить какую-то работу с кадровым буфером, которая вынуждает вас создать новый проход визуализации ... велика вероятность, что это будет медленнее, чем если бы вы могли разместить его в отдельном подпроходе прохода рендеринга. Это не значит, что вы не можете этого сделать, но API заранее предупреждает вас, что это может вызвать проблемы с производительностью.
В OpenGL API в основном приглашает вас произвольно менять вложения фреймбуфера. Нет никаких указаний на то, какие изменения будут быстрыми или медленными.
Так что в этом случае изучение Vulkan поможет вам лучше узнать, как сделать графику быстрее. И это, безусловно, поможет вам снизить нагрузку на процессор.
Это все еще займет гораздо больше времени, прежде чем вы сможете добраться до точки, где вы можете изучить методы графического рендеринга.