Назад в раздел
Мифы 3D программирования.
eManual.ru - электронная документация
Topic from FAQRobot To: FAQRobot, 2:5004/39 Subj: %LIST %HELP
Мифы 3D программирования
Автор: Максим Кизуб
Date: 03/01/2000
Почему мерять скорость карты используя FPS неправильно
Хотя все наши читатели и знакомы со значением слова FPS - я рискну еще раз
напомнить, о чем идет речь.
FPS (frames per second) означает количество выводимых кадров в секунду. И он,
безусловно, является одним из основных показателей скорости игры.
В связи с этим, есть тенденция его абсолютизировать. То есть, попытки
представить его главным и единственным скоростным показателем. Доходит до
совершенно курьезных вещей, когда не понимая сути измеряемого показателя, его
пытаются представить как измеритель скорости видео-акселераторов. Зачастую этим
грешат и маркетинговые отделы компаний-производителей, что вносит еще большую
путанницу. Вспомните, хотя-бы, лозунг компании 3dfx - "60 fps в любой игре!".
Давайте попробуем разобраться, в чем тут ошибка
Во-первых, никогда и ни при каких обстоятельствах нельзя применять этот
показатель без приведения конкретных обстоятельств его получения. Ести вещи, от
программ не зависящие - например, та-же частота смены кадров монитора. Неважно,
как ведут себя программы, но, если и видео-карта, и монитор, поддерживают
выставленную частоту - частота смены кадров (60 кадров в секунду, 75, 85, 100,
и пр.) будет иметь место всегда. Совершенно другой случай мы имеем с FPS. Под
FPS подразумевается реальная скорость генерации новых кадров игровой сцены,
которая ничего общего не имеет с аппаратными вещами, типа refresh rate
монитора, и очень сильно зависит от способа генерации сцены - даже если сама
визуальная картинка одна и та-же.
Во-вторых, fps - это интегральный показатель, точнее - это усредненное за
определенный период времени значение. И как со всякими усредененными величинами
- с ним нужно обращаться осторожно. Любимый пример моей мамы (преподавателя
статистики в институте) - это средняя температура больных по госпиталю...
Кто-то лежит в горячке, а чей-то труп уже остывает в морге. А средняя
температура - 36.6 градусов ;-)
От чего зависит FPS
Итак, от чего он зависит?
Давайте пройдем по пунктам, и попробуем проанализировать их.
1. Загрузка процессора
1 Скорость процессора (CPU), для большиства игр, имеет очень большое значение.
Но она используется одновременно для двух, совершенно разных вещей. Первое, это
обслуживание самой игры, расчет изменений во времени,
1.1 AI (Artificial Intelligence - искусственный интеллект) участников, за
которых играет компьютер (NPC), и прочее. В зависимости от игры, влияние этого
фактора может варьировать от нуля до большей части загрузки процессора.
Естественно, чем точнее (реалистичнее) расчитывается физика происходящих в игре
процессов, чем умнее ведут себя "компьютерные" персонажи - тем больше времени
тратиться на их расчет. Основной способ борьбы с этим - оптимизация как самого
AI, так и всей суммы аппаратных и программных средств. Большинство
видео-акселераторов имеют специальный (FIFO) буффер, который кеширует
последовательность рисования графических примитивов, плюс, небходимость (как
правило) синхронизировать смену кадров сцены со сменой кадров экрана. В
результате, как стратегия для программиста, необходимо очень быстро нарисовать
сцену (которая в значительной степени осядет в FIFO буффере
видео-акселератора), уведомить драйвер, о смене буфера рисования (для double и
triple buffering), и немедленно приступить к пересчету (но не рисованию!)
следующей сцены и обработки AI. Если физика происходящего не требует больших
расчетов и используется простенький AI - современные процессоры, как правило,
успевают пересчитать всю сцену за то время, пока графический акселератор
заканчивает обработку очереди примитивов, и синхронизирует смену буферов с
частотой кадров монитора. Если он не успеват справиться с этой работой - FPS
игры падает, как минимум, вдвое, по сравнению с возможностью скорости вывода
самой видео-карты.
1.2 T&L (Transformation and Lighting - трансформация и освещение) - процесс
преобразования локальных для объкта (модели) трехмерных координат в двухмерные
координаты экрана. Сам по себе этот процесс не сложен, но требует значительных
ресурсов процессора, и именно в области плавающей арифметики. Тут, для борбы с
этой частью нагрузки, требуются свои меры. Во-первых, это покупка более
быстрого процессора. Однако, скорость процессора (тактовая частота) - это не
единственный, и далеко не главный показатель. Поскольку плавающие вычисления в
3D выполняются, достаточно "приблизительно", то играет роль скорость работы
именно с float (а не double) числами. Скажем, AMD K6-II или PentiumIII имеют
специальные инструкции процессора (3DNow! и SSE соответственно),
предназанченные для быстрой и параллельной обработки плавающих чисел, и, при
той-же тактовой частоте способны обрабатывать 3D графику более чем в два раза
быстрее, чем аналогичные процессоры, но не имеющие этих инструкций (PerntiumII,
Celeron, AMD K6-I и более старые). Поэтому, например, AMD K6-II 350 ведет себя
лучше, чем тот-же переразогнанный Celeron 466.
Заметьте, что MMX инструкции предназначенны для работы с целочисленной
арифметикой, и имеют значение только для software mode графики. Эти операции
уже давно выполняются видео-акселераторами аппаратно, и нужда в MMX (в области
игры) уже прошла.
1.3 Скорость системной шины и кэш памяти так-же играют существенную роль.
Однако, это проблема в первую очередь именно программистов. Именно они обязаны
разместить данные таким образом, чтобы при обработке они оказывались рядом, то
есть попадали в кэш первого уровня одновременно. Зачастую, это ведет к
увеличению требований игры по памяти, но, обычно, это не самая большая часть.
Стоит напомнить, что если программисты пишут игры без учета этой части
современной аппаратной реализации компьютеров, скорость игры может упать в
разы, а то и и более. Впрочем, купив себе компьютер и процессов с большим
объемом кэш-памяти, и более быстрой системной шиной - вы можете значительно
облегчить задачу программистов и несколько "исправить" их ошибки ;-)
1.4 Разное. Сюда можно отнести очень много факторов, влияющих на скорость игры.
Напримет, тип шины (AGP/PCI) видео-акселератора. Огромное значение имеют вещи,
о которых вы можете даже не задумываться - например, ISA звуковая карта может
нещадно тормозить вашу игру, а как вы об этом узнаете?
Если речь зашла о звуке, то, например, программная реализация 3D звука может
запросто отъесть значительную часть ваших ресурсов (от 3 до 6 % процессорного
времени на каждый 3D звуковой буффер). Играют роль фоновые задачи - зачастую вы
о них ничего не знаете, но, например, автоматически устанавливаемая MS
Office-ом в авто-запуск, "быстрый поиск файлов" программка может с легкостью
превратить ваш компьтер в полный тормоз, для некоторых игр.
Подведем итоги этой главы. Главное - скорость игры, и, следовательно,
показатель FPS значительно зависит не только от вашего видео-акселератора, но и
от других основных параметров вашего компьтера - процессора (и поддерживаемого
им набора инструкций), количество памяти, размер кэш памяти первого и второго
уровня, скорость шины, другая установленная переферия, фоновые задачи,
настройки многозадачного режима и пр. и пр. и пр.
Когда канонический персонаж Вася Пупкин говорит - на моем видео-акселераторе
игра показывает XX fps, а Петя ему вторит, что на той-же самой карточке он
имеет YY fps - это вообще ни о чем не говорит! Остальные отличия компьютеров и
программного обеспечения могут легко изменить результаты в несколько раз!
От чего зависит FPS (продолжение)
Продолжим наши разбирательства со скоростью игр и видео-акселераторов. Если вы
внимательно проинспектировали свой компьютер на предмет совместимости
оборудования, программа написана "правильно" - то один из главных лимитирующих
факторов, влияющий на FPS определился достаточно четко - скорость, с которой
CPU просчитывает данные и "скармливает" их видео-акселератору - то есть
скорость плавающей арифметики процессора, величина кэша первого уровня, и
пропускная способность системной шины (и локальной шины акселератора PCI/AGP).
Сейчас вы спросите - а как-же другой "главный" показатель видео-карты -
скорость заполнения (fillrate)? И спросите совершенно справедливо - это
действительно один из основных показателей, влияющих на скорость игры. Но не
всегда и не везде.
2. Fillrate
Fillrate - это скорость, с которой видео-акселератор заполняет (расчитанные)
значения пикселей в буффер, то есть скорость рисования. На первый вгляд,
ограничения накладываемые fillrate-ом обойти невозможно. Это чисто аппаратный
показатель, он зависит только от скорости видео-памяти и процессора. Ну, еще от
ширины канала, ведь, расчет цвета пикселей происходит аппаратно, и можно
расчитывать их параллелльно, параллелльно же загружая в память видео-карты.
Поэтому и растет ширина (а, следовательно, и пропускная способность) шины к
видео-памяти - 64 бита, 128 бит, а теперь уже и 256 бит... Поэтому и
ограничивается качество цвета, и используются только 16 бит на цвет, вместо
"положенных" 24.
Fillrate - это одно из самых узких мест, и в борьбе за него жертвуют многим.
Однако, и тут, оказывается, есть варианты.
2.1 Разные типы буферов. Необходимо понимать, какие именно данные записывает
акселератор в память. Кроме буфера самих цветов (цвет каждого пикселя),
видео-акселератор хранит в своей памяти еще и другие данные. Как правило, это
Z-буфер ("глубина", Z-координата, каждой точки экрана) и иногда, буфер
шаблонов. Есть еще и другие типы буферов памяти, самый из известных который -
накопительный буфер (accumulator), вариацией которого и является
разрекламированный T-buffer будущих карт фирмы 3dfx. Однако, большинством
"игровых" акселераторов, аппаратно поддерживаются только Z-буфер, и буфер
шаблонов (как правило, в 32-битном режиме).
При использовании других типов буферов аккселерация не поддерживается, драйвера
переходят в software режим... В общем, никто их (по этой причине) и не
использует.
Таким образом, акселератор записывает в память, как правило, вдвое больше
инофрмации, чем вы видите на экране.
2.2 Чтение видео-памяти. Кроме записи в видеопамять сформированной картинки,
акселератору необходимо еще и читать из нее. Необходимость возникает в двух
случаях - необходимость знать Z-координату пикселя, для того, что-бы не
рисовать поверх него точки, лежащие за ним;
- необходимость прочитать цвет уже нарисованной точки, для смешения цветов, а
именно, когда рисуется полупрозрачный объект (дым, огонь, вода, стекло и пр.)
находящийся к нам ближе, чем уже нарисованная точка.
2.3 Текстуры. Текстуры объектов тоже храняться (как правило) в видео-памяти
акселератора, и их чтение (перед накладывание на поверность объекта) так-же
отъедает значительную часть пропускной способности шины.
Взглянув на эти два пункта, становится ясным, как увеличить скорость игры, даже
при фиксированном fillrate. Для этого нам нужно минимизировать все операции,
связанные с записью и чтением данных в/из памяти видеокарты.
Простейший пример - стена. Непрозрачная. Совершенно точно известно, что
объекты, находящиеся за стеной, видны не будут. Значит, если программист сможет
заранее выяснить, какие именно объекты рисовать не нужно - отпадает
необходимость
а) в записи в Z-буфер данных, относящихся к стене, и
б) чтение из Z-буфера данных, при рисовании объектов находящихся "перед"
стеной. Таким образом, можно, практически, на 2/3 сократить объем данных,
передаваемых по шине памяти акселератора, и увеличить "эффективный" fillrate в
3 раза. Разумное использование прозрачных объктов так-же может значительно
сократить наши затраты.
Конечно, эти "хитрости" программирования 3D движков не всегда удается
использовать, но фокус заключается в том, что именно фон картинки требует
максимальной скорости заполнения (так как он занимает большую часть физической
поверхности экрана), и здесь этот прием работает в полную силу.
Таким образом, в типичной игре, даже при наличии не слишком высокого уровня
fillrate современных акселераторов, возможно создание достаточно "заполненных"
сцен. Больше того, уж позвольте мне немного удариться в философию, но я уверен,
что значительное повышения скорости заполнения следующего поколения
видео-акселераторов, не даст настолько же значительного повышения скорости
игры. Многие их моих знакомых ностальгически впоминают Word 2.0. Помните,
текстовый такой? И работал он с приемлемой скоростью, и функционально не было
обделен. Что-же произошло, что имея супер современный пентиум и дикое (как
казалось совсем недавно) количество памяти, пользователи все так-же мучаются
"тормознутостью" современных программ?
Впрочем, ответ вы знаете не хуже меня. И позвольте выразить уверенность - как
только fillrate перестанет быть самым узким местом - никто, ну совершенно никто
не будет его экономить. Да, еще какое-то время он будет расти - будет нужен для
полносценного антиалиасинга, для стерео-режима, для увеличения разрешения
экрана. Но уже наступает насыщение, и когда fillrate увеличится в несколько раз
- вы это не сильно-то и заметите...
Мифы 3D программирования. Часть Вторая
Glide, D3D, OpenGL
Давайте рассмотрим еще одни (а то и несколько ;-)) мифов 3D программирования.
Один из наиболее часто встречаемых - Glide API лучше, чем D3D, или OpenGL. Как
доказательство, приводят то, что игры, написанные с использованием Glide
работают быстрее (на этом API), чем на D3D или OpenGL, выглядят красивше и пр.
Хм. В общем-то результат действительно имеет место быть. Действительно, игры
типа Unreal, и написанные с использованием этого движка - выглядят, при
использовании Glide значительно красивее, и бегают не в пример быстрее.
Но из "верных" исходных посылок делают неверный вывод, что API Glide лучше, чем
другие. Я думаю, путанница связана с тем, что при настройке игры, пользователь
выбирает пункт меню "Использовать Glide", и автоматически ассоциирует результат
с данным API.
Это в корне неверно.
Давайте разберем, что же именно делает Glide игры более быстрыми реально.
Прежде всего, должен вам заметить, что если игра поддерживает Glide - то с
вероятностью 99.9% она изначально и писалась для этого API. Скорее всего, тут
имеют место исторические причины - еще совсем недавно Glide было чуть-ли не
единственным API, пригодным для создания игр на PC. D3D еще пешком под стол
ходил, и сравнивать возможности версии 3.0 с версией 7.0 просто смешно. OpenGL
использовался, в основном, только на high-end графических станциях, и
нормальных драйверов для него для PC просто не существовало как класса.
Игры, особенно сложные, тоже пишуться не один день. И не месяц. Они пишутся
годами, и когда их начинали писать - Glide-у просто не было альтернатив.
Впрочем, D3D пытались использовать, но он был изначально оптимизирован под
software рендеринг, поэтому его в расчет для акселераторов (в то время -
практически монопольно представляемых 3dfx) брать не имеело смысла.
По ходу дела замечу, что программисты, пишушие 3D игры, должны бы каждый день
ходить и ставить свечку Кармаку, который "позволил" себе оставить отживший свое
Glide, и не поддаться шантажу мелкософта, и остановил свой выбор на OpenGL.
Первые OpenGL драйвера на PC писались чуть-ли не исключительно с целью
поддержки Quake, и только благодаря ему мы имеем сейчас возможность сравнивать
и выбирать.
Но вернемся к Glide. Итак, большинство игр изначально начинало писаться на нем.
Но. Но не это является причиной, по которой игры на Glide являются "самыми"
красивыми и быстрыми. Дело в том, что Glide является прямым отражением
аппаратных возможностей Voodoo видео-акселераторов. Для того, что-бы писать
игру на Glide - программисты работали в первую очередь на Voodoo картах, и
отлаживались на них-же, и оптимизировали свои движки на Voodoo картах.
Как-то давно, я читал об одном поставленном экперименте, еще на заре
программирования и компьютеризации. Взяли несколько программистов. Одних их
лучших. Поставили им одну и ту же задачу, и, как говориться, засекли время. Так
вот, время написания ими программы, практически не отличалось. Но вот скорость
работы программ - отличалась в десятки раз. Все были очень хорошими
специалистами, все были асами своего дела. Причина такого разрыва была в том,
что одну и ту же задачу можно решить несколькими различными способами. Я вообще
верю в то, что Господь Бог не может предложить ситуацию, с менее чем тремя
возможными вариантами поведения, ибо это будет прямое оскорбление человека,
чего Отец наш не допустит.
Но вернемся к нашему разговору. Итак, из простого я понятного факта, что
начиналась разработка 3-х мерных игр, как правило, на Voodoo, на них-же в
первую очередь отлаживалась и оптимизировалось - из этого следует простой
вывод. В каждом случае, когда один и тот-же результат можно было достичь
разными способами - выбирался тот, который быстрее работал именно на Voodoo
картах. Понимаете? Кроме рисования (fillrate), и расчета геометрии (T&L) - есть
еще уйма, прорва всего, что влияет на производительность карты.
На некоторых медленно происходит переключение контекста рисования (например,
смена текстуры), или еще какой процесс. Одни драйвера делаю упор на оптимизацию
одного способа рисования, другие - другую часть. У одного акселератора размер
FIFO буффера графических примитивов один, у другого другой. Даже при
(приблизительно) одинаковых аппаратных характеристиках, разница в скорости
рисования одной и той-же сцены может отличаться в несколько раз. Легко.
Оптимизация драйверов - это вообще совершенно отдельная, неспетая песня. Просто
маленький пример из OpenGL Game Developers Mailing List. Один программист хотел
использовать PixelTransfer - чтение данных из видео-буфера. Это оказалось очень
и очень медленной операцией. Это показалось ему странным, и он связался с ATI,
и помог им оптимизировать ту часть драйвера, которая отвечала за этот процесс.
Скорость данной операции выросла, по его словам в 2000 раз. В две тысячи раз. К
сожалению, он потом отказался от этого пути решения своих проблем, так как все
остальные драйвера (к другим видео-аккселетарорам), естественно, не были
оптимизированны в этом месте.
Ну и конечно, имея несколько-кратный запас по скорости на Voodoo карточках,
программисты могли себе позволить добавить больше эффектов (опять-же, используя
способ, лучше всего работающий на Voodoo) - и, как результат, эти игры работают
на картах 3dfx не только быстрее, но и выглядят красивее.
Итак, проблема не в том, что Glide как API лучше. Просто большинство самых
сложных современных игр изначально писалось, тестировалось и оптимизировалось
под Voodoo карты (и только на них и работает Glide, ведь так-же?). Если раньше
это был вынужденный шаг, и правильная политика (поскольку, 3dfx имел этот рынок
практически монопольно), то сейчас, когда пальму лидерства по продажам и
установленным картам перехватила NVidia - медленная работа на других картах, и
в первую очередь на народных картах TNT/TNT2 - это просто неуважение к нам, к
тем, кто им платит деньги, в конце концов (хотя, последнее было бы лучше
замять, для ясности ;-)).
D3D, OpenGL
Итак, поговорив немного о "лучшести" Glide, давайте попробуем сравнить
оставшиеся два широко распространенных API - Direct3D, и OpenGL.
Прежде всего, пнем, по ходу дела, еще один распространенный миф. А именно -
"Direct3D изначально быстрее, чем OpenGL". Дело именно в слове "изначально",
отображающее маркетинговые происки M$, о том, что, мол, OpenGL изначально
делался для High-End графических станций, а, мол, Direct3D делался специально
для задач написания игр, и потому, как-бы OpenGL не тянулся - до Direct3D ему
не достать.
Миф. И очень вредный, кстати говоря.
Да, никто не будет отрицать, что современные Direct3D драйвера, как правило,
несколько быстрее, чем их OpenGL собратья, и более стабильны... Но это не
результат "изначальной" лучшей проектировки D3D, или его "специальной" заточки
под 3D игры. Это результат постоянного шантажа и выкручивания рук
производетелям драйверов и железа, со стороны M$, разумеется.
Изначально, то есть с точки зрения проектирования, дизайна API, его удобства
для разработчиков игр и драйверов, его целостности, его красоты, в конце концов
- изначально OpenGL намного впереди D3D.
Не буду распространяться слишком много, ведь это, в конце концов, читают в
основном те, кто играют в игры, а не те, кто их пишет. Но все-же несколько слов
общего плана сказать стоит.
1. Написание программ состоит из нескольких этапов - поектирование, реализация
предварительного варианта, и затем - отладка, оптимизация и сопровождение.
2. По всем - совершенно по всем и каждому пункту OpenGL предоставляет больше
возможностей программисту.
2.1 Проектирование. Ну, если говорить о 3D части игр, то OpenGL значительно
лучше документирован, его интерфейс намного более удобен и прозрачен, по
сравнению с Direct3D, вы можете найти тонны примеров, как реализовать то или
иное.
2.2 Предварительный вариант. Тут OpenGL опять вне конкуренции. Объем
написанного кода (в смысле - количество строк исходного текста) в разы меньше,
необходимого для D3D. OpenGL не требует хранить и передавать драйверу данные в
определенном формате, практически каждая функция имеет варианты для разных
типов аргументов - короткое и длинное целое, короткое и длинное число с
плавающей запятой.
Вы можете разместить различные данные в одной структуре, и формат этой
структуры никак не диктуется OpenGL API, в отличие от, так сказать. Опять-же,
OpenGL не привязан к различным proprietary вещам типа COM интерфейса, и имеет
прявязки (возможность вызова), практически из всех распространенных языков
программирования.
2.3 Отладка. Тут OpenGL тоже на высоте. В любом месте программы вы можете
полностью проверить состояние драйвера и текущие настройки. Каждый вызов
системной функции предполагает (и располагает!) полную проверку правильности
всех аргументов, а ошибки не приводят к фатальным последствиям и легко
находятся. Кстати, именно это и заставило меня перейти от Glide API на OpenGL -
потому что, начиная с некоторого порогового уровня сложности, я оказался просто
не в состоянии отследить работу Glide.
К сожалению (а скорее - к счастью), я не имел чести отлаживать программу,
написанную на D3D. Но вынужненное знакомство с "родственными" API - DirectSound
и DirectInput оставили у меня (как и вообще весь стиль MS) тягостное
впечатление.
2.4 Оптимизация. Пожалуй, самая интересная, с точки зрения конечного
пользователя, возможность. Тут Direct3D и рядом не стоял. Вообще. Начнем все с
того-же - OpenGL не диктует формат данных. Ни программисту, пишущему игру, ни
писателю драйверов. Соответсвенно, те, кто пишут драйвер, могут сохранять
данные, переданные программой - где угодно и как угодно. Например, после
предварительной обработки (T&L) - в той-же видео-памяти, которая значительно
быстрее, чем обычная. Да и формат хранения они, естественно, выбирают наиболее
близкий к необходимому для передачи в железо. Кроме того, для "статических"
объектов, то есть не меняющих свою геометрию и пр. свойства во времени - есть
возможность скомпилировать их в display list. Опять-же, поскольку эти данные не
изменяются во времени, уровень возможной оптимизации значительно выше, чем у
ближайшего аналога из D3D. Есть и форматы хранения и передачи данных,
позволяющие модифицировать объект в течении времени, к тому-же, предполагающие
более удобный и компактный вид, чем D3D - DrawArrays и DrawElements.
2.5 Сопровождение. Сопровождение предполагает исправление ошибок (то есть
постоянный процесс отладки) и постоянное обновление программы, для поспевания
за быстротекущим временем - это включает в себя поддержку нового железа, и
переносимость на другие платформы. Вы уже догадались - D3D не может даже
претендовать на равность в этих впоросах. О переносимости (а следовательно - и
освоении смежных сегментов рынка) D3D говорить просто не приходится. Он и в
Windows-то не успевает - скажем, последняя официальная версия для NT - это
DirectX 3.0, а для Windows 95/98 - 7.0. А ведь NT - это стандартная платформа
разработчиков программ Win32. Как вы догадываетесь - о Mac, Linux, OS/2, BeOS и
других - говорить просто не приходится - а ведь за ними тоже стоит немало
людей, и для бизнеса - это тоже деньги!
В плане поддержки новых технологий... Ну как закрытый и контролируемый только
одной корпорацией API может соперничать с открытым стандартом? OpenGL
официально поддерживает механизм расширений - и каждый производитель 3D
акселераторов может добавить в него именно те возможности, которые есть только
у него, и нет у других производителей. Кроме того - расширения - это и
эффективный механизм развития API. Наиболее часто используемые программистами
расширения постепенно и естественным образом переходят в разряд стандарта, к
тому-же, все производители имеют время для доработки и улучшения как нового
стандарта, так и своего железа - в течении времени "обкатки" расширения.
Опять-же, отсутсвие жесткого формата данных позволяет вносить и совершенно
радикальные изменения - например, мультитектурирование, которое, при
фиксированном формате данных, может потребовать переработки всего API типа D3D.
И под конец, почему-же все-таки Direct3D быстрее OpenGL? Да по политическим
причинам. Только. Именно по политическим причинам программная реализация OpenGL
"от Microsoft" была значительно медленнее, чем Direct3D реализация. Больше
того, существовала реализация OpenGL для Windows "от SGI" - значительно более
быстрая. Но после того, как M$ и SGI "помирились", договорившись не вести войн
стандартов, а совместно начать работать над проектом Fahrengeht (кажется
так...) - мелкосфот потребовал убрать из интеренета все ссылки на SGI
реализацию OpenGL, и прекратить его дальнейшую поддержку... Что, увы, и было
сделано. Мелкософт же, как обычно, попытался всех "кинуть" - и реализовать
Фаренгейт только через Direct3D. Впрочем, за OpenGL часть проекта отвечал SGI,
но ему стало как-то скучно на этом рынке, лучшие специалисты перебрались в
NVidia, и так-бы OpenGL и скончался, тихо и незаметно... не получи он мощную
поддержку со стороны Кармака. За что, как я писал, программисты ему ежедневно
свечку должны ставить и молиться за здравие ;-)
Мифы 3D программирования. Часть Третья
Поддержка T&L
Поговорим теперь о модной нынче теме - T&L (попросту transformation and
lighting - трансформация и освещение).
Строго говоря, нельзя назвать неподдержку аппаратного T&L мифом. Скорее - это
аттавизм и косность программистов.
Если вы уже читали мои статьи здесь, или постинги на www.3dclub.ru или сами
знакомы с написанием 3D программ - вы должны уже быть в курсе, что каждая,
каждая 3D игра требует T&L как промежуточный этап. Не буду останавливаться на
этом подробно, так как уже писал на эту тему. Но хотелось бы объяснить - каким
же образом получилось, что, все программы используют T&L, и в то же время - они
оказались не готовы к аппаратному T&L ?
Ответ достаточно прост. Проблема заключается в том, что до самого последнего
времени, ни Glide ни Direct3D не имели поддержки T&L. Glide и сейчас ее не
имеет, кстати говоря, и это была одна из причин, по которой 3dfx отказалась от
его поддержки и дальнейшего развития.
Как действует программист, который должен поддерживать T&L, если в API его
поддержки нет? Тут и угадывать нечего - он его пишет сам. И даже если в числе
поддерживаемых API есть OpenGL, который, на уровне API, поддерживает T&L -
кому, ну кому нужна головная боль, с ведением параллельно двух видов исходных
текстов - для самостоятельной реализации T&L, и для реализации T&L через
OpenGL?
Конечно, их предупреждали. Им говорили - ребята, вот-вот появятся 3D
акселераторы с поддержкой T&L. Ну и что, ну говорили? Вы же знаете - пока гром
не грянет, мужик не перекрестится.
Им говорили - ну как-же так, ведь на уровне драйвера значительно легче
оптимизировать процесс T&L. Драйвер может автоматически использовать все
возможности железа - например, автоматически будут поддерживаться новые
инструкции AMD 3DNow! и SSE. Возмите во внимание еще и такой факт. У вас есть
1000 человеко-часов на оптимизацию. Если вы оптимизируете каждую из 1000 игр -
получится один час на каждую игру. Или, если вы оптимизируете только драйвер -
можно добиться совершенно фантастического уровня оптимизации. И, как следствие,
алгоритмы используемые в драйверах - значительно лучше и быстрее "самопальных".
Но очень мало кто прислушался к таким советам. Вообще, это американская модель
- жить сегодняшним днем. Жить сегодняшней прибылью - а там видно будет...
Вот так мы и пришли к совершенно абсурдной ситуации, когда все используют T&L,
почти все даже поддерживают OpenGL - а игр, поддерживающих аппаратную
реализацию T&L - совсем немного.
Впрочем, не все так печально. Игры поддерживающие аппаратный T&L появятся очень
быстро. Ведь, фактически, для этого нужно совсем немного. Новые игры -
изначально проектировать так, чтобы они не занимались самодеятельным T&L. А из
старых - просто убрать лишнее. Просто убрать... Как говориться, ломать - не
строить. И это, пожалуй, единственный изветсный мне пример, когда эта поговорка
несет положительный смысл ;-)
Заключение
Можно вспомнить и обсудить еще много мифов, связанных с 3D программированием,
но, пожалуй, стоит остановиться. Как говорят поляки - что занадто, то не в
здраве.
И все-же, мне хотелось бы завершить эту статью небольшим призывом. Вы, как
пользователи, как люди, для кого мы работаем - вспомните и о тех, кто пишет для
вас игры.
Поддерживайте OpenGL. Пишите письма фирмам-производителям, требуйте исправлять
ошибки и оптимизировать OpenGL драйвера. Поверьте, вы первые, кто выиграет от
того. Мы сможем писать игры быстрее и лучше, они будут содержать меньше ошибок
и работать быстрее.
Почему измерять скорость в играх в FPS правильно
Комментарий 3DNews
Максим Кизуб в своей статье о мифах 3D программирования обоснованно доказывает,
что измерение скорости игр в FPS неверно в принципе. Не хочу сказать что я не
согласен с его точкой зрения, однако хочется высказать и своё мнение. Максим
говорит что результаты, получаемые в тестах "усреднены", и считает что это
плохо. Но то, что не подходит для больницы хорошо для тестов. Ещё в Quake II
была комманда timerefresh, позволяющая получить средний FPS в конкретном месте.
Год назад timerefresh многих смущал - получались результаты, существенно
отличные от результатов timedemo. Неудивительно, ведь многие проводили тест в
уровне base1 в самом начале, месте, где практически не создавалось серьёзной
нагрузки на акселератор - память не загружалась большими текстурами, геометрия
видимой сцены не слишком нагружала процессор. Timerefresh - типичный
некомпетентный тест, не отражающий реальной производительности акселератора в
игре. Недавний выход "Dagooth Moor Zoological Gardens" показал, что бенчмарки
не так легко делать - общий результат теста портится, если уткнуться в тёмный
угол или наоборот залезть повыше и осмотреть всю сцену. Нормальный современный
тест проходит при средней нагрузке на акселератор, при этом средней можно
считать нагрузку в рассчёте на среднестатистический акселератор. Никто не
делает тестов, безбожно тормозящих на всех акселераторах - такой тест не будет
пользоваться популярностью. Возьмём, к примеру, "Quake 3 Arena" с его демками.
Сомневаюсь, что в iD демки отбирались от фонаря - заметьте, что человек, от
лица которого играются демки играет весьма средне и не висит на первом месте.
Демка отобрана по принципу, показывающему, как средние по детализации сцены,
так и "напрягающие" места, в которых даже самые мощные акселераторы получают
серьёзный удар. Результирующие FPS показывают насколько удачно акселератор
способен справится с игрой в целом. И результаты вполне совпадают с
реальностью.
Другим вопросом является то, что нельзя возводить FPS в абсолют. Это всего-лишь
цифры, которые важны сегодня, которые показывают, насколько быстр будет
конкретный акселератор в сегодняшних приложениях. Как пример - первые чипы TNT,
имевшие множество теоретических плюсов, которые востребованы только сегодня.
Отличный акселератор, появление которого во многом продвинуло индустрию в
целом. Но в тот момент он был не самым удачным выбором из-за Glide, который был
ещё более чем жив.
Рассматривая акселератор сегодня мы должны показать, насколько его преобретение
необходимо сегодня, а так же коснуться его перспективности. Перспективность
рассматривается на возможностях, актуальность - на результатах. Рассматривать
голые цифры вроде Fillrate, Setup Engine Performance, T&L performance не имеет
смысла - хороший пример в этом роде Savage2000, чип имеющий много плюсов на
бумаге и ещё больше минусов реализации в железе. Я уверен, что завтра появятся
игры, на которых тот же GeForce покажет 5 fps, и все будут его ругать. Подходя
к анализу акселератора стоит рассматривать его возможности, важные в будущем,
технологии, которые имеют перспективы, рассматривать инновации и сложность их
использования. Проще говоря, обзор должен рассматривать акселератор со всех
сторон, а не быть зацикленным на одних только FPS в "Quake 3" или "Unreal
Tournament" и т.д. В этом вопросе Максим совершенно прав. Но на сегодня
результат в FPS остаётся единственным, что может обьективно показать
возможности чипа, затмить его технические параметры и показать что он может,
насколько отлажены драйвера и эффективна архитектура в современных играх.
В качестве примера можно взять PoverVR с его тайловой архитектурой и некоторыми
нововведениями в рендеринге, которые позволяют имея весьма средненькие
характерискики получить неплохую графику и приличную производительность. А вот
если бы мы сравнивали отдельно Fillrate, отдельно другие характеристики, то
полученный обзор имел бы чисто академический интерес, и не представлял бы
ценности для потенциального покупателя пытающегося разобраться в море карт.
Ещё одна мысль, высказанная в обзоре Максима - "Когда канонический персонаж
Вася Пупкин говорит - на моём видео-акселераторе игра показывает XX fps, а Петя
ему вторит, что на той-же самой карточке он имеет YY fps - это вообще ни о чем
не говорит! Остальные отличия компьютеров и программного обеспечения могут
легко изменить результаты в несколько раз!" Мысль совершенно правильная, но
хотелось бы дополнить - отличия не только в программном обеспечении, запущенных
приложениях, качестве и количестве его железа. Дело может быть в настройке
драйверов, игры, BIOS, да и просто, к примеру, в материнской плате. При обзорах
акселераторов есть специальный пункт - масштабирование ядра, который примерно
призван показать разницу в работе чипа на разных системах. Около двух лет назад
в Рунете была популярна фраза "Voodoo2 недостаточно оптимизирован для работы со
слабыми процессорами, например Pentium 133, и обеспечивает небольшой прирост
производительности". Фраза в корне неверная - откуда будет прирост, если не
хватает мощи засыпать акселератор данными? Лишь позднее люди полностью поняли
идею масштабируемости и стали использовать её в обзорах. Конечно, результаты
зависят от вышеназванных параметров, однако никто и никогда не сумеет полностью
прояснить ситуацию со всеми видами оборудования, совместимостью, скоростью
работы и т.д. Каждый должен "выстрадать" результат для своей системы сам. К
сожалению не все это понимают, и Максим правильно поднял этот вопрос в статье.
|
|
 |
|
