Из вики : «Vulkan API изначально упоминался как« инициатива OpenGL следующего поколения »от Khrono», и что это « основополагающая попытка редизайна объединить OpenGL и OpenGL ES в один общий API, который не будет обратным» совместим с существующими версиями OpenGL ".
Так стоит ли лучше изучать Vulkan вместо OpenGL тем, кто сейчас занимается графическим программированием? Кажется, они будут служить той же цели.
Ответы:
Едва!
Это похоже на вопрос «Должны ли новые программисты изучать C ++ вместо C» или «Должны ли новые художники изучать цифровую живопись вместо физической».
Тем более, что графические программисты НЕ имеют обратной совместимости, было бы глупо исключать самый распространенный графический API в отрасли просто потому, что есть новый. Кроме того, OpenGL делает разные вещи по-разному. Вполне возможно, что компания выберет OpenGL вместо Vulkan, особенно в начале игры, и эта компания не будет заинтересована в том, кто не знает OpenGL, независимо от того, знают ли они Vulkan или нет.
Специализация редко является рыночным навыком.
Для тех, кому не нужно продавать свои навыки как таковые, например, для независимых разработчиков, было бы еще более глупо удалять инструмент из их набора инструментов. Инди-разработчик еще больше зависит от гибкости и способности выбирать то, что работает, а не то, что финансируется. Специализируясь на Vulkan только ограничивает ваши возможности.
Специализация редко является эффективной парадигмой.
источник
Если вы только начинаете и хотите работать с графическим процессором (в отличие от постоянного использования игрового движка, такого как Unity), вам определенно стоит начать изучать Vulkan. Возможно, вам стоит изучить GL и позже, но есть несколько причин, чтобы подумать о Вулкане.
GL и GLES были разработаны много лет назад, когда графические процессоры работали совсем по-другому. (Самым очевидным отличием является то, что вызовы рисования в непосредственном режиме сравниваются с тайлингом и очередями команд.) GL побуждает вас мыслить в стиле немедленного режима и имеет много устаревших ошибок. Vulkan предлагает модели программирования, которые намного ближе к тому, как работают современные графические процессоры, поэтому, если вы изучите Vulkan, вы лучше поймете, как на самом деле работает технология, а также что является эффективным, а что - неэффективным. Я вижу много людей, которые начали с GL или GLES и сразу же приобрели вредные привычки, такие как выдача отдельных вызовов отрисовки для объекта вместо использования VBO или, что еще хуже, с использованием списков отображения. Программистам GL трудно понять, что больше не поощряется.
Гораздо проще перейти с Vulkan на GL или GLES, чем наоборот. Vulkan делает явным много вещей, которые были скрыты или непредсказуемы в GL, такие как управление параллелизмом, совместное использование и состояние рендеринга. Он продвигает большую сложность от драйвера к приложению, но, делая это, он дает управление приложению и упрощает получение предсказуемой производительности и совместимости между различными поставщиками графических процессоров. Если у вас есть какой-то код, который работает в Vulkan, его довольно просто перенести на GL или GLES, и вы получите что-то, что использует хорошие привычки GL / GLES. Если у вас есть код, который работает в GL или GLES, вам почти придется начинать заново, чтобы заставить его работать эффективно в Vulkan: особенно если он был написан в устаревшем стиле (см. Пункт 1).
Сначала я был обеспокоен тем, что с Vulkan гораздо сложнее программировать, и хотя опытным разработчикам в крупных компаниях это будет хорошо, это будет огромным барьером для инди-любителей и любителей. Я задал этот вопрос некоторым членам Рабочей группы, и они сказали, что у них есть некоторые данные от людей, с которыми они говорили, которые уже переехали в Вулкан. Эти люди варьируются от разработчиков в Epic, работающих над интеграцией UE4, до разработчиков игр-любителей. Их опыт заключался в том, что для начала работы (то есть, чтобы иметь один треугольник на экране) потребовалось изучить больше концепций и иметь более длинный шаблонный код, но это не было слишком сложно, даже для инди. Но после того, как они достигли этой стадии, они обнаружили, что гораздо проще создать реальное приложение для отправки, потому что (а) поведение намного более предсказуемо между реализациями разных производителей, и (б) получение чего-то, что хорошо работало со всеми включенными эффектами, не включало столько проб и ошибок. Благодаря опыту настоящих разработчиков они убедили меня в том, что программирование на Vulkan жизнеспособно даже для начинающего пользователя графики, и что общая сложность уменьшается, если вы пройдете обучение и начнете создавать демонстрации или приложения, которые вы можете дать другим людям.
Как уже говорили другие: GL доступен на многих платформах, WebGL - хороший механизм доставки, есть много существующего программного обеспечения, которое использует GL, и есть много работодателей, нанимающих для этого навыка. Это будет происходить в течение следующих нескольких лет, пока Вулкан набирает обороты и развивает экосистему. По этим причинам было бы глупо полностью исключить изучение GL. Несмотря на это, вам будет гораздо легче с этим справиться, и вы станете лучшим программистом GL (и вообще лучшим программистом на GPU), если вы начнете с того, что поможет вам понять GPU вместо понимания того, как они работают 20 лет спустя.
Конечно, есть еще один вариант. Я не знаю, относится ли это, в частности, к вам, но я все равно должен сказать это для других посетителей.
Чтобы быть разработчиком инди-игр, гейм-дизайнером или виртуальным опытом, вам не нужно изучать Vulkan или GL. Многие люди начинают работать с игровым движком (сейчас популярны Unity или UE4). Использование такого движка позволит вам сосредоточиться на опыте, который вы хотите создать, а не на технологии, стоящей за ним. Это скроет различия между GL и Vulkan от вас, и вам не нужно беспокоиться о том, что поддерживается на вашей платформе. Это позволит вам узнать о трехмерных координатах, преобразованиях, освещении и анимации, не имея дело со всеми мелкими деталями сразу. Некоторые игровые или виртуальные студии работают только в движке, и у них вообще нет штатного эксперта по GL. Даже в больших студиях, которые пишут свои собственные движки, люди, которые занимаются графическим программированием, составляют меньшинство,
Изучение деталей взаимодействия с графическим процессором, безусловно, является полезным навыком, который оценят многие работодатели, но вы не должны чувствовать, что должны изучать его, чтобы войти в 3D-программирование; и даже если вы это знаете, это не обязательно будет чем-то, что вы используете каждый день.
источник
Изучение графического программирования - это больше, чем просто изучение 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 поможет вам лучше узнать, как сделать графику быстрее. И это, безусловно, поможет вам снизить нагрузку на процессор.
Это все еще займет гораздо больше времени, прежде чем вы сможете добраться до точки, где вы можете изучить методы графического рендеринга.
источник
Основная привлекательность 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 на Java и работаю уже более 6 месяцев.
Другая проблема, с которой я столкнулся, связана с претензиями Vulkan о том, как он утверждает, что он лучше. Хотя OpenGL, конечно, не очень часто обновляет свой сайт. Они продолжают постоянно выпускать обновления, и я всегда с нетерпением жду новых обновлений, которые будут работать быстрее или лучше работать с новым оборудованием.
При этом, хотя я в основном работаю с OpenGL, я понимаю основные принципы DirectX и Vulkan. Хотя я не очень много с ними работаю, особенно с Vulkan, так как его очень трудно освоить и он не так хорошо структурирован для программирования, как OpenGl и DirectX.
Наконец, я хотел бы добавить, что специализация на одной области, такой как я в основном использую Java и OpenGL, не является удивительно привлекательной на рынке. Если бы я хотел устроиться на работу в компанию, производящую игры, то по большей части OpenGL использовался бы только для разработки игр для Linux и Android, а также для OSX. DirectX для Windows и консолей, <которые Vulkan может заменить в некоторых случаях.
Я не могу долго держаться за обновления OpenGL, и я не буду. Но это мое предпочтение развития.
источник
Я хотел бы дать вам мой взгляд начинающего графика на эту тему. Что я понял (много лет работая инженером в другой области), так это то, что фундаментальные понятия являются наиболее важной частью. Когда у вас есть четкое представление о них, изучение последнего блестящего нового 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, библиотеки и приложения, такие как Unity или Unreal Engine, и просто написать исходный код и сценарии, необходимые для работы приложения. ,
Исходя из моего собственного понимания и того, как я это вижу, это так, если вы хотите построить быструю игру только ради создания игры; пойти с уже существующими рамными работами, которые сделают ваше производственное время намного меньшим. С другой стороны, если вы хотите понять, как устроены игровые / физические движки / анимационные двигатели и симуляторы, и хотите создать их самостоятельно, тогда у вас есть выбор между выбором API, например DirectX, OpenGL или Vulkan. Одним из определяющих факторов здесь также будут ваши существующие знания в области программирования. Под этим я подразумеваю, что если вы ничего не знаете о многопоточности, синхронных и асинхронных вызовах, выделениях памяти, гонках данных, семафорах и параллелизме (параллельное программирование),
Я упоминаю об этом, потому что, если вы не знаете, как правильно управлять своей памятью, потоками и временем доступа; Вулкан укусит тебя в задницу! Где OpenGL и DirectX будут держать вас всю руку, потребляя гораздо больше ресурсов процессора.
Теперь, если ваш уровень знаний в области программирования является приличным, и у вас есть следующие математические знания, которые включают все уровни алгебры, геометрии, тригонометрии, булевой алгебры, вероятности, статистики, алгебры на основе векторной матрицы, исчисления I, II, .... Infinty (смеется). Векторное исчисление, линейная алгебра, системы линейных уравнений, аналитическая геометрия с векторным исчислением многопараметрических вычислений, теория чисел и множеств, наборы данных и структуры, вычислительный анализ, вычислительный и алгоритмический дизайн. Затем вы можете получить представление о том, что нужно для создания реального игрового движка, и это без какой-либо прикладной математики или каких-либо физических уравнений, которые вам понадобятся. Как только у вас появится этот опыт и достаточно опыта программирования, особенно управления памятью и арифметики указателей, вы можете приступить к созданию игрового движка.
Итак, дело в том, что вы должны понимать все аспекты того, что нужно для создания игрового движка, чтобы заниматься продвинутым графическим программированием. Если вы делаете только 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 и иметь "
В конце концов, все зависит от того, какой человек выберет маршрут, по которому он хочет идти, и оттуда его успех будет определяться их преданностью, постоянным обучением, тяжелой работой, пробами и ошибками и, что наиболее важно, их неудачами. Если вы не провалились, значит, вы не успешны! Вы добились успеха только в том случае, если вы потерпели неудачу, нашли свои ошибки, исправили их, пошли дальше, вернулись и сделали все заново!
источник
Сначала вы должны изучить OpenGL, так как это стандарт для графики на многих платформах.
Даже если есть более новая библиотека, понимание основ и работа с языком, который используется во всей отрасли, очень важна ... Тем более, что с тех пор Vulkan не будет использоваться в больших компаниях некоторое время.
Никто не хочет сразу приспосабливаться и заканчивать тем, что отказывается от нестабильной среды Framework / Library.
Им нужно будет нанимать / переучивать своих нынешних программистов Open-GL, и в этом нет необходимости.
Кроме того, я слышал, что OpenGL и Vulkan не совсем одинаковы. Я слышал, что Vulkan - это API более низкого уровня и ближе к машинному коду, чем OpenGL.
Этот ответ, который я только что нашел, кажется, содержит много полезной информации
https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl
Еще одна вещь, на которую стоит обратить внимание, - это проблема, возникшая с OpenGL 1.
От OpenGL 1 к OpenGL 2 произошли ОСНОВНЫЕ изменения, и, поскольку многие люди использовали OpenGL1 и аппаратное обеспечение его поддерживали, в некоторых приложениях / движках требовалась обратная совместимость, и иногда разработчикам было очень больно поддерживать его. ,
Помимо поддержки, язык изменился настолько, что вам пришлось изучать новые вещи.
Это произошло с такими фреймворками, как JavaFX (от 1.x до 2.x) и Play! Framework (также 1.x к 2.x). Полные изменения в структуре, что означает, что мы должны переучиваться ... все ...
По сути, вам следует подождать, пока Vulkan не станет СТАБИЛЬНЫМ. Это означает, что нужно подождать до версии 2.0. Это не означает, что вы не можете узнать об основах Vulkan, но просто знайте, что это может измениться. Я бы предположил, что такая группа, как Kronos, с самого начала предоставила бы очень стабильный API, тем более что над Vulkan работают несколько инженеров Nvidia и AMD, включая высокопоставленного сотрудника Nvidia, который, очевидно, наблюдает за проектом, а также The Base of Mantle; однако, как и любое программное обеспечение, мы, программисты, увидим, насколько хорошо оно работает с самого начала, но многие настороженно ждут, чтобы увидеть, что произойдет.
источник