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

Архитектура рендеринга сцены - что уменьшает FPS? (3 стр)

Страницы: 1 2 3 4 5 Следующая »
#30
23:52, 22 апр. 2010

http://kore3d.blogspot.com/2010/04/dip-directx9.html


#31
9:08, 23 апр. 2010

Cyclone
> Да, колебаний действительно не будет, однако фальшивые результаты на части
> тестов при этом запросто.
Данные в буферах одинаковые, чтобы во все случаях конвейер делал одну и ту же работу, в т.ч. чтобы результат растеризации был одинаковым

> Какая нафиг видеокарта, если на 1024 дипах и выше тотальный CPU bound?
Это легко померять. Кроме этого, если взять код, который приведен, и увеличить буфера, например, в 2 раза, то скачка fps не будет. Загрузка ЦПУ 5-25% и 45% при 4098 (по task manager'у). Позже PerfHUDом посмотрю.
Что еще не учтено?

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

#32
9:51, 23 апр. 2010

Cyclone
> Теоретически, филлрейт может ограничивать фпс до тех пора пока не появится ещё
> более узкий ботлнек
у нас на старых картах типа radeon9600 на сценах с большин числом lights shaft fsp падал по неприличных 3-5 ( спасибо артовикам :) )
прореживание плантации lights shaft помогло

#33
11:01, 23 апр. 2010

Cyclone
> Если рисовать большие треугольники, то все легко упрётся в филлрейт.
какое это отношение имеет к теме? проверялось имеет ли смысл объединять раздельные буферы в один и сколько стоят простейшие переключения состояний

> Источник надо указывать, либо честно писать, что "по моему мнению".
Если источник не указан, то это подразумевает авторское мнение.

> batch, batch, batch от NV
да я читал ее давно, вот возник вопрос ее актуальности на данный момент, поэтому и сделан тест

#34
12:18, 23 апр. 2010

А профайлером померять не? ну там NVPerfHUD например, или аналог АТИшный.
У NVPerfHUD'а прямо есть frame profiler, чего уж казалось бы проще, чем сидеть и гадать "любит не любит".
А то уже три страницы накатали а так и не понятно что тормозит.

#35
12:37, 23 апр. 2010

evirus
> http://kore3d.blogspot.com/2010/04/dip-directx9.html
автор, чему у тебя равно omp_get_wtick()? а то 12ms очень похожи на квант времени работы треда
да и изменение показаний подозрительно кратное...
ещё не понятен смысл использования D3DUSAGE_DYNAMIC для вершинного буфера, но это ладно

#36
13:32, 23 апр. 2010

Outlaw
> А профайлером померять не?
Раньше пытался померять PIXом - не помогло. Доберусь до офиса - померяю NVPerfHUD и отпишусь.

#37
14:41, 23 апр. 2010

Cyclone
> batch, batch, batch от NV
Она уже давно устарела. Сейчас дрова намного умнее, а в GPU появился командный процессор.

#38
14:51, 23 апр. 2010

SNVampyre
> > batch, batch, batch от NV
> Она уже давно устарела. Сейчас дрова намного умнее, а в GPU появился командный
> процессор

слышал про такое - "новое, это хорошо забытое старое " :)

#39
15:26, 23 апр. 2010
omp_get_wtime()
Elapsed wall clock time in seconds. The time is measured per thread, no guarantee can bee made that two distinct threads measure the same time. Time is measured from some "time in the past". On POSIX compliant systems the seconds since the Epoch (00:00:00 UTC, January 1, 1970) are returned.
#40
15:37, 23 апр. 2010

evirus
> omp_get_wtick() - функ возвращает результат в секундах, это не квант работы треда,
omp_get_wtick() возвращает квант инкремента omp_get_wtime()
так чему равен результат вызова этой функции? а то мне неспокойно как-то

> omp_get_wtick()
> Elapsed wall clock time in seconds...
справку я читал, спасибо
к тому же, это про omp_get_wtime()

#41
15:51, 23 апр. 2010

arabesc
квант могу написать только позже, нету тестовой машины под рукой
давай разговор в личку, а то оффтоп уже, я тебе напишу как доберусь до ноутбука (часа через 3)

#42
18:47, 26 апр. 2010

Благодарю всех за участие, в процессе решения данной проблемы я узнал много нового.
Оказалось, проблема была заключена в подсчете fps.
Изначально я засекал время рендеринга одного кадра, исходя из результата считал fps. Поскольку Direct3D9 возвращает программе управление до того, как закончится реальный рендеринг, то результаты оказались несоответствующими реальности.

Между тем, я так же провел множество проверок для выяснения, какие именно вызовы Direct3D приводят к дополнительным потерям времени. В итоге оказалось, что в случае с упомянутым ландшафтом действует некий fillrate ботлнек - но выявить какой он именно, я не могу (не хватает инструментария и понимания происходящих процессов). То есть можно при каждом вызове рендера суб-меша заново устанавливать текстуры, шейдеры, константы, буфера - итоговая скорость обновления кадров остается такая же, как если бы один раз за кадр всё установить, а потом рендерить все одним мешем.

Еще раз всем спасибо.

#43
18:51, 26 апр. 2010

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

#44
18:17, 7 окт. 2010

Если смена состояний происходит несколько раз на одно и то же значение, это снижает производительность? Например:
    glColor3f(0.1f, 0.2f, 0.3f);
    //Следующий фрагмент кода будет выполняться в 100 раз дольше предыдущего?
    for(int i=0;  i<100; i++)
        glColor3f(1.0f, 0.9f, 0.8f);
Следует ли писать так: if(!lighting) {glEnable(GL_LIGHTING); lighting=true;}? Или это не даст никакого повышения производительности?

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

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