Компьютерра (№255) - Журнал «Компьютерра» № 13 от 04 апреля 2006 года

Словарь-минимум

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

Самое главное — понимание организации памяти. Универсальной встроенной структурой данных в GPU является текстура. Текстуры бывают одномерные, двухмерные и трехмерные[Т. Кормен, Ч. Лейзерсон, Р. Ривест. Алгоритмы. Построение и анализ. — М.: МЦНМО, 2000]. Это прямой аналог многомерному массиву. Пиксел текстуры (тексел) -элемент массива. К сожалению, максимальные ширина, высота и глубина текстуры строго ограничены. Этот предел зависит от платы и от размерности и обычно равен 2048 или 4096. Поэтому одномерные текстуры становятся малоинтересными — в них вмещается слишком мало данных. Трехмерные текстуры отпадают по другой причине — они могут быть только считаны, но рисование в них невозможно. Остаются только двухмерные текстуры, в которые нужно научиться упаковывать все прочие структуры данных. Заметим, что эффективная размерность всех текстур на единицу больше, поскольку каждый тексел может содержать до четырех цветовых компонентов. Например, длинный одномерный массив можно упаковать таким образом: первые четыре элемента записываются в тексел на пересечении первой строки и первого столбца, следующие четыре — в тексел из второго столбца и так до исчерпания первой строки, затем всё продолжается со следующей строки и т. д.

Любопытна система адресации в текстуре, которая осуществляется заданием по каждой координате действительного числа из диапазона [0,1]. Расстояние (изменение индекса при переходе) между соседними текселами уже не 1, как в обычном массиве, а зависит от разрешения текстуры (рис. 3). Для получения точного значения тексела необходимо указать координаты центра его «квадратика», при запросе по другому адресу результат будет зависеть от текущего режима фильтрации.

Запись данных в текстуру достигается назначением ее в качестве цели рендеринга (render target). Последующее рисование какой-либо фигуры фактически выбирает обновляемые элементы текстуры (рис. 4). Обычно рисуют один большой треугольник, покрывающий цель рендеринга с запасом, либо прямоугольник точно совпадающих размеров. Неудобно то, что координаты углов фигур нужно задавать уже не в текстурных, а в отличающихся от них экранных (viewport) координатах. Итак, координаты вершины определяют рассчитываемые фрагменты. Входные аргументы пиксельному шейдеру передаются через ассоциированные с вершиной данные, в первую очередь через текстурные координаты.

Процедура обработки одинакова для всех пикселов. Поэтому о пиксельном шейдере можно думать как о теле некоторого цикла. Также можно, рисуя меньшие фигуры и «играя» с тестом глубины, применять различные шейдеры избирательно. Такая необходимость возникает, когда алгоритмы обработки внутренних и приграничных точек текстуры существенно отличаются и их невозможно или нецелесообразно совмещать в одном шейдере.

Простейшие программы

Сейчас мы уже знаем, что GPU способен применять одинаковую программу для вычисления значения каждого элемента одного массива, основываясь на данных других массивов. Есть ли алгоритмы, которые формулируются именно таким образом? Оказывается, есть. К этому классу относятся, например, методы фильтрации изображений и часть способов приближенного решения дифференциальных уравнений, отражающих динамические явления физики. Именно такие алгоритмы проще всего переносятся на GPU, и именно на них достигается наибольшее ускорение.

Давайте рассмотрим что-нибудь посложнее. Задача редукции массива заключается в нахождении какой-то скалярной функции его элементов. Это может быть сумма всех чисел массива, или величина максимума, или что-то в том же духе. Поскольку шейдер ограничен в количестве операций, за один проход рендеринга решить задачу решительно невозможно. Применяется следующий способ. Порождается вспомогательная текстура, размерами чаще всего вдвое меньше исходной по обеим осям. Используемый шейдер, заполняя ее, вычисляет функцию только от четырех величин. Затем вспомогательная текстура назначается на вход шейдера, а выходом служит еще вчетверо меньшая текстура. И так до получения текстуры из одного пиксела, которая содержит ответ (рис. 5). Число проходов составляет логарифм от начального размера массива.

Умножить матрицу на вектор при ограничениях Shader Model 2.0 тоже не так-то просто. Одно из определений гласит, что произведение является линейной комбинацией столбцов исходной матрицы, взятых с весами из второго сомножителя. Поступают таким образом. На первом шаге каждый элемент матрицы умножается на соответствующий ему вес — получается вторая матрица. Последующие шаги посвящаются комбинированию столбцов — редукции только по горизонтали.

Еще интереснее дела обстоят с сортировкой массива. Сразу понятно, что в случае с GPU понадобится второй вспомогательный массив из-за невозможности выполнять чтение и запись одновременно с одним массивом. Но на этом сложности не кончаются. Алгоритмы сортировки основываются на операции сравнить-и-обменять: для выбранных двух позиций в массиве производится сравнение элементов, и, если они нарушают порядок сортировки, происходит их обмен. В GPU, как мы помним, определение новых значений массива выполняется независимо, поэтому каждое сравнение приходится делать дважды. Но и это еще не все. Выбор позиций для очередной операции сравнить-и-обменять в быстрых последовательных алгоритмах зависит от результата сравнения в предыдущих операциях. К счастью, в теории параллельных вычислений уже разработана тема сортирующих сетей, которую можно адаптировать для GPU. Количество операций, выполняемых параллельным алгоритмом, больше, чем у лучших последовательных алгоритмов, и их отношение растет с ростом массива. Тем не менее, благодаря своей мощи, современные GPU не уступают в скорости сортировки, хотя о существенном ускорении речь пока не идет.

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

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

Перспективы

Если говорить о ближайшем будущем самих чипов, то здесь все замечательно. Год за годом GPU прибавляют в скорости работы куда быстрее, чем CPU, увеличивая и без того немалый отрыв. Поколения графических чипов тоже сменяются куда чаще. Даже для непрофессионального использования уже некоторое время предлагается устанавливать в компьютер две видеокарты (технологии SLI или Crossfire). Можно будет использовать вторую плату исключительно как сопроцессор для расчетов, полностью освободив ее от обработки графики. Радужные перспективы GPGPU способны поблекнуть только из-за недостаточной программной поддержки.

Заключение

Неспособность центрального процессора в одиночку справляться с возникающими вычислительными задачами — секрет Полишинеля. Раньше всего это стало очевидно в машинной графике. В результате за прошедшие годы сформировался стандартный современный графический сопроцессор GPU. Сейчас речь заходит о создании других аппаратных акселераторов, в том числе и для игровых целей [Например, скоро вы можете столкнуться с невозможностью запустить игру без еще одного, на сей раз физического процессора:www.ageia.com/products/physx.html]. Но под каждое приложение свою «железку» не выпустишь, куда как интереснее увидеть нераскрытые возможности GPU, находящегося внутри почти каждого персонального компьютера.

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

Лабораторные опыты

