opengl vs vulcan что лучше

Vulkan vs OpenGL ES на Android: почувствуйте разницу

Один из ведущих мировых производителей мобильных ГПУ, Imagination Technologies (ее PowerVR используются во всех последних чипсетах Apple, которые отличаются завидной стабильностью в производительности), продемонстрировала возможности интерфейса программирования Vulkan. Напомним, что он был анонсирован год назад, а полгода назад разработавший его консорциум Khronos объявил о поддержке Vulkan мобильными устройствами. Вчера стало известно о планируемом включении поддержки Vulkan в будущие версии Android, но на самом деле, при помощи специальных драйверов, разработанные под этот API приложения могут работать и на нынешней прошивке.

В качестве испытательного полигона выступила телеприставка Nexus Player. Она как раз работает под управлением Android и оснащена процессором Intel Atom со встроенным ГПУ PowerVR G6430 (такой же в процессоре Apple A7 у iPhone 5S).

Как мы уже рассказывали, главным достоинством низкоуровнего API Vulkan является прямой доступ к аппаратным ресурсам процессора и, как следствие, возможность распределения нагрузки ЦПУ между несколько его ядрами и увеличения скорости обработки ими вызовов отрисовки. До сих пор преимущество такого подхода демонстрировались на настольных системах (см. результаты бенчмарков Star Swarm и 3DMark API Overhead) — давайте посмотрим на возможности мобильной версии Vulkan. Слева вы видите рендеринг в режиме реального времени специализированного бенчмарка Gnome Horde, написанного с использованием API Vulkan, а справа — с использованием OpenGL ES 3.0:

Как видите, по мере увеличения объектов в сцене (и соответственно вызовов отрисовки, выполняемых ЦПУ), возможности 4-ядерного Intel Atom раскрываются в полной мере — благодаря Vulkan он вполне успешно справляется с отрисовкой 400 тысяч маленьких гномов и других объектов за одну секунду (13,500 вызовов отрисовки в одном кадре, на скорости 30 к/с).

Напомним, что в свое время низкоуровневую API Metal для своей мобильной операционной системы iOS (а позднее и для десктопной Mac OS X) представила Apple, тогда как Microsoft готовится к релизу мобильной версии Windows 10 (с поддержкой низкоуровнего API DirectX 12). Таким образом, все три основные мобильные платформы, Android, iOS и Windows, почти одновременно вступают в соперничество между поддерживаемыми ими низкоуровневыми API, позволяющими добиться более реалистичной графики в мобильных приложениях.

Насколько значительным будет прогресс непосредственно в играх предсказать сложно: пока результаты комплексных графических тестов (как десктопных, которые мы упоминали выше, так и мобильного GFXBench 3.0 Metal) существенно уступают специализированным. В конечном счете все будет зависеть от того, как много объектов (например, в виде разлетающихся при взрыве осколков) задействовано в игровой сцене. Можно предположить, что наиболее ощутимой разница будет в стратегиях вроде Total War: Attila, где на полях сражений самостоятельно (но под вашим чутким руководством) сражаются тысячи воинов.

Источник

Opengl 4.* или vulkan?

Это вообще разные вещи.
Нужно отличать изучение API, от изучения технологии. Если вы хотите выучить просто API, учите что угодно, ибо разницу заметите только, когда поймёте основы, базу.

OpenGL проектировался когда были другие архитектуры железа. Мультипроцессорность была только в теории, и считалась уделом суперкомпьютеров и ненужной для пользовательских ПК.
Можно привести аналогию: OpenGL == C++, Vulkan == асинхронный Assembler + hardware threads. Например, в C++ сейчас довольно много архитектурных косяков, которые пытаются решить новыми стандартами, объявляют какие вещи устаревшими, потому что они концептуально неверны и не подходят под современные реалии.
Но, при этом, вы можете всё то же самое написать на ассемблере, но нужно намного лучше понимать, как работает процессор и ОС, самому писать примитивы синхронизации, и т. п.

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

В итоге, я бы ответил так:

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

Если же вы пишете простые прикладные вещи, которым нужно показать какую-то графику, то учите OpenGL. Здесь вы учите только API, соглашаясь с уже готовым, слегка устаревшим, архитектурным дизайном.

Если хотите писать игры не мирового класса, то учите готовые движки, Unity или Unreal. Они уже поддерживают за вас Vulkan, продумали за вас API и архитектуру.

Источник

OpenGL vs Vulkan

Difference Between OpenGL vs Vulkan

