Что скрывается за технологией Intellisample? |
12.05.2003 |
Спросите у среднестатистического геймера-эстета, какую из функциональных возможностей графического ускорителя он считает наиболее важной с точки зрения улучшения качества изображения в уже существующих сегодня играх, и с очень большой долей вероятности Вы получите следующий ответ: анизотропную фильтрацию. К сожалению, именно анизотропия, безупречная по качеству, но чрезвычайно ресурсоёмкая из-за универсальной реализации 'в лоб', несомненно, была и по-прежнему остаётся самым слабым местом графических процессоров NV25. Не случайно, что от последователя NV25, процессора NV30, многие ждали только одного: быстрой анизотропной фильтрации, способной, наконец, обеспечить играбельную частоту кадров в высоких разрешениях. Не могли не понимать этого и в NVIDIA. Именно для того, чтобы устранить это самое слабое место и избавиться от катастрофического падения производительности при активизации анизотропной фильтрации, и была предназначена технология Intellisample, анонсированная вместе с семейством графических процессоров NV30. Судя по всему, термин Intellisample происходит от словосочетания Intelligent Sampling, то есть NVIDIA, таким образом, намекает на наличие неких интеллектуальных технологий анализа сцены, позволяющих снизить вычислительную ресурсоёмкость процесса анизотропной фильтрации путём внесения упрощений в её алгоритмы в тех случаях, когда они не приводят к значительному ухудшению качества изображения. Действительно, как мы знаем, в OpenGL драйвере уже достаточно давно (а именно, начиная с версии 28.90) появились алгоритмы анализа геометрии сцены, полностью отключающие анизотропную фильтрацию при текстурировании некоторых полигонов и позволяющие достичь очень значительного прироста производительности в режиме мультитекстурирования. Проверка индекса текстурной стадии и использование данного алгоритма только на стадиях с индексами, отличными от нуля, позволили NVIDIA сделать алгоритмы отброса полигонов максимально незаметными для тестов качества изображения, поскольку упрощения в львиной доле случаев касались лишь второстепенных текстур (например, карт освещённости), не оказывающих значительного влияния на чёткость результирующего изображения. Именно этот алгоритм и активизировался OpenGL драйвером в режимах Balanced и Aggressive при форсировании анизотропной фильтрации, и, к сожалению, до недавнего времени данный алгоритм был единственной компонентой технологии Intellisample, доступной всему семейству графических процессоров GeForce в OpenGL. Сразу оговоримся, что в этой статье мы не будем затрагивать специфичный для процессоров NV3x код (а именно, упрощения, связанные с трилинейной фильтрацией, коррекцию LOD bias и т.д.) и поговорим только об общих алгоритмах оптимизации анизотропии, присущих всему семейству GeForce. Благо, что повод для этого есть более чем достойный. Само собой, речь идёт о появлении драйверов Detonator 43.45 и 43.51, поднявших планку производительности анизотропной фильтрации в OpenGL на новый уровень и содержащих принципиально новые алгоритмы оптимизации для всех графических процессоров семейства GeForce. Именно об этих оптимизациях мы сегодня и поговорим.
Как можно заметить, в зависимости от используемой таблицы максимально качественный Level 8 может быть заменён на Level 1 либо Level 2 в режиме Performance и на Level 2 либо на Level 4 в режиме Balanced. Не зная первоначально критерия выборки индекса таблицы, мы предположили, что в его качестве используется индекс текстурной стадии и программисты из NVIDIA занялись откровенным надувательством, элементарно занижая степень анизотропии на первой и второй текстурных стадиях. Для проверки этой гипотезы мы специально разработали тестовое приложение OpenGL anisotropic filtering quality test v1.0, отображающее тестовую сцену, состоящую из одной единственной поверхности, на которую в режиме мультитекстурирования накладывается до четырёх текстур за один проход: Кроме этого, наше тестовое приложение позволяет выбрать текущую текстурную стадию, с которой будет ассоциирована однородная текстура белого цвета с цветными mipmap уровнями (чередование белого, красного, зелёного и синего цветов). Совокупность возможности выбора текущей стадии, использующей текстуру с разноцветными mipmap уровнями, и возможность одновременного отображения одной и той же тестовой сцены с различными комбинациями билинейной (изотропной), анизотропной и трилинейной фильтрации должны были неизбежно выявить снижение степени анизотропии на разных текстурных стадиях, если бы оно, конечно, имело место. Режим Quality Итак, скриншоты явно говорят о том, что в нашем приложении явно используется таблица упрощения анизотропии с индексом 2:
Однако каким образом выбирается индекс таблицы упрощения? Он явно не зависит от текстурной стадии. Более того, в нашем тестовом приложении OpenGL драйвер стабильно выбирал именно вторую таблицу упрощения, и на этот выбор не влиял ни угол поворота, ни размер сцены, то есть выбор индекса явно производился и не на основе геометрии. Для окончательного выяснения этого вопроса нам пришлось провести более глубокий анализ кода OpenGL драйвера. Честно отметим, что мы были очень приятно удивлены результатом. Итак, чем же специфично наше приложение и что заставляет драйвер использовать для него самую грубую таблицу упрощения? Впрочем, ответ лежит на поверхности: наш тест специфичен лишь..... однородной текстурой. Да-да, именно текстурой. Вы не ослышались, максимальный уровень анизотропии теперь напрямую зависит от содержимого фильтруемой текстуры. Остаётся только пожать руку программистам OpenGL драйвера, придумавшим столь оригинальный подход в оптимизации анизотропной фильтрации. Действительно, такой метод оптимизации, бесспорно, имеет право на жизнь: к примеру, зачем загружать графический процессор усреднением цветов тридцати двух текселей для формирования финального цвета пикселя, если цвета этих текселей одинаковы и усреднение четырёх текселей из стандартной билинейной выборки даст абсолютно такой же результат? Теперь алгоритмы Intellisample в OpenGL по праву могут считаться интеллектуальными, поскольку драйвер рассчитывает степень чёткости каждой текстуры при её создании, и именно эта степень чёткости и используется в качестве индекса используемой таблицы упрощения анизотропии. Режим Balanced, неоднородная текстура средней чёткости Как видно, при переходе чёткости текстуры через определённый порог, драйвер переключается сначала на таблицу упрощения 3, а затем и вовсе отключает упрощения, переключившись на таблицу 4. Остаётся только ещё раз виртуально пожать руку программистам, реализовавшим такой метод оптимизации. Режим Performance, полностью однородная DXT1 текстура Ясно видно, что при использовании компрессии чёткость текстуры не оказывает никакого влияния на качество анизотропной фильтрации и драйвер просто не активизирует оптимизации. К счастью, оба этих ограничения довольно легко устранимы, поскольку мы знаем их природу, и это не может не радовать.
Стенд работал под управлением операционной системы Windows XP Professional и драйверов Detonator 43.51. В качестве тестового приложения мы не случайно выбрали Quake III : Arena. Дело в том, что это как раз одно из тех приложений, которые не используют весь потенциал оптимизаций на уровне анализа чёткости текстур из-за включенного по умолчанию сжатия. Поэтому мы приводим результаты тестов как с включенной, так и с отключенной текстурной компрессией, дабы наглядно оценить прирост производительности, который может быть вызван использованием новых оптимизаций. Кроме этого, мы также приводим результат тестирования нашего скрипта AnisoBoosterOGL, который уже достаточно долго включен в утилиту твикинга RivaTuner и позволяет поднять эффективность упоминаемого в статье алгоритма отброса полигонов путём блокирования проверки индекса текстурной стадии, тем самым увеличивающего производительность за счёт применения алгоритмов отброса полигонов и к нулевой текстурной стадии:
Обратите внимание на практически идентичные результаты между режимами Intellisample, полученные с включенной компрессией текстур (81,1 FPS в режиме Quality против 84,7 в режиме Performance, разница между ними составляет всего 4.5%), и почти пятидесятипроцентную разницу между ними (72,9 FPS в режиме Quality против 108,8 FPS в режиме Performance) при её отключении. Более того, использование скрипта AnisoBoosterOGL даёт ещё почти десятипроцентную прибавку в производительности. Остаётся только счастливо прослезиться, глянув на максимально возможные 120 FPS и вспомнив 50 FPS, которые мы не так давно получали в тех же самых условиях тестирования до появления в драйвере алгоритмов отброса полигонов и алгоритмов анализа чёткости текстур. Понадеемся на то, что алгоритмы Intellisample будут и далее развиваться такими же семимильными шагами и при этом качество изображения не будет страдать очень сильно. Выводы:
Николайчук Алексей a.k.a. Unwinder (AlexUnwinder@mail.ru) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||