Супер лекция! Mаленькая заметка - в "presént" в значении "представить" ударение идёт на 2 слог а не на 1ый. С ударением на 1 слоге это "подарок" или "настоящее". Кажется мелочью и доебыванием но меня лично это безостановояно сбивало с толку 😂 (ведь буфер мы представляем (presEnt) перед пользователем, а не просим систему дать нам какой-то текущий (prEsent) буфер)
Пытался залезть на Vulkan раньше, не получалось никак. Код ну просто чудовищен, вообще официальные туторы отбивают желание этим заниматься. Туда напихивают сразу же и слои валидации, и всю работу с экстеншенами. Как говорит Константин, "Путь до первого треугольника", с офф туторами это просто минное поле из тонн неструктурированного грязного кода. Так что спасибо за эту лекцию, мне была крайне полезна! Ну и Vulkan-hpp реально лучше for use. Она хотя бы чистит все эти сотни структур с заданием sType в рантайме, через которые ты общаешься с API. Уже за это ее можно и нужно юзать в cpp коде.
Как всегда отличная лекция, к сожалению посмотрел далеко не сразу. Оставлю небольшие замечания, чтобы в следующий раз было еще лучше🤓 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 в таком случае будет работать не до, а после фрагментного шейдера. Но раз в норме он идет до, то на картинках так и указывают.
Брошу еще камней в огород OpenGL - Отсутствие пред компилированного байт-кода, как например у DX еще с бородатых времен(Добавили только в 4.6 версии поддержку SPIR-V, особо доставляла функция glLinkProgram) - Из за сложной стэйт машины высокая нагрузка на CPU, на мобилках это довольно критично - Неконсистентность самого API
Лекция хороша, но хотелось бы пару замечаний, хоть возможно они и являются чуть большим углублением в вулкан, чем нужно на первой лекции. Про управление памятью: у вас есть серьёзное ограничение на количество выделяемых блоков (к примеру блоков 2048 на 2070S). Про вычисления: можно было намекнуть, что мы можем передавать не только матрицы 4х4 но и других размеров, а так же, на сколько помню трёхмерные.
Да, про управление памятью это вообще огромная тема. Есть целые библиотеки которые используются практически чтобы упростить управление памятью в вулкане.
на 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 для их комбинаций.
На 43:43 uniform матрицы умножаются в самом шейдере. Оптимизируют ли как-либо это компиляторы? Мне всегда казалось, что лучше передать предварительно вычисленную матрицу MVP, если есть такая возможность.
Я с вами до какой то степени согласен. Мы во первых делаем уйму повторяющейся работы в каждом потоке, во вторых гоним на GPU втрое больше данных. Но я не смог устоять -- мне нужен был пример нетривиального вершинного шейдера.
1:40:10 Дайте угадаю, ускорились за счет UBO рингбуфера? На самом деле на ogl тоже самое можно сделать и не стоит хоронить старичка раньше времени. API оверхед у него конечно больше, но не такой драмматичный как в примере.
@@tilirПринцип такой же - пока GPU читает один буфер, пишем в следующий и так по кругу. Кроме того не использовать Buffer|Sub|Data, а мапить единожды содержимое на cpu с флагами persistent и coherent. Здесь главное понять где ogl расставляет имплисит синкпоинты cpu-gpu. Хоть и нет возможности ими управлять, как в Vulkan'е, но контролировать извне их вполне возможно.
Замечательная лекция! Смотрел большим интересом и почерпнул много интересного. Не могли бы Вы дополнить список литературы каким-нибудь пособием по базовой теории компьютерной графики? Что бы понимать как в теории происходит построение изображений и мочь испльзовать то или иное api осознанно, а не как набор фунций, которые нужно вызвать в определенном порядке.
Алексей Боресков - Программирование компьютерной графики, 2019 Небольшая, но довольно неплохая книга по введению в компьютерную графику. В книге рассматриваются различные алгоритма и структуры данных, используемых в графике, рассматривается рейтрейсинг, и основы современного opengl.
Спасибо большое за лекцию! На OpenGL игрался когда-то, тоже рисовал кубы, а вот про Vulkan было очень интересно послушать. Если будут ещё доп. семинары по графике, можете осветить тему отрисовки шрифтов? Честно говоря у меня до сих пор нет понимания как рисуются буквы, да ещё и без "лесенок" и прочих артефактов
Ничего сложного, сначала загружается шрифт, а потом все символы, которые поддерживает этот шрифт переносятся на текстурный атлас. Ну а дальше не трудно догадаться, что просто на экране на месте символов рисуются квадраты с наложенными текстурами букв из текстурного атласа. Вот и всё
@@tilir а это то тут при чем? Тут же не будет двух точек куба, которые при проецировании попадут в один пиксель, с одинаковой глубиной? А на видео видно именно отсечение ребер невидимых граней куба.
Да я форкнул на свой гитхаб тот снимок с проекта Димы который был актуален на момент записи лекций: github.com/tilir/3d-render-examples ну и там можете перейти в апстрим, работа в процессе.
уух, спасибо. Будь у меня такие преподаватели, я бы может быть крудошлепом бы не стал. Вопросы, возможно я пропустил. 1. Поддержка вулкана на видеокартах реализована на уровне драйверов? На старых его не завести? 2. Если уже есть код, который рисует в openGL, передавая в точку рендерера данные вершин и данные для униформ с полной отвязкой в проектировании от внутренностей GL, за исключением разве что последовательностей байтов в текстурах, тяжело ли будет переписаться на вулкан?
получается что фрагментные шейдеры имеют квадратичную сложность? 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 вынужденно сишные. Дело в манглировании.
Вычисления на vulkan проводить вполне можно. Но не являясь специализированным API для compute, Vulkan для этого является немыслимо тяжёлым выбором. 9-12 слайды отсюда дают представление о том что хорошо для компьюта и почему: www.iwocl.org/wp-content/uploads/iwocl-syclcon-2020-meyer-11-slides.pdf Обычный сценарий компьюта на Вулкане это примерно так: у вас уже есть игра с 3D обработкой и вы дописываете в ту же систему ещё и шейдер для вычислений. Стартовать же на вулкане именно вычислительный проект это странно.
@@tilir Вопрос про то, на сколько процентов на гпу будет быстрее чем на цпу. У меня есть еще один вопрос, не относящейся к данной теме. Я его под лекцией по метапрограммированию написал, но, видимо, у Вас не было оповещения о комментарии или по каким-то причинам оно затерялось. Я тут вопрос продублирую, т.к. как-то иначе не могу дать на него ссылку, если Вас не затруднит, прокомментируйте пожалуйста. Вопрос об использовании типов unit32_t, int32_t и им подобных. Вы не рекомендуете использование данных типов, но в c++ core guidelines в разделе Р.5 рекомендуют в похожем случае (ua-cam.com/video/UJqW_eEBA6I/v-deo.html тайминг по лекции по мете, лекция номер 16) использование именно int32_t. Сможете как-то прокомментировать? Возможно, я что-то не правильно понял.
@@yakryt7228 про int32_t я вроде уже отвечал, но я ответил вам в ту ветку. Я не слишком высоко ценю эти самые core guidelines. Сравнение производительности GPU и CPU конечно будет на лекции по компьюту. Коротко -- для тех вычислительных задач, для которых GPU подходит, оно в разы лучше. Но оно подходит не для всех задач. Матрицы перемножить -- очень хорошо. А вот что-то другое -- надо смотреть отдельно.
Я работаю в vim. Проблема в том что на лекции у меня нет полноценной клавиатуры, а показывать вещи надо быстро. Поэтому npp. Если у вас есть другие предложения -- озвучьте.
![Процедурная 3D Графика. Ray Marching Tutorial [ OpenGL / GLSL ]](/img/n.gif)
ваш канал - это просто золотая жила для cs
Ужасно интересно! Трёхкратный прирост впечатлил 👍👍
Тут в комментариях уже обнаружилось что такие цифры скорее от того, что я несколько недожал в OpenGL части. Попытаюсь наверстать к следующему году =)
Это самое лучшее объяснение, лично для меня многие непонятки прояснились.
вотэта мне надо такое
Отличная премьера, спасибо!
Всегда знал что openGL круто но что-то с ним не так! Очень впечатлен обострением проблем и переходом к вулкану. Смотрю про него с интересом! Спасибо!
Прекрасная лекция для введения в графику
Вы уверенны что это прекрасная лекция для ВВЕДЕНИЯ в графику ?
Супер лекция!
Mаленькая заметка - в "presént" в значении "представить" ударение идёт на 2 слог а не на 1ый. С ударением на 1 слоге это "подарок" или "настоящее". Кажется мелочью и доебыванием но меня лично это безостановояно сбивало с толку 😂
(ведь буфер мы представляем (presEnt) перед пользователем, а не просим систему дать нам какой-то текущий (prEsent) буфер)
У меня тоже задание по 3D, и я не заснул за 2 часа этой лекции!
Ого, прямо одним куском? Мои поздравления ))
Пытался залезть на Vulkan раньше, не получалось никак. Код ну просто чудовищен, вообще официальные туторы отбивают желание этим заниматься. Туда напихивают сразу же и слои валидации, и всю работу с экстеншенами. Как говорит Константин, "Путь до первого треугольника", с офф туторами это просто минное поле из тонн неструктурированного грязного кода.
Так что спасибо за эту лекцию, мне была крайне полезна! Ну и Vulkan-hpp реально лучше for use. Она хотя бы чистит все эти сотни структур с заданием sType в рантайме, через которые ты общаешься с API. Уже за это ее можно и нужно юзать в cpp коде.
Ооочень ждал после анонса!
Интересно слышать в одном видео про поддержку OpenGL 2.0 и Vulkan) но лекция выглядит очень структурировано, этому стоило бы поучится некоторым
Как всегда отличная лекция, к сожалению посмотрел далеко не сразу. Оставлю небольшие замечания, чтобы в следующий раз было еще лучше🤓
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 в таком случае будет работать не до, а после фрагментного шейдера. Но раз в норме он идет до, то на картинках так и указывают.
Брошу еще камней в огород OpenGL
- Отсутствие пред компилированного байт-кода, как например у DX еще с бородатых времен(Добавили только в 4.6 версии поддержку SPIR-V, особо доставляла функция glLinkProgram)
- Из за сложной стэйт машины высокая нагрузка на CPU, на мобилках это довольно критично
- Неконсистентность самого API
Лекция хороша, но хотелось бы пару замечаний, хоть возможно они и являются чуть большим углублением в вулкан, чем нужно на первой лекции.
Про управление памятью: у вас есть серьёзное ограничение на количество выделяемых блоков (к примеру блоков 2048 на 2070S).
Про вычисления: можно было намекнуть, что мы можем передавать не только матрицы 4х4 но и других размеров, а так же, на сколько помню трёхмерные.
Да, про управление памятью это вообще огромная тема. Есть целые библиотеки которые используются практически чтобы упростить управление памятью в вулкане.
на 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 для их комбинаций.
На 43:43 uniform матрицы умножаются в самом шейдере. Оптимизируют ли как-либо это компиляторы? Мне всегда казалось, что лучше передать предварительно вычисленную матрицу MVP, если есть такая возможность.
Я с вами до какой то степени согласен. Мы во первых делаем уйму повторяющейся работы в каждом потоке, во вторых гоним на GPU втрое больше данных. Но я не смог устоять -- мне нужен был пример нетривиального вершинного шейдера.
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 было очень интересно послушать.
Если будут ещё доп. семинары по графике, можете осветить тему отрисовки шрифтов? Честно говоря у меня до сих пор нет понимания как рисуются буквы, да ещё и без "лесенок" и прочих артефактов
Я там в конце книжку порекомендовал как раз по этому вопросу. Базовые алгоритмы компьютерной графики очень интересны.
Ничего сложного, сначала загружается шрифт, а потом все символы, которые поддерживает этот шрифт переносятся на текстурный атлас. Ну а дальше не трудно догадаться, что просто на экране на месте символов рисуются квадраты с наложенными текстурами букв из текстурного атласа. Вот и всё
51:19 а разве отображение задних граней не должен face culling отбрасывать, а не depth test?
Ради интереса погуглите z-fighting =)
@@tilir а это то тут при чем? Тут же не будет двух точек куба, которые при проецировании попадут в один пиксель, с одинаковой глубиной? А на видео видно именно отсечение ребер невидимых граней куба.
Очень здорово и огромная благодарность за лекцию! А исходник примера не доступен для ознакомления?
Да я форкнул на свой гитхаб тот снимок с проекта Димы который был актуален на момент записи лекций: github.com/tilir/3d-render-examples ну и там можете перейти в апстрим, работа в процессе.
@@tilir благодарствую!
уух, спасибо. Будь у меня такие преподаватели, я бы может быть крудошлепом бы не стал. Вопросы, возможно я пропустил. 1. Поддержка вулкана на видеокартах реализована на уровне драйверов? На старых его не завести? 2. Если уже есть код, который рисует в openGL, передавая в точку рендерера данные вершин и данные для униформ с полной отвязкой в проектировании от внутренностей GL, за исключением разве что последовательностей байтов в текстурах, тяжело ли будет переписаться на вулкан?
1. На уровне рантайма. Это не совсем "драйвера", но нечто на них похожее. 2. Сложно, у Vulkan высокий входной порог.
@@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 есть доки?
извините, я бы хотел понять, почему не стоит производить вычисления на vulkan api?
Вычисления на vulkan проводить вполне можно. Но не являясь специализированным API для compute, Vulkan для этого является немыслимо тяжёлым выбором.
9-12 слайды отсюда дают представление о том что хорошо для компьюта и почему: www.iwocl.org/wp-content/uploads/iwocl-syclcon-2020-meyer-11-slides.pdf
Обычный сценарий компьюта на Вулкане это примерно так: у вас уже есть игра с 3D обработкой и вы дописываете в ту же систему ещё и шейдер для вычислений. Стартовать же на вулкане именно вычислительный проект это странно.
А правильный ответ на вопрос, озвученный в конце лекции, мы узнаем в следующей серии ? :)
Следующая лекция как раз про компьют. А что за вопрос вы имеете в виду?
@@tilir Вопрос про то, на сколько процентов на гпу будет быстрее чем на цпу.
У меня есть еще один вопрос, не относящейся к данной теме. Я его под лекцией по метапрограммированию написал, но, видимо, у Вас не было оповещения о комментарии или по каким-то причинам оно затерялось. Я тут вопрос продублирую, т.к. как-то иначе не могу дать на него ссылку, если Вас не затруднит, прокомментируйте пожалуйста.
Вопрос об использовании типов unit32_t, int32_t и им подобных. Вы не рекомендуете использование данных типов, но в c++ core guidelines в разделе Р.5 рекомендуют в похожем случае (ua-cam.com/video/UJqW_eEBA6I/v-deo.html тайминг по лекции по мете, лекция номер 16) использование именно int32_t. Сможете как-то прокомментировать? Возможно, я что-то не правильно понял.
@@yakryt7228 про int32_t я вроде уже отвечал, но я ответил вам в ту ветку. Я не слишком высоко ценю эти самые core guidelines.
Сравнение производительности GPU и CPU конечно будет на лекции по компьюту. Коротко -- для тех вычислительных задач, для которых GPU подходит, оно в разы лучше. Но оно подходит не для всех задач. Матрицы перемножить -- очень хорошо. А вот что-то другое -- надо смотреть отдельно.
@@tilir Спасибо и за ответ на тот вопрос, и про вычисления на гпу. Ждем с нетерпением следующей лекции :)
@@tilir "Я не слишком высоко ценю эти самые core guidelines." А можно с этого места подробнее?)) Их вроде пишут (сами!) Саттер и Страуструп.
А теперь проверка ссылки на другое видео:
ua-cam.com/video/J6SNO5o9ADg/v-deo.html
Комменты с ссылками на godbolt молча удаляются, комменты с ссылками на другие youtube видео выживают)
Какой у вас опыт в программирование, начиная с любительской лиги ?
Хочется стать таким же опытным человеком🙄
У меня есть интервью (см. на коммьюнити-вкладке канала) где я рассказываю про свой опыт.
note: 3730
Ну блин сколько можно в этих notepad+++ рабоать, кровь с глаз же.
Я работаю в vim. Проблема в том что на лекции у меня нет полноценной клавиатуры, а показывать вещи надо быстро. Поэтому npp. Если у вас есть другие предложения -- озвучьте.
@@tilir vs code
Разве тут не glGetProgramiv? cpp-graduate/10-3d/ogl-frag-shader . cc:145