- bykabak
- Постоялец
Frustum Culling (комментарии)
Это сообщение сгенерировано автоматически.
Почему transform feedback, а не compute shaders? Может быстрее выйдет.
Нового не нашел, но статейка хорошая. Раньше бы сократила время.
Отличная статья. Благодарю.
Отдельная благодарность за ссылки по теме после статьи.
Mira
bykabak
>Отличная статья. Благодарю.
спасибо
HplusDiese
>Почему transform feedback, а не compute shaders? Может быстрее выйдет.
не думаю, что быстрее через compute. Проверять надо.
transform feedback - DX10 железо, compute shaders - DX11 железо.
Да и смысл был - просто показать что на GPU делать кулинг - быстро + есть плюшки в виде Hierarchical-Z map based occlusion кулинга.
Хочу еще раз заметить что кулится 100к объектов! Это надо ОЧЕНЬ постараться чтобы в сцене (вокруг игрока) столько было.
Мелкие объекты просто выбрасываются, если далеко от игрока - их кулить не надо. Так что 100к объектов - это овер дофига.
А возможно расписать в подробностях как формируются frustum_planes ? ( этого в статье нет )
_Wizard_
> не думаю, что быстрее через compute. Проверять надо.
Если организовать объекты не в виде точек, а как матрицы используемые уже для отрисовки самих объектов то плюс не придется лишний комит делать для точек.
SSE 1,2 1,45 4,63 SSE, multithreading 1,18 1,2 2,02 GPU 1,19
Получается если на SSE считать, то для GPU как раз всю производительность сожрет обмен данных.
Дополнительно если использовать физику/анимацию на GPU, то есть расчет матриц, то их не придется все время туда постить.
Кстати, из геометрического шейдера результат можно прочитать назад в CPU?
Меня интересовал вопрос передачи результата работы или отдельный пользовательский буфер геометрического шейдера одного объекта в другой. Чтобы побочные промежуточные результаты расчета для отрисовки можно было потом использовать и не считать заново.
Тоже хочу поиграться с gpgpu или на шейдере сделать. Simd дает вкусные результаты, а это в теории должно еще больше дать.
bykabak
>А возможно расписать в подробностях как формируются frustum_planes ? ( этого в статье нет )
в конце статьи можно скачать полный код всех примеров - там есть
foxes
>Получается если на SSE считать, то для GPU как раз всю производительность сожрет обмен данных.
>Дополнительно если использовать физику/анимацию на GPU, то есть расчет матриц, то их не придется все время туда постить.
да, когда на цпу считаешь, нужно передавать данные по шине
единственно - ты передаешь информацию только видимых инстансов
>Кстати, из геометрического шейдера результат можно прочитать назад в CPU?
на количество сгенерированных инстансов - делается запрос
//get feedback from prev frame
num_visible_instances = 0;
glGetQueryObjectiv(num_visible_instances_query[prev_frame], GL_QUERY_RESULT, &num_visible_instances);
сами данные ВИДИМЫХ инстансов пишутся в отдельный буфер (dips_texture_buffer), если их хочется получить - нужно лочить буфер... но не надо этого делать (лучше все на стороне гпу считать)
+DX11 железа в том, что можно использовать DrawIndirect... т.е. не нужно даже считывать количество сгенерированных инстансов на цпу - информацию о дипе можно сформировать на стороне гпу
_Wizard_
> +DX11 железа в том, что можно использовать DrawIndirect... т.е. не нужно даже
> считывать количество сгенерированных инстансов на цпу - информацию о дипе можно
> сформировать на стороне гпу
Да я сейчас так и делаю, но конкретно в своей задаче уперся в лимит [maxvertexcount(192)] на один поток, и приходится решение делать через повторение отрисовки одного и того же объекта с входными данными от предыдущей итерации, поэтому перенес все из геометрического шейдера в расчетный. Я стек рекурсии перенес на расчет в ширину, где каждый триангл это отдельная колонка (глубина) рекурсии. Как вариант ручной и достаточно глубокой тесселяции. Где стандартная тесселяция делает детализацию не более чем на 3 уровня - это как раз равно лимиту выходного maxvertexcount (DIVIDED_PARTS_COUNT^(3)*VERTEX_COUNT_PER_TRIANGLE=192) для одного прохода в геометрическом шейдере.
foxes
не очень может понял - ты делаешь тесселяцию на геометрических шейдерах / компуте?
не делай так)
есть специальные стадии конвеера/шейдера где это делается
_Wizard_
> есть специальные стадии конвеера/шейдера где это делается
Да, но глубина и результат в целом меня не удовлетворил, поэтому перенес на Compute. На самом деле очень быстро работает я вообще не вижу проседаний в FPS в сравнении с соответствующими стадиями шейдера. Примера как на обычной тесселяции сделать 16 делений в глубину (на каждом триангл делиться на 4) я не нашел максимум 3, и FPS уже очень проседает.
Как то прифигел от цифр:
Только кулинг 0,92
Весь кадр 1,94
для решения на cpu для 100к объектов это как то слишком офигенно....
——
не думаю, что быстрее через compute. Проверять надо.
У нас вот свой движок и весь scene graph на compute stage (там не только frustum culling).
Так вот у нас на 10к объектах вычислительная часть выполняется за 1.3 ms - это время в себя включает обновление world-матриц (ессесвено по необходимости, но в данном замере обновлялись все 10к) + сам frustum culling (у нас OBB) + всякие служебные операции (мы на выходе вычислительной части получаем готовые буферы для Multi draw indirect команд) + синхронизация (тоже вся на gpu, с host-ом синхронизации нет).
1.3 ms - это у меня получается на GTX 750-ой (проц не привожу, так на нем у нас ничего не делается кроме запекания pipeline-ов).
Для сравнения своего результата я брал Ogre-вский octree scene manager - он на той же самой сцене (10k объектов) выдает over 16 ms и до того как я прочитал эту статью, я думал, что у меня все хорошо...
Пойду застрелюсь....
Bave
> Пойду застрелюсь....
Уточните место работы