Одно дело — лицезреть графики ускорения на страницах чужих статей, и совсем другое — убедиться в этом самостоятельно. Не случайно ведь пользуются широкой популярностью такие тесты, как 3DMark и Doom 3. Ничего подобного им по удобству и авторитетности в области вычислений на GPU пока не существует. Можно упомянуть разве что пакет GPUBench из Стэнфордского университета, но он предназначен для сравнения GPU только между собой и содержит лишь синтетические тесты вроде скорости выполнения одной инструкции, повторенной многократно. Более того, далеко не каждую найденную программу для GPU вообще удается запустить из-за ориентации ее авторов на конкретного производителя[Если вы читали статью сначала, то легко угадаете какого. К сожалению, неполная совместимость GPU еще не изжита окончательно] графических чипов. Поэтому я решил подойти к проблеме творчески и предложить самодельный набор тестов [Исходные тексты и исполняемые файлы http://jorik.sourceforge.net], а заодно убедить вас, что работа с GPU не так уж и сложна, как может показаться.

Тест 1. Решается динамическая задача распространения звуковых волн в двухмерном пространстве (см. рис.) при помощи простейшей разностной схемы на сетке 1536x1536. Как уже было сказано, такого рода задачи идеально подходят для GPU. Результат неудивителен — GPU может справиться с заданием в десять с лишним раз быстрее (табл. 1).

Примечательно другое. Во-первых, расстановка плат по производительности в играх и в неграфических приложениях может сильно отличаться. Во-вторых, на бюджетной плате ATI Radeon 9600 установлена такая же обычная память, что и на многих системных платах: 200 МГц DDR SDRAM 128 бит (аналог двухканального режима). Оказывается, огромное ускорение может быть получено даже без быстрой и дорогой графической памяти топовых моделей!

Тест 2. Любопытно также рассмотреть другую крайность — «неудобную» для GPU задачу. Производится сортировка массива из 16 млн. действительных чисел. Здесь CPU выполняет алгоритм быстрой сортировки (STL quick sort), GPU — параллельной битонической сортировки (см. выше). В результате разного количества операций в алгоритмах быстрая видеокарта лишь приближается к центральному процессору (табл. 2).

Тест 3. Исследуется скорость копирования многомегабайтной текстуры, где каждый пиксел содержит четыре 32-битных действительных числа, из системной памяти в видеопамять и обратно. Эта скорость важна, потому что она определяет, какие задачи имеет смысл доверять GPU. Если задача проста, то преимущество GPU может быть нивелировано временем передачи данных к нему. Поэтому выгода получается только на крупных задачах, обсчет которых занимает гораздо больше времени, нежели пересылка данных. Результаты[Их достоверность перепроверялась пакетом GPUBench, скорость для платы nVidia близка к данным презентации "Interactive Geometric Computations using Graphics Processors"] теста оказались просто обескураживающими (табл. 3).

Эти скорости не только ниже 4 Гбит/с шины PCI-Express, но, пожалуй, и самых первых версий AGP. Хочется надеяться, результаты столь низки оттого, что современным играм не приходится часто выполнять копирование больших текстур, особенно описанного формата, и мы имеем дело всего лишь с временной недоработкой драйверов.

До проведения тестирования предполагалось, что использующие GPU программы практически не будут загружать центральный процессор. Действительность оказалась не такой радужной. Нагрузка была очень высокой, доходя до 100%, так что даже окошки по экрану перетаскивались с трудом. Эффект наблюдался и для DirectX-, и для OpenGL-приложений. И еще нельзя не отметить, что плата ATI при большей сетке в первом тесте и при некоторых других обстоятельствах приводила к синему экрану смерти — это уж совсем никуда не годится.

ТЕМА НОМЕРА: По ту сторону треугольников

Автор: Павел Воронин

Приблизительно так можно перевести с английского «Beyond Triangles» — название последней главы замечательной книги «GPU Gems». Она одной из первых рассказала массовому читателю о возможности использовать графический процессор для чего-то большего, нежели рендеринг составленных из треугольников моделей. Тогда это были главным образом научные расчеты: динамика жидкостей, визуализация результатов объемного сканирования, расчет стереограмм и т. д. Однако за прошедшие несколько лет ситуация радикально изменилась: на GPU были перенесены все классические алгоритмы и разработан целый ряд новых, максимально использующих преимущества, даваемые архитектурой современных видеокарт. Техника GPGPU[General-Purpose Computation on GPUs, вычисления общего назначения на графических процессорах] становится по-настоящему general-purpose, универсальной, подходящей для решения практически любых задач. Мне, как большому энтузиасту этой области компьютерных наук, хотелось бы рассказать об одном из самых многообещающих ее направлений: использовании GPU для расчета внутренней логики игр.

Отчего да почему

Дело в том, что обычно ядро игры устроено так: сначала на центральном процессоре рассчитываются все перемещения и взаимодействия объектов, изменение их формы (анимация), параметры среды и пр. Затем, с учетом всех этих данных, сцена (то есть набор моделей и спецэффектов) переводится все тем же центральным процессором в стандартное представление: набор координат вершин треугольников и их атрибутов (нормалей, цветов, текстурных координат и прочего). Полученный массив данных, зачастую довольно большой, пересылается на видеокарту, которая и занимается их выводом на экран: расчетом освещения, наложением текстур и применением различных спецэффектов. И хотя пропускная способность шины процессор-видеокарта за последние годы подросла довольно сильно, она до сих пор зачастую является «узким местом» при программировании игр. Поэтому весьма соблазнительно избежать этой пересылки и реализовать выполнение как можно большей части алгоритмов прямо на графическом процессоре.

Уроки физики

Чего не хватает современным играм, чтобы их наконец-то можно было назвать по-настоящему реалистичными? Поиграв во второй HalfLife на максимальных настройках графики, я уже совсем не уверен, что главным препятствием на пути окончательного переселения человечества в компьютерные миры является несовершенство визуальной составляющей. Несколько лет назад мне довелось повозиться с хорошим шлемом виртуальной реальности, и я не сомневаюсь: подай на него картинку уровня детища Valve, и достоверности изображения для девяноста девяти процентов случаев хватит с лихвой.

Другое дело, взаимодействие объектов игрового мира друг с другом и отклик их на действия человека. Лично меня при игре даже в самые динамичные игры вроде Warcraft III, Need For Speed, Grand Theft Auto или ту же HalfLife не покидает ощущение, что я попал в галактику, вдруг остывшую до нуля градусов по Кельвину. Планеты здесь подобно Луне лишены атмосферы, и ветер на них отсутствует. Дым и осколки разорвавшихся снарядов во всем подражают рентгеновским лучам и проходят сквозь тела, не причинив им ни малейшего вреда. Сами тела при этом сделаны из сплошного куска металла, но, разрушаясь, тут же растворяются в воздухе. Жидкостей здесь не бывает. Как, впрочем, и резины, дерева, глины или ваты.

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

Таким образом, перед нами стоит задача: повысить скорость физических расчетов хотя бы на порядок. И, как уже давно догадался внимательный читатель, помогут нам в этом всемогущие шейдеры и запредельные мощности современных GPU.

Тут я тоже начну издалека. Идея снять нагрузку по расчету физики с явно не справляющегося с ней центрального процессора витает в воздухе не первый год. В числе прочих долгое время муссировалась и концепция специально сконструированного для этих целей сопроцессора. И вот в марте 2005 года никому не известная тогда фирма AGEIA, с кучей шума и надоевшего до зубовного скрежета пиара в околокомпьютерных изданиях, публично огласила свои планы по созданию физического акселератора PhysX. Употребленное здесь слово «акселератор» говорит сердцу бывалого игромана больше тысяч эпитетов и стопок хвалебных пресс-релизов. Оно, сердце, истосковавшись по былым потрясениям, вновь наполняется кровью и бешено колотится в предчувствии революции. Всего каких-то десять лет назад появление легендарного 3D-акселератора Voodoo Graphics взорвало рынок трехмерных игр, впервые дав ощущение реальности происходящего — и мы не забыли, как это было. Мы хотим еще.

Но давайте глядеть на вещи трезво. В отличие от видеокарты, работающей с потоками треугольников и пикселов, гипотетический PhysX должен будет эффективно справляться с обсчетом самых разных взаимодействий и математических моделей, разнообразие которых порой кажется мне даже большим, чем разнообразие реального мира. В возможность такого верится, прямо скажем, с трудом. Более того, по заявлению разработчиков, прямого API предоставляться не будет, и все программирование будет вестись через фирменную библиотеку. Негибкость такого подхода многим сразу же показалась фатальной, особенно если учесть, что главным конкурентом в борьбе за роль физического ускорителя выступает практически универсальный вычислитель — GPU.

Еще в 2002 году, выпуская на рынок Radeon 9700, корпорация aTI бросалась громкими заявлениямио переносе физических вычислений на карту и незамедлительном наступлении эры кинематографического качества рендеринга. Хотя за рекламной мишурой не стояло ничего, кроме нескольких лабораторных исследований и пары кривых прототипов, чаяния отрасли и научного сообщества эти слова отражали очень точно: в том, что считать физику на GPU можно и нужно, были уверены все. Так что никто из сторонних наблюдателей иллюзий по поводу будущего aGEIa не питал: все сходились во мнении, что nVidia и aTI постараются задавить начинание в зародыше. И вот буквально на днях битва за потребителя началась: 23 марта было объявлено о выпуске PhysX на рынок, а двумя днями ранее на GDC[Game Developers Conference] миру было представлено детище nVidia и знаменитых Havok — работающий целиком на карте физический движок Havok FX.

Анонсированная на второй квартал новинка продолжает сверхудачную серию физических движков Havok, использовавшихся в Max Payne 2, Age of Empires III, HalfLife 2, F.E.A.R. и еще доброй сотне самых крутых тайтлов последних лет, так что внимание разработчиков к Havok FX обеспечено.

Заявлено, что система будет работать на любых картах, поддерживающих Shader Model 3.0, то есть это линейки GeForce 6xxx и 7xxx плюс Radeon X1xxx. Более того, наконец-то в полную мощь заработает технология SLI: одна карточка будет заниматься просчетом физики, а другая — отрисовкой сцены.

Подробностей внутреннего устройства движка сообщается пока очень мало. В общих чертах устроено все будет так: к набору стандартных базовых типов объектов добавляется ряд новых, описывающих те структуры, которые удалось эффективно реализовать на GPU. Например, примитив Debris[Переводится это слово вовсе не так, как вы подумали, а «осколки», «обломки», «частицы»], абстракция твердого тела. Примитивы можно будет как задавать готовыми 3D-моделями, так и конструировать на лету силами центрального процессора. Последнее может оказаться особенно полезным при визуализации взрывов и прочих разрушений: например, размер и форма выбиваемых снарядами из кирпичной стены кусков будут зависеть от силы выстрела и места попадания. После того как описание объекта передано на карту, CPU им больше не занимается: все, начиная от расчета столкновений и заканчивая выводом треугольников на экран, делает графический процессор.

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

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

К лету nVidia и Havok обещают довести технологию до ума, так что к концу года можно ожидать первых игр с официальной поддержкой нового движка. До революции остались считанные месяцы, друзья.

С небес на землю

Как известно, две трети населенных пунктов России находится в сельской местности, где зачастую нет даже телефона. Что уж там говорить о паре видеокарт nVidia семейства GeForce 7xxx с поддержкой технологии SLI. Так что давайте обратим взор к разработкам, не требующим таких больших мощностей, но оттого не менее интересным. В конце концов, говоря, что на GPU можно делать что угодно, я ведь не врал.

Если вы смотрели чудесный мультфильм «Последняя фантазия» («Final Fantasy: The Spirits Within»), то наверняка обратили внимание, как реалистично там выглядят волосы героев. Я был сражен наповал: и на плечи ложатся, и на ветру колышутся, и друг с другом переплетаются. И волосков там не два и не десять, а тысячи, десятки тысяч. Даже страшно представить вычислительную мощь, стоявшую за этим шедевром. Я это все к чему говорю: в сделанном пару лет назад к выходу GeForce 6800 демо-ролике «Nalu» одноименная русалка обладала шевелюрой сравнимой реалистичности. А просчитывалось все (не без участия GPU, конечно) в реальном времени. В играх я пока такого нигде не встречал, но, думаю, это лишь вопрос времени.

Другим довольно редким на экранах наших мониторов гостем является имитация одежды. Обратите внимание: плащи к персонажам игр насмерть прибиты гвоздями, в шляпы вделан титановый каркас, а все складки накрахмалены и для надежности пропитаны клеем-"момент". Но надежда есть: в последнее время стали появляться алгоритмы, позволяющие сравнительно недорогими средствами моделировать поведение ткани в интерактивном режиме. В простейшем случае поступают так: участок ткани представляют как решетку узлов, каждый из которых образует упругие связи с четырьмя соседями. Затем на каждом кадре последовательно: а) применяют действие гравитации, то есть сдвигают все узлы вниз в соответствии со временем, прошедшим с предыдущего кадра; б) проверяют, что расстояние между соседними узлами не стало слишком большим, в противном случае корректируют координаты узлов; в) следят за тем, чтобы узлы не проходили сквозь препятствия и, опять-таки, подправляют их положение в случае необходимости. Все три стадии элементарно переписываются в терминах операций над текстурами, и скорость выполнения получающегося кода весьма высока. Впрочем, в этом каждый может убедиться самостоятельно, скачав соответствующую программу, например, с сайта NVIDIA.

