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

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

Страницы: 1 2 Следующая »
#0

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

6 ноя. 2018

#1

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

6 ноя. 2018

#2

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

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

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

#3

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

6 ноя. 2018

#4

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

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

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

6 ноя. 2018

#5

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

+ Показать

6 ноя. 2018

#6

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

6 ноя. 2018

#7

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

6 ноя. 2018

#8

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

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

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

11 ноя. 2018

#9

Danilw

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

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

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

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

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

#10

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

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

#11
mssao

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

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

#12

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

11 ноя. 2018

#13

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

11 ноя. 2018

#14
/A\
> есть подозрение что ssao и hbao полная херня не имеющая ничего общего с
> реальным AO
Ну а что делать-то?
Да и если серьезно, тот же пбр (не с рейтрейсингом) мало имеет отношения к реальной жизни из-за огромного числа допущений.

11 ноя. 2018

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика