Что нового я узнал про GPU
В своей программе я добавил замер времени над каждым компонентом (рис. 1). Это очень полезно не только для оптимизации кода компонента на Rust, но ещё и чтобы подобрать параметры когда симуляция/визуализация выглядят и работают ОК, но не тратят слишком много времени на вычисления. Среди этих параметров могут быть: точность, количество под-итераций за один фрейм, размер итд. Я очень рад что добавил это, так как теперь могу сразу видеть степень лага и уже пытаться оптимизировать сцены если лаг меня не устраивает.
Но после недавнего рефакторинга системы рисования /885, у меня также появились компоненты, которые делают какую-то работу на GPU, и оказывается её не видно в обычном CPU-таймере, и я начал разбираться, почему.
Если вы используете OpenGL, то его вызовы выглядят так, как будто они исполняются вот-прям-щас:
Как будто сейчас треугольник с шейдером и нарисовался в ваш фреймбуффер. И вот я узнал что на самом деле это не так, и это обман чтобы набрать классов. Когда вы вызываете эти методы, то они складываются в память и в памяти строится буфер команд. Делается это так, потому что связь CPU <-> GPU очень медленная. Поэтому лучше один раз отправить всю инфу, вместо того чтобы ждать. И происходят все вычисления на GPU обычно в конце фрейма, когда вам уже надо всё нарисовать на экране.
И если поставить обычный CPU-таймер вокруг этих команд, то он покажет ничтожное время, когда на самом деле ваша программа может очень сильно лагать. Тогда как измерить время? Можно ли гранулярно измерять время работы каждого компонента, а не только FPS?
На самом деле можно, и это вторая вещь про которую я узнал. Оказывается существуют особые GPU-таймеры, которые можно вставить посреди ваших команд и затем, на следующем кадре получить время их исполнения. Драйвер сам будет правильно замерять время на GPU. Главное ограничение - нельзя чтобы хоть один таймер пересекался с другим :(. Там надо использовать другой более муторный API
Вот я реализовал это (рис. 2), и недавно добавил камеру, которая может бегать по поверхности, которая задаётся шейдером на GPU. Чтобы это работало, мне надо отправлять инфу про камеру в шейдер, затем вызывать его чтобы он спроецировал камеру на эту поверхность, и забирать эту инфу из шейдера. Делаю я это через рисование в текстуру 2x1 пикселей. Очень маленькая текстура, вычисления занимают очень мало времени. Но по недавно добавленному GPU-таймеру заметил что время в этой функции на GPU занимает около 2 миллисекунд (ЧТО ОЧЕНЬ МНОГО). Как такая простейшая операция может длиться так долго?
И тут ещё одна вещь про которую я узнал. По сути в этом компоненте камеры мне нужно считать пиксели из фреймбуффера на процессор чтобы спроецировать CPU-камеру прям щас, но буфер исполнения на GPU у нас асинхронный, тогда что делать? Заблокировать всё нафиг и исполнить этот буфер команд, конечно же. Поэтому в этом компоненте происходит вся работа что зашедулили другие компоненты, и это отражается как на таймере CPU (потому что ждём), так и на таймере GPU. Так что нужно быть аккуратным когда вы вызываете блокирующие методы типо
Как вариант, можно получать эту инфу на следующем кадре, тогда будет совсем без ожидания, но и информация будет опаздывать на один кадр. Но я не стал так сильно заморачиваться.
А ещё я замерил время переноса информации с GPU на CPU чтобы считать эту 2x1 текстуру, и это получается 20 микросекунд. Это очень много для такой простейшей операции.
Так что если это возможно, то лучше все вычисления GPU-данных делать на GPU, и минимизировать их отправку на процессор. Я это испытал на себе.
В своей программе я добавил замер времени над каждым компонентом (рис. 1). Это очень полезно не только для оптимизации кода компонента на Rust, но ещё и чтобы подобрать параметры когда симуляция/визуализация выглядят и работают ОК, но не тратят слишком много времени на вычисления. Среди этих параметров могут быть: точность, количество под-итераций за один фрейм, размер итд. Я очень рад что добавил это, так как теперь могу сразу видеть степень лага и уже пытаться оптимизировать сцены если лаг меня не устраивает.
Но после недавнего рефакторинга системы рисования /885, у меня также появились компоненты, которые делают какую-то работу на GPU, и оказывается её не видно в обычном CPU-таймере, и я начал разбираться, почему.
Если вы используете OpenGL, то его вызовы выглядят так, как будто они исполняются вот-прям-щас:
glBindFramebuffer(GL_FRAMEBUFFER, framebuffer);
glUseProgram(shader_program);
glBindVertexArray(triangle_vao);
glDrawArrays(GL_TRIANGLES, 0, 3);
Как будто сейчас треугольник с шейдером и нарисовался в ваш фреймбуффер. И вот я узнал что на самом деле это не так, и это обман чтобы набрать классов. Когда вы вызываете эти методы, то они складываются в память и в памяти строится буфер команд. Делается это так, потому что связь CPU <-> GPU очень медленная. Поэтому лучше один раз отправить всю инфу, вместо того чтобы ждать. И происходят все вычисления на GPU обычно в конце фрейма, когда вам уже надо всё нарисовать на экране.
И если поставить обычный CPU-таймер вокруг этих команд, то он покажет ничтожное время, когда на самом деле ваша программа может очень сильно лагать. Тогда как измерить время? Можно ли гранулярно измерять время работы каждого компонента, а не только FPS?
На самом деле можно, и это вторая вещь про которую я узнал. Оказывается существуют особые GPU-таймеры, которые можно вставить посреди ваших команд и затем, на следующем кадре получить время их исполнения. Драйвер сам будет правильно замерять время на GPU. Главное ограничение - нельзя чтобы хоть один таймер пересекался с другим :(. Там надо использовать другой более муторный API
glQueryCounter.Вот я реализовал это (рис. 2), и недавно добавил камеру, которая может бегать по поверхности, которая задаётся шейдером на GPU. Чтобы это работало, мне надо отправлять инфу про камеру в шейдер, затем вызывать его чтобы он спроецировал камеру на эту поверхность, и забирать эту инфу из шейдера. Делаю я это через рисование в текстуру 2x1 пикселей. Очень маленькая текстура, вычисления занимают очень мало времени. Но по недавно добавленному GPU-таймеру заметил что время в этой функции на GPU занимает около 2 миллисекунд (ЧТО ОЧЕНЬ МНОГО). Как такая простейшая операция может длиться так долго?
И тут ещё одна вещь про которую я узнал. По сути в этом компоненте камеры мне нужно считать пиксели из фреймбуффера на процессор чтобы спроецировать CPU-камеру прям щас, но буфер исполнения на GPU у нас асинхронный, тогда что делать? Заблокировать всё нафиг и исполнить этот буфер команд, конечно же. Поэтому в этом компоненте происходит вся работа что зашедулили другие компоненты, и это отражается как на таймере CPU (потому что ждём), так и на таймере GPU. Так что нужно быть аккуратным когда вы вызываете блокирующие методы типо
glReadPixels.Как вариант, можно получать эту инфу на следующем кадре, тогда будет совсем без ожидания, но и информация будет опаздывать на один кадр. Но я не стал так сильно заморачиваться.
А ещё я замерил время переноса информации с GPU на CPU чтобы считать эту 2x1 текстуру, и это получается 20 микросекунд. Это очень много для такой простейшей операции.
Так что если это возможно, то лучше все вычисления GPU-данных делать на GPU, и минимизировать их отправку на процессор. Я это испытал на себе.
🔥37👍12❤7🥰1💯1
Мне кажется что все эти споры про LLM не имеют смысла?
Вроде как суть кодящих LLM-агентов (с точки зрения самих компаний) не в том чтобы заменить программистов, а в том, чтобы ускорить кодинг и ресёрч новых архитектур нейронок, которые станут настоящим AGI. OpenAI как раз высказывала что к сентябрю этого года они хотят сделать intern ML researcher на основе своих моделей, и они активно в этом направлении развиваются. А полноценного автоматизированного исследователя хотят к марту 2028.
Я уверен на 90% что в ближайшие 5-10 лет найдут новую архитектуру искусственного интеллекта (тут я намеренно использую этот термин), который способен обучаться как человек: читая книгу, делая примеры, программируя; на собственном опыте, без поглощения всех данных интернета.
И тогда все споры про LLM пойдут в топку, поскольку эта новая сущность будет принципиально другой, сможет на 100% заменить некоторых людей и не будет иметь тех спорных свойств, что имеют текущие LLM.
Точно ли LLM - это то, на что нужно обращать столько внимания сейчас?
Вроде как суть кодящих LLM-агентов (с точки зрения самих компаний) не в том чтобы заменить программистов, а в том, чтобы ускорить кодинг и ресёрч новых архитектур нейронок, которые станут настоящим AGI. OpenAI как раз высказывала что к сентябрю этого года они хотят сделать intern ML researcher на основе своих моделей, и они активно в этом направлении развиваются. А полноценного автоматизированного исследователя хотят к марту 2028.
Я уверен на 90% что в ближайшие 5-10 лет найдут новую архитектуру искусственного интеллекта (тут я намеренно использую этот термин), который способен обучаться как человек: читая книгу, делая примеры, программируя; на собственном опыте, без поглощения всех данных интернета.
И тогда все споры про LLM пойдут в топку, поскольку эта новая сущность будет принципиально другой, сможет на 100% заменить некоторых людей и не будет иметь тех спорных свойств, что имеют текущие LLM.
Точно ли LLM - это то, на что нужно обращать столько внимания сейчас?
👍50🥱9👎8❤4🤔3🤡3😁2🔥1🥰1👀1
В качестве прокрастинации от монтажа видео я начал немного играться с path tracing'ом червоточин (!). И вот захотел сделать анимацию того как меняется фокусное расстояние камеры рядом с червоточиной, чтобы увидеть как бы она выглядела в реальности, когда мы своими глазами меняем фокусное расстояние. Такое 100% никто раньше не делал.
И вот для этого нужно ОЧЕНЬ много сэмплов, потому что очень много размытия из-за расфокуса. Поэтому я навайбкодил программу, которая берёт мой Portal Lab и рендерит эту анимацию в сырые float буферы каждого цвета, и в этих буферах аккумулирует цвета. И работает она так что она по кругу бегает по этим буферам и добавляет и добавляет сэмплов чтобы я мог её запускать много-много ночей подряд чтобы получать менее шумную картинку.
И вот я оставил эту программу работать в течении 20 часов (на моей 5080), пока скалолазался, гулял, спал. Но есть одна проблема...
Сегодня я решил посмотреть превью этих буферов и поставил их отрисовку в png. Смотрю на кадры, а они как будто все одни и те же, как будто фокус не меняется. Дождался пока сырые буферы отрисуются в png (это было долго), смотрю и ВСЕ кадры одинаковые, с одним и те же фокусом, анимации никакой нет, все эти 20 часов я рендерил ПЕРВЫЙ КАДР! ААААА!!
Начал грешить на кодекса что он неправильно написал код рендеринга и отправил его разбираться. Но как говорится, в расследовании преступления главное не выйти на самого себя. Что и прозошло, баг был в моей сцене, я забыл анимировать изменение фокуса...
Ну ладно, чего уже добру пропадать, раз я рендерил ОДИН ГРЁБАНЫЙ КАДР целых 20 часов, давайте хоть проведу аналитику насколько количество сэмплов влияет на то как выглядит итоговый кадр. Объединю их все и построю графики.
For your information: когда рендеришь path tracing'ом, то главная операция что ты делаешь - это просто берёшь рандомный луч и пускаешь его и записываешь цвет. Поэтому чем больше рандомных лучей, тем лучше. Поэтому если все мои кадры использовали независимый рандом, то их можно объединить и получить универсальный супер-пупер классный кадр.
Значит я рендерил по 32 сэмпла каждый проход по всем 720 кадрам, и уже успело случиться 10 таких проходов, поэтому каждый кадр у меня имеет 320 сэмплов. Далее, когда я объединяю эти кадры, для аналитики, то шаг будет равен 320 сэмплов. Максимальное количество сэмплов - 223_200 😵💫
Картинка будет показывать очень размытую червоточину, потому что с этого кадра начиналась анимация, там должен был меняться фокус чтобы фокусироситься на червоточине и за ней.
Вот вам картинки насколько шумно выглядит при размном количестве сэмплов (кадры без сжатия будут в комментариях).
Я думаю остановлюсь где-то на 5к-10к сэмплов в своей анимации.
И ещё в комментариях приложу прикольные графики!
И вот для этого нужно ОЧЕНЬ много сэмплов, потому что очень много размытия из-за расфокуса. Поэтому я навайбкодил программу, которая берёт мой Portal Lab и рендерит эту анимацию в сырые float буферы каждого цвета, и в этих буферах аккумулирует цвета. И работает она так что она по кругу бегает по этим буферам и добавляет и добавляет сэмплов чтобы я мог её запускать много-много ночей подряд чтобы получать менее шумную картинку.
И вот я оставил эту программу работать в течении 20 часов (на моей 5080), пока скалолазался, гулял, спал. Но есть одна проблема...
Сегодня я решил посмотреть превью этих буферов и поставил их отрисовку в png. Смотрю на кадры, а они как будто все одни и те же, как будто фокус не меняется. Дождался пока сырые буферы отрисуются в png (это было долго), смотрю и ВСЕ кадры одинаковые, с одним и те же фокусом, анимации никакой нет, все эти 20 часов я рендерил ПЕРВЫЙ КАДР! ААААА!!
Начал грешить на кодекса что он неправильно написал код рендеринга и отправил его разбираться. Но как говорится, в расследовании преступления главное не выйти на самого себя. Что и прозошло, баг был в моей сцене, я забыл анимировать изменение фокуса...
Ну ладно, чего уже добру пропадать, раз я рендерил ОДИН ГРЁБАНЫЙ КАДР целых 20 часов, давайте хоть проведу аналитику насколько количество сэмплов влияет на то как выглядит итоговый кадр. Объединю их все и построю графики.
For your information: когда рендеришь path tracing'ом, то главная операция что ты делаешь - это просто берёшь рандомный луч и пускаешь его и записываешь цвет. Поэтому чем больше рандомных лучей, тем лучше. Поэтому если все мои кадры использовали независимый рандом, то их можно объединить и получить универсальный супер-пупер классный кадр.
Значит я рендерил по 32 сэмпла каждый проход по всем 720 кадрам, и уже успело случиться 10 таких проходов, поэтому каждый кадр у меня имеет 320 сэмплов. Далее, когда я объединяю эти кадры, для аналитики, то шаг будет равен 320 сэмплов. Максимальное количество сэмплов - 223_200 😵💫
Картинка будет показывать очень размытую червоточину, потому что с этого кадра начиналась анимация, там должен был меняться фокус чтобы фокусироситься на червоточине и за ней.
Вот вам картинки насколько шумно выглядит при размном количестве сэмплов (кадры без сжатия будут в комментариях).
Я думаю остановлюсь где-то на 5к-10к сэмплов в своей анимации.
И ещё в комментариях приложу прикольные графики!
🔥49😁8😱6👍3❤2❤🔥2🥰1🙏1👀1🆒1
Про самосилу и чёрные дыры.
В моём последнем видео я рассказывал о явлении само-силы, которое обнаружил совершенно случайно, когда считал как негативный портал телепортирует гравитацию.
Само-сила - это явление, когда гравитация тела создаёт силу, которая толкает это же тело, за счёт искривления пространства. У меня в порталах есть точка сингулярности на границах порталов, где угол в точке равен не 360 градусов, а все 720. И именно от этой точки создавалась отталкивающая само-сила, потому что она вела себя как точка с большой кривизной пространства. Её можно сгладить, чтобы она не была сингулярностью, и эффект будет оставаться примерно такой же.
И вот сегодня я задумался - а насколько реальна эта вещь? А то я всё думаю что мои портальчики - это лишь спекуляции и фиктивная физика, и никогда даже не задумывался о том чтобы это было применимо в реальности.
Так вот, само-сила от искривления пространства существует в реальности. Она работает как для гравитации, так и для электромагнетизма. Последнее совершенно неожиданно, ведь я то рассчитывал гравитацию, и само-силу обнаружил для неё, но электромагнетизм работает по похожим принципам. Проблема в том что само-сила электромагнетизма настолько слаба, что она ни в каких ситуациях не может показать хоть какой-то значимый вклад. Разве что только рядом с червоточиной нанометрового размера само-сила электромагнетизма может хоть чуток влиять на химию.
А вот гравитационная само-сила намного более сильна и наверное единственное место где её можно достоверно обнаружить - это при вращении массивных тел рядом с чёрной дырой. Даже в этом случае само-сила довольно слаба, но она оказывает измеримый эффект на тысячах и десятках тысяч оборотов.
И это как раз исследуют люди, которые занимаются лазерным интерферометром (это тот что зафиксировал гравитационные волны), который будет в космосе - LISA. Для LIGO эффект само-силы вроде слишком слабый чтобы всерьёз его учитывать.
Вот даже есть такое чтиво на эту тему: https://the-center-of-gravity.com/documents/333/1805.10385v2.pdf (я прочитал только абстракт)
В моём последнем видео я рассказывал о явлении само-силы, которое обнаружил совершенно случайно, когда считал как негативный портал телепортирует гравитацию.
Само-сила - это явление, когда гравитация тела создаёт силу, которая толкает это же тело, за счёт искривления пространства. У меня в порталах есть точка сингулярности на границах порталов, где угол в точке равен не 360 градусов, а все 720. И именно от этой точки создавалась отталкивающая само-сила, потому что она вела себя как точка с большой кривизной пространства. Её можно сгладить, чтобы она не была сингулярностью, и эффект будет оставаться примерно такой же.
И вот сегодня я задумался - а насколько реальна эта вещь? А то я всё думаю что мои портальчики - это лишь спекуляции и фиктивная физика, и никогда даже не задумывался о том чтобы это было применимо в реальности.
Так вот, само-сила от искривления пространства существует в реальности. Она работает как для гравитации, так и для электромагнетизма. Последнее совершенно неожиданно, ведь я то рассчитывал гравитацию, и само-силу обнаружил для неё, но электромагнетизм работает по похожим принципам. Проблема в том что само-сила электромагнетизма настолько слаба, что она ни в каких ситуациях не может показать хоть какой-то значимый вклад. Разве что только рядом с червоточиной нанометрового размера само-сила электромагнетизма может хоть чуток влиять на химию.
А вот гравитационная само-сила намного более сильна и наверное единственное место где её можно достоверно обнаружить - это при вращении массивных тел рядом с чёрной дырой. Даже в этом случае само-сила довольно слаба, но она оказывает измеримый эффект на тысячах и десятках тысяч оборотов.
И это как раз исследуют люди, которые занимаются лазерным интерферометром (это тот что зафиксировал гравитационные волны), который будет в космосе - LISA. Для LIGO эффект само-силы вроде слишком слабый чтобы всерьёз его учитывать.
Вот даже есть такое чтиво на эту тему: https://the-center-of-gravity.com/documents/333/1805.10385v2.pdf (я прочитал только абстракт)
🔥49🥰24❤9👍3🦄3👀1💘1