Еще одна весьма многообещающая техника — так называемые Coupled Map Lattices (CML). Многие из вас, наверное, слышали про математическую игру «Жизнь». Напомню правила. Место действия — двухмерный массив клеток, противоположные края которого во избежание граничных эффектов отождествлены: получается этакий дискретный тор. Каждая клетка может находиться в двух состояниях: она либо жива, либо мертва. У клетки, очевидно, восемь соседей. Задается распределение живых клеток в начале игры. Это «первое поколение». Каждое следующее поколение рассчитывается по таким правилам: 1) если у мертвой клетки ровно три живых соседа, она оживает; 2) если у живой клетки два или три живых соседа, она продолжает жить; 3) если же живых соседей меньше двух или больше трех, то клетка умирает (от одиночества и от перенаселенности соответственно). Задавая различные первые поколения, можно получать разнообразнейшие картины развития популяции. Так вот, если в игре «Жизнь» разрешить клеткам принимать не два состояния, а больше, и соответственно усложнить свод правил, по которым клетки переходят из одного состояния в другое, то как раз и получится CML. Оказывается, при помощи этих систем очень удобно моделировать целый ряд природных явлений, в частности кипение жидкостей, рост барханов и формирование облаков. Более того, эта техника как будто специально придумана, чтобы ее реализовали на графическом процессоре: N+1-е поколение (текстура) получается из N-го поколения (текстуры) применением одного и того же свода правил (пиксельного шейдера) к каждой клетке поля (пиксела текстуры). Замечу, что я писал такую программу для центрального процессора, и нормального быстродействия удавалось добиться лишь для сеток весьма скромных размеров. Здесь же все просто летает.

Идеологически чем-то похожи на CML и «боиды», при помощи которых уже двадцать лет моделируется поведение стай птиц, косяков рыб, облаков насекомых и т. д. [«КТ» уже писала об этой технике] Если вкратце, каждый член стаи подчиняется трем простым правилам: избегай столкновений; двигайся туда же, куда и все; придерживайся центра стаи. А поскольку область зрения считается весьма небольшой, то движение каждой птицы определяется движением лишь нескольких ближайших ее соседей. Группа итальянских ученых еще в 2004 году написала целиком работающую на GPU мощную систему для моделирования передвижений больших стай птиц (с облетом препятствий, включая динамические) и отрапортовала об отличных скоростных показателях детища. Если же вспомнить, что прямой потомок «боидов», система Massive, использовалась для расчета поведения многотысячных армад в кинотрилогии «Властелин Колец»… Ох, славные битвы грядут, камрады-ролевики!

О программировании систем частиц на современных графических процессорах я могу говорить часами. Хотя бы потому, что именно так называлась одна из моих курсовых работ. Более очевидного кандидата на вынос с CPU, наверное, не найти. Тысячи точек движутся по простым законам, минимально взаимодействуя друг с другом и окружающим миром — или не взаимодействуя вовсе. Выигрыш от того, что эти гигантские массивы данных не гоняются на каждом кадре из оперативной памяти на видеокарту, огромен. Если же приложение таково, что частицам требуется сортировка (такое бывает, например, при моделировании воды), то преимущество шейдерного подхода становится просто разгромным. Мой почти не оптимизированный код давал выигрыш в два-три раза, в Сети же встречаются отчеты о реализациях, дающих восьми— и даже десятикратный выигрыш.

Ну и конечно, на карточку уходит практически вся рутина: анимация (от колыхания травы до обратной кинематики моделей); выделение границ и силуэтных ребер; определение видимости (в том числе закрывание объектов друг другом); LOD-техника (выбор в реальном времени подходящей детализации модели для сокращения числа выводимых полигонов); вычисление пересечений геометрических примитивов (например, луча и объектов сцены, для определения точки попадания пули). GPU стали по-настоящему универсальны и, повторюсь, подходят практически для любых задач. Судя по всему, уже в ближайшие несколько лет можно ожидать серьезного повышения как качества картинки, так и реалистичности взаимодействия с игровым миром. И этому решительно невозможно не радоваться!

ТЕМА НОМЕРА: GPU в кино

Автор: Алексей Калиниченко

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