Архитектура Lerrabee изменит представление об игре

На конференции Game Developers Conference, которая проходит в Сан-Франциско (Калифорния), Том Форсайт (Tom Forsyth), разработчик программных и аппаратных средств для архитектуры Intel под кодовым наименованием Larrabee, и легенда игровой отрасли Майкл Абраш (Michael Abrash) представляют новые инструкции Larrabee (LRBni). До прихода в Intel Форсайт занимался созданием различных игр в Microprose, Mucky Foot и SEGA, создавал драйверы Microsoft DirectX в 3DLABS, а также был одним из руководителей компании RAD Game Tools, расположенной в Сиэтле (Вашингтон).

Некоторые считают, что работать над проектом Larrabee — все равно что находиться в самом центре<игровой вселенной>. Чувствовали ли Вы нечто подобное? Общались ли Вы со специалистами Intel и других компаний?

Я чувствовал, что нахожусь на переднем крае вселенной графических игр. Мы всегда имели в виду, что хотя графика очень важна, она не является главной составляющей игры. Игры создаются для развлечения, и графика в них — всего лишь одно из выразительных средств. Но этому компоненту игр уделяется наибольшее внимание, и проектировщики, художники и аниматоры, занимающиеся графикой, составляют большую часть производственной команды. На создание графических изображений также затрачивается большая часть средств, выделяемых на разработку. Работая в команде Larrabee, я столкнулся с удивительным явлением: разработчики игр используют все методы визуализации, приводя в соответствие аппаратные и программные возможности. Обдумывая графический алгоритм, мы имеем практически уникальную возможность выбора. Будет ли он реализован аппаратно, полностью программно или будет представлять объединение этих двух подходов — создание модифицированной инструкции позволяет ускорить выполнение в целом. Мы тесно сотрудничали со многими очень способными людьми. Среди них профессор Стэнфордского университета Пэт Ханрахам (Pat Hanrahan) и Тим Свинэй (Tim Sweeney) из компании Epic Games. Множество разработчиков игр, представителей промышленных и научных кругов помогали нам определять направления разработки аппаратных и программных средств.

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

Вы долгое время занимались разработкой графических программных стандартов OpenGL и DirectX. Как Вы считаете, продолжится ли их развитие в связи с появлением новой модели? Как, по Вашему мнению, будет организовано взаимодействие существующих стандартов программирования с новыми функциями Larrabee?

В целом программистов, создающих графику для игр, можно разделить на две основные категории. Представители одной из них хотят получить максимально возможное качество изображений, и для достижения своей цели они используют единственную платформу и API (интерфейс прикладного программирования) для нее. Эти программисты активно применяют все самые современные функции и преодолевают любые препятствия, чтобы получить наилучшее из возможных качество графики. Чтобы снять ограничения, они пишут одноплатформенные консольные игры для графических карт старших моделей. Если в графической карте реализована какая-либо функциональная возможность, пусть даже поддерживаемая только специализированным<одноразовым>API, они все равно будут использовать ее. Нам нравятся такие люди, ведь благодаря их усилиям архитектура Larrabee позволяет создавать ошеломительные, бросающиеся в глаза видеоэффекты. Прискорбно только, что подобных энтузиастов очень мало.

Программисты, принадлежащие к другой категории, стремятся сделать свои творения доступными для самого широкого круга игроков. Их игры должны выполняться на самых разных доступных графических картах и платформах. Эти программисты используют только те функции, которые поддерживаются большинством платформ, поэтому они игнорируют специальные возможности, характерные для каждой конкретной реализации. Их мастерство вызывает у меня не меньшее восхищение. Достижение совместимости с множеством платформ, каждая из которых имеет некоторые особенности, — как минимум с 20 различными графическими картами для ПК, с Microsoft Xbox 360, Sony PlayStation 3 и Nintendo Wii — действительно впечатляет. Я уверен, что, если вы когда-нибудь попытаетесь реализовать нечто подобное, вы поймете, насколько это сложно.

Такие программисты всегда рады получить хоть какую-то помощь, чтобы облегчить свою жизнь, поэтому стандарты OpenGL и DirectX очень важны для них. Если эти стандарты не предоставляют доступ к некоторой функции, у них просто нет времени для ее изучения. Архитектура Larrabee должна обеспечить самую лучшую из возможных поддержку OpenGL и DirectX, т. к. эти стандарты используются в большинстве игр. Но некоторые программисты занимают центристскую позицию: они чаще всего используют имеющиеся API, но у них есть время и возможности, чтобы экспериментировать с некоторыми новаторскими функциями — в различных направлениях. Например, они могут реализовать эффект светорассеивания в объективе на одной карте, но не на всех графических адаптерах. Может быть, расширение динамического диапазона на одной карте достигается не так, как на других. Возможно также, что рендеринг частиц на одной карте организован немного эффективнее, чем на другой.

К этой категории относятся разработчики межплатформенных игр (как индивидуалы, так и работники студий). Когда они создают графические<движки>, которые предназначены для использования в нескольких играх, добавление нескольких участков специального кода для поддержки конкретных карт является разумной тратой времени и сил. Поэтому такие люди используют стандартные API, но также изучают некоторые новые возможности, хотя бы поверхностно, и экспериментируют с ними, если не считают эти функции слишком<заумными>. Мы оказываем поддержку программистам, относящимся ко всем трем типам: тем, кто пользуется исключительно средствами Direct3D и OpenGL, тем, кто думает о будущем и изучает расширенный набор функций, а также тем, кто программирует на C++ и даже на ассемблере на уровне<голого железа>и пишет собственные системы рендеринга.

