Войти
ПрограммированиеФорумОбщее

Применение многопоточности в играх. (Комментарии к статье) (5 стр)

Страницы: 14 5 6 710 Следующая »
#60
11:57, 14 ноя. 2003

Gnom
Ну, вот уже сколько я пытаюсь узнать, зачем это делать, считать во время Present (), который случается раз в три кадра... Потому что если мы обгоняем карту на несколько кадров, то я не вижу смысла увеличивать разрыв.

> Чтобы такого не случалось можно задать в D3DPRESENT_PARAMETERS.PresentationInterval
> D3DPRESENT_INTERVAL_IMMEDIATE
Во-первых, не спасет, а во-вторых - зачем с этим бороться? Это же как раз здорово что мы меньше синхронизуемся и ждем.


#61
12:00, 14 ноя. 2003

Семен
>"Такая" последовательность - чтобы во время рендера первого кадра считался
>следующий.
дык он рендериться-то не будет до тех пор, пока не сделаешь Present
>
>Насколько я понимаю, теперь мы уже говорим не об этом, а о переполнениях
>push-buffer'a, ага?
>Т.е. именно это - решающий фактор?
дык в том-то и дело, что в реальной ситуации Present и последующий рендер занимают значительное время и вот это время мы и не хотим упускать.
>
>Несколько фраз.
>AFAIK, размер push-buffer на Xbox регулируется, и чтобы вытащить его в большие
>мегабайты нужно действительно постараться с индексными буферами, которые
>большую часть его занимают.
>Второе - на XBox очень хороший фиксированный fps, и поэтому можно очень хорошо
>спланировать сколько нужно времени GPU и CPU, и не отдавать больше кадров чем
>надо.
>Это все очень поверхностные замечания, про XBox я знаю только понаслышке. Как
>на самом деле?
а что значит "хороший фиксированный"? 60/30/20/15/12/10?
интересно, как ты собрался планировать сколько времени нужно? брать по максимуму? т.е. если в каком-то случае возможно всё будет занимать 100 ms, то ставим фиксированный fps 10, даже там где легко могло быть 60?

#62
12:04, 14 ноя. 2003

Семен
>Ну, вот уже сколько я пытаюсь узнать, зачем это делать, считать во время
>Present (), который случается раз в три кадра... Потому что если мы обгоняем
>карту на несколько кадров, то я не вижу смысла увеличивать разрыв.
бли-и-ин... сколько раз говорить, не обгоняем мы карту, а считаем только следующий посылаемый кадр, который начнёт рендериться только тогда, когда мы реально отрендерим текущий кадр. и Present случается каждый кадр.

#63
12:09, 14 ноя. 2003

> дык он рендериться-то не будет до тех пор, пока не сделаешь Present
Серьезно? Можно какие-нибудь подтверждения? Цитаты из доков или еще что? Я очень не верю. Прямо очень и очень.

> дык в том-то и дело, что в реальной ситуации Present и последующий рендер занимают значительное время и вот это время мы и не хотим упускать.
Так. Мы GPU-limited или нет? Бывают ситуации GPU Idle кроме небольшого отрезка времени после синхронизации? Если на  ответы "да" и "нет", то я вообще ничего не понимаю. Потому что тут некуда кушать это время Present'a (). Или расскажи чего вы таки делаете в это время. В расчет следующего кадра не верю - и так уже много насчитали вперед карты.

> а что значит "хороший фиксированный"? 60/30/20/15/12/10?
Опять же, AFAIK, на XBox разговор короткий - либо укладываешься в 60 либо 30, либо нет. Если нет - думать чего делать, если да - жить с ним. Именно в этом ключе и можно точно сказать когда будет рендерятся кадр и сколько их считать в секунду на СPU чтобы stall'ов не было.

#64
12:11, 14 ноя. 2003

Я не могу так ваще :)
Это все имеет смысл, если действительно рендер начинается только по команде Present (). Если нет - то однопоточная схема _ничем_ не хуже. Я очень жду подтверждений насчет Present'a.

#65
12:12, 14 ноя. 2003

Gnom
Проблема с задержкой в Resent() не стоит и выеденного яйца. Ее можно решить и не прибегая к многопоточности, например, как предложил Семен.


Интереснее узнать, часто ли случается ли в реале переполнение того самого push-buffer'а, или это может произойти только теоретически?


fighter125
>дык он рендериться-то не будет до тех пор, пока не сделаешь Present
А разве Present() - это не просто переключение экранных буферов ?!?!? В ОпенГЛ он вообще называется SwapBuffers! Если отключить синхроцизацию с обратным ходом луча, так вообще никакой задержки в нем не будет.

#66
12:21, 14 ноя. 2003

Семен
>> дык он рендериться-то не будет до тех пор, пока не сделаешь Present
>Серьезно? Можно какие-нибудь подтверждения? Цитаты из доков или еще что? Я
>очень не верю. Прямо очень и очень.

тебе жизненного опыта недостаточно?

>Так. Мы GPU-limited или нет? Бывают ситуации GPU Idle кроме небольшого отрезка
>времени после синхронизации? Если на ответы "да" и "нет", то я вообще ничего не
>понимаю. Потому что тут некуда кушать это время Present'a (). Или расскажи чего
>вы таки делаете в это время. В расчет следующего кадра не верю - и так уже
>много насчитали вперед карты.

