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

OpenGL: стоит ли конструировать FBO каждый кадр или лучше все создать заранее один раз?

Страницы: 1 2 Следующая »
#0
0:18, 6 ноя. 2018

Вопрос производительности, FBO около 15 штук


#1
0:24, 6 ноя. 2018

Создание объектов на лету - зло. Так что второе )

#2
(Правка: 0:27) 0:27, 6 ноя. 2018

BingoBongo
Сам то как думаешь?

vindast
> Создание объектов на лету - зло
Тут надо уточнить, что речь идет о одноразовых, а не о ленивой инициализации например.

#3
0:30, 6 ноя. 2018

Great V.
> Тут надо уточнить, что речь идет о одноразовых, а не о ленивой инициализации
> например.
По хорошему, нужно выделять память заранее, желательно, в виде буферов. Раз пошла такая пьянка.

#4
1:40, 6 ноя. 2018

1. в вулкане, и CUDA считают(и говорят на видосах что я смотре, от девелоперов)
что статические текстуры до гигабайта размером лучше хранить в RAM (так и делают в DX11/12 в ГТА5 например), подключая их по необходимости во время рендера
только если у вас 2гб(например) текстура всего, которая нужна всем шейдерам, то ее пихать в видеопамять

2. во всех туториалах по 2д от кронос-а, говориться буквально-"рендерите как хотите, текущих мощностей хватит чтоб покрыть практически любой даже самый неправильный подход"

создавая фреймбуфер и рендеря в него, все останется в видеокарте, это плохо (да в вулкане/DX12 можно указывать расположение буферов в RAM)

#5
2:00, 6 ноя. 2018

На всякий случай, выбор между:

+ Показать

#6
3:43, 6 ноя. 2018

пока памяти хватает делай как угодно, как мало станет тогда и оптимизируй динамической загрузкой

#7
14:29, 6 ноя. 2018

BingoBongo
> Вопрос производительности, FBO около 15 штук
скорее вопрос занятой памяти. Если FBO не являются частью MRT, их можно перезаюзывать для других нужд.

#8
18:34, 11 ноя. 2018

Мне начинает закрадываться смутное подозрение, что, кроме переключения стейтов в устаревших апи, гпу грузят те же вещи, что и цпу - включая то, укладываются ли обрабатываемые конкретными потоком данные в кеш. Магии-то никакой нет, гпу очень похож на цпу, только специализированный, стоядерный. Плохо оптимизированные обращения к памяти его бьют точно так же.

То есть, смотреть надо на пропускную способность памяти.

Конкретно: я издевался над пиксельным шейдером, делая дохрена выборок из огромной текстуры, с билинейной фильтрацией. Пока они все ложились кучно, в крошечной области, гетто-железка "стыдно уже иметь такую в 2012-м" держала до 30 выборок на пиксел в FullHD. Но стоило начать увеличивать диаметр области, из которой шла выборка - всё, сушите вёсла, слайд-шоу.
(и да, это был встроенный intel HD 3000)

#9
(Правка: 18:49) 18:41, 11 ноя. 2018

Danilw

что статические текстуры до гигабайта размером лучше хранить в RAM

Какое это имеет отношение к FBO ?!
Ты опять какую то дичь пишешь.

BingoBongo лучше скажи для чего 15 FBO создаешь ? Многовато 15 FBO.
А то не понятен мотив.
Может и не придется делать так как ты сейчас делаешь.

Например если ты рендеришь дифферед то обычно:
1) создают один раз нужное число FBO.
2) Потом их переключают\чистят в рендере и делают в них рендер нужного.
3) Игровой цикл на пункт 2)

#10
(Правка: 19:25) 19:24, 11 ноя. 2018

ronniko
> лучше скажи для чего 15 FBO создаешь
downscale и вычисления в каждом mip уровне в mssao

#11
(Правка: 19:29) 19:26, 11 ноя. 2018
mssao

https://www.slideshare.net/ozlael/mssao-presentation

#12
19:37, 11 ноя. 2018

Угу, есть более новое и нормальное описание https://www.comp.nus.edu.sg/~lowkl/publications/mssao_visual_computer_2012.pdf (правда, есть подозрение, что все это херня супротив обычного hbao)

#13
21:12, 11 ноя. 2018

BingoBongo
> есть подозрение, что все это херня
есть подозрение что ssao и hbao полная херня не имеющая ничего общего с реальным AO

#14
21:56, 11 ноя. 2018
/A\
> есть подозрение что ssao и hbao полная херня не имеющая ничего общего с
> реальным AO
Ну а что делать-то?
Да и если серьезно, тот же пбр (не с рейтрейсингом) мало имеет отношения к реальной жизни из-за огромного числа допущений.
Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика