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 и архитектуру.
Сравнительный тест DirectX 11, OpenGL и Vulkan
На минувшей неделе был представлен API Vulkan, о широкой поддержке которого заявили AMD и NVIDIA. Новый графический интерфейс разрабатывал Khronos Group, консорциум, основанный в 2000 году. Khronos Group отвечает за разработку и поддержку открытых стандартов в сфере мультимедийных приложений на разных платформах и устройствах. Консорциум поддерживают AMD и NVIDIA, а также многие другие компании.
На минувшей неделе была ратифицирована финальная версия 1.0 API Vulkan. AMD и NVIDIA представили соответствующие бета-драйверы. AMD заранее выпустила бета-версию Radeon Software еще 14 февраля. NVIDIA представила драйвер GeForce 356.39, который тоже ориентирован на поддержку API Vulkan.
Подход API Vulkan очень похож на API Mantle. Суть заключается в том, чтобы разработчики получили более глубокий доступ к «железу», чтобы выжать из него максимум. Такой подход позволяет максимально избежать существующих «узких мест». С другой стороны, разработчики должны точно знать, что они делают – например, при работе с памятью. Интерфейс OpenGL не так популярен, как DirectX, но позволяет выжать больше.
Интерфейс API Vulkan в версии 1.0 поддерживается под Windows 7, Windows 8.1, Windows 10, Android и Linux. Разработчики игр пока что не объявили о поддержки в конкретных играх, но здесь стоит дождаться Games Developer Conference, которая будет проводиться с 14 по 18 марта в Сан-Франциско. Из игровых движков пока есть информация о Source 2, который уже поддерживает API Vulkan. Процесс отладки облегчается поддержкой Valve, LunarG и Codeplay.
The Talos Principle
Хорошо, но какая игра или движок поддерживают API Vulkan? Игра The Talos Principle разрабатывалась компанией Croteam, которая и в прошлом была известна поддержкой многих графических API. И в последней итерации игра The Talos Principle не стала исключением – она поддерживает DirectX 9, DirectX 11, OpenGL и теперь Vulkan. Для студии разработчиков Vulkan является пробным шаром, хотя API Vulkan доступен в версии 1.0, поддержка пока находится в бета-стадии. На добавление поддержки разработчики Croteam затратили порядка трех месяцев. Но универсальный характер API позволяет вскоре представить вариант Linux.
API Vulkan теоретически совместим с несколькими платформами – но пока что тесты и сравнения можно провести только под Windows, причем здесь имеются свои ограничения. Реализация пока остается на очень раннем этапе. Путь рендеринга DirectX 11 совершенствовался многие годы, поэтому потенциала для оптимизации здесь уже нет. Здесь ситуация больше зависит от разработчиков драйверов, а именно AMD и NVIDIA. Игра The Talos Principle стала первой с поддержкой Vulkan. Поэтому пока нет возможности сделать сравнительный тест для оценки хорошей или плохой реализации поддержки.
Новые технологии первое время реализуются в примерах, подготовленных производителями. В случае DirectX 12 акцент был выставлен на Draw Calls, тот же тест 3DMark DirectX 12 опирается только на измерение производительности Draw Calls, игры DirectX 12, подобные Star Wars, тоже пытаются задействовать подобную нагрузку. Но The Talos Principle не так сильно зависит от высокой скорости Draw Call, чтобы низкоуровневый API дал большую разницу.
Поддержка API Vulkan версии 1.0 находится на ранней стадии, то же самое касается драйверов AMD и NVIDIA. Оба драйвера, по сути, относятся к бета-версиям, именно так их рассматривают производители GPU. Здесь обычно нет новых улучшений производительности или поддержки новых технологий, так что мы получаем шаг назад. Но как только определенный уровень разработки будет достигнут, драйверы обоих разработчиков GPU получат поддержку Vulkan в финальной версии. Когда это произойдет – не совсем понятно. Но пока ключевые приложения не используют Vulkan и игры с поддержкой API находятся в состоянии бета-версии, так что разработчики GPU могут спокойно дорабатывать свои драйверы.
Для тестов мы взяли нашу тестовую систему для видеокарт. Драйверы видеокарт AMD и NVIDIA мы уже описали выше. В настройках мы выставили максимальный уровень графики, но при этом протестировали и низкие разрешения вплоть до 1.280 x 720 пикселей, чтобы увеличить производительность Draw Call.
Как можно видеть по результатам, API Vulkan дает существенный прирост по сравнению с OpenGL. Но до производительности DirectX 11 новый API не дотягивает. Тому есть несколько причин. С одной стороны, разработка под Vulkan находится в ранней стадии. Это касается и самого API, и драйвера, и игры The Talos Principle. По сравнению с OpenGL новый интерфейс позволяет освободить часть ресурсов и избежать «узких мест». Но DirectX много лет совершенствовался до текущего уровня. В любом случае, потенциал у API Vulkan очень хороший.
Если погрузиться в детали, то визуальных отличий между API Vulkan и DirectX 11 мы не обнаружили. Так что путь рендеринга очень хорошо адаптирован. У текущей реализации The Talos Principle видеокарты с 2 Гбайт памяти получают падение производительности, вероятно, из-за не самой эффективной работы с памятью. Как и Mantle и DirectX 12, API Vulkan может обращаться к ресурсам памяти на более глубоком уровне – сей факт можно рассматривать как преимущество, но он может стать и недостатком, если разработчики не смогут эффективно использовать память.
Несколько разочаровала ошибка в текущем драйвере NVIDIA, из-за которой после каждого теста приходилось перезагружать систему. Без перезагрузки игра «вылетала». Хотя с драйвером AMD мы не обнаруживали подобной ошибки.
Нынешняя реализация API Vulkan кажется обещающей. Пока что для игр на настольных ПК она будет не такой актуальной, поскольку рынок DirectX 11 и 12 очень велик, и по сравнению с тем же DirectX 12 затраты на реализацию могут быть слишком велики, а отдача слишком мала. Но если игры необходимо запускать на разных платформах с разными аппаратными требованиями, Vulkan может сыграть важную роль. В любом случае, следует дождаться реакции со стороны разработчиков игр, иначе мы получаем проблему курицы и яйца, из которой сложно выйти.
Графический api vulkan или opengl pubg mobile что лучше
Консорциум Khronos Group, в котором состоят AMD, Intel и NVIDIA, объявил преемника API OpenGL под названием «Vulkan». Ранее новый API был известен под названием GLnext. Возможно, данное название было дано в честь API Mantle, под который сегодня как раз вышел OpenSDK. Основная цель Vulkan, как и в случае API Mantle и DirectX12, заключалась в уменьшении избыточной вычислительной нагрузки, что позволило бы выполнять больше операций Draw Call.
Vulkan уменьшает нагрузку на CPU путём организации операций Draw Call в партии (batches), которые эффективнее обрабатываются видеокартой, чем операции по отдельности. Разработчики обещают даже большее число операций Draw Call, чем у сравнимых API, таких как OpenGL или DirectX 11. Кроме того, Vulkan больше не будет, подобно OpenGL, разделяться на два API для настольных ПК и смартфонов, всё будет объединено в одном API. Так что мы получаем действительно кросс-платформенный и универсальный интерфейс, в отличие от DirectX, Mantle или Apple Metal.
В принципе, Vulkan можно понимать практически как ответвление интерфейса Mantle. В любом случае, значительная часть кода была взята у AMD, поэтому вполне логично, что калифорнийский разработчик больше не занимается активной разработкой Mantle 1.0. Но AMD может вернуться к Mantle, если инновации будут внедряться недостаточно быстро.
В целом, Vulkan можно назвать серьёзным конкурентом Microsoft DirectX 12. Будет интересно посмотреть на расстановку сил. Появится ли однозначный лидер рынка на сегменте игр для ПК?
Графический api vulkan или opengl pubg mobile что лучше
В марте этого года консорциум Khronos Group представил перспективный API Vulkan (раннее кодовое название — Next Generation OpenGL), который должен прийти на смену морально устаревшему OpenGL. Новый API благодаря низкоуровнему доступу к «железу» и более эффективному использованию ЦП должен существенно повысить производительность в использующих его играх. Сегодня у нас появилась возможность посмотреть, как сильно меняется ситуация с производительностью при использовании Vulkan. Соответствующее видео разместила на своём YouTube-канале компания Imagination Technologies.
реклама
В проигрываемой «демке» Gnome Horde был задействован прототип Vulkan, а также OpenGL ES 3.0. Как видим, когда на экране мало объектов, разница в производительности едва заметна, но стоит только «демке» начать отрисовывать колоссальное количество объектов, как производительность «Вулкана» начинает говорить сама за себя. Связана она в том числе и с более равномерной нагрузкой на все четыре доступных процессорных ядра, в то время как OpenGL-версия «демки» с трудом задействует два. Обратите внимание на общую разницу в использовании ресурсов процессора.
OpenCL
Vulkan
Я не придумал ничего умнее чем некоторую информацию представить скриншотом:
Vulkan Instance extensions:
Vulkan device features:
Vulkan device limits:
OpenGL
реклама
реклама
Расширения присутствующие в обоих драйверах (272 расширения):
Расширения присутствующие только в драйвере AMD (55 расширений):
Расширения присутствующие только в драйвере nVidia (149 расширений):
OpenGL core capabilities:
OpenGL extension capabilities:
Данная статья отпочковалась от другой статьи, ссылка на статью:
Мегаслив топовой 3070 Gigabyte Aorus дешевле любого Палит
Я сомневаюсь что данный материал будет интересен большинству обычных пользователей, здесь не будет фотографий видеокарт, как логотипы подсвечиваются, графики с FPS в играх и т.п., здесь будет очень много текста, но очень мало слов.
Если вам интересно посмотреть «изнутри» как обстоят дела с графическими (и не очень) API, то добро пожаловать.
реклама
Я не стану в пределах данной статьи разбирать каждое расширение до последнего бита, но поверхностно я постараюсь наглядно выделить разницу.
Выводы
Кто-то скажет — безумие, и возможно будет прав, но как иначе сравнивать если даже не видел то, что собираешься сравнить?
Я старался в минимальный объем всё поместить, но даже так, количество текста оказалось на десятки тысяч символов, разбивать на несколько частей не вижу целесообразным, статья имеет конкретную тематику.
Мне пришлось перенести основную массу информации в изображения, просто чтобы хоть как-то сделать размер статьи адекватнее.
Можно заметить, что в разных API некоторые возможности совпадают, например «CL_DEVICE_MAX_WORK_ITEM_SIZES» из OpenCL и «Threads Per Block» из CUDA имеют одинаковые ограничения.
Еще можно заметить «maxImageDimensionXX» из Vulkan и «GL_MAX_TEXTURE_SIZE » из OpenGL, а так же ряд других аналогичных параметров имеют одинаковые ограничения, и они судя по всему обусловлены архитектурой видеокарт.
Я думаю многие люди как минимум слышали про такую игру как Minecraft, а некоторые еще и с одной интересной проблемой вероятно сталкивались, когда применяешь текстурпак (ресурспак) и он крашит игру с видеокартой от AMD, но в паре с видеокартой от nVidia все работает, как так?
Возможно некоторые уже заметили такие ограничения как «GL_MAX_TEXTURE_SIZE», просто создатели ресурспака порой не учитывают (а может специально. ) разные ограничения у nVidia и AMD, и в итоге рождаются листы текстур размером 1024х20480 (и другие вариации), для анимации лавы или воды в игре, естественно такие текстуры не входят в лимит 16384 и Minecraft благополучно падает с видеокартой от AMD, когда с видеокартой от nVidia все нормально т.к. лимит 32768.
Надеюсь достаточно понятно объяснил как могут влиять ограничения, это был конечно лишь один пример, но в целом сложно сказать у кого лучше обстоят дела с ограничениями.
Очень многое зависит от конкретных случаев и разработчиков, одной лишь манипуляцией с размером текстур можно заставить работать игру только на видеокартах от nVidia, даже если эту текстуру никогда никто не увидит, и она будет размером всего 2х20480.
Очевидно количество расширений на стороне nVidia, хотя у AMD я заметил несколько расширений «GOOGLE_», что показалось мне довольно забавным.
Единственное, где большинство расширений оказалось на стороне AMD это OpenCL, причем у nVidia выделяются расширения «NV_», некоторые имеют одинаковые имена с расширениями «KHR_».
Хотя ради справедливости nVidia наштамповала 89 «GL_NV_» расширений, когда за AMD числится лишь 29 «GL_AMD_» расширений и 5 «GL_ATI_», естественно без учета расширений которые поддерживаются как AMD, так и nVidia.
А еще отмечу что в OpenCL у AMD есть «cl_khr_fp16» расширение (вычисления с половинной точностью), но отсутствует у nVidia, хотя в Vulkan расширение «VK_KHR_shader_float16_int8» есть у AMD и nVidia.
Несмотря на меньшее количество расширений у AMD, версии таких API как Vulkan, OpenCL и OpenGL выше чем у nVidia, и больше добавить нечего.
Я не знаю что еще добавить интересного для людей которые видят во всей массе статьи лишь набор символов и цифр.
Люди которым нужна будет данная информация вполне вероятно обойдутся и без выводов, что я написал.
Doom (2016) – тест производительности комплектующих с включенной/выключенной защитой Denuvo, а также в API OpenGL 4.5 и Vulkan
В данном обзоре будет проведено сводное тестирование видеокарт и процессоров в игре Doom (2016). В относительно недавнем прошлом в этом проекте была отключена защита Denuvo. На тот момент у меня в наличии были свежие тесты с еще включенной защитой. Поэтому я решил провести повторный тест, целью которого стало выяснение того, как влияет Denuvo на производительность комплектующих.
Помимо этого было решено протестировать процессоры и видеокарты в двух графических API: OpenGL 4.5 и Vulkan. Уверен, что такое исследование более чем актуально для многих наших читателей.
В материале присутствуют сводные диаграммы производительности видеокарт и процессоров, на которых наглядно представлены полученные результаты тестов. В связи с этим комментарии отсутствуют, так как каждый читатель сможет самостоятельно почерпнуть нужную ему информацию.
Напомним, что с работой тестовых стендов, методикой и обработкой результатов тестирования можно ознакомиться, перейдя по этой ссылке.
Мегаслив топовой 3070 Gigabyte Aorus дешевле любого Палит
Тестовая конфигурация
Тесты видеокарт проводились на следующем стенде:
Тесты процессоров проводились на следующем стенде:
реклама
Инструментарий и методика тестирования
Для более наглядного сравнения конфигураций игра, используемая в качестве тестового приложения, запускалась в разрешениях 1920 х 1080, 2560 х 1440 и 3840 x 2160. При этом тестирование процессоров проводилось в разрешении 1920 х 1080.
Список режимов игры:
Во всех играх замерялись минимальные и средние значения FPS. VSync при проведении тестов был отключен.
Результаты
Результаты были собраны утилитой GPU Caps Viewer версии 1.50.0.0, сбор информации был проведен в текстовый файл, именно из этого файла я и буду брать данные, по сути там повторяется всё, что отображается в окне самой программы.
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, где на полях сражений самостоятельно (но под вашим чутким руководством) сражаются тысячи воинов.
Маленькая статья про 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
Маст хев для разработки, в комплекте неплохие примеры кода на каждую фичу.
