Что такое Hardware T&L?

Выглядит, как отрывок криминального романа: "Блок Hardware T&L, он же -- Hardware TCL, он же -- геометрический процессор". Что скрывается за всеми этими аббревиатурами? А скрывается за ними часть графического чипа, которая обеспечивает аппаратный расчет некоторых геометрических преобразований без использования ресурсов центрального процессора (CPU). Впрочем, "часть" -- это применительно к современным игровым акселераторам, на профессиональных видеокартах блок аппаратного расчета геометрии, как правило, присутствует в виде отдельного чипа (знаменитая серия GLINT Gamma от 3Dlabs).

Собственно, именно из мира профессиональных OpenGL-карт и пришли к нам все вышеперечисленные термины. Правда, как водится, "персональный" пользователь, склонный больше к играм, чем к серьезным OpenGL-приложениям, ждал от ускорителей трехмерной графики несколько других качеств, поэтому старую идею пришлось на лету подгонять под новые требования. В результате Hardware T&L в исполнении лидеров игровой 3D-акселерации по-прежнему не очень подходит профессионалам, так что обсуждать мы будем в дальнейшем только одно его применение, а именно -- игры.

Что "умеет" аппаратная геометрия?

Для начала -- расшифровки и терминология. Аббревиатура Hardware T&L полностью звучит как Hardware Transformation and Lighting, т. е. "аппаратный расчет трансформации и освещения", она обозначает то, чем занимается соответствующий блок. Правда, в последнее время иногда подвергают критике этот термин, потому что в свете реальных возможностей современных чипов он несколько неполный. Более корректно называть данный набор функций Hardware TCL -- Hardware Transformation, Clipping & Lighting, т. е. к трансформации и освещению добавляется еще один пункт -- "отсечение". В принципе, аббревиатура T&L уже прижилась, но для корректности, по крайней мере в этой статье, мы будем далее употреблять полное перечисление, т. е. TCL. Разбираться во всех этих дебрях проще всего постепенно, что мы и сделаем.

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

Clipping. Отсечение -- очень простая и очевидная операция: вычислить все те объекты (и/или их части), которые не будут видны на экране, и "отсечь" их, т. е. попросту не обрабатывать далее никаким образом. Clipping -- очень существенное подспорье для графического акселератора. Как известно, один из наиболее действенных способов ускорения любой работы -- это четко определить, чего делать не надо. При аппаратном TCL clipping осуществляется следующим образом: блоку геометрических вычислений определяют шесть плоскостей, ограничивающих именно ту часть "мира", которая сейчас будет отображена на экране (в самом простом варианте эти плоскости образуют усеченную пирамиду). После этого все объекты, находящиеся за пределами получившейся фигуры, объявляются для данного кадра значения не имеющими и, соответственно, не обрабатываются. На самом деле TCL-блоки современных игровых акселераторов умеют работать даже с большим количеством отсекающих плоскостей, но общий принцип процесса во всех случаях одинаков.

Lighting. Этот блок отвечает за освещение присутствующих в сцене объектов. Все современные 3D-акселераторы с поддержкой аппаратного TCL обеспечивают расчет освещения от восьми независимых источников. Объясняется это и тем, что таков необходимый минимум (явно указанный в спецификации OpenGL), и принципом разумной достаточности. Кстати, под словами "источник света" подразумевается именно первичный источник -- блики и отражения самостоятельными осветителями не считаются, как раз их и "вычисляет" TCL-блок. Классическим примером возможного применения аппаратного расчета освещения является элементарная горящая свеча. Кстати, пример этот в то же самое время и очень сложный, даже для чипа с TCL -- ведь пламя свечи постоянно изменяется, так же как и блики от него, к тому же само по себе пламя обладает определенной прозрачностью. Насколько нам известно, ни один современный графический чип не может отобразить в режиме реального времени полностью реалистичную модель горящей свечи. Однако именно такая степень реализма и является основной целью введения различных "геометрических" новшеств в 3D-акселераторы.

Альтернативы

Естественно, и до появления игровых чипов с поддержкой TCL соответствующие эффекты в играх все равно присутствовали. Их расчетом занимался центральный процессор, что, естественно, накладывало определенные ограничения. Причем не только по количеству эффектов, но и по качеству их реализации: для того чтобы не задавать CPU "непосильных задачек", разработчики игр применяли значительно упрощенные алгоритмы, к примеру для расчета динамического освещения. Кстати, именно поэтому многие сравнения программного и аппаратного TCL выглядят не совсем корректно -- заявляется: "Вот, смотрите, скорость почти одинакова!", но не принимается во внимание качество результата, в котором программная реализация может значительно уступать аппаратной.

Кроме того, сторонники программного TCL забывают об одном немаловажном факторе: аппаратный расчет геометрии, реализованный в графическом чипе, позволяет разгрузить CPU, в результате чего у процессора появится возможность уделить больше внимания другим вещам. Каким? К примеру, искусственному интеллекту компьютерного противника. "Тупость" AI (искусственного интеллекта) уже давно стала притчей во языцех у всех игроков, но посудите сами: откуда ему быть "умным", если почти все время процессор занят обсчетом графики? Вот и приходится останавливаться на самых примитивных алгоритмах, чтобы скорость игры не страдала.

Реальное применение: ложка дегтя

Применение Hardware TCL в современных играх оставляет желать лучшего. Из недавно вышедших, в которых заявлена его полная поддержка, "сходу" вспоминаются только MDK2, Soldier of Fortune и Heavy Metal F.A.K.K.2. Quake III для расчета освещения использует CPU, только трансформацию "отдавая на откуп" графической карте при условии наличия на ней соответствующего блока. Ну а второй по популярности движок -- Unreal/Unreal Tournament -- аппаратную геометрию не использует вовсе. Так что пока нам остается утешаться технологическими демо от NVidia и ATI да красивостями игровых тестов в 3DMark 2000 -- пожалуй, только в этом ПО возможности Hardware TCL используются пока в полную силу. Ну и естественно, ждать новых игр -- в большинстве из них разработчики заявили поддержку TCL чуть ли не как одно из основных достоинств.

Мини-тест

В приведенных диаграммах мы попытались проиллюстрировать наиболее интересные особенности применения аппаратного расчета геометрии на примере трех ведущих чипов с поддержкой Hardware TCL -- NVidia GeForce2 GTS/MX и ATI RADEON. S3 Savage 2000, также имеющий "на борту" TCL-блок, из тестирования выбыл по причинам, описанным ниже (в выводах).

Как видно из диаграммы (рис. 1), наиболее значительный эффект от TCL наблюдается в низких разрешениях. Это свидетельствует о том, что пока основным "тормозящим" фактором являются все же не геометрические преобразования, а банальный fillrate (скорость заполнения сцены, за которую отвечает блок растеризации). В высоких разрешениях графический чип просто не успевает сформировать "картинку" с той скоростью, с какой TCL-блок ее обсчитывает, поэтому разница между программным и аппаратным TCL становится менее заметной.

Рис. 1

Представим себе условную ситуацию: на рендеринг каждого кадра при скорости 100 fps уходит 1000/100 = 10 мс. Предположим, что в низком разрешении по 3 мс этого времени занимают "процессорная" и TCL-стадии, а остальные 4 мс -- формирование результирующей "картинки" во фрейм-буфере блоком растеризации (наложение текстур и спецэффектов).

Теперь переключимся в более высокое разрешение и 32-битовый цвет. Процессорная и TCL-стадии практически не зависят от разрешения (операции умножения/деления/сложения/вычитания над числами в довольно широком диапазоне выполняются с одинаковой скоростью). А вот для блока растеризации по-прежнему "альфой и омегой" является одна-единственная точка на экране (она же -- во фрейм-буфере), которую нужно "покрасить" в определенный цвет путем наложения одной или нескольких текстур плюс спецэффекты. И чем больше этих точек, чем больше бит используется для задания цвета каждой из них, тем медленнее происходит процесс. Предположим, что в результате fps снизился до значения 60. Таким образом, на две первые стадии мы по-прежнему тратим 6 мс, на рендеринг же подготовленного кадра -- (1000 : 60) - 6 " 10,7 мс. И если в предыдущем примере "удельный вес" блока TCL в общем времени расчета кадра составлял 30%, то с повышением разрешения он снизился до 3 : 16,7 " 18%. Наоборот, значимость "вклада" блока растеризации возрастет с 40% до 10,7 : 1 6,7 " 64%. При дальнейшем увеличении размера картинки зависимость сохранится, и доля блока растеризации будет становиться еще больше.

Также заметно (рис. 2), что аппаратный TCL "виднее" на более слабых процессорах. Однако можно к этому факту подойти и с другой стороны: посмотрите, насколько велика разница между Pentium III 600EB с включенной поддержкой аппаратного TCL и Pentium III 866 в режиме "процессорного" расчета геометрии. Велика -- это даже не то слово, она громадна. А теперь попробуйте представить, какой частоты процессор может понадобиться для того, чтобы программный TCL сравнялся по производительности со схемой "аппаратный TCL плюс далеко не самый мощный CPU". Нам кажется, что данные этого теста убедительно показывают преимущество аппаратного TCL над простым наращиванием мощности центрального процессора.

Рис. 2

Ну а на этом примере (рис. 3) мы четко видим эффект, уже обсуждавшийся выше, -- GeForce2 MX, чей текстурный блок слабее, чем у GeForce2 GTS, да и пропускная способность памяти ниже, демонстрирует меньшую результативность, в том числе и у блока аппаратного TCL. Причина тому одна: полностью проявить себя он может только при высокой производительности блока растеризации, иначе его потенциал оказывается фактически невостребованным.

Рис. 3

Ну и раз уж мы проводили тесты наиболее популярных 3D-акселераторов с поддержкой аппаратной геометрии, интересно заодно было выяснить, чей TCL-блок является максимально результативным. В диаграмме на рис. 4 можно видеть максимальные значения "КПД TCL-блока", полученные на двух самых мощных видеокартах, принимавших участие в тестировании. Значение "КПД" получалось самым простым образом: результат теста с включенной TCL-оптимизацией делился на fps этого же теста с оптимизацией выключенной. Как ясно из диаграммы, лидирующее место занял ATI RADEON. Впрочем, ввиду новизны самого понятия аппаратного расчета геометрии и освещенности с использованием возможностей 3D-акселератора, слишком серьезно это сравнение мы воспринимать не рекомендуем -- все может очень существенно измениться просто при переходе на другую тестовую программу.

Рис. 4

Выводы

Как ни странно (впрочем, зачастую именно так и случается в отношении новых технологий), легче всего перечислить неправильные утверждения относительно полезности аппаратного расчета геометрии и освещения.

Неправильное утверждение # 1: если в чипе присутствует блок аппаратного TCL, то это -- хороший графический чип. S3 Savage 2000, выбывший из нашего тестирования, опровергает данное утверждение самим фактом своего существования. Он тоже поддерживает TCL, но настолько медленно, что в тестах включение соответствующей оптимизации оборачивалось падением производительности.

Неправильное утверждение # 2: Hardware TCL никому не нужен, это просто "модная штучка", срок жизни которой истечет сразу же после того, как она перестанет быть модной. И это не так, потому что приложения, в которых положительный эффект от использования аппаратного расчета трансформации и освещения виден, существуют.

Но это все -- утверждения, основанные на отрицании. Что же можно уже сейчас сказать позитивного о TCL? И много, и мало -- смотря с какой стороны подойти к вопросу.

Нужен ли он сегодняшним играм? По большому счету -- нет. Существенный эффект от использования TCL наблюдается в таких режимах цветности и разрешениях экрана, в которых ни один здравомыслящий обладатель мощного 3D-акселератора играть не станет. При увеличении же этих параметров основным "тормозом" становится уже отнюдь не TCL, а блок растеризации. Также необходимо учесть то, что игры, и тем более графические движки игр, разрабатываются, как правило, не один год. Следовательно, в те времена, когда закладывались основы тех игр, в которые мы играем сейчас, аппаратный расчет трансформации и освещения воспринимался лишь как интересная новинка с непонятным будущим, а то и не был известен вообще. Соответственно строились и сцены, и дизайн уровней -- все, что увеличивало нагрузку на процессор (при использовании программного TCL), беспощадно "вырезалось" где только можно было с целью повысить скорость. Таким образом, создалась ситуация, когда даже наспех в последний момент сделанная TCL-оптимизация подобным играм мало помогает, -- объем расчетов, которые можно "перекинуть" с процессора на графическую карту, оказывается ничтожно малым по сравнению с общим.

Нужен ли TCL как таковой? Безусловно, да. Будущие графические движки и игры, вне всяких сомнений, очень скоро дорастут до того уровня сложности, при котором процессору станет трудно справляться с программным расчетом геометрии. И тогда разработчикам придется делать выбор: либо уступать конкурентам в качестве и "количестве" графики, либо сводить к минимуму функциональность искусственного интеллекта, либо... ориентироваться на Hardware TCL.

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

Следовательно, скорость "старых" графических чипов (без Hardware TCL) на старых же играх окажется, скорее всего, примерно равна быстродействию современных чипов на новых играх. А вот если захочется с видеокартой на старом чипе поиграть в новую игру -- тут, вероятно, со скоростью возникнут очень большие проблемы. Те же, кто утверждает, что растущей не по дням, а по часам мощности CPU хватит к тому времени "на всех", не учитывают одну простую и давно известную истину: никогда универсальный процессор не мог составить конкуренцию по скорости и функциональности специализированному. Примеров этому настолько много, что даже нет смысла их приводить. Хотя бы даже сами 3D-акселераторы.