- innuendo
- Постоялец
VirT
>Ну, про Винду сложно сказать почему так, там в драйвер особо не залезешь
ну т.е. все о чем ты так с упоением говориш, мол все стало чудесно и т.д для винды не соответствует истине.
а для консолей пишут не все.
VirT
> В начале рендера ты все отправляешь на окклюжен тест, потом делаешь другие
> проходы, которые от этого теста не зависят
ну имелось ввиду ZOnlyPass, то есть никаких 'с предыдущего кадра' и flush, если не готов результат считаем что виден ?
VirT
> Ну, про Винду сложно сказать почему так, там в драйвер особо не залезешь. На
> Маке можно еще посмотреть вызовы драйвера по OpenGL Profiler, так вот он
> показывал, что куча времени уходит на формирование следующего пакета для
> видеокарты (следуюшего после ридбека)
возможно тут дело именно в GL для мака
не знаю, у меня получалось что под GL HOQ шустрее был чем на DX9, это на XP было
истина одна, правд много :)
В принципе, если есть тени, особенно каскаднъе - то тогда можно их вставить пока ждем или результата HWOC или сам буфер, да.
Outlaw
> ну т.е. все о чем ты так с упоением говориш, мол все стало чудесно и т.д для
> винды не соответствует истине.
Ситуация была примерно такая: ОГЛ на винде примерно на 15-20% медленнее, чем ДХ. На Маке еще на 15-20% медленнее, чем ОГЛ на винде. Тот патч примерно компенсировал резницу между ОГЛ на Маке и на Винде.
Цифры эти с разных !реальных! проектов и разных компаний!
Внимание! На синтетическом тесте, который рендерил около 3000 DIP'ов с несложным шейдером, переключением стейтов и т.п. скорость получалась примерно равной DXовой.
innuendo
> то есть никаких 'с предыдущего кадра' и flush, если не готов результат считаем
> что виден ?
Подробностей не знаю, к сожалению.
innuendo
> истина одна, правд много :)
вот это точно )
innuendo
> имеется ввиду - что ты вводишь людей в заблуждение относительно пользы HOQ :)
Эй, да ладно ))) Никого никуда вводить не хотел )
Тот, который встроенный HOQ, я не считаю полезным, собственно по этому в DX11 появился Conditional Rendering. Я просто сказал, что даже его можно использовать и люди так и делают. Просто не стоит занимать крайние позиции и говорить, что это непобедимое зло )) Это как СТЛ или СТЛ на консолях, или ЛУА на консолях... да есть проблемы с использованием, да кому-то не нравится, да у кого-то есть отрицательный опыт. Но у кого-то есть и положительный, кто-то использует и никак особо негативно на проекте, движке или процессе разработки это не сказывается.
innuendo
> тебе укажут, что ты живёшь в фантезийном мире и всё такое
Не можеш ли свои базаръ перенести в чат, а не в каждом втором сообщении писать отсебятину?
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).
Это теория не подтвержденная осциллографом, но по поверхностным тестам примерно так и получается
shekh
проблема в том что без двойной буферизации вроде никто не рисует. и пока ты заполняешь текущий кадр гпу рисует предыдущий. и вбланк ждёт предыдущий
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", так что все как раз.
shekh
> Это теория не подтвержденная осциллографом, но по поверхностным тестам примерно
> так и получается
собственно так и делается при мультипассах
интересно, а oq что в Froblins это софтварный или аппаратный ? :)
innuendo
> интересно, а oq что в Froblins это софтварный или аппаратный ? :)
Софтварный на GPU :) И с чтением данных с GPU =\
NULL_PTR
> И с чтением данных с GPU =\
не понял про чтение, что имелось ввиду ?
innuendo
> не понял про чтение, что имелось ввиду ?
На CPU запрашивается размер stream out буфера и идёт синхронизация CPU с GPU. Поэтому им приходится считать АИ для следующего кадра, чтобы к моменту запроса была больше вероятность, что результат куллинга готов.
NULL_PTR
я подумал, что ты имеешь ввиду чтение HiZ на CPU :)
Тема в архиве.