100K танцующих кубов с костями, нужны замеры FPS (7 стр)

скиньте мне скриншот этих кубов

Там всего 100к кубов? Я бы легко отрендерил хоть 10млн кубов на таком же FPS

Mikle
> оба теста стабильно показывают 188 fps, что-то совсем мало, судя по предыдущим результатам.
У тебя в процессоре есть интегрированное видео. Возможно на нём запустилось. Можно ли средствами ОС принудить запуск на дискретной видеокарте?

THE_MASTER
> Там всего 100к кубов?
Да. Кубы размером 1x1x1 юнит. Разбросаны равномерно в окрестностях центра координат не дальше 50 единиц ворлдспейса. Куб состоит из 8 вершин (важное отличие от 100к истинных кубов у Марины, у нее под каждую грань свой набор вершин с индивидуальными нормалями).
На каждом кубе текстура 256 на 256px. Кубы с имитацией скелетной анимации.

скрин в студию

THE_MASTER

1. у тебя каждый куб - не инстанс, а честный куб со своими координатами?
2. они же у тебя пляшут? Ты их как двигаешь? Читеришь в каком-нибудь вертексном шейдере, добавляя шафл к координатам от дельта тайм? Или на компьют шейдере по какому-то алгоритму сдвигаешь?
3. попробуй RTX, отрендеришь намного больше, хотя там нужно смотреть на сколько они у тебя смещаются, короче на возможные оверлапы.

Vitorio
> У тебя в процессоре есть интегрированное видео. Возможно на нём запустилось.
И вывело изображение на монитор через разъём на видеокарте?

THE_MASTER
1. да, честный куб. Инстансинг не используется.
2. в архиве есть исходник. В версии с Джакондой см. вершинный шейдер в файле bin/custom.vs и функцию BonesAnimationSimulation в src/main.cpp
3. цель данного треда не вывести over 100500 кубов с over 100500 fps, а убедиться, что даже в "нагруженном" pipeline не имеет значения как мы располагаем атрибуты вершин в буфферах.

Mikle
> И вывело изображение на монитор через разъём на видеокарте?
Я подумал, что а вдруг ноут с одним общим видеоразъемом для встройки и дискретки, для них это актуально.

Vitorio
> что даже в "нагруженном" pipeline не имеет значения как мы располагаем атрибуты вершин в буфферах
Конечно не имеет, там выравниваний нет, ты же явно оффсеты задаёшь.

THE_MASTER
> Конечно не имеет, там выравниваний нет, ты же явно оффсеты задаёшь.
Тестируется это: https://gamedev.ru/flame/forum/?id=248801&page=170&m=5912185#m2540

Vitorio
по хорошему нужно еще замерить fps когда сцена не попадает в viewport, ибо ты легко можешь упереться в пиксельный шейдер и fillrate, когда способ задания вершин это про вершинный шейдер.

MrShoor
> Тестируется это
А...вот вы что здесь перетираете уже который день (достаточно было посмотреть в нуль пост :)

Ну что ж, судя по вашим результатам разницы нет, но вы хоть поняли почему?
Кто-то там что-то говорил про кэш (вроде nes), но как я уже писал в ветке про вулкан, кеш для рендеров бесполезен и вот почему:

Кеш - это такая память, которая полезна только при многократном использование одних и тех же данных. То есть мы медленно закидываем какие-то данные из глобал мемори в кеш, который находится близко к кристаллу(gpu) и потом их многократно используем для чтения на высокой скорости. Да, вроде звучит круто, но задайтесь теперь вопросом, а причём здесь рендеры? Где в рендерах хоть какие-то данные многократно используются/ переиспользуются? Нету там такого, при рендере кадра у тебя огромный вертекс буфер читается линейно из глобал мемора повертексно, далее каждый вертекс используется только один раз! (перемножаешь его на матрицы или ещё что) и всё, больше он не нужен (то же самое касается нормалей, текстурных координат и пр.), поэтому смысла хранить одноразовые данные в кеше нет никакого и именно поэтому у вас и результаты для вариантов 1 и 2 - одинаковые, т.к. кеш там не используется и именно в связи с этим без разницы как подавать данные в шейдер, одним буфером или несколькими.

Кеш-ы (всякие shared/const memory) используются только для вычислений на GPU (CUDA/OpenCL/Compute Shaders и пр.), где есть над ними ручной контроль, а в рендерах же в них загоняются скорее всего только всякие пуш-константы и юниформы что, к слову - полезно.