The following article provides an outline for OpenGL vs Vulkan. OpenGL is a cross-platform API where API refers as application programming interface and focus on rendering of 2D as well as 3D vector graphics with effective result. For accelerated hardware rendering it interact with graphics processing unit (GPU). The plus point about this is it an open source and free API. Vulkan is also cross platform software which works as 3d graphics as well as computing software not only this but it also deals with programming of video games and multimedia elements. Both software has also most same work even though they are different from each other. Today in this article we will find out what are those things which make this two software different from each other although their developer is same.

Head to Head Comparison Between OpenGL vs Vulkan (Infographics)

Below are the top 6 differences between OpenGL vs Vulkan:

3D animation, modelling, simulation, game development & others

Key Difference Between OpenGL vs Vulkan

Let us discuss some of the major key differences between OpenGL vs Vulkan:

OpenGL vs Vulkan Comparison Table

Let’s discuss the top comparison between OpenGL vs Vulkan:

The points which we seen above are most important points because it gives basic requirement, capability, needs as well as working ability of both software and helps us for taking decision about which one will be good for us.

Conclusion

OpenGL and Vulkan are familiar word for you and you can easily understand them for exploring your idea in field related to this software. Will suggest you if you start working in this field with these API then you must try both of them one by one so that you can find pros and cons of these software itself.

Recommended Articles

This is a guide to OpenGL vs Vulkan. Here we discuss OpenGL vs Vulkan key differences with infographics and comparison table respectively. You may also have a look at the following articles to learn more –

Источник

Маленькая статья про Vulkan

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

Command Buffers

Самое главное отличие Vulkan от OpenGL — явная асинхронность работы с GPU. Если в OpenGL драйвер сам решал, когда начинать нагружать видеокарту, то здесь это делает явно само приложение. Когда вы хотите нарисовать треугольник, запустить вычислительный шейдер, скопировать данные в память устройства вам нужно записать command buffer и отправить его в очередь на исполнение. Командные буферы можно использовать повторно, запускать из них вторичные буферы, собирать в цепочки с помощью семафоров. Тут есть достаточно широкий простор для оптимизации рендера.

Graphics Pipeline

Графический конвейер — центральная часть 3D API. Сама структура конвейера не изменилась — те же шейдерные стадии, тесты глубины, параметры блендинга и так далее. Но если в OpenGL параметры пайплайна — глобальная машина состояний, которую нужно настраивать под каждый вызов отрисовки, то в Vulkan он выделен в отдельный объект. Сначала вы создаёте pipeline-объекты, а потом в буфере команд просто устанавливаете нужный, подключаете descriptor sets с ресурсами (UBO, SSBO, текстурами, семплерами), атрибуты вершин и рисуете. Основная задача такого подхода — локализовать очень затратную операцию создания пайплайна на стадии инициализации, и в дальнейшем быстро переключаться между готовыми к применению наборами параметров. Это намного эффективнее ситуации в OpenGL, когда драйвер каждый кадр вынужден много раз проверять корректность запросов приложения. Также в API есть возможность наследования и pipeline cache, которые позволяют ускорять создание конвейера за счет переиспользования уже имеющихся или сохранённых в предыдущей сессии пайплайнов.

Renderpass

В Vulkan есть еще один связанный с графикой объект, о котором нужно упомянуть, и который отличает его от других nextgen API — это renderpass. Изначально он был добавлен для облегчения жизни на мобильных тайловых GPU, в которых для всех draw call-ов сначала отрабатывает вершинная часть конвейера, а затем для каждого тайла фреймбуфера фрагментный конвейер для полигонов, попавших в тайл. Рендерпасс позволяет явно группировать вызовы отрисовки, которые должны обрабатываться вместе, в отдельные сабпассы. Это не актуально на десктопном железе, но, как пишут AMD, с помощью renderpass здесь тоже можно применить некоторые оптимизации. Кроме этого рендерпассы выполняют еще несколько полезных функций — управление текстурами фреймбуфера (очистка, смена image layout), синхронизация сабпассов, резолв мультисемплинга.

Синхронизация

В силу асинхронной природы работы GPU в Vulkan не гарантируется последовательное выполнение даже для команд в одном буфере, не говоря уже о разных буферах и разных очередях, поэтому все зависимости должны указываться приложением явно. Кроме прописывания зависимостей в рендерпассе есть еще четыре механизма синхронизации – semaphore, fence, event, pipeline barrier. Семафоры — самый часто используемый механизм. Сигнализируют о том, что буфер команд завершил работу и разрешают следующему буферу продолжить выполнение. Для уведомления программы о том же событии используются fences. Events — тонкий инструмент для синхронизации конкретного места в command buffer. Могут и ожидаться и устанавливаться/сбрасываться как в буфере, так и на хосте. Барьер синхронизирует последующие команды буфера с предыдущими.

