Супер лекция! Mаленькая заметка - в "presént" в значении "представить" ударение идёт на 2 слог а не на 1ый. С ударением на 1 слоге это "подарок" или "настоящее". Кажется мелочью и доебыванием но меня лично это безостановояно сбивало с толку 😂 (ведь буфер мы представляем (presEnt) перед пользователем, а не просим систему дать нам какой-то текущий (prEsent) буфер)
Пытался залезть на Vulkan раньше, не получалось никак. Код ну просто чудовищен, вообще официальные туторы отбивают желание этим заниматься. Туда напихивают сразу же и слои валидации, и всю работу с экстеншенами. Как говорит Константин, "Путь до первого треугольника", с офф туторами это просто минное поле из тонн неструктурированного грязного кода. Так что спасибо за эту лекцию, мне была крайне полезна! Ну и Vulkan-hpp реально лучше for use. Она хотя бы чистит все эти сотни структур с заданием sType в рантайме, через которые ты общаешься с API. Уже за это ее можно и нужно юзать в cpp коде.
на 1:50:00 не понял что мешало им сделать просто оператор для енама без всяких лишних классов. Ну и реализацию to_underlying за одну строку тоже впринципе можно было бы вкинуть, она даже в С++23 есть template constexpr auto to_underlying(T value) noexcept { return static_cast(value); } P.S. до С++20 если вы не поставите enable if с проверкой что это enum, то std::underlying_type на не енам ЭТО UB!! Не шучу! А за лекцию спасибо, давно хотел узнать что то про эти апишки, но нигде нет нормальной информации
Идея оператора для enum class плоха вот чем: у вас есть флаги A, B, C но например A | B уже не член enum class и мы не хотим чтобы он им был. Поэтому у нас есть enum class для индивидуальных возможных флагов и отдельный класс который хранит underlying type для их комбинаций.
Брошу еще камней в огород OpenGL - Отсутствие пред компилированного байт-кода, как например у DX еще с бородатых времен(Добавили только в 4.6 версии поддержку SPIR-V, особо доставляла функция glLinkProgram) - Из за сложной стэйт машины высокая нагрузка на CPU, на мобилках это довольно критично - Неконсистентность самого API
Лекция хороша, но хотелось бы пару замечаний, хоть возможно они и являются чуть большим углублением в вулкан, чем нужно на первой лекции. Про управление памятью: у вас есть серьёзное ограничение на количество выделяемых блоков (к примеру блоков 2048 на 2070S). Про вычисления: можно было намекнуть, что мы можем передавать не только матрицы 4х4 но и других размеров, а так же, на сколько помню трёхмерные.
Да, про управление памятью это вообще огромная тема. Есть целые библиотеки которые используются практически чтобы упростить управление памятью в вулкане.
На 43:43 uniform матрицы умножаются в самом шейдере. Оптимизируют ли как-либо это компиляторы? Мне всегда казалось, что лучше передать предварительно вычисленную матрицу MVP, если есть такая возможность.
Я с вами до какой то степени согласен. Мы во первых делаем уйму повторяющейся работы в каждом потоке, во вторых гоним на GPU втрое больше данных. Но я не смог устоять -- мне нужен был пример нетривиального вершинного шейдера.
Как всегда отличная лекция, к сожалению посмотрел далеко не сразу. Оставлю небольшие замечания, чтобы в следующий раз было еще лучше🤓 0. Про небольшое введение в 3d тут написал уже некий You Tube 1. Немного из истории пропущено, между glVertex3fv и VBO были еще функции glVertexPointer, со своими нюансами и непонятками) 2. У меня аж глаз задергался, когда увидел, что мы на каждом кадре делаем glGetUniformLocation() 3. Вы собираетесь на лету менять код шейдера в процессе исполнения программы? Было и такое - генерация специализированных шейдеров, по описаниям, полученным во время работы программы. Но это, конечно же, исключение) 4. 51.20 Это не depth-test пройдет, а face-culling отрежет. Depth буффер пишется после успешного прохождения фрагмента, а здесь фрагменты это только линии. 5. Я не работал еще с Вулканом. Depth-test перенесли до FS? Это же, вроде бы, была оптимизация(Early Fragment Test на сайте хроноса). В вулкане нельзя из фрагментного шейдера менять значение глубины фрагмента? 6. Ускорение при переносе вычислений на GPU вещь очень тонкая и зависит от многих факторов. В плохом случае можно получить даже замедление)
Отличный комментарий, спасибо. Я надеялся что придут люди, которые лучше знают графику -- для меня-то и шейдеры это не код это тесты для компилятора =) (0) Я рассматриваю всю эту лекцию как небольшое введение в 3d (1) Я думал. Не влезло бы и в наши дни уже, наверное, не слишком актуально. Или ещё используется? (2) Упс. Спасибо. Я чего-то тоже это только что осознал. Но, кстати, Дима в его примере так не делает. (3) Учитывая specialization constants в SPIRV менять код на лету уже не слишком нужно. (4) Я был уверен, что именно depth даёт артефакты. Но для линий наверное да, он не при чём. (5) Там как-то сложно. С одной стороны gl_FragDepth всё так же доступен разумеется, GLSL никто не менял. Но с другой стороны depth test действительно идёт раньше. Надо почитать спеку, может ещё разок пересчитывается позднее? (6) Да, конечно
@@tilir 1. Ну, на предыдущей моей работе оно до сих пор используется в режиме compatibility profile при некоторых плохих условиях. Просто это неплохой логический переход. В начале веков было так, потом решили сделать glVertexPointer(). Но эта функция весьма магическая и непонятно, что она в реальности делает. И тогда придумали нормальные VBO) 2. Я бы глянул на код примера, он есть в материалах примера? Но думаю, там все хорошо) 3. Я делал нечто, что называют functional textures. По описанию штрихованных линий генерировал код фрагментного шейдера, который обычные линии превращает в пунктирные. А так да, ради констант любят шейдеры перекомпилировать. 5. Думаю, изменение глубины во фрагментном шейдере мало распространено, поэтому обычно тест идет до. Но у программы есть флажок, меняет ли она глубину, и depth-test в таком случае будет работать не до, а после фрагментного шейдера. Но раз в норме он идет до, то на картинках так и указывают.
1:40:10 Дайте угадаю, ускорились за счет UBO рингбуфера? На самом деле на ogl тоже самое можно сделать и не стоит хоронить старичка раньше времени. API оверхед у него конечно больше, но не такой драмматичный как в примере.
@@tilirПринцип такой же - пока GPU читает один буфер, пишем в следующий и так по кругу. Кроме того не использовать Buffer|Sub|Data, а мапить единожды содержимое на cpu с флагами persistent и coherent. Здесь главное понять где ogl расставляет имплисит синкпоинты cpu-gpu. Хоть и нет возможности ими управлять, как в Vulkan'е, но контролировать извне их вполне возможно.
Замечательная лекция! Смотрел большим интересом и почерпнул много интересного. Не могли бы Вы дополнить список литературы каким-нибудь пособием по базовой теории компьютерной графики? Что бы понимать как в теории происходит построение изображений и мочь испльзовать то или иное api осознанно, а не как набор фунций, которые нужно вызвать в определенном порядке.
Алексей Боресков - Программирование компьютерной графики, 2019 Небольшая, но довольно неплохая книга по введению в компьютерную графику. В книге рассматриваются различные алгоритма и структуры данных, используемых в графике, рассматривается рейтрейсинг, и основы современного opengl.
Спасибо большое за лекцию! На OpenGL игрался когда-то, тоже рисовал кубы, а вот про Vulkan было очень интересно послушать. Если будут ещё доп. семинары по графике, можете осветить тему отрисовки шрифтов? Честно говоря у меня до сих пор нет понимания как рисуются буквы, да ещё и без "лесенок" и прочих артефактов
Ничего сложного, сначала загружается шрифт, а потом все символы, которые поддерживает этот шрифт переносятся на текстурный атлас. Ну а дальше не трудно догадаться, что просто на экране на месте символов рисуются квадраты с наложенными текстурами букв из текстурного атласа. Вот и всё
уух, спасибо. Будь у меня такие преподаватели, я бы может быть крудошлепом бы не стал. Вопросы, возможно я пропустил. 1. Поддержка вулкана на видеокартах реализована на уровне драйверов? На старых его не завести? 2. Если уже есть код, который рисует в openGL, передавая в точку рендерера данные вершин и данные для униформ с полной отвязкой в проектировании от внутренностей GL, за исключением разве что последовательностей байтов в текстурах, тяжело ли будет переписаться на вулкан?
@@tilir а это то тут при чем? Тут же не будет двух точек куба, которые при проецировании попадут в один пиксель, с одинаковой глубиной? А на видео видно именно отсечение ребер невидимых граней куба.
Да я форкнул на свой гитхаб тот снимок с проекта Димы который был актуален на момент записи лекций: github.com/tilir/3d-render-examples ну и там можете перейти в апстрим, работа в процессе.
получается что фрагментные шейдеры имеют квадратичную сложность? O(n^2) (не XOR, а степень) for(Vertex vert : verticies){ Fragment[] fragments = getAllNearFragmentsToNextVerticies(vert); for(Fragment frag : fragments){ float[] arr = new float[{0.5}, {0.5}, {0.5 * currentTimeMillis()}, {1.0}]; frag.setColour(arr) } } Спасибо за лекции! С удовольствием их смотрю все! Сложно немного понимать эти функции... почему бы не сделать их более объектно-ориентированными? API OpenGL'а. Извиняюсь за такой глупый вопрос... Но у меня огромное желание изучать все это. Еще раз спасибо!
Вы пропустили растеризатор. Он строит по вершинам массив фрагментов и дальше он уже параллелится по фрагментному процессингу. Что до API... я вроде на первых же лекциях объясняю почему все нормальные API вынужденно сишные. Дело в манглировании.
@@tilir Вопрос про то, на сколько процентов на гпу будет быстрее чем на цпу. У меня есть еще один вопрос, не относящейся к данной теме. Я его под лекцией по метапрограммированию написал, но, видимо, у Вас не было оповещения о комментарии или по каким-то причинам оно затерялось. Я тут вопрос продублирую, т.к. как-то иначе не могу дать на него ссылку, если Вас не затруднит, прокомментируйте пожалуйста. Вопрос об использовании типов unit32_t, int32_t и им подобных. Вы не рекомендуете использование данных типов, но в c++ core guidelines в разделе Р.5 рекомендуют в похожем случае (th-cam.com/video/UJqW_eEBA6I/w-d-xo.html тайминг по лекции по мете, лекция номер 16) использование именно int32_t. Сможете как-то прокомментировать? Возможно, я что-то не правильно понял.
@@yakryt7228 про int32_t я вроде уже отвечал, но я ответил вам в ту ветку. Я не слишком высоко ценю эти самые core guidelines. Сравнение производительности GPU и CPU конечно будет на лекции по компьюту. Коротко -- для тех вычислительных задач, для которых GPU подходит, оно в разы лучше. Но оно подходит не для всех задач. Матрицы перемножить -- очень хорошо. А вот что-то другое -- надо смотреть отдельно.
Вычисления на vulkan проводить вполне можно. Но не являясь специализированным API для compute, Vulkan для этого является немыслимо тяжёлым выбором. 9-12 слайды отсюда дают представление о том что хорошо для компьюта и почему: www.iwocl.org/wp-content/uploads/iwocl-syclcon-2020-meyer-11-slides.pdf Обычный сценарий компьюта на Вулкане это примерно так: у вас уже есть игра с 3D обработкой и вы дописываете в ту же систему ещё и шейдер для вычислений. Стартовать же на вулкане именно вычислительный проект это странно.
Я работаю в vim. Проблема в том что на лекции у меня нет полноценной клавиатуры, а показывать вещи надо быстро. Поэтому npp. Если у вас есть другие предложения -- озвучьте.
ваш канал - это просто золотая жила для cs
Это самое лучшее объяснение, лично для меня многие непонятки прояснились.
Ужасно интересно! Трёхкратный прирост впечатлил 👍👍
Тут в комментариях уже обнаружилось что такие цифры скорее от того, что я несколько недожал в OpenGL части. Попытаюсь наверстать к следующему году =)
вотэта мне надо такое
Всегда знал что openGL круто но что-то с ним не так! Очень впечатлен обострением проблем и переходом к вулкану. Смотрю про него с интересом! Спасибо!
Отличная премьера, спасибо!
Супер лекция!
Mаленькая заметка - в "presént" в значении "представить" ударение идёт на 2 слог а не на 1ый. С ударением на 1 слоге это "подарок" или "настоящее". Кажется мелочью и доебыванием но меня лично это безостановояно сбивало с толку 😂
(ведь буфер мы представляем (presEnt) перед пользователем, а не просим систему дать нам какой-то текущий (prEsent) буфер)
Прекрасная лекция для введения в графику
Вы уверенны что это прекрасная лекция для ВВЕДЕНИЯ в графику ?
Пытался залезть на Vulkan раньше, не получалось никак. Код ну просто чудовищен, вообще официальные туторы отбивают желание этим заниматься. Туда напихивают сразу же и слои валидации, и всю работу с экстеншенами. Как говорит Константин, "Путь до первого треугольника", с офф туторами это просто минное поле из тонн неструктурированного грязного кода.
Так что спасибо за эту лекцию, мне была крайне полезна! Ну и Vulkan-hpp реально лучше for use. Она хотя бы чистит все эти сотни структур с заданием sType в рантайме, через которые ты общаешься с API. Уже за это ее можно и нужно юзать в cpp коде.
Интересно слышать в одном видео про поддержку OpenGL 2.0 и Vulkan) но лекция выглядит очень структурировано, этому стоило бы поучится некоторым
на 1:50:00 не понял что мешало им сделать просто оператор для енама без всяких лишних классов. Ну и реализацию to_underlying за одну строку тоже впринципе можно было бы вкинуть, она даже в С++23 есть
template
constexpr auto to_underlying(T value) noexcept {
return static_cast(value);
}
P.S. до С++20 если вы не поставите enable if с проверкой что это enum, то std::underlying_type на не енам ЭТО UB!! Не шучу!
А за лекцию спасибо, давно хотел узнать что то про эти апишки, но нигде нет нормальной информации
Идея оператора для enum class плоха вот чем: у вас есть флаги A, B, C но например A | B уже не член enum class и мы не хотим чтобы он им был. Поэтому у нас есть enum class для индивидуальных возможных флагов и отдельный класс который хранит underlying type для их комбинаций.
Брошу еще камней в огород OpenGL
- Отсутствие пред компилированного байт-кода, как например у DX еще с бородатых времен(Добавили только в 4.6 версии поддержку SPIR-V, особо доставляла функция glLinkProgram)
- Из за сложной стэйт машины высокая нагрузка на CPU, на мобилках это довольно критично
- Неконсистентность самого API
Лекция хороша, но хотелось бы пару замечаний, хоть возможно они и являются чуть большим углублением в вулкан, чем нужно на первой лекции.
Про управление памятью: у вас есть серьёзное ограничение на количество выделяемых блоков (к примеру блоков 2048 на 2070S).
Про вычисления: можно было намекнуть, что мы можем передавать не только матрицы 4х4 но и других размеров, а так же, на сколько помню трёхмерные.
Да, про управление памятью это вообще огромная тема. Есть целые библиотеки которые используются практически чтобы упростить управление памятью в вулкане.
На 43:43 uniform матрицы умножаются в самом шейдере. Оптимизируют ли как-либо это компиляторы? Мне всегда казалось, что лучше передать предварительно вычисленную матрицу MVP, если есть такая возможность.
Я с вами до какой то степени согласен. Мы во первых делаем уйму повторяющейся работы в каждом потоке, во вторых гоним на GPU втрое больше данных. Но я не смог устоять -- мне нужен был пример нетривиального вершинного шейдера.
Как всегда отличная лекция, к сожалению посмотрел далеко не сразу. Оставлю небольшие замечания, чтобы в следующий раз было еще лучше🤓
0. Про небольшое введение в 3d тут написал уже некий You Tube
1. Немного из истории пропущено, между glVertex3fv и VBO были еще функции glVertexPointer, со своими нюансами и непонятками)
2. У меня аж глаз задергался, когда увидел, что мы на каждом кадре делаем glGetUniformLocation()
3. Вы собираетесь на лету менять код шейдера в процессе исполнения программы? Было и такое - генерация специализированных шейдеров, по описаниям, полученным во время работы программы. Но это, конечно же, исключение)
4. 51.20 Это не depth-test пройдет, а face-culling отрежет. Depth буффер пишется после успешного прохождения фрагмента, а здесь фрагменты это только линии.
5. Я не работал еще с Вулканом. Depth-test перенесли до FS? Это же, вроде бы, была оптимизация(Early Fragment Test на сайте хроноса). В вулкане нельзя из фрагментного шейдера менять значение глубины фрагмента?
6. Ускорение при переносе вычислений на GPU вещь очень тонкая и зависит от многих факторов. В плохом случае можно получить даже замедление)
Отличный комментарий, спасибо. Я надеялся что придут люди, которые лучше знают графику -- для меня-то и шейдеры это не код это тесты для компилятора =)
(0) Я рассматриваю всю эту лекцию как небольшое введение в 3d
(1) Я думал. Не влезло бы и в наши дни уже, наверное, не слишком актуально. Или ещё используется?
(2) Упс. Спасибо. Я чего-то тоже это только что осознал. Но, кстати, Дима в его примере так не делает.
(3) Учитывая specialization constants в SPIRV менять код на лету уже не слишком нужно.
(4) Я был уверен, что именно depth даёт артефакты. Но для линий наверное да, он не при чём.
(5) Там как-то сложно. С одной стороны gl_FragDepth всё так же доступен разумеется, GLSL никто не менял. Но с другой стороны depth test действительно идёт раньше. Надо почитать спеку, может ещё разок пересчитывается позднее?
(6) Да, конечно
@@tilir
1. Ну, на предыдущей моей работе оно до сих пор используется в режиме compatibility profile при некоторых плохих условиях. Просто это неплохой логический переход. В начале веков было так, потом решили сделать glVertexPointer(). Но эта функция весьма магическая и непонятно, что она в реальности делает. И тогда придумали нормальные VBO)
2. Я бы глянул на код примера, он есть в материалах примера? Но думаю, там все хорошо)
3. Я делал нечто, что называют functional textures. По описанию штрихованных линий генерировал код фрагментного шейдера, который обычные линии превращает в пунктирные. А так да, ради констант любят шейдеры перекомпилировать.
5. Думаю, изменение глубины во фрагментном шейдере мало распространено, поэтому обычно тест идет до. Но у программы есть флажок, меняет ли она глубину, и depth-test в таком случае будет работать не до, а после фрагментного шейдера. Но раз в норме он идет до, то на картинках так и указывают.
Ооочень ждал после анонса!
1:40:10
Дайте угадаю, ускорились за счет UBO рингбуфера? На самом деле на ogl тоже самое можно сделать и не стоит хоронить старичка раньше времени. API оверхед у него конечно больше, но не такой драмматичный как в примере.
Расскажите вкратце как это сделать на opengl, постараюсь улучшить честность сравнения.
@@tilirПринцип такой же - пока GPU читает один буфер, пишем в следующий и так по кругу. Кроме того не использовать Buffer|Sub|Data, а мапить единожды содержимое на cpu с флагами persistent и coherent. Здесь главное понять где ogl расставляет имплисит синкпоинты cpu-gpu. Хоть и нет возможности ими управлять, как в Vulkan'е, но контролировать извне их вполне возможно.
Замечательная лекция! Смотрел большим интересом и почерпнул много интересного. Не могли бы Вы дополнить список литературы каким-нибудь пособием по базовой теории компьютерной графики? Что бы понимать как в теории происходит построение изображений и мочь испльзовать то или иное api осознанно, а не как набор фунций, которые нужно вызвать в определенном порядке.
Алексей Боресков - Программирование компьютерной графики, 2019
Небольшая, но довольно неплохая книга по введению в компьютерную графику. В книге рассматриваются различные алгоритма и структуры данных, используемых в графике, рассматривается рейтрейсинг, и основы современного opengl.
@@АндрейШевелёв-г2щ Благодарю за рекомендацию!
Спасибо большое за лекцию! На OpenGL игрался когда-то, тоже рисовал кубы, а вот про Vulkan было очень интересно послушать.
Если будут ещё доп. семинары по графике, можете осветить тему отрисовки шрифтов? Честно говоря у меня до сих пор нет понимания как рисуются буквы, да ещё и без "лесенок" и прочих артефактов
Я там в конце книжку порекомендовал как раз по этому вопросу. Базовые алгоритмы компьютерной графики очень интересны.
Ничего сложного, сначала загружается шрифт, а потом все символы, которые поддерживает этот шрифт переносятся на текстурный атлас. Ну а дальше не трудно догадаться, что просто на экране на месте символов рисуются квадраты с наложенными текстурами букв из текстурного атласа. Вот и всё
уух, спасибо. Будь у меня такие преподаватели, я бы может быть крудошлепом бы не стал. Вопросы, возможно я пропустил. 1. Поддержка вулкана на видеокартах реализована на уровне драйверов? На старых его не завести? 2. Если уже есть код, который рисует в openGL, передавая в точку рендерера данные вершин и данные для униформ с полной отвязкой в проектировании от внутренностей GL, за исключением разве что последовательностей байтов в текстурах, тяжело ли будет переписаться на вулкан?
51:19 а разве отображение задних граней не должен face culling отбрасывать, а не depth test?
Ради интереса погуглите z-fighting =)
@@tilir а это то тут при чем? Тут же не будет двух точек куба, которые при проецировании попадут в один пиксель, с одинаковой глубиной? А на видео видно именно отсечение ребер невидимых граней куба.
Очень здорово и огромная благодарность за лекцию! А исходник примера не доступен для ознакомления?
Да я форкнул на свой гитхаб тот снимок с проекта Димы который был актуален на момент записи лекций: github.com/tilir/3d-render-examples ну и там можете перейти в апстрим, работа в процессе.
@@tilir благодарствую!
Glsl ещё и на midl похож своими входными выходными параметрами. Но все же больше на си
получается что фрагментные шейдеры имеют квадратичную сложность? O(n^2) (не XOR, а степень)
for(Vertex vert : verticies){
Fragment[] fragments = getAllNearFragmentsToNextVerticies(vert);
for(Fragment frag : fragments){
float[] arr = new float[{0.5}, {0.5}, {0.5 * currentTimeMillis()}, {1.0}];
frag.setColour(arr)
}
}
Спасибо за лекции! С удовольствием их смотрю все! Сложно немного понимать эти функции... почему бы не сделать их более объектно-ориентированными? API OpenGL'а. Извиняюсь за такой глупый вопрос... Но у меня огромное желание изучать все это. Еще раз спасибо!
Вы пропустили растеризатор. Он строит по вершинам массив фрагментов и дальше он уже параллелится по фрагментному процессингу.
Что до API... я вроде на первых же лекциях объясняю почему все нормальные API вынужденно сишные. Дело в манглировании.
@@tilir спасибо большое! Сейчас посмотрю.
А по Vulkan-hpp есть доки?
А правильный ответ на вопрос, озвученный в конце лекции, мы узнаем в следующей серии ? :)
Следующая лекция как раз про компьют. А что за вопрос вы имеете в виду?
@@tilir Вопрос про то, на сколько процентов на гпу будет быстрее чем на цпу.
У меня есть еще один вопрос, не относящейся к данной теме. Я его под лекцией по метапрограммированию написал, но, видимо, у Вас не было оповещения о комментарии или по каким-то причинам оно затерялось. Я тут вопрос продублирую, т.к. как-то иначе не могу дать на него ссылку, если Вас не затруднит, прокомментируйте пожалуйста.
Вопрос об использовании типов unit32_t, int32_t и им подобных. Вы не рекомендуете использование данных типов, но в c++ core guidelines в разделе Р.5 рекомендуют в похожем случае (th-cam.com/video/UJqW_eEBA6I/w-d-xo.html тайминг по лекции по мете, лекция номер 16) использование именно int32_t. Сможете как-то прокомментировать? Возможно, я что-то не правильно понял.
@@yakryt7228 про int32_t я вроде уже отвечал, но я ответил вам в ту ветку. Я не слишком высоко ценю эти самые core guidelines.
Сравнение производительности GPU и CPU конечно будет на лекции по компьюту. Коротко -- для тех вычислительных задач, для которых GPU подходит, оно в разы лучше. Но оно подходит не для всех задач. Матрицы перемножить -- очень хорошо. А вот что-то другое -- надо смотреть отдельно.
@@tilir Спасибо и за ответ на тот вопрос, и про вычисления на гпу. Ждем с нетерпением следующей лекции :)
@@tilir "Я не слишком высоко ценю эти самые core guidelines." А можно с этого места подробнее?)) Их вроде пишут (сами!) Саттер и Страуструп.
А теперь проверка ссылки на другое видео:
th-cam.com/video/J6SNO5o9ADg/w-d-xo.html
Комменты с ссылками на godbolt молча удаляются, комменты с ссылками на другие youtube видео выживают)
извините, я бы хотел понять, почему не стоит производить вычисления на vulkan api?
Вычисления на vulkan проводить вполне можно. Но не являясь специализированным API для compute, Vulkan для этого является немыслимо тяжёлым выбором.
9-12 слайды отсюда дают представление о том что хорошо для компьюта и почему: www.iwocl.org/wp-content/uploads/iwocl-syclcon-2020-meyer-11-slides.pdf
Обычный сценарий компьюта на Вулкане это примерно так: у вас уже есть игра с 3D обработкой и вы дописываете в ту же систему ещё и шейдер для вычислений. Стартовать же на вулкане именно вычислительный проект это странно.
Какой у вас опыт в программирование, начиная с любительской лиги ?
Хочется стать таким же опытным человеком🙄
У меня есть интервью (см. на коммьюнити-вкладке канала) где я рассказываю про свой опыт.
note: 3730
Ну блин сколько можно в этих notepad+++ рабоать, кровь с глаз же.
Я работаю в vim. Проблема в том что на лекции у меня нет полноценной клавиатуры, а показывать вещи надо быстро. Поэтому npp. Если у вас есть другие предложения -- озвучьте.
@@tilir vs code
Разве тут не glGetProgramiv? cpp-graduate/10-3d/ogl-frag-shader . cc:145