DirectX 8. Начинаем работу с DirectX Graphics - [19]

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

Оптимизация трехмерного приложения может вестись по нескольким ключевым позициям:

1. Оптимизация рендеринга.

2. Оптимизация процессорной части приложения.

3. Оптимизация алгоритмов.

Такой порядок обычно считается направлением, в котором оптимизируется приложение. Программисты с энтузиазмом берутся оптимизировать графическое ядро, в нем, естественно, вязнут (оптимизация — процесс итерационный, а потому бесконечный, к тому же переходить ко второму пункту не хочется, а про третий вообще стараются забыть). Но это обусловлено не отдачей от каждой конкретной части, а скорее нежеланием программистов думать о сложном и высоком, обращать внимание на мелкие детали и тщательно следить за качеством кода. Хотя математики давно знают, что никакое улучшение аппаратуры не может сравниться с оптимизацией (улучшением существующих, разработкой новых) алгоритмов. Оптимизация процессорной части важна, поскольку большинство приложений ограничиваются процессором и выигрыш в скорости расчета процессором специфических функций (начиная от поиска пути и заканчивая графикой) напрямую увеличивает производительность приложения. Графическая подсистема постоянно улучшается, но пределы производительности практически достигнуты и скоро будет произведена замена существующих способов рисования сцены новыми. Поэтому оптимизация графического ядра, это вещь важная, но не стоит уделять ей внимания больше, чем она того заслуживает (это относится только к Direct3D программистам).

Рассмотрим их по порядку, причем начнем с конца.

3. Оптимизация алгоритмов

Мы интересуемся только графической частью приложения, поэтому здесь главное правило, как и в программировании:

Если можно что-то сделать вне цикла — делай это вне цикла.

Если можешь создать таблицу с параметрами и ее использовать — создай и используй.

Если можешь что-то не считать — не считай это.

А главное, если есть возможность что-то ускорить, то эту возможность нельзя упускать.

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

Если можно обновлять информацию не для каждого фрейма, а хотя бы для каждого второго, то рост производительности в этой части будет на 100%.

Если используются функции (для сглаживания пути или формирования волн на воде), то создание таблиц значений и интерполяция между ними может дать значительный прирост. Если вершина не попала на экран ее можно смело не рисовать (здесь нужна аккуратность — быстрый алгоритм отсечения и невидимые полигоны на сцене предпочтительнее, чем ни одного лишнего и чистый qsort для сортировки). С сортировкой вообще нужно быть осторожным — мы не можем предсказать разброс значений в массиве, а значит, не можем предсказать время выполнения сортировки методами типа "разделяй и властвуй" (qsort), поэтому возможен предварительный разброс значений и последующая быстрая сортировка, или сортировка маленьких массивов методами типа "Пузырек" (все знают как плохо работает qsort в случае обратной упорядоченности массива или массива с большим количеством повторяющихся значений).

2. Оптимизация процессорной части приложения

Интересно, что для этой части предлагаются только методы оптимизации выполнения на уровне аппаратуры, но забывать про оптимизацию параллельности выполнения тоже не стоит. Мы имеет не один процессор, а два: CPU и GPU. В GPU работа хорошо распараллеливается, и мы за ней не следим, но есть ряд операций, выполнение которых заставляет процессор простаивать, поэтому ТАКИЕ операции нужно стараться уменьшать в количестве и следовать рекомендациям, приведенным в части статьи, посвященной непосредственно примерам. Кстати в этом процессе может помочь Statistical Driver от NVIDIA, но его нужно получать непосредственно от NVIDIA, а для этого необходимо стать регистрированным разработчиком на developer.nvidia.com.

Итак, самое главное

1 удаляем непосредственное преобразование типа float к типу long или int.

Каждый раз, когда вы пишите

int i = f; // f - float, вы неявно вызываете функцию ftol() или ftoi(), поэтому лучше так:

Вместо:

int i = f; // вызов __ftoi()

Пишем:

__inline void myftol(int *i, float f) {
 __asm fld f;
 __asm mov edx, I
 __asm fistp[edx];
}
//…
MyFtoL(&i, f);

Либо используем недокументированный переключатель оптимизации /QIfist чтобы избежать вызовов __ftol().

2 Не используем fsqrt — 79 циклов это слишком долго.

Достаточно качественная реализация приведена в NVToolkit (MUST HAVE для всех кто программирует графику, но не хочет лезть в математику). Полный архив NVToolkit можно скачать с http://developer.nvidia.com/. Когда я ее выкачивал он лежал по адресу http://developer.nvidia.com/docs/IO/1208/ATT/NVTK_no_libs.zip.

/********************************************************************* ulSqrt.cpp
 Copyright (C) 1999, 2000 NVIDIA Corporation