Вы мне сейчас скажите, мол как же так, в случае одного буфера идёт грубо говоря одно чтение для вершины из глобал мемори, а в случае нескольких буферов - несколько чтений. Ну что ж, такие мысли имели бы место быть на процессорах 80-х годов и более того, вы не умеете мыслить многомерно. Вот  смотрите, вы же рендерите не один пиксель, а миллионы сразу, так вот пусть будет 3 чтения из глобал мемори для одного пикселя, он прочитает (VVVV) (NNNN) (CCCC) или что там у вас было, и вот здесь как раз может (наверное) сработать кеш, то есть GPU же не читает по одному байту из глобал мемори, он читает за одну операцию количество данных размером в разрядность шины GPU, то есть за раз он подтянет больше чем на один вертекс и V и N и C. Эти данные прочитает наш целевой пиксель, про который мы говорим, не лишние данные то в кеш-е лежат и почему бы ими не воспользоваться соседними пикселями, возможно так оно и есть? То есть да, мы читаем несколько раз из глобал мемори, но этого чтения хватает на несколько пикселей, а не только на один как в случае монолитных атрибутов, поэтому и разницы никакой не будет.

Почему я здесь использую слова "наверное", "возможно" и пр - да потому что как на самом деле работает кеш на конкретном GPU - известно только инженерам этого GPU, более того, разрядность шины памяти - не гарантия высокой скорости чтения из глобал мемори, т.к. это чтение - очень многофакторная штука и больше зависит от тактовой частоты, нежели от ширины шины. Я в своё время игрался с шинами HBM и честно сказать - какого-то крутого прироста я не заметил (если не сказать обратного), всё это больше похоже на маркетинговый трюк, т.к. на профессиональные карты (где есть HBM) - это больше маркетинговый трюк, нежели реальный перворменс; единственное из-за чего стоит брать всякие nvidia tesla - больше количество вычислительных блоков для double, если они конечно вам нужны. Тактовые частоты памяти на проф. картах намного ниже, чем на игровых, поэтому весь этот гон, что мол смотрите, у нас HBM память, типа огромная пропускная способность - и ломанного гроша не стоит. Это как с руслом реки, в узким местах скорость воды больше (игровые GPU), а в широких - меньше (русло шире - HBM, но частоты - меньше), а результат - русло несёт одно и тоже количество воды.
Более того, сам процессор GPU не читает огромными блоками, нитки (стрэнды) warp-ов, если я не ошибаюсь, могут за раз прочитать только 16 байт (под vec4), целиком warp (32х) может стянуть 512 байт получается, но сам контроллер DRAM не даст читать такой блок за раз, скорее всего он его разобьёт на множественное чтение почками по 128 байт, он так устроен. Поэтому, считать количество чтений в шейдере из глобал мемори - дохлый номер, контроллер DRAM их сделать столько, сколько посчитает нужным и скорее всего больше, чем ты думаешь.

Ещё здесь на счёт ширины шины и кеш-ей могу сказать, что было бы круто, если бы GPU читал в кеш VVVV) (NNNN) (CCCC) и весь без остатка этот кеш использовали бы другие, предназначенные для этих данных пиксели, но по факту кеш то маленький и на все пиксели его не хватит, а все пиксели рендеряться то параллельно (по крайней мере так считается), поэтому с большой долей вероятности будет многократный кеш-резет, хотя опять же, всё это лишь догадки, т.к. в рендерах у нас нет возможности вручную управлять кеш-ом, в отличии от вычислений на GPU, где мы можем явно задействовать шаред мемори (кеш). Оптимизировать рендеры под размера кеша или разрядность шины памяти - гнилое дело, у тебя нет над этим контроля, всё это может поменяться в любом момент.

Вот если бы в рендерах можно было использовать кеш между кадрами, например, намеренно загнать какую-то часто используемую текстуру туда или микро вертекс буфер или какие-то другие данные - вот тогда можно было бы говорить об оптимизациях, но всего этого сделать нельзя и GPU сам решает, что туда положить, а по сколько у GPU нет True AI и он ничего не знает о вашем коде - сделать это оптимально он не сможет никогда.

p.s.: синтаксические ошибки не проверял, лень перечитывать свой пост :)

THE_MASTER
Гениально

Ладно THE_MASTER двоечник.

Почему GPU - это новые Короли Кэша?
https://i2hard.ru/publications/34123/?ysclid=lx5oqmd4us469969044

А ты то Иннуендо куда ?

Юзать GPU кэш это пореже менять шейдеры и почаще юзать DrawInstanced и мелкие текстуры 512х512(желательно dds).

Через DrawInstanced отрисовал сотни планок(одна буква) текста , уже профит.
Через DrawInstanced и один общий шейдер отрисовал сотни деревьев, камней и 10 000 травинок , уже профит от кэша.

ronniko
> Через DrawInstanced отрисовал сотни планок(одна буква) текста
Клоун, кеш для инстансов может помочь как раз только в том случае, если весь меш модели помещяется в этот кеш, в противном случае на каждый инстан будешь читать весь меш из глобал мемори заново, поэтому по факту этот кеш в инстансинге годится только для твоих планок из 4х вертексов, но велика ли будет выгода хрань в кеше твои сраные 4 вертекса? На филрейте потеряешь намного больше.

В случае твоих деревьев на инстансе, ты получаешь буст только за счёт синг дроу кол-а,
т.к. без него ты бы рисовал всё циклом, не умея создавать монолитный буфер.

Более того, в данном треде нет инстансинга.