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

Software Occlusion Culling (комментарии) (8 стр)

Страницы: 14 5 6 7 8 9 Следующая »
#105
15:32, 6 апр. 2011

VirT
>Ну, про Винду сложно сказать почему так, там в драйвер особо не залезешь
ну т.е. все о чем ты так с упоением говориш, мол все стало чудесно и т.д для винды не соответствует истине.
а для консолей пишут не все.


#106
15:32, 6 апр. 2011

VirT
> В начале рендера ты все отправляешь на окклюжен тест, потом делаешь другие
> проходы, которые от этого теста не зависят

ну имелось ввиду ZOnlyPass, то есть никаких 'с предыдущего кадра' и flush, если не готов результат считаем что виден  ?

VirT
> Ну, про Винду сложно сказать почему так, там в драйвер особо не залезешь. На
> Маке можно еще посмотреть вызовы драйвера по OpenGL Profiler, так вот он
> показывал, что куча времени уходит на формирование следующего пакета для
> видеокарты (следуюшего после ридбека)

возможно тут дело именно в GL для мака
не знаю, у меня получалось что под GL HOQ шустрее был чем на DX9, это на XP было


истина одна, правд много :)

#107
16:11, 6 апр. 2011

В принципе, если есть тени, особенно каскаднъе - то тогда можно их вставить пока ждем или результата HWOC или сам буфер, да.

#108
16:17, 6 апр. 2011

Outlaw
> ну т.е. все о чем ты так с упоением говориш, мол все стало чудесно и т.д для
> винды не соответствует истине.
Ситуация была примерно такая: ОГЛ на винде примерно на 15-20% медленнее, чем ДХ. На Маке еще на 15-20% медленнее, чем ОГЛ на винде. Тот патч примерно компенсировал резницу между ОГЛ на Маке и на Винде.
Цифры эти с разных !реальных! проектов и разных компаний!
Внимание! На синтетическом тесте, который рендерил около 3000 DIP'ов с несложным шейдером, переключением стейтов и т.п. скорость получалась примерно равной DXовой.
innuendo
> то есть никаких 'с предыдущего кадра' и flush, если не готов результат считаем
> что виден ?
Подробностей не знаю, к сожалению.
innuendo
> истина одна, правд много :)
вот это точно )

#109
16:34, 6 апр. 2011

innuendo
> имеется ввиду - что ты вводишь людей в заблуждение относительно пользы HOQ :)
Эй, да ладно ))) Никого никуда вводить не хотел )
Тот, который встроенный HOQ, я не считаю полезным, собственно по этому в DX11 появился Conditional Rendering. Я просто сказал, что даже его можно использовать и люди так и делают. Просто не стоит занимать крайние позиции и говорить, что это непобедимое зло )) Это как СТЛ или СТЛ на консолях, или ЛУА на консолях... да есть проблемы с использованием, да кому-то не нравится, да у кого-то есть отрицательный опыт. Но у кого-то есть и положительный, кто-то использует и никак особо негативно на проекте, движке или процессе разработки это не сказывается.

#110
17:56, 6 апр. 2011

innuendo
> тебе укажут, что ты живёшь в фантезийном мире и всё такое
Не можеш ли свои базаръ перенести в чат, а не в каждом втором сообщении писать отсебятину?

#111
19:13, 6 апр. 2011

Z
>В принципе, если есть тени, особенно каскаднъе - то тогда можно их вставить пока ждем или результата HWOC или сам буфер, да.

А собственно в чем проблема.
Допустим такой пример:

0) отправляем примитивов
1) отправляем примитив для OQ
2) отправляем тонну примитивов
(до сюда все это на cpu отнимает например >1мс)
3) считываем результат OQ
4) отправляем еще тонну примитивов
5) present, повтор цикла

Здесь 2 потенциальные точки синхронизации: (3) и (5).
Допустим ничто ни во что не упирается кроме vblank, тогда синхронизация только в (5), т.о. с (0) cpu и gpu начинают одновременно.
Тогда чтобы не было больше никаких простоев нужно:
(0 на gpu) < (2 на cpu) < (2 на gpu)

При таких условиях в п. (3) примитив OQ будет уже отрендерен и результат OQ физически готов, вопрос только в том как далеко он от общей памяти.
Если он пересылается хотя бы не через емейл, то почему бы ему идти долго.

Допустим (2 на cpu) > (2 на gpu) и gpu на этом этапе имеет пузырь.
Тогда результат OQ тем более должен быть готов, кроме того синхронизация из (5) может убраться (скроется в 2).

Это теория не подтвержденная осциллографом, но по поверхностным тестам примерно так и получается

#112
19:15, 6 апр. 2011

shekh
проблема в том что без двойной буферизации вроде никто не рисует. и пока ты заполняешь текущий кадр гпу рисует предыдущий. и вбланк ждёт предыдущий

#113
20:18, 6 апр. 2011

kas
да, с буферизацией констрейны меняются

1) подготовка сцены
2) отправляем примитивов
3) отправляем примитив для OQ
4) отправляем тонну примитивов
(до сюда все это на cpu отнимает например >1мс)
5) считываем результат OQ
6) отправляем еще тонну примитивов
7) present, повтор цикла

Допустим в (5) gpu занят забуферизованой работой (6), и еще новой (2).
Тогда в (5) будет синхронизация.
Однако если  (6+2 на gpu) < (1+4 на cpu) то вместо этого будет пузырь для gpu например где-то в процессе (1).
А это и есть "cpu limited", так что все как раз.

#114
21:29, 6 апр. 2011

shekh
> Это теория не подтвержденная осциллографом, но по поверхностным тестам примерно
> так и получается
собственно так и делается при мультипассах

#115
8:13, 7 апр. 2011

интересно, а oq что в Froblins это софтварный или аппаратный ? :)

#116
10:20, 7 апр. 2011

innuendo
> интересно, а oq что в Froblins это софтварный или аппаратный ? :)
Софтварный на GPU :) И с чтением данных с GPU =\

#117
10:24, 7 апр. 2011

NULL_PTR
> И с чтением данных с GPU =\

не понял про чтение, что имелось ввиду ?

#118
10:35, 7 апр. 2011

innuendo
> не понял про чтение, что имелось ввиду ?
На CPU запрашивается размер stream out буфера и идёт синхронизация CPU с GPU. Поэтому им приходится считать АИ для следующего кадра, чтобы к моменту запроса была больше вероятность, что результат куллинга готов.

#119
11:38, 7 апр. 2011

NULL_PTR
я подумал, что ты имеешь ввиду чтение HiZ на CPU :)

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

Тема в архиве.