Управление памятью

Тема, которая многих пугает — ручное управление памятью на устройстве. В Vulkan вы сначала создаёте буфер или текстуру, а потом назначаете для них область памяти с параметрами размера и выравнивания, получеными из функции
vkGetBufferMemoryRequirements или
vkGetImageMemoryRequirements.

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

Это все основные моменты. Что-то осталось за кадром (вроде устройств, очередей, слоёв, расширений, многопоточности, SPIR-V шейдеров), но это сервисные вещи, о которых можно почитать в туториалах.

Заключение

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

Куда копать дальше.

Vulkan API «Hello Triangle»
Следующая статья об основах использования Vulkan на примере создания простого приложения.

LunarG Vulkan SDK
Маст хев для разработки, в комплекте неплохие примеры кода на каждую фичу.

Источник

Должны ли новые графические программисты изучать Vulkan вместо OpenGL?

Из вики : «Vulkan API изначально упоминался как« инициатива OpenGL следующего поколения »от Khrono», и что это « основополагающая попытка редизайна объединить OpenGL и OpenGL ES в один общий API, который не будет обратным» совместим с существующими версиями OpenGL «.

Так стоит ли лучше изучать Vulkan вместо OpenGL тем, кто сейчас занимается графическим программированием? Кажется, они будут служить той же цели.

Это похоже на вопрос «Должны ли новые программисты изучать C ++ вместо C» или «Должны ли новые художники изучать цифровую живопись вместо физической».

Тем более, что графические программисты НЕ имеют обратной совместимости, было бы глупо исключать самый распространенный графический API в отрасли просто потому, что есть новый. Кроме того, OpenGL делает разные вещи по-разному. Вполне возможно, что компания выберет OpenGL вместо Vulkan, особенно в начале игры, и эта компания не будет заинтересована в том, кто не знает OpenGL, независимо от того, знают ли они Vulkan или нет.

Специализация редко является рыночным навыком.

Для тех, кому не нужно продавать свои навыки как таковые, например, для независимых разработчиков, было бы еще более глупо удалять инструмент из их набора инструментов. Инди-разработчик еще больше зависит от гибкости и способности выбирать то, что работает, а не то, что финансируется. Специализируясь на Vulkan только ограничивает ваши возможности.

Специализация редко является эффективной парадигмой.

Если вы только начинаете и хотите работать с графическим процессором (в отличие от постоянного использования игрового движка, такого как Unity), вам определенно стоит начать изучать Vulkan. Возможно, вам стоит изучить GL и позже, но есть несколько причин, чтобы подумать о Вулкане.

Гораздо проще перейти с Vulkan на GL или GLES, чем наоборот. Vulkan делает явным много вещей, которые были скрыты или непредсказуемы в GL, такие как управление параллелизмом, совместное использование и состояние рендеринга. Он продвигает большую сложность от драйвера к приложению, но, делая это, он дает управление приложению и упрощает получение предсказуемой производительности и совместимости между различными поставщиками графических процессоров. Если у вас есть какой-то код, который работает в Vulkan, его довольно просто перенести на GL или GLES, и вы получите что-то, что использует хорошие привычки GL / GLES. Если у вас есть код, который работает в GL или GLES, вам почти придется начинать заново, чтобы заставить его работать эффективно в Vulkan: особенно если он был написан в устаревшем стиле (см. Пункт 1).

Сначала я был обеспокоен тем, что с Vulkan гораздо сложнее программировать, и хотя опытным разработчикам в крупных компаниях это будет хорошо, это будет огромным барьером для инди-любителей и любителей. Я задал этот вопрос некоторым членам Рабочей группы, и они сказали, что у них есть некоторые данные от людей, с которыми они говорили, которые уже переехали в Вулкан. Эти люди варьируются от разработчиков в Epic, работающих над интеграцией UE4, до разработчиков игр-любителей. Их опыт заключался в том, что для начала работы (то есть, чтобы иметь один треугольник на экране) потребовалось изучить больше концепций и иметь более длинный шаблонный код, но это не было слишком сложно, даже для инди. Но после того, как они достигли этой стадии, они обнаружили, что гораздо проще создать реальное приложение для отправки, потому что (а) поведение намного более предсказуемо между реализациями разных производителей, и (б) получение чего-то, что хорошо работало со всеми включенными эффектами, не включало столько проб и ошибок. Благодаря опыту настоящих разработчиков они убедили меня в том, что программирование на Vulkan жизнеспособно даже для начинающего пользователя графики, и что общая сложность уменьшается, если вы пройдете обучение и начнете создавать демонстрации или приложения, которые вы можете дать другим людям.

Конечно, есть еще один вариант. Я не знаю, относится ли это, в частности, к вам, но я все равно должен сказать это для других посетителей.

Чтобы быть разработчиком инди-игр, гейм-дизайнером или виртуальным опытом, вам не нужно изучать Vulkan или GL. Многие люди начинают работать с игровым движком (сейчас популярны Unity или UE4). Использование такого движка позволит вам сосредоточиться на опыте, который вы хотите создать, а не на технологии, стоящей за ним. Это скроет различия между GL и Vulkan от вас, и вам не нужно беспокоиться о том, что поддерживается на вашей платформе. Это позволит вам узнать о трехмерных координатах, преобразованиях, освещении и анимации, не имея дело со всеми мелкими деталями сразу. Некоторые игровые или виртуальные студии работают только в движке, и у них вообще нет штатного эксперта по GL. Даже в больших студиях, которые пишут свои собственные движки, люди, которые занимаются графическим программированием, составляют меньшинство,

Изучение деталей взаимодействия с графическим процессором, безусловно, является полезным навыком, который оценят многие работодатели, но вы не должны чувствовать, что должны изучать его, чтобы войти в 3D-программирование; и даже если вы это знаете, это не обязательно будет чем-то, что вы используете каждый день.

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

Но на самом деле они не являются графическими концепциями. Они являются средством для достижения цели.

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

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

Просто сравните, что нужно сделать, чтобы сделать что-то простое, как очистка экрана. В Vulkan это требует, по крайней мере, некоторого понимания большого количества понятий: буферов команд, очередей устройств, объектов памяти, изображений и различных конструкций WSI.

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

Кроме того, OpenGL является (относительно) безопасным API. Обычно выдает ошибки, когда вы делаете что-то не так. Вулкан нет. Хотя существуют слои отладки, которые вы можете использовать, чтобы помочь, ядро ​​Vulkan API почти ничего не скажет, если не возникнет аппаратная ошибка. Если вы делаете что-то не так, вы можете получить мусор рендеринга или сбой графического процессора.

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

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

Чтобы быть программистом в области 3D-графики, обычно требуется некоторое представление о том, как оптимизировать ваш код. И именно здесь OpenGL скрывает информацию и делает что-то за вашей спиной.

Модель памяти OpenGL является синхронной. Реализация может выдавать команды асинхронно, пока пользователь не может определить разницу. Поэтому, если вы визуализируете какое-либо изображение, а затем попытаетесь прочитать его, реализация должна выдать явное событие синхронизации между этими двумя задачами.

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

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

Так что в этом случае изучение Vulkan поможет вам лучше узнать, как сделать графику быстрее. И это, безусловно, поможет вам снизить нагрузку на процессор.

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

Основная привлекательность OpenGL (по крайней мере для меня) заключается в том, что он работает на многих платформах. В настоящее время Vulkan не работает на OSX, и у Apple есть конкурирующий API под названием Metal. Вполне возможно, что пройдет некоторое время, прежде чем Apple поддержит Vulkan, и когда они это сделают, поддержка Vulkan может появиться только на их новейшем оборудовании. OpenGL уже поддерживает большинство аппаратных средств и будет продолжать это делать.

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

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

Vulkan ближе к аппаратному обеспечению, потому что OpenGL делает много вещей под капотом, что в Vulkan вы делаете вручную, например выполнение очереди команд. Также управление памятью зависит от приложения, а не от драйвера. Вам нужно беспокоиться о выделении памяти uniforms (переменная, которую вы передаете из CPU в GPU), об отслеживании их. У вас есть больше поводов для беспокойства, но это также дает больше свободы при использовании памяти. Это может звучать страшно и подавляюще, но на самом деле это не так. Это только следующий API, который вы должны изучить.

Понимание этого также поможет понять, как работает GPU. Что позволит вам провести некоторую оптимизацию как на Vulkan, так и на OpenGL.

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

Я уже давно занимаюсь графическим программированием уже несколько месяцев.

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

При этом, хотя я в основном работаю с OpenGL, я понимаю основные принципы DirectX и Vulkan. Хотя я не очень много с ними работаю, особенно с Vulkan, так как его очень трудно освоить и он не так хорошо структурирован для программирования, как OpenGl и DirectX.

Наконец, я хотел бы добавить, что специализация на одной области, такой как я в основном использую Java и OpenGL, не является удивительно привлекательной на рынке. Если бы я хотел устроиться на работу в компанию, производящую игры, то по большей части OpenGL использовался бы только для разработки игр для Linux и Android, а также для OSX. DirectX для Windows и консолей, — Зимний Робертс
источник

Я хотел бы дать вам мой взгляд начинающего графика на эту тему. Что я понял (много лет работая инженером в другой области), так это то, что фундаментальные понятия являются наиболее важной частью. Когда у вас есть четкое представление о них, изучение последнего блестящего нового API является наименее сложной частью. Я не знаю, являетесь ли вы молодым хобби, пытающимся запрограммировать новый Skyrim или ищете работу в области компьютерной графики.

Я самоучка на C ++ без какого-либо формального образования, и в течение последних 15 лет я изучал OpenGL 1.0 через Modern OpenGL и DirectX 9c, 10 и 11. Я не попал в DirectX 12 и хотел попробуй свои силы в Вулкане. Я только закончил несколько основных уроков, чтобы нарисовать простой треугольник или простой вращающийся куб с помощью Vulkan. Как и в случае DirectX 11 и OpenGL 3.3+, я написал полностью работающие движки 3D-игр и даже использовал их для создания простых игр.

Я должен сказать, что это зависит от общей среды человека, который учится. Если вы только начинаете программировать в 3D-графике, я бы сказал, для начала, чтобы перейти к OpenGL или DirectX 11, так как существует множество учебных пособий, ресурсов, примеров и уже работающих приложений. Изучение 3D-графики никоим образом не является легким предметом.

Если мы абстрагируемся от этого аспекта программирования и сосредоточимся только на понятии, какие методы используются, включая различные уровни математики, ведущие к наборам данных, структурам данных и алгоритмам; Есть много вещей, которые вы должны знать и понимать в первую очередь, прежде чем вы сможете даже попытаться создать 3D игровой движок или эффективно использовать существующий.

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

Я упоминаю об этом, потому что, если вы не знаете, как правильно управлять своей памятью, потоками и временем доступа; Вулкан укусит тебя в задницу! Где OpenGL и DirectX будут держать вас всю руку, потребляя гораздо больше ресурсов процессора.

Итак, дело в том, что вы должны понимать все аспекты того, что нужно для создания игрового движка, чтобы заниматься продвинутым графическим программированием. Если вы делаете только 2D-графику, то жизнь не так уж сложна, как вы можете сделать это в Python без какого-либо из вышеупомянутых API! Но если вы хотите быть серьезным и разработать полноценный мощный движок Game Engine, который будет иметь множество наборов функций, тогда вам следует выбрать C или C ++ и использовать OpenGL, Direct X или Vulkan. Любой из них был бы просто в порядке. Теперь, если вы собираете движок с нуля и ищете наиболее «эффективный» работающий движок с наименьшими затратами ресурсов, вам следует выбрать Vulkan. Но если вы пойдете по этому пути, вы должны хотя бы знать все, что я упомянул выше, и некоторые!

Итак, как вы можете видеть, Vulkan на самом деле не ориентирован на начинающих программистов в этой области. Вы должны обладать обширными знаниями по всей математике, парадигмам программирования, всем различным наборам данных и алгоритмам, включая многопоточность, синхронизацию памяти, параллельное программирование. И даже в этом случае приложение просто загружает простой 2D-треугольник на экран. То, что можно сделать с помощью примерно 100 строк кода в OpenGL или 250 строк кода в DirectX, занимает почти 1000 строк кода в Vulkan!

Vulkan оставляет все на ваше усмотрение, поскольку вы несете ответственность за все аспекты использования Vulkan в своем приложении. Там нет руки, которая мешает вам, она позволит вам застрелиться в ноге или повесится, купите рекурсивную петлю!

Нельзя сказать, что новички или новички в этой области не должны изучать Vulkan, но я бы посоветовал им следующее: во-первых, изучите достаточно OpenGL и DirectX, чтобы вымокли, чтобы понять, как Основное приложение структурировано только для рендеринга простого треугольника или вращающегося куба. Познакомьтесь с их API и повторяющимися шаблонами их структур. Узнав, что вы можете изучать Vulkan на параллельной стороне, таким образом, вы можете увидеть, как каждый из трех выполняет одну и ту же задачу, но знать, как они делают это по-разному, тогда вы также можете сравнить результаты между различными API и из там вы можете сделать выбор, который предпочтительнее для вас. Этот метод также даст вам еще один инструмент в вашем наборе инструментов, и вы даже можете написать свое приложение для поддержки всех 3 и иметь «

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

Источник