Тёмная тема
- innuendo
- Постоялец
_Wizard_
> кучу glDrawElementsInstanced за 1 вызов... +можно собирать информацию о дипах
> на ГПУ
Ох! После вашего комента до меня дошло :)
А DIP'ы обычно считают по количеству вызовов gl...Draw... на CPU? Или по факту, сколько было на GPU?
"Batch" - количество биндингов шейдеров и буферов вместе с glMultidrawElementsIndirect?
Ещё я вот заценил код тестов... Наткнулся на
//NOTE: seems data transfering is not bottle neck
Действительно ли всё так?
И в чем смысл от GL_DRAW_INDIRECT_BUFFER, если инфа всё равно каждый раз изменяется на CPU?
Как правильно использовать .instanceCount? Например в батче лежит объект, который должен быть выведен 1000 раз. Неужели всегда придётся создавать отдельные 1000 draw_indirect_commands?
И я так посчитал... Например мы хотим сразу вывести 1'000'000 обжектов. Каждая команда - 20 байт. В итоге каждый кадр надо передавать 20*1'000'000/(1024^2) = ~19 мб данных. То есть это произойдет почти мгновенно? А если речь о 190 мб? :)
Laynos
> И в чем смысл от GL_DRAW_INDIRECT_BUFFER, если инфа всё равно каждый раз
> изменяется на CPU?
Ты точно понимаешь смысл indirect draw?
innuendo
> Ты точно понимаешь смысл indirect draw?
Перенести gl...Draw... на GPU. Каждый вызов API OpenGL - проверка со стороны драйвера, это замедляет работу движка.
А glMultidraw - один вызов, всё остальное идет на видеокарте. AZDO или что-то там, вроде
Laynos
> Перенести gl...Draw... на GPU.
Почитай доки
Laynos
>Например в батче лежит объект, который должен быть выведен 1000 раз. Неужели всегда придётся создавать отдельные 1000 draw_indirect_commands?
нет... это у меня пример такой просто... читаем доки в общем
дипы на ЦПУ, glDraw*
>И в чем смысл от GL_DRAW_INDIRECT_BUFFER, если инфа всё равно каждый раз изменяется на CPU?
1. так надо) информация должна лежать в этом буфере. Причем оно даже работать будет если напрямую передать, но так не правильно делать - читаем спецификацию
2. можно залить туда данные 1 раз и переиспользовать (несколько кадров/проходов)
3. инфу можно готовить на ГПУ
>//NOTE: seems data transfering is not bottle neck
>Действительно ли всё так?
в данном случае, не более того...
итоговая производительность зависит от кучи всего: количества данных, с какими флагами мапить буфер, в какой момент ты захочешь эти данные заиспользовать, какая шина у карточки...
>И я так посчитал...
1кк - очень много) но я видел похожие примеры - нормально работало
Ребят, довольно тупой вопрос, вот смена фреймбуфера - это дорогая операция, а если менять приаттаченную текстуру, а сам FBO оставить тем же, в рамках производительности - это то же самое или нет? Вообще странный вопрос возникает, зачем менять забинденный fbo если можно приаттачить другую текстуру?
Запускал в убунту под вайном, программа сама не завершилась, закрылась эскейпом, так и должно быть?
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz GPU: GeForce GTX 650 Ti/PCIe/SSE2 Parameters: CURRENT_NUM_INSTANCES 1000 NUM_FBO_CHANGES 200 INSTANCING_NUM_ITERATIONS 100. Time in ms. ---States changing time: SIMPLE_DIPS_TEST 0.18 FBO_CHANGE_TEST 1.96 SHADERS_CHANGE_TEST 2.32 VBO_CHANGE_TEST 0.26 ARRAY_OF_TEXTURES_TEST 0.91 TEXTURES_ARRAY_TEST 0.26 UNIFORMS_SIMPLE_CHANGE_TEST 0.74 UNIFORMS_SSBO_TEST 0.24 ---API call cost: glBindFramebuffer: 9.62 5468% glUseProgram: 2.14 1215% glBindVertexArray: 0.08 46% glBindTexture: 0.12 69% glDrawRangeElements: 0.18 100% glUniform4fv: 0.06 31% ---Instancing time: cpu time (gpu time) num instances 50 100 200 UBO_INSTANCING 0.43 (0.10) 0.47 (0.17) 0.54 (0.30) TBO_INSTANCING 1.11 (0.59) 1.14 (0.66) 1.20 (0.80) SSBO_INSTANCING 0.47 (0.10) 0.50 (0.17) 0.58 (0.31) VBO_INSTANCING 0.41 (0.10) 0.44 (0.17) 0.53 (0.30) TEXTURE_INSTANCING 0.50 (0.10) 0.53 (0.17) 0.61 (0.30) UNIFORMS_INSTANCING 0.46 (0.10) 0.50 (0.17) 0.66 (0.40) MULTI_DRAW_INDIRECT_INSTANCING 0.54 (0.46) 0.63 (0.57) 0.85 (0.77)
Windows 7 x64, 16 Гб
CPU: AMD FX(tm)-8350 Eight-Core Processor GPU: GeForce GTX 760/PCIe/SSE2 Parameters: CURRENT_NUM_INSTANCES 1000 NUM_FBO_CHANGES 200 INSTANCING_NUM_ITERATIONS 100. Time in ms. ---States changing time: SIMPLE_DIPS_TEST 0.42 FBO_CHANGE_TEST 2.18 SHADERS_CHANGE_TEST 2.66 VBO_CHANGE_TEST 0.43 ARRAY_OF_TEXTURES_TEST 1.75 TEXTURES_ARRAY_TEST 0.36 UNIFORMS_SIMPLE_CHANGE_TEST 0.88 UNIFORMS_SSBO_TEST 0.36 ---API call cost: glBindFramebuffer: 10.48 2470% glUseProgram: 2.24 527% glBindVertexArray: 0.00 0% glBindTexture: 0.22 52% glDrawRangeElements: 0.42 100% glUniform4fv: 0.05 10% ---Instancing time: cpu time (gpu time) num instances 50 100 200 UBO_INSTANCING 0.59 (0.08) 0.73 (0.12) 1.01 (0.22) TBO_INSTANCING 1.20 (0.69) 1.34 (0.70) 1.62 (0.80) SSBO_INSTANCING 0.62 (0.07) 0.77 (0.12) 1.02 (0.22) VBO_INSTANCING 0.57 (0.08) 0.73 (0.13) 0.99 (0.22) TEXTURE_INSTANCING 0.67 (0.07) 0.79 (0.12) 1.19 (0.22) UNIFORMS_INSTANCING 0.62 (0.08) 0.81 (0.14) 1.19 (0.57) MULTI_DRAW_INDIRECT_INSTANCING 0.60 (0.52) 0.72 (0.64) 0.96 (0.86)
CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GPU: TITAN X (Pascal)/PCIe/SSE2 Parameters: CURRENT_NUM_INSTANCES 1000 NUM_FBO_CHANGES 200 INSTANCING_NUM_ITERATIONS 100. Time in ms. ---States changing time: SIMPLE_DIPS_TEST 0.30 FBO_CHANGE_TEST 2.01 SHADERS_CHANGE_TEST 2.28 VBO_CHANGE_TEST 0.38 ARRAY_OF_TEXTURES_TEST 1.16 TEXTURES_ARRAY_TEST 0.36 UNIFORMS_SIMPLE_CHANGE_TEST 0.78 UNIFORMS_SSBO_TEST 0.38 ---API call cost: glBindFramebuffer: 9.77 3279% glUseProgram: 1.98 665% glBindVertexArray: 0.09 28% glBindTexture: 0.14 47% glDrawRangeElements: 0.30 100% glUniform4fv: 0.05 16% ---Instancing time: cpu time (gpu time) num instances 50 100 200 UBO_INSTANCING 0.42 (0.04) 0.43 (0.09) 0.43 (0.17) TBO_INSTANCING 3.04 (2.86) 3.03 (2.84) 2.84 (2.65) SSBO_INSTANCING 0.48 (0.04) 0.48 (0.09) 0.47 (0.14) VBO_INSTANCING 0.41 (0.04) 0.41 (0.09) 0.41 (0.14) TEXTURE_INSTANCING 0.50 (0.04) 0.49 (0.09) 0.51 (0.14) UNIFORMS_INSTANCING 0.46 (0.05) 0.48 (0.09) 0.54 (0.14) MULTI_DRAW_INDIRECT_INSTANCING 0.54 (0.45) 0.61 (0.53) 0.67 (0.60)
MAMOHT-92
> а если менять приаттаченную текстуру, а сам FBO оставить тем же, в рамках
> производительности - это то же самое или нет?
Думаю это хуже, в вулкане например ты создаешь фреймбуфер сразу со всеми аттачами, чтобы их поменять придется пересоздать фреймбуфер.
Формировать поток рендер-команд на лету и мерять их время - это уже анахронизм.
После Вулкана с его прекомпилированными state objects и запечённых комманд-буферов - выглядит просто ужасно.
MAMOHT-92
> а если менять приаттаченную текстуру, а сам FBO оставить тем же, в рамках
> производительности - это то же самое или нет
Будет дороже.
> Вообще странный вопрос возникает, зачем менять забинденный fbo если можно
> приаттачить другую текстуру?
Вообще если там посмотреть, то много вопросов возникает. Зачем вообще делать VAO, если можно каждый раз биндить буфера. Зачем биндить буфера, если можно каждый раз делать glBufferData. Зачем менять program, если можно каждый раз шейдера менять, и т.п.
MrShoor
> Зачем менять program, если можно каждый раз шейдера менять
это как?
innuendo
> это как?
glDetachShader glAttachShader glLinkProgram
Апну тему. Не проводил ли кто-нибудь замеры стоимости рендеринга одинаковых мешей с разными vertex layout/vertex buffer format?
Например:
(VVVV) (NNNN) (CCCC)
(VVVVNNNNCCCC)
(VNCVNCVNCVNC)
Подробнее можно посмотреть тут:
https://www.khronos.org/opengl/wiki/Vertex_Specification_Best_Practices
От туда ясно, что
The optimal layout depends on the specific GPU and driver (plus OpenGL implementation)
Это в теории, но хотелось бы узнать, как дело обстоит на практике.
Тема в архиве.