Войти
ПрограммированиеФорумГрафика

Тормоза из-за glBufferData() (Решено.) (5 стр)

Страницы: 14 5 6 7 8 Следующая »
#60
(Правка: 11:01) 10:58, 31 дек. 2019

> В целом время такое же как на последней гифке.
Хм. ок. Кстати, а можешь побыстрому перекомпилировать, но с памятью объёмом не 6...7,5 Гб, а 2,5...3. И выложить. Я запущу, посмотрю, как оно у меня работает.

И да, я тут RenderDoc запустил. У меня 5000 вызовов glDrawElements(). Это куски крупных VBO, которые попали в поле зрения камеры.

*** Summary ***

Draw calls: 1039
Dispatch calls: 0
API calls: 4859
API:Draw/Dispatch call ratio: 4.67661

45 Textures - 101.82 MB (101.82 MB over 32x32), 19 RTs - 43.73 MB.
Avg. tex dimension: 839.538x823.385 (872.96x856.16 over 32x32)
1079 Buffers - 406.80 MB total 25.48 MB IBs 381.32 MB VBs.
552.35 MB - Grand total GPU buffer + texture load.


Это за один кадр. О том, что не рисуется за камерой, renderdoc не знает.
#61
11:06, 31 дек. 2019

romanshuvalov
> Хм. ок. Кстати, а можешь побыстрому перекомпилировать, но с памятью объёмом не
> 6...7,5 Гб, а 2,5...3. И выложить. Я запущу, посмотрю, как оно у меня работает.
Вот, держи, 500 буферов того размера, который ты просил сделать. Поидее должно быть около 3Гб, может чуть больше.
Instancing

#62
11:21, 31 дек. 2019

romanshuvalov
Там если что в семпле не Core контекст создается. Если вдруг нужен Core контекст, то скажи какой версии тебе его сделать.

#63
11:24, 31 дек. 2019

Здрасьте :) 7-11 мс с периодическими прыжками до 40-60 мс.

glBufferData задержки | Тормоза из-за glBufferData() (Решено.)

#64
11:28, 31 дек. 2019

Кстати, так и не выяснено же, кто виноват - объём памяти или фрагментация.

#65
11:32, 31 дек. 2019

romanshuvalov
> Здрасьте :) 7-11 мс с периодическими прыжками до 40-60 мс.
Хех, интересно драйвер пляшет. Тогда вот тебе еще версия:
Instancing_v1
Изменения:
1. Создается Core контекст 4.5
2. Буфер не удаляется через glDeleteBuffers а резюзается
3. Реюз использует трюк с nullptr и Named функциями:

      glNamedBufferDataEXT(FHandle, 0, nil, GLPoolType[FTargetPool]);
      glNamedBufferDataEXT(FHandle, ASize, Data, GLPoolType[FTargetPool]);  
Можешь чекнуть есть те же тормоза или нет?
#66
11:37, 31 дек. 2019

romanshuvalov
Кстати в обоих семплах ты с помощью Ctrl+A можешь переключиться на DX11 и обратно. Только смотри чтобы фокус был на окне с рендером, а не на консоли.

#67
11:57, 31 дек. 2019

MrShoor
> Можешь чекнуть есть те же тормоза или нет?
Без изменений, точно такие же тормоза, что и без трюка.

> можешь переключиться на DX11 и обратно
На DX11 2-3 мс, тормозов нет. При переключении на OpenGL 6-7 мс, а через некоторое время снова появляются те же прыжки до ~50 мс, что и на скриншоте выше. Кстати, при инициализации поведение тоже такое же: сначала чистенькие 6-7 мс, затем стабильно по 50-60 и даже 100 мс, и возврат к 7 мс только после создания окна.

А можешь сделать версию с регулируемым объёмом данных? Т.е. вместо фиксированных 500 объектов дай возможность задать их количество (например, параметром запуска). Проверю, будет ли проблема при малом количестве объектов (если да, то виновата фрагментация, если нет, то виноват перенос данных с RAM в VRAM).

#68
(Правка: 12:17) 12:01, 31 дек. 2019

Совсем забыл написать, На OpenGL у меня срабатывает VSync, даже если он принудительно выключен в настройках nVidia. Забыл применить. Проверил, ни включенный, ни отключенный VSync ни на что не влияет.

И ещё, при запуске fps всегда около 45-50. После переключения на DX fps взлетает до 300, после обратного переключения на OpenGL падает ровно до 60 (это уже vsync).

#69
(Правка: 12:29) 12:28, 31 дек. 2019

MrShoor
> glBufferSubData
Мем цпу + мап / анмап
MrShoor
> 5 тысяч VBO - не такая уж и много. Даже если все они в кадре. А у него даже не
> все 5К в кадре.

Я надеюсь что это не террейн так рисуют )

romanshuvalov
> Что конкретно это даст? Какой функционал крайне полезен? (Название, чтоб я
> погуглил.)
Дает возможность юзать мап / анмап буфер (glMapBuffer  / glUnmapBuffer) + инстансинг.

romanshuvalov
> и 2 Гб данных (которые при таком подходе разбухнут до 2,5 Гб)
Что там за геометрия то такая? Что ее 2гб.

Посмотрел что MrShoor наворотил, стало интересно.
Вы меня возбудили не на шутку. После нг сделаю vao с возможностью динамического расширения. Надо будет сравнить скорость создания / удаления объектов и эффективность по памяти. Аж самому интересно стало.

#70
(Правка: 12:31) 12:30, 31 дек. 2019

Короче, единственно верное решение следующее: не хранить всё в VBO, вместо этого создать несколько крупных VBO (аллокация видеопамяти), геометрию хранить в оперативной памяти, при приближении игрока к точке возможного показа геометрии - переносить готовую геометрию из оперативки в VBO через glBufferSubData. Таким образом вместо 2,5 Гб VRAM мне потребуется 2,5 Гб RAM, а видеопамяти ровно столько, сколько нужно для размещения геометрии, непосредственно отрисовываемой в кадре (мегабайт 300-400, но можно задействовать и 1 Гб, чтобы при перемещении игрока туда-сюда и/или вращения камеры на 180 градусов избежать лишних подгрузок).

Займусь после нового года.

#71
12:35, 31 дек. 2019

vindast
> Что там за геометрия то такая? Что ее 2гб.
Крупная часть города. Грузится около 5х5 км.

#72
(Правка: 12:43) 12:39, 31 дек. 2019

romanshuvalov
компрессией формата вершин тоже стоит заняться. Если модельки в мелком масштабе как у тебя и глобальная позиция всё равно задается матрицей то 6 байт на позицию спокойно хватит, еще 3 байта на нормаль, 2 байта на uv итого 16 байт (5 байт в запас).

#73
12:43, 31 дек. 2019

romanshuvalov
> я тут RenderDoc запустил
Как такую статистику собирать вообще? Какую кнопку нажать?

#74
13:01, 31 дек. 2019

lookid
скачай да посмотри, создашь "проект", указываешь в нем своё приложение, запускаешь его из rd и собираешь инфу. Можешь в любой момент поставить на паузу и собирать статистику за кадр или вовсе рисовать по одному примитиву.

Страницы: 14 5 6 7 8 Следующая »
ПрограммированиеФорумГрафика