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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если смена состояний происходит несколько раз на одно и то же значение, это снижает производительность? Например:
    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;}? Или это не даст никакого повышения производительности?