Еще недавно присутствовала некоторая неопределенность по поводу того, какой метод рендеринга изображений будет использоваться в Larrabee — растеризация или трассировка лучей. В апреле прошлого года в своем блоге Вы объявили, что архитектура Larrabee будет полностью рассчитана на поддержку традиционного конвейера растеризации. Будет ли трассировка лучей доступна хотя бы для проектов, которые Вы назвали<эксцентричными>? Что Вы хотели этим сказать? Остается ли метод трассировки лучей настолько далеким от реальности, что его использование в коммерческих проектах не может быть экономически оправдано?

Трассировка лучей и растеризация — существенно различные методы рендеринга. У каждого из них есть свои сильные и слабые стороны. Уже более десяти лет разработчики игр за редкими исключениями используют только растеризацию. За это время выработаны художественные техники и технологии конвейерных вычислений, использующие достоинства этого метода и обходящие его недостатки. Используемые методы определяют типы создаваемых игр — визуальный ряд и возможные действия игрока. Если с помощью растеризации не удается достичь приемлемого качества игры, она вряд ли станет достоянием публики. Трассировка лучей, с одной стороны, требует совершенно другого иллюстративного материала и контента, но, с другой стороны, открывает возможности для существенных изменений стиля игры. И не стоит удивляться, что я называю некоторые новые возможности<экстравагантными>(в хорошем смысле)! Но время массового выпуска таких игр еще не настало. Необходимо обеспечить широкую аппаратную поддержку данной технологии, чтобы различные команды разработчиков смогли начать эксперименты с новыми типами контента. Я не верю, что трассировка лучей в своей основе<лучше>растеризации — это просто разные методы. Дело в том, что Larrabee скоро позволит прекратить эти беспредметные разговоры! В конечном счете у нас появятся некоторые аппаратные средства, поддерживающие оба этих алгоритма одновременно. Скоро самые талантливые люди в мире начнут разрабатывать системы рендеринга, используя собственные технические приемы, и мы сможем объективно сравнить результаты и узнать правду. Перед вами не стоит задача выбора лучшей методики — можно будет использовать обе. Уже рассматриваются гибридные схемы, и проводятся эксперименты в этом направлении: в одной части эпизода можно применять растеризацию, а в другой — трассировку лучей. Эти два метода не исключают друг друга, как арахисовое масло и шоколад. Конечно, ничто не ново под луной. Майкл Абраш напомнил мне, что в исходном графическом ядре Quake* использовались две существенно разные схемы рендеринга.

Для создания эффекта перекрытия объектов использовался метод span-buffer (он обычно применяется в геометрии уровней), а рендеринг персонажей переднего плана выполнялся по<традиционной>схеме Z-buffer. Для прорисовки одних типов изображений более эффективным является первый метод, а для других — второй. Приятно, что разработчики снова получили возможность гибкого выбора алгоритмов рендеринга, и скоро мы своими глазами сможем оценить результаты такого подхода.

В работе над проектом Larrabee принимали участие как разработчики аппаратуры, так и программисты. Как Вам удавалось поддерживать равновесие между этими мирами? С какой самой серьезной проблемой Вам пришлось столкнуться?

Труднее всего было сделать так, чтобы участники проекта почувствовали необходимость поддержки определенного соотношения между аппаратными и программными средствами. Люди стремились разделиться на противоположные группы. Разработчики оборудования и программисты говорили на разных языках. Нам всегда приходилось выступать посредниками между представителями двух<лагерей>. В этом и заключалась моя основная роль на этапе проектирования. Создание ПО можно начать гораздо позже, поэтому на начальных этапах не требуется принимать окончательных решений. После реализации решения<в железе>некоторые вещи могут измениться. Меня удивляет, что люди до сих пор интересуются изменениями аппаратной составляющей Larrabee. Вы что, смеетесь надо мной? Изменения аппаратных функций архитектуры были прекращены еще год назад.

В чем состоит наибольшее преимущество архитектуры Larrabee для разработчиков игр?

Во-первых, появилась возможность создания более реалистичных изображений. Но теперь, когда мы добились успеха в этом направлении, мы понимаем, что значение реализма сильно переоценивается. В фильмах не используется естественное освещение — изображение при этом кажется фальшивым. Физические параметры, используемые в играх, далеки от реальных — если вы упадете с высоты 4 метров, вы сломаете ногу. Если бы искусственный интеллект был абсолютно совершенным, каждый выстрел врага попадал бы вам в голову. Поэтому игрок не только хочет, чтобы игра была интеллектуальной и реалистичной. В первую очередь он стремится к победе. Мы должны предоставить разработчикам средства для создания максимально реалистичных сцен и в то же время позволить им точно настраивать степень реализма. Чтобы подчеркнуть значение цвета и яркости в графике, вспомним сериал<Мертвые до востребования>(Pushing Daisies). Кадры этого фильма бывают решены в светлых тонах или имеют высокую контрастность, или их оттенок меняется для передачи настроения. Хотя цвета абсолютно нереальны, мы не только воспринимаем их, но и усваиваем некую информацию на подсознательном уровне. Но все подобные эффекты можно создавать, только имея полный контроль над рендерингом. Архитектура Larrabee предоставит разработчикам такие возможности: они получат новые технологии, позволяющие усилить внутренние ощущения от игры.