Direct3D9: элементарные правила оптимизации (комментарии)

Direct3D9: элементарные правила оптимизации (комментарии)

Это сообщение сгенерировано автоматически.

Прошу прощения за прошлый, неудачный «вброс». Перенес тему в «статьи» из «советов» и поправил права доступа к документу.

slava_mib, в прошлый раз, внес дельное замечание:

>[...]очень плохо, что написано ЧТО не надо делать, но не написано ПОЧЕМУ этого не надо делать. В итоге, людям придётся зазубривать все правила. Хотя, в том случае, если просто понимать логику почему не надо делать так-то и так-то - запомнить их значительно легче

Правда, в данном случае, мне потребуется ваша помощь в адекватном толковании советов, данных MSDN.
И да, спасибо тому, кто придумал местные «термины» — использовать их было очень удобно :-)

>Все объекты, которые вы собираетесь отрисовать в текущем кадре, должны быть отсортированы по принципу «от ближнего к дальнему» по отношению к камере
>Все объекты, которые вы собираетесь отрисовать в текущем кадре
ща начнут спрашивать - а почему у меня альфабленд не работает?

mrt
Предлагаю больше осветить данную тему в статье. Навскидку я думаю следует добавить:
1) RenderStates объединять в IDirect3DStateBlock9.
2) Не всегда нужно выводить от ближнего к дальнем, нужно учитывать прозрачность объектов.
3) Нужно упомянуть про много поточность в Direct3D9, а именно стараться вызывать все в одном потоке, и не использовать флаг создания устройства D3DCREATE_MULTITHREADED
Если еще что вспомню скажу.

Andrey
> Если еще что вспомню скажу.

ну как же, как же - константы только за 1 вызов :)

>1) RenderStates объединять в IDirect3DStateBlock9.
кстати, судя по PIX, и обычные последовательности рендерстейтов объединяются в блоки.

innuendo
> ну как же, как же - константы только за 1 вызов :)

А я, кстати, проверял, оптимальнее отправлять одним буфером :) Что я и делаю. И еще, конечно, нужно отправлять только изменившиеся константы, это дает такой прирост, что я обалдел. Кто-то мне подсказал, только не помню кто.

mrt
Молоца, все правильно написано. Сошлюсь на тебя в своей статье про рендер, чтобы не повторяться. :)

> Все объекты, которые вы собираетесь отрисовать в текущем кадре, должны быть отсортированы по принципу «от ближнего к дальнему» по отношению к камере

Лучше так: Все НЕ ПРОЗРАЧНЫЕ объекты, которые вы собираетесь отрисовать в текущем кадре, должны быть отсортированы по принципу «от ближнего к дальнему» по отношению к камере

PS и то это утверждение - оговорка, поскольку  если рендить таким способом  настигнет батлнек на батчинге. Если  видяшка слабая на пиксельные, то в крайнем случае  подойдёт  Z препас.

Osiris
> А я, кстати, проверял, оптимальнее отправлять одним буфером :) Что я и делаю. И
> еще, конечно, нужно отправлять только изменившиеся константы, это дает такой
> прирост, что я обалдел.

и на сколько ты обалдел в цифрах ? :)

innuendo
> и на сколько ты обалдел в цифрах ? :)

Ну для 100 float4 для источников света в 4 раза где-то. Со 100 fps до 400. Для пары матриц камеры это не так заметно.

Osiris
> Ну для 100 float4 для источников света в 4 раза где-то. Со 100 fps до 400. Для
> пары матриц камеры это не так заметно.

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

innuendo
> я имел ввиду про "только те что изменились" ?

Ну я про него. У меня на сцене была группа объектов, освещенная n числом истокников света.

До реализации проверки, для каждого объекта я отправлял массив float4 размером n, так как я не знал что я уже отправил в шейдер.
После реализации проверки это один заброс массива float4 размером n, так как я знаю, что массив не поменялся.

На основании этого подхода я оптимизировал форвард рендер освещения.

Osiris
> До реализации проверки, для каждого объекта я отправлял массив float4 размером
> n,

Osiris
> После реализации проверки это один заброс массива float4 размером n,

n == n ? :)

innuendo
> n == n ? :)
Ага :) первый раз ВСЕ источники для КАЖДОГО объекта, второй раз ВСЕ источники один раз для ВСЕХ объектов.

mrt, новая версия лучше, но, к сожалению, не сильно )
Думаю, надо навалиться всем хором и довести до ума - сейчас многовато лексических и прочих помарок. И, как и в предыдущей версии, очень мало объяснений (простите, но я не считаю "привет кэшу видеокарты" очень внятным и, главное, запоминающимся объяснением). Сейчас, к сожалению, нет времени, но попозже (в ближ. дни) могут попробовать помочь с доводкой, если есть такое желание.