НОВОСТИ: Затмения как двигатель прогресса
К тому времени мне было уже сильно за пятьдесят, жизнь одарила меня знакомством и общением со многими интересными и некоторыми великими людьми, – а вот поди ж ты: подходя к дому на окраине Кракова, я трясся в мальчишеском треморе. Нервничал сильнее, чем на первом экзамене.
Почему? Черт его знает!.. Неужели только потому, что книжки Лема в ранней юности были для меня так важны и значимы? Что «Сумма технологии», прочтенная тогда, стала чуть ли не основным философским трудом, определившим на всю дальнейшую жизнь мое мировоззрение? Если б я ехал на встречу с Достоевским или с Пушкиным, волновался б, наверное, не меньше, – но с Достоевским и Пушкиным встретиться было уже совершенно невозможно, а с Лемом…
Когда я, поговорив с паном Станиславом часа полтора, записав разговор на пленку и отщелкав полгигабайта фотографий, вышел на улицу, меня пронзила банальная, но показавшаяся странной идея о человеческом невнимании, человеческой несправедливости. «Кто более чем Лем, – подумал я, – достоин Нобелевской премии, во всех отношениях достоин? И как печально, что он скорее всего ее никогда не получит. Не получит потому, что на Западе недостаточно хорошо знакомы с его книгами, а в Штатах, можно сказать, не знакомы вообще. И еще потому, что он был пророком Земли, а ведь известно, что нет пророка в своем отечестве».
Об уровне понимания Лема американцами можно судить по ужасающему фильму Содеберга «Солярис». Если даже гениальный одноименный фильм Тарковского вызывал у пана Станислава такое недоумение непониманием, – что, он подумал, посмотрев фильм американский? Задать этот вопрос Лему я не смог, потому что в тот момент фильма еще не было.
Впрочем, я бы не удивился, если б узнал, что Лем просто отказался его смотреть. Да-да! Потому что от встречи у меня осталось такое вот общее впечатление: пан Станислав последние годы огорченно недоумевает от того, что его почти никто не понимает. Его острый, пронзительный ум, который никогда не мыслил на уровне ниже онтологического, философского, раньше многих осознал тщету технических ухищрений – пусть сколь угодно революционных – на фоне кардинальных, имманентно человеку и человечеству присущих проблем. Он писал об этом, когда еще не взлетел в Космос первый спутник, когда не было и помину Интернета и персональных компьютеров. Он с легкостью, но и с грустью населял свои рассказы, романы и эссе этим бесчувственным «железом будущего», – но его не услышали.
Когда он писал свои последние статьи, к нему относились с легким даже пренебрежением: мол, спятил старик, – а он просто оставался на обычном своем пронзительном уровне постижения мира. На него чуть ли не обижались: как так? человек, предсказавший нынешний мир хайтека, столь скептически к нему относится?! Это – неправильно!!!
И от этого вот непонимания он чувствовал себя – во всяком случае, выглядел – особенно одиноким. С этой своей сгорбленной спиной и яснейшим разумом…
Мертвых у нас любят больше, чем живых, – так что есть надежда, что сегодняшние читатели с бо,льшим вниманием отнесутся к его книгам и статьям, – ему же теперь, увы, все равно…
ТЕМА НОМЕРА: Персональный суперкомпьютер
Графический конвейер
Чтобы обстоятельно ответить на эти и другие вопросы, нам необходимо вспомнить основы устройства графической подсистемы. Ее работа организуется в форме конвейера, упрощенно представленного на рис. 1. Информация проходит все стадии конвейера, прежде чем преображается в видимый на экране образ.
В самом начале располагается блок обработки вершин трехмерной сцены, целью которого является выработка данных о каждой вершине: ее положение в экранной системе координат, пара цветов (диффузный и зеркальный), до восьми текстурных координат. Следует напомнить, что текстурными называют координаты на отдельно хранящемся растровом изображении (текстуре). Их задание в каждой вершине треугольника позволяет привязать нужную часть изображения к этому треугольнику. Входные данные отдельно для каждой вершины поступают от программного приложения. Как правило, передаются координаты и нормали вершин в системе модели, которые по известным характеристикам, положению и направлению взгляда камеры трансформируются в экранные координаты. Цвета определяются взаимным расположением вершины, камеры и источников освещения. Отсюда и принятое название: блок трансформации и освещения (T&L). Обработка вершин происходит независимо, здесь система еще не знает, как они связаны между собой.
Информация о том, какие тройки вершин образуют треугольники, поступает только на следующий этап конвейера, носящий название «сборка треугольников» (triangle setup). После этого уже можно определить, какие треугольники будут не видны на экране. Независимым исследованием вершин этого установить нельзя: три выходящие за границы экрана вершины могут сформировать частично видимый треугольник. Полностью скрытые треугольники удаляются, чтобы больше не отнимать на себя ресурсов. От частично видимых треугольников отсекаются ненужные части.
На этапе растеризации треугольники разбиваются на множество фрагментов, каждый из которых соответствует одному пикселу экрана, накрываемому треугольником. Здесь же происходит еще одна важная операция – линейная интерполяция значений из вершин треугольника в соответствии с положением фрагмента. После этого обработка каждого фрагмента может происходить автономно от других фрагментов.
В конечном результате для каждого фрагмента необходимо определить его итоговый цвет и, возможно, изменившуюся глубину. Для чего часто требуется доступ к хранящимся в видеопамяти текстурам, которые могут содержать как непосредственно цвет, так и освещенность, отражательную способность или карту неровностей. Доступ к текстурам осуществляется через блок выборки (fetch), который может вернуть цвет текстуры в произвольной точке, а также может выполнять билинейную или анизотропную фильтрацию.
О фрагментах следует думать как о пре-пикселах. Окончательное значение цвета на экране формируется в результате композиции цвета фрагмента с цветом, уже находящимся в экранном буфере, только частным случаем которой является полное замещение. Фрагмент на этом этапе может быть вообще отвергнут, если не пройдет один из тестов, например тест глубины или величины альфа-канала.
Свое окончание конвейер находит в экранном буфере или текстуре, его заменяющей, при включении специального режима render-to-texture. Это единственное место в конвейере, которое доступно приложению для обратного считывания (read back).
Предыстория
Как же использовать графический конвейер не только для отображения трехмерных сцен? Еще относительно недавно нужно было обладать незаурядными знаниями всех операций, которые производители «зашили» в графический чип, чтобы заметить задачу, сводимую к рисованию некоторой сцены. В любом случае, способностей GPU хватало лишь на очень узкий круг вычислительных проблем[Не хочется задерживаться на этой теме, но чтобы не быть голословным, привожу одну из ссылок, где есть программа построения диаграммы Вороного], как правило, не слишком требовательных к точности результата. Но с наступлением нового тысячелетия ситуация начала мало-помалу меняться.
Прежде программирование графики можно было отнести к декларативному типу. Трехмерное приложение перечисляло все объекты в сцене, свойства их поверхностей, говорило, где расположены источники освещения, куда смотрит камера и т. п. В завершение следовала команда графической плате: «А теперь возьми и отобрази, что видит камера!» Эта ситуация была бы всем хороша в спокойные времена, но не когда производители игр отчаянно борются за внимание пользователей, которое, по их мнению, можно привлечь только новыми и желательно уникальными эффектами. Поэтому наметился постепенный переход к императивной парадигме программирования графики. То есть вместо выбора одного из предопределенных типов обработки данных производители игр получили возможность самостоятельно писать малюсенькие программки, непосредственно выполняемые графическим процессором. В первую очередь это затронуло блок обработки вершин, а затем и фрагментов (обведены оранжевым цветом на рис. 1). Поскольку главным образом под эффектами понималась более точная передача игры света и тени, то программки эти стали называть шейдерами (от англ. shade – тень), соответственно разделяя их на вершинные и пиксельные. Появились специализированные низкоуровневые ассемблеры.
Поначалу (2001 год) шейдеры были сильно ограничены в функциональности: например, пиксельный шейдер мог считывать цвет точки текстуры только четыре раза и выполнять над этими цветами не больше восьми арифметических операций[Хотя малым это стало казаться только сейчас, а на момент появления впечатляло].
Альтернативное применение
Переломным моментом можно считать самый конец 2002 года, когда в продаже появились платы семейства GeForce FX от nVidia и Radeon 9500 (и выше) от ATI. В них была заложена поддержка стандарта шейдеров Shader Model 2.0, который примечателен главным образом двумя аспектами.
Стандарт требовал от GPU умения выполнять гораздо более сложные программы и по количеству инструкций, и по числу обращений к текстурам.
Все промежуточные операции должны были выполняться с действительными числами высокой (в сравнении с предшествующими моделями GPU) точности. А производители сразу ввели поддержку текстур, в которых цвета хранятся также в виде действительных чисел.
Хотя позже появляются и другие модификации стандарта, включая последний на сегодняшний день Shader Model 3.0, шейдеры второй версии остаются по-прежнему актуальными, потому что платы, поддерживающие только их, присутствуют на рынке и сегодня. Особенности стандартов приведены в таблице 1.