в большинстве случаев все игры CPU-limited, а не GPU, кроме, конечно, простейших игр, где ничего считать не надо, а только рендери, или в случае P4-3200 с RivaTNT.

>Опять же, AFAIK, на XBox разговор котороткий - либо укладываешься в 60 либо 30,
>либо нет. Если нет - думать чего делать, если да - жить с ним. Именно в этом
>ключе и можно точно сказать когда будет рендерятся кадр и сколько их считать в
>секунду на СPU чтобы stall'ов не было.

на Xboxe проблема в том, что CPU слабенький, какую-нить приличную физику считать сложно, а если CPU считает кадр быстрее, чем GPU рендерит, то проблем нет никаких.

#67
12:22, 14 ноя. 2003

Семен
>Это все имеет смысл, если действительно рендер начинается только по команде Present ().

Даже если все именно так, то я всеравно не понимаю, зачем разносить рендер и все остальное по разным потокам, достаточно вынести только один Present() и не париться!

#68
12:26, 14 ноя. 2003

prVovik
>Gnom
>Проблема с задержкой в Resent() не стоит и выеденного яйца. Ее можно решить и
>не прибегая к многопоточности, например, как предложил Семен.
>
>
>Интереснее узнать, часто ли случается ли в реале переполнение того самого
>push-buffer'а, или это может произойти только теоретически?
часто. мне вот очень интересно, вы только по докам рассуждаете или хоть какой-то реальный опыт имеете? компилирование примеров из DSK не в счёт.
>
>
>fighter125
>>дык он рендериться-то не будет до тех пор, пока не сделаешь Present
>А разве Present() - это не просто переключение экранных буферов ?!?!? В ОпенГЛ
>он вообще называется SwapBuffers! Если отключить синхроцизацию с обратным ходом
>луча, так вообще никакой задержки в нем не будет.
правда что-ли? а почему тогда именно Flip занимает больше всего времени? именно из-за того, что рендериться начинает только в нём, если конечно не было переполнения push-bufferа

#69
12:28, 14 ноя. 2003

fighter125
> тебе жизненного опыта недостаточно?
Весь мой жизненный опыт говорит, что все не так. Что рендеряться все начинает как только я отдал команды. Я очень удивляюсь с этого твоего заявления. Невыразимо удивляюсь. И потому хочу документальных подтверждений.

> в большинстве случаев все игры CPU-limited, а не GPU, кроме, конечно, простейших игр, где ничего считать не надо, а только рендери, или в случае P4-3200 с RivaTNT
Если вы CPU-limted, то почему у вас вообще Present () синхронизацию вызывает???
Мы уже говорили об этом. Цитирую aruslan'a
> Если CPU-bound вызван внутренними причинами (что, как правило, редкость), то да, тогда распараллеливание ничего не даст в принципе.
> Если же CPU-bound вызван необходимостью синхронизации с GPU (переполнение push buffer, блокировка ресурсов и т.п.), то здесь мы как раз и можем что-то сделать.
Если ты про внутренние причины (физика & stuff) - то проблем нету.

Если необходимость синхронизации - она совсем не имеет отношения к Present. И давай обсуждать именно ее. Я рассказал свое видение проблемы push-buffer'ов.

#70
12:35, 14 ноя. 2003

fighter125

> а что значит "хороший фиксированный"? 60/30/20/15/12/10?

в консольных играх обычно фиксированный fps. 60 либо 30. в отдельных играх бывает 20.

> интересно, как ты собрался планировать сколько времени нужно?
> брать по максимуму?

бюджетами на полигоны, качественным lod разных систем,
алгоритмами с фиксированным overhead,
работой со статическими пулами памяти,
асинхронным доступом к устройствам, итд итп.

> т.е. если в каком-то случае возможно всё будет
> занимать 100 ms, то ставим фиксированный fps 10, даже там где легко
> могло быть 60?

не должно быть случаев, когда 100 ms.
совсем никак нельзя.

на консолях оптимизируют минимальный fps а не средний.
единственное вмеру оправданное исключение - fillrate bound на отдельных эффектах.

#71
12:38, 14 ноя. 2003

fighter125

> в большинстве случаев все игры CPU-limited, а не GPU, кроме, конечно,
> простейших игр, где ничего считать не надо, а только рендери, или
> в случае P4-3200 с RivaTNT.

большинство игр в разные моменты CPU-bound и GPU-bound.
т.е. stall-ы на CPU очень часто тогда, когда GPU "опаздывает".

крайне мало видел игр исключительно CPU-bound.
потому как добавить "бесплатных" полигонов - всегда легко и приятно ;)

#72
12:40, 14 ноя. 2003

fighter125

> дык он рендериться-то не будет до тех пор, пока не сделаешь Present

это только если отстаёшь больше чем на backBuffer-1 буферов.
в этом случае чётко GPU-bound. практически de-facto.

опять-же с нюансами. даже и в таких случаях можно блокировку изжить.

во всех остальных случаях - Present асинхронный.

#73
12:41, 14 ноя. 2003

fighter125
>а почему тогда именно Flip занимает больше всего времени?
Из-за синхронизации с обратным ходом луча.

#74
13:23, 14 ноя. 2003

Boris Batkin

Откуда такая уверенность, что Present() асинхронный?

Страницы: 14 5 6 710 Следующая »
ПрограммированиеФорумОбщее

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