Кроме Intel попытку внедрить VLIW-архитектуру в повседневную жизнь предпринимала со своими x86-совместимыми процессорами небезызвестная Transmeta. У команды, в которой работал сам Линус Торвальдс, не было претензий на «новую сверхархитектуру», но процессоры они создали не менее интересные. Transmeta не стала проталкивать свой VLIW как индустриальный стандарт, а сосредоточилась на разработке специального софта, полностью имитирующего (программно!) на VLIW-процессоре обычную архитектуру x86. Производительностью такое решение не отличалось, но зато было простым (ибо VLIW архитектурно проще), дешевым (ибо простым) и потребляющим совсем немного энергии (в силу все той же простоты), что позволило Transmeta вполне успешно позиционировать свои CPU в нишу недорогих мобильных процессоров и даже процессоров для блейд-серверов. К сожалению, производственные трудности и появление технологии Centrino, которая свела конкуренцию на мобильном рынке почти к нулю, привели к тому, что Transmeta терпела огромные убытки. Так что судьба двух доступных пока VLIW-архитектур - Intel Itanium 2 и Transmeta Efficeon - очень похожа. Обе оказались вытеснены в узкоспециализированные ниши: Itanium 2 - в высокопроизводительную; Efficeon - в экономичную.
Итак, VLIW/EPIC на роль процессора завтрашнего дня пока не годится - те потенциальные преимущества, которыми она обладает, сегодня не оправдываются. Но существенные изменения в грядущих процессорах мы все-таки увидим.
Хотим мы того или нет, работать нам придется с многоядерными процессорами. Как уже говорилось, разработка нового процессорного ядра - дело весьма долгое даже при наличии опытной команды и чертежей предыдущей версии изделия; совершенствование технологических процессов, позволяющих уместить на одном кусочке кремния все больше транзисторов, происходит гораздо быстрее. Раньше это выливалось во все более «кэшастые» варианты одних и тех же архитектур и во все более «прямолинейные» варианты их разводки (пожертвовав площадью кристалла и увеличив его размеры, разводку можно сделать «более высокочастотной»); теперь же стало выгоднее просто устанавливать два-три-четыре одинаковых или почти одинаковых ядра в один кристалл или на одну подложку.
Но коль уж все равно нам светит повальный переход на параллельные алгоритмы (а параллельное программирование нетривиальных алгоритмов по праву считается одной из самых сложных современных задач), то имеет смысл уже сегодня заняться разработкой перспективных параллельных архитектур на основе принципиально новых концепций. Именно такой подход в лице процессора Cell (совместное детище Sony, Toshiba и IBM), возможно, и определит облик завтрашнего дня компьютинга.
По меркам же дня сегодняшнего Cell вызывает интерес своей необычностью и потрясающей футуристичностью: девять ядер, из которых одно главное, а восемь - вспомогательные; сумасшедшей пропускной способности интерфейсы и оперативная память Rambus; тактовая частота под три гигагерца. Но новизна процессора не в этом (вернее, не только в этом). Cell - это еще и попытка значительно пересмотреть существующие парадигмы программирования.
Cell в переводе на русский - ячейка. В концепции Cell существуют аппаратные и программные ячейки. Аппаратная ячейка - любой процессор, способный выполнять программные ячейки и связанный с другими процессорами. Программная ячейка - это данные, либо особая программа (apulet), описывающая, как следует обрабатывать данные. В идеале нет никаких самостоятельно существующих программ, нет процессоров и компьютеров. Есть только данные, код, который их обрабатывает, и абстрактная аппаратура, обеспечивающая существование того и другого. Не поняли? Смотрите: пусть у нас есть, например, передаваемый по Сети видеопоток.
Что такое видеопоток? На программном уровне это последовательность фреймов - небольших блоков данных, описывающих маленький кусочек (скажем, 0,1 с) видео или звуковой дорожки. В терминах Cell - поток ячеек, содержащих данные разного типа. Его воспроизведение можно представить как результат выполнения некоторой большой программы, с исходными данными в виде этого потока, а можно - как процесс многократного преобразования ячеек с данными, в ходе которого ячейки одного типа (например, сжатый звук) превращаются в ячейки другого типа (несжатый звук) маленькими программками (апулетами). Обычно все эти превращения запрятаны глубоко в некую всеобъемлющую программу, которая копирует поступающие данные в оперативную память, поочередно обрабатывает их разными алгоритмами и старается распределить обработку по нескольким процессорам. Идея Cell состоит в том, что вместо этой программно-ориентированной модели мы берем более естественную, ориентированную на данные модель декодирования видеопотока и сводим написание видеопроигрывателя к написанию инструкций типа «чтобы воспроизвести видеотрансляцию, нужно подключиться по такому-то адресу в Сети к источнику ячеек, преобразовать поступающий поток в поток ячеек со сжатым видео и сжатым звуком, преобразовать сжатый звук в несжатый, сжатое видео в несжатое, обработать несжатый звук эквалайзером и эффект-процессором, а к несжатому видео применить деинтерлейсинг, подогнать получившуюся картинку к размерам экрана, скорректировать яркость, насыщенность и контрастность и воспроизвести получившиеся аудио- и видеопотоки». Вот это и есть программа для Cell! В ней даже нет инструкций, указывающих, как делать все вышеописанное, - за «подробностями» Cell-устройство обращается к библиотеке алгоритмов, причем каждый алгоритм (апулет) - это тоже ячейка, которую, к примеру, можно на лету скачать из Сети с того же самого источника видеотрансляции. А какое железо и какая операционная система обеспечивает этот процесс с точки зрения Cell-программиста (фактически автора алгоритмов и описаний, подобных вышеприведенному), пользователя и главных действующих лиц - данных и апулетов, - совершенно неважно.
Какую выгоду мы имеем при такой организации? Во-первых, все написанные таким образом Cell-программы параллельны по самой своей сути. Мало того что мы разбиваем исполнение программы на несколько явно независящих друг от друга стадий, которые можно исполнять «в параллель». У нас же целая цепочка ячеек-данных, требующих обработки и в подавляющем большинстве случаев все эти ячейки друг от друга совершенно независимы - а значит, мы можем «превращать» по одному и тому же алгоритму несколько ячеек одновременно. Таким образом, в Cell удается загрузить работой не просто десятки - а сотни и даже тысячи «элементарных процессоров» (Synergetic Processing Element, SPE), причем задействовать для запущенной на одном процессоре задачи SPE всех процессоров данного устройства и даже совершенно прозрачным образом привлечь к ней же SPE других устройств! Представьте, что игровая приставка, домашний компьютер, телевизор, холодильник и КПК совместно работают над, скажем, запущенной пользователем задачей рендеринга трехмерной сцены, причем делают это совершенно прозрачным и незаметным для вас способом - и вы поймете всю прелесть подобной организации! А самое замечательное, что вся эта красота не стоила ни малейших усилий. Нам не требовалось размышлять над кластеризацией, пересылкой данных, блокировками, потоками и прочими «прелестями» параллельного программирования, превращающего жизнь программиста в кошмар: мы написали только «интересную» и «содержательную» часть кода, собственно «алгоритмику» задачи, переложив всю рутину на автоматику и, возможно, прозрачным образом задействовав для решения своих задач произвольное количество чужого кода[Скажем, если в трансляции видеопоток сжат нашим «фирменным» кодеком, а звук - обычным стандартным, то потребуется обеспечить лишь «свою» часть по видеодекодированию, а все остальное - декодирование звука, набор «улучшалок» для картинки и т. п. - Cell-устройство возьмет стандартное или ранее загруженное пользователем.].
Возможности для применения Cell-сети необъятны. По сути дела, это некий единый «живой организм», который «растет» (регистрирует в сети новые устройства) или «уменьшается»; который обладает «знаниями» (апулетами) и «живет» в глобальном мире - всемирной Сети, «питаясь» разнообразными данными и «перерабатывая» их. У этого «организма» есть «глаза» (веб-камеры), «уши» (микрофоны), «органы чувств» (клавиатура, мышь, джойстик), «средства коммуникации с внешним миром» (монитор, телевизор, колонки); которые физически могут принадлежать совершенно разным устройствам, но в действительности - одному Cell’у.
Добавление новых устройств в Cell-сеть, как правило, не изменяет ее функциональности (разве что добавляет новые «органы чувств», «средства отображения» и повышает быстродействие) - даже в самом простом варианте Cell универсальна.
Как это все реализовано в железе? В статье о приставках следующего поколения[ «Три тополя на Плющихе»] я подробно описывал аппаратную составляющую одного из первых Cell-устройств - PlayStation 3, и его «сердце» - процессор Cell[Вообще-то он называется Broadband Processor, но это название как-то не прижилось], так что еще раз восхищаться сверхсовременными решениями вроде Rambus-памяти и интерконнекта FlexIO, пожалуй, не будем. Лучше посмотрим, откуда эта своеобразная «несимметричная девятиядерная архитектура» взялась.
Напомню, что в процессоре Cell девять ядер - одно главное и восемь вспомогательных. Но если посмотреть на это с точки зрения концепции Cell, то вспомогательным на самом деле является главное процессорное ядро - PPE (The Power Processing Element). На нем работает операционная система сети Cell, обеспечивающая прозрачное объединение нескольких устройств в сеть; выполнение программ - выборку данных и их распределение вместе с необходимыми апулетами по собственно вычисляющим элементам; взаимодействие с пользователем, работу драйверов устройств… в общем, все то, что мы тремя абзацами выше отнесли к рутине. А самое интересное происходит в маленьких ядрышках процессора Cell - модулях SPE. Фактически каждый такой Synergetic Processing Element - это крошечный самостоятельный компьютер (со своим процессором и своей оперативной памятью), который занимается одним-единственным делом: конвертирует поступающие к нему ячейки-данные согласно заложенному в него алгоритму. То есть физически воплощает в жизнь алгоритм, заложенный нами в одну ячейку-апулет, над ячейками-данными. Все, чем занимается PPE, в сущности, сводится к одному действию: взять данные, требующие обработки, поместить их в память SPE, запустить «процесс превращения» данных в другие данные и куда-нибудь передать полученный результат. Именно поэтому SPE очень много, а блок PPE - один; и именно поэтому у каждого SPE есть своя персональная «локальная» память и нет выхода на «глобальную» (она им попросту не нужна); именно поэтому SPE связаны очень быстрыми шинами и могут передавать данные друг другу напрямую, выстраивая те самые цепочки обработки данных, которые в обычном процессоре являются чистейшей воды абстракцией.
Кстати, использовать для создания Cell-устройств, способных стать частью Cell-сети, описанный процессор вовсе не обязательно. Концептуально от устройства требуется только одно: уметь интегрироваться в сеть (то есть содержать процессор, работающий под управлением соответствующих программ) и уметь выполнять над ячейками-данными ячейки-апулеты (например, содержать хотя бы один SPE). Вполне можно представить, что после «суперпроцессора» Cell появятся более простые варианты с меньшим (или наоборот, большим) числом SPE или даже совсем простые и дешевые мини-процессоры (использующие один SPE и более простой PPE, причем PPE может быть даже не PowerPC-процессором), которые можно будет за сущие гроши устанавливать в любую бытовую технику. С помощью Cell можно одинаково эффективно реализовывать и суперкомпьютеры[Уже представлены блейд-серверы из нескольких Cell-процессоров], и «цифровой дом».
Правда, настанет все это счастье, увы, нескоро - на создание принципиально новых операционных систем (основы Cell), стандартных Cell-библиотек, компиляторов и сред разработки, на перенос имеющегося программного обеспечения и, наконец, на самую обыкновенную перестройку мышления программистов уйдут в лучшем случае годы.
Доживем ли мы до «умных» сетей и распределенных «повсеместных» вычислений, столь же прозрачных, привычных и незаметных, как современные электросети? Годика через три увидим.
ТЕХНОЛОГИИ: Новая надежда
Выхода графического ускорителя нового поколения от ATI, известного под кодовым названием R520, ожидали долго. Даже, пожалуй, слишком долго: мы искали его на Computex, мы надеялись увидеть его в июле, когда nVidia начала продавать видеокарты GeForce 7800GTX, затем в сентябре, когда, казалось, ждать дальше уже было некуда.
Но прошли уже все мыслимые сроки, а R520 все не было.
Тестовая система:
Материнская плата: ASUS A8N SLI Deluxe. Оперативная память: Corsair DDR CMX512-3200XLPRO, 2x512 Мбайт, 2-2-2-10. Видеокарта: nVidia 7800GTX 256 Мбайт, ATI X1800XT 512 Мбайт. Операционная система: Microsoft Windows XP SP2. Драйверы: последние официальные на момент написания статьи. Все настройки системы оставлялись по умолчанию, процессоры функционировали на своих номинальных частотах: Athlon 64 FX-57 2,8 ГГц - множитель 14, шина 200 МГц, память в синхронном режиме с таймингами 2-2-2-10
Вот и получилось, что ситуация на рынке сегодня далеко не в пользу канадцев. Уверенно лидируя в «дешевых» и «интегрированных» нишах, солидных по оборотам, но, увы, не приносящих по-настоящему большой прибыли, самые «вкусные», высокопроизводительные сегменты еще недавно доминировавшая здесь ATI утратила. В результате - провальный квартал и 104 млн. долларов убытков.
Почему так вышло? Думаю, отчасти виноват новый, прогрессивный 90-нм low-k технологический процесс, освоение которого на заводах TSMC, производящей GPU по заказам aTI, вероятно, проходило далеко не так гладко, как рапортуют теперь маркетологи[Все мы помним, что первая итерация 90-нм процессоров Intel получилась «слишком горячей» (большие токи утечки вносили ощутимый вклад в тепловыделение ранних степпингов Prescott), а у aMD - «слишком медленной». Да и nVidia, тоже размещающая заказы на заводах TSMC, предпочла изготавливать свой новый GPU G70 по «старому, дорогому и медленному», зато проверенному 110-нм техпроцессу]. Отчасти - «погоня за двумя зайцами», то есть одновременная разработка и запуск в серию двух совершенно разных продуктов: основанного на унифицированной шейдерной архитектуре процессора R500[На нем построена приставка Xbox 360, выпуск которой намечен на ноябрь], который невозможно использовать в обычных видеокартах; и нашего сегодняшнего героя R520, построенного по «классической», но сильно переработанной архитектуре. Вдобавок чип получился по-настоящему новым и революционным (после едва ли не трех лет постепенной эволюции удачной линейки Radeon 9xxx), так что его проектирование и доводка наверняка отличались особенной сложностью, и сколько ушло итераций на то, чтобы отловить все ошибки, - знают только инженеры aTI.
Впрочем, довольно толочь воду в ступе. В конце концов, пусть и с полугодовым опозданием, но R520 - перед нами, и в ближайшее время видеокарты на его основе появятся в розничной продаже.
Итак, что же удалось сделать ATI? Я бы сказал, невероятно многое. Словно все три года, пока регулярно выходили превосходные видеокарты, полученные экстенсивным расширением старой технологии, инженеры откладывали все по-настоящему интересные задумки в долгий ящик, чтобы потом реализовать их скопом.
Во-первых, радикально переработано сердце любого графического ускорителя - блок пиксельных процессоров, отвечающий за закраску сцены по заданным алгоритмам. Традиционно в этом блоке ставится энное количество одинаковых пиксельных конвейеров, каждый из которых «в параллель» с остальными вычисляет цвет отдельно взятого пиксела (или субпиксела) в нашей сцене[Строго говоря, одиночные конвейеры сейчас уже никто не использует, поскольку гораздо эффективнее собирать их в группы по четыре штуки (процессоры квадов), чтобы они обрабатывали не отдельные пикселы, а блоки 2x2 пиксела (квады). При этом часть логики удается объединить, проводя некоторые операции не над отдельными пикселами, а над квадами целом - это и быстрее и проще]. То есть, единожды попав на какой-нибудь конвейер, пиксел, обрабатываемый соответствующей ему программой - пиксельным шейдером, раз за разом проходит по этому конвейеру, как бы крутится внутри него до тех пор, пока не закончится вычисление его цвета. Соответственно все устройства, и, в частности, текстурные модули, выбирающие из видеопамяти необходимые для этих вычислений данные, напрямую подключены к исполнительным устройствам конвейера. Схема достаточно простая и эффективная: нужно увеличить вычислительную мощность графического процессора - ставим больше конвейеров, и количество обрабатываемых за такт пикселов, а вместе тем и скорость закраски изображения пропорционально возрастет.
Инженеры aTI пошли другим, «процессорным» путем,[Подробнее см. «КТ» #609 (рубрика 'Архитектура ХХ века")] не став дублировать конвейеры, а организовав из GPU своеобразный суперскалярный процессор с единым конвейером, на котором несколько пикселов могут обрабатываться одновременно. Вместо того чтобы «распихать» пикселы по разным конвейерам, R520 накапливает их (вместе с соответствующими шейдерными инструкциями) в специальном огромном планировщике, который aTI называет Ultra-Threading Dispatch Processor. Почему Ultra? Да потому, что этот планировщик управляет одновременным выполнением колоссального числа операций (512 квадов 2x2 пиксела в High-End, и более скромные 128 квадов - в менее дорогих Middle-End и Low-End графических чипах). Все квады хранятся в длиннющих очередях, и по мере того, как освобождаются вычислительные ресурсы, отправляются на соответствующее устройство, будь то вычислительный, текстурный блок или блок графического Back-end’а (запись результатов во фрейм-буфер, блендинг, z-тест, антиалиасинг и пр.). Это более сложный подход, чем несколько однотипных конвейров, но и более гибкий и эффективный. Например, мы можем сколь угодно гибко варьировать соотношение количества вычислительных и текстурных модулей, так как они больше не подключаются друг к другу, образуя единое целое, а разделены по операциям, которые они выполняют[Подобную оптимизацию можно будет увидеть в ядре R530 - сердце Middle-End ускорителя Radeon X1600. В нем будет три процессора квадов (3x4 = 12 пиксельных конвейера), но всего один процессор текстур (1x4 = 4 TMU). Для современных шейдеров, которые больше занимаются вычислениями, нежели выборкой данных из оперативной памяти, такой подход оправдан, поскольку позволяет рациональнее расходовать площадь кристалла, увеличив число пиксельных конвейеров за счет сокращения числа TMU]. Речь идет о текстурных операциях, которые ранее могли блокировать конвейер до тех пор, пока не будет завершена операция выборки очередного тексела[Традиционный конвейер GPU устроен гораздо проще конвейера CPU, так что переупорядочивания инструкций, которое позволило бы обогнать застрявшую в конвейере инструкцию другой, не зависящей от нее, - в графических процессорах нет].
Заодно решается и проблема динамических условных переходов в шейдерах. Что это такое? Сейчас объясню: ради все того же упрощения пиксельных конвейеров, которых нужно уместить побольше на ограниченный кусочек кремния, эти конвейеры устраивают таким образом, что они вначале как бы настраиваются на ту или иную конкретную операцию над пикселами (сложение, вычитание, умножение) и затем применяют ее много раз подряд к разным пикселам; после чего перестраиваются на следующую операцию и снова применяют ее много раз к тем же пикселам, и т. д. Поскольку один и тот же шейдер обычно требуется применить к умопомрачительному количеству пикселов, такая схема обычно работает замечательно. Однако если встречается шейдер, в котором есть динамические условные переходы (которые нельзя заранее предсказать), то может оказаться так, что для одной части пикселов, «бегающих по кругу» в конвейере, какую-то операцию применять нужно, а для другой - нет. И это столь серьезная проблема, что графические чипы ATI долгое время не поддерживали динамические переходы (а значит, и Shader Model 2.0a и 3.0).
Правда, решение nVidia очень уж красивым тоже не назовешь: в ее варианте «глупый» конвейер по кругу обрабатывает все пиксели, но в решающий момент над некоторыми из них производит операцию, а некоторые - игнорирует[Похожий способ исполнения условных переходов можно встретить в процессорах ARM]. ATI нашла гораздо лучший выход: поскольку вместо нескольких «глупых» и простых конвейеров у нее лишь один, но «умный» и сложный, то не требующие обработки пиксельные квады до исполнительных устройств просто-напросто не добираются, уступая место тем квадам, с которыми действительно нужно что-то делать. В результате конвейер хоть и исполняет по-прежнему одну и ту же операцию над разными пикселами, неторопливо перестраиваясь с одной на другую, но делает это не в пример интеллектуальнее и не разбазаривает попусту свои ресурсы. А заодно семейство Radeon X1000 получает практически «бесплатную» поддержку шейдеров третьей версии. Честно говоря, столь блестящему решению, убивающему разом целую стаю зайцев, можно только позавидовать! Это еще не унифицированная шейдерная архитектура, где единый конвейер (а вернее, набор из таковых) может обрабатывать любые шейдеры - как пиксельные, так и вершинные, но то, что полшага в ее сторону сделано, - несомненно.
Вторая группа изменений коснулась оптимизации графического процессора для работы на больших и очень больших тактовых частотах. Например, архитектура подсистемы памяти была полностью переделана для поддержки казавшейся невероятно быстрой видеопамяти - 1500 МГц GDDR3[И ведь это еще не предел - ходят вполне правдоподобные слухи, что R520 поддерживает не вышедшую пока в свет графическую оперативную память следующего поколения, GDDR4]. Вместо традиционной схемы с множеством текстурных модулей (TMU), централизованно подключавшихся к единому контроллеру оперативной памяти, который, в свою очередь, по широким шинам запрашивал данные из памяти и возвращал ответ по тем же каналам связи, по которым пришел запрос, ATI изобрела принципиально новую, кольцевую внутреннюю шину видеопамяти, «размазывающую» контроллер памяти едва ли не по всему графическому процессору. Идея в том, что вместо одного большого и сложного контроллера мы делаем до восьми маленьких контроллеров, каждый из которых контролирует только свой относительно небольшой кусочек видеопамяти. Причем он расположен в кристалле так, чтобы сравнительно узкую (32-разрядную) шину видеопамяти от него было удобнее разводить на печатной плате и тем самым сводить к минимуму помехи, обычно возникающие из-за несовершенства разводки. Вдобавок, небольшим контроллерам требуются небольшие же кэши данных, что позволяет отказаться от традиционных упрощенных и имеющих ряд недостатков кэшей прямого отображения и наборно-ассоциативных кэшей в пользу более сложных, но лишенных этого недостатка полностью ассоциативных кэшей.
Маленькие контроллеры (точнее, интерфейсы для подключения модулей памяти) объединяются очень быстрой внутренней двунаправленной кольцевой шиной (шириной 256 линий в каждом направлении для моделей с 256-разрядной основной шиной памяти и 128 линий - для более дешевых). На кольце имеется четыре «остановки» - точки подключения к внешних устройств. Например, для топовых R520 к каждой такой «остановке» подключено по два модуля памяти (шина памяти 2x32 разряда) и какая-то часть внутренних устройств процессора, расположенных поблизости. Каких? А неважно: какие было удобно подключить именно в этом месте, такие и подключили. Кроме того, по специальным простым управляющим шинам (по которым передаются только инструкции) каждая такая «остановка» подключена к «диспетчеру» - тому самому централизованному контроллеру памяти, который не занимается доставкой данных к исполнительным устройствам, а только «отдает распоряжения» и «присматривает» за тем, чтобы нужные данные прочитал нужный маленький контроллер и отправил их по кольцу до нужной «остановки», где их сможет снять само исполнительное устройство.
Концепция Cell
Хотим мы того или нет, работать нам придется с многоядерными процессорами. Как уже говорилось, разработка нового процессорного ядра - дело весьма долгое даже при наличии опытной команды и чертежей предыдущей версии изделия; совершенствование технологических процессов, позволяющих уместить на одном кусочке кремния все больше транзисторов, происходит гораздо быстрее. Раньше это выливалось во все более «кэшастые» варианты одних и тех же архитектур и во все более «прямолинейные» варианты их разводки (пожертвовав площадью кристалла и увеличив его размеры, разводку можно сделать «более высокочастотной»); теперь же стало выгоднее просто устанавливать два-три-четыре одинаковых или почти одинаковых ядра в один кристалл или на одну подложку.
Но коль уж все равно нам светит повальный переход на параллельные алгоритмы (а параллельное программирование нетривиальных алгоритмов по праву считается одной из самых сложных современных задач), то имеет смысл уже сегодня заняться разработкой перспективных параллельных архитектур на основе принципиально новых концепций. Именно такой подход в лице процессора Cell (совместное детище Sony, Toshiba и IBM), возможно, и определит облик завтрашнего дня компьютинга.
По меркам же дня сегодняшнего Cell вызывает интерес своей необычностью и потрясающей футуристичностью: девять ядер, из которых одно главное, а восемь - вспомогательные; сумасшедшей пропускной способности интерфейсы и оперативная память Rambus; тактовая частота под три гигагерца. Но новизна процессора не в этом (вернее, не только в этом). Cell - это еще и попытка значительно пересмотреть существующие парадигмы программирования.
Cell в переводе на русский - ячейка. В концепции Cell существуют аппаратные и программные ячейки. Аппаратная ячейка - любой процессор, способный выполнять программные ячейки и связанный с другими процессорами. Программная ячейка - это данные, либо особая программа (apulet), описывающая, как следует обрабатывать данные. В идеале нет никаких самостоятельно существующих программ, нет процессоров и компьютеров. Есть только данные, код, который их обрабатывает, и абстрактная аппаратура, обеспечивающая существование того и другого. Не поняли? Смотрите: пусть у нас есть, например, передаваемый по Сети видеопоток.
Что такое видеопоток? На программном уровне это последовательность фреймов - небольших блоков данных, описывающих маленький кусочек (скажем, 0,1 с) видео или звуковой дорожки. В терминах Cell - поток ячеек, содержащих данные разного типа. Его воспроизведение можно представить как результат выполнения некоторой большой программы, с исходными данными в виде этого потока, а можно - как процесс многократного преобразования ячеек с данными, в ходе которого ячейки одного типа (например, сжатый звук) превращаются в ячейки другого типа (несжатый звук) маленькими программками (апулетами). Обычно все эти превращения запрятаны глубоко в некую всеобъемлющую программу, которая копирует поступающие данные в оперативную память, поочередно обрабатывает их разными алгоритмами и старается распределить обработку по нескольким процессорам. Идея Cell состоит в том, что вместо этой программно-ориентированной модели мы берем более естественную, ориентированную на данные модель декодирования видеопотока и сводим написание видеопроигрывателя к написанию инструкций типа «чтобы воспроизвести видеотрансляцию, нужно подключиться по такому-то адресу в Сети к источнику ячеек, преобразовать поступающий поток в поток ячеек со сжатым видео и сжатым звуком, преобразовать сжатый звук в несжатый, сжатое видео в несжатое, обработать несжатый звук эквалайзером и эффект-процессором, а к несжатому видео применить деинтерлейсинг, подогнать получившуюся картинку к размерам экрана, скорректировать яркость, насыщенность и контрастность и воспроизвести получившиеся аудио- и видеопотоки». Вот это и есть программа для Cell! В ней даже нет инструкций, указывающих, как делать все вышеописанное, - за «подробностями» Cell-устройство обращается к библиотеке алгоритмов, причем каждый алгоритм (апулет) - это тоже ячейка, которую, к примеру, можно на лету скачать из Сети с того же самого источника видеотрансляции. А какое железо и какая операционная система обеспечивает этот процесс с точки зрения Cell-программиста (фактически автора алгоритмов и описаний, подобных вышеприведенному), пользователя и главных действующих лиц - данных и апулетов, - совершенно неважно.
Какую выгоду мы имеем при такой организации? Во-первых, все написанные таким образом Cell-программы параллельны по самой своей сути. Мало того что мы разбиваем исполнение программы на несколько явно независящих друг от друга стадий, которые можно исполнять «в параллель». У нас же целая цепочка ячеек-данных, требующих обработки и в подавляющем большинстве случаев все эти ячейки друг от друга совершенно независимы - а значит, мы можем «превращать» по одному и тому же алгоритму несколько ячеек одновременно. Таким образом, в Cell удается загрузить работой не просто десятки - а сотни и даже тысячи «элементарных процессоров» (Synergetic Processing Element, SPE), причем задействовать для запущенной на одном процессоре задачи SPE всех процессоров данного устройства и даже совершенно прозрачным образом привлечь к ней же SPE других устройств! Представьте, что игровая приставка, домашний компьютер, телевизор, холодильник и КПК совместно работают над, скажем, запущенной пользователем задачей рендеринга трехмерной сцены, причем делают это совершенно прозрачным и незаметным для вас способом - и вы поймете всю прелесть подобной организации! А самое замечательное, что вся эта красота не стоила ни малейших усилий. Нам не требовалось размышлять над кластеризацией, пересылкой данных, блокировками, потоками и прочими «прелестями» параллельного программирования, превращающего жизнь программиста в кошмар: мы написали только «интересную» и «содержательную» часть кода, собственно «алгоритмику» задачи, переложив всю рутину на автоматику и, возможно, прозрачным образом задействовав для решения своих задач произвольное количество чужого кода[Скажем, если в трансляции видеопоток сжат нашим «фирменным» кодеком, а звук - обычным стандартным, то потребуется обеспечить лишь «свою» часть по видеодекодированию, а все остальное - декодирование звука, набор «улучшалок» для картинки и т. п. - Cell-устройство возьмет стандартное или ранее загруженное пользователем.].
Возможности для применения Cell-сети необъятны. По сути дела, это некий единый «живой организм», который «растет» (регистрирует в сети новые устройства) или «уменьшается»; который обладает «знаниями» (апулетами) и «живет» в глобальном мире - всемирной Сети, «питаясь» разнообразными данными и «перерабатывая» их. У этого «организма» есть «глаза» (веб-камеры), «уши» (микрофоны), «органы чувств» (клавиатура, мышь, джойстик), «средства коммуникации с внешним миром» (монитор, телевизор, колонки); которые физически могут принадлежать совершенно разным устройствам, но в действительности - одному Cell’у.
Добавление новых устройств в Cell-сеть, как правило, не изменяет ее функциональности (разве что добавляет новые «органы чувств», «средства отображения» и повышает быстродействие) - даже в самом простом варианте Cell универсальна.
Как это все реализовано в железе? В статье о приставках следующего поколения[ «Три тополя на Плющихе»] я подробно описывал аппаратную составляющую одного из первых Cell-устройств - PlayStation 3, и его «сердце» - процессор Cell[Вообще-то он называется Broadband Processor, но это название как-то не прижилось], так что еще раз восхищаться сверхсовременными решениями вроде Rambus-памяти и интерконнекта FlexIO, пожалуй, не будем. Лучше посмотрим, откуда эта своеобразная «несимметричная девятиядерная архитектура» взялась.
Напомню, что в процессоре Cell девять ядер - одно главное и восемь вспомогательных. Но если посмотреть на это с точки зрения концепции Cell, то вспомогательным на самом деле является главное процессорное ядро - PPE (The Power Processing Element). На нем работает операционная система сети Cell, обеспечивающая прозрачное объединение нескольких устройств в сеть; выполнение программ - выборку данных и их распределение вместе с необходимыми апулетами по собственно вычисляющим элементам; взаимодействие с пользователем, работу драйверов устройств… в общем, все то, что мы тремя абзацами выше отнесли к рутине. А самое интересное происходит в маленьких ядрышках процессора Cell - модулях SPE. Фактически каждый такой Synergetic Processing Element - это крошечный самостоятельный компьютер (со своим процессором и своей оперативной памятью), который занимается одним-единственным делом: конвертирует поступающие к нему ячейки-данные согласно заложенному в него алгоритму. То есть физически воплощает в жизнь алгоритм, заложенный нами в одну ячейку-апулет, над ячейками-данными. Все, чем занимается PPE, в сущности, сводится к одному действию: взять данные, требующие обработки, поместить их в память SPE, запустить «процесс превращения» данных в другие данные и куда-нибудь передать полученный результат. Именно поэтому SPE очень много, а блок PPE - один; и именно поэтому у каждого SPE есть своя персональная «локальная» память и нет выхода на «глобальную» (она им попросту не нужна); именно поэтому SPE связаны очень быстрыми шинами и могут передавать данные друг другу напрямую, выстраивая те самые цепочки обработки данных, которые в обычном процессоре являются чистейшей воды абстракцией.
Кстати, использовать для создания Cell-устройств, способных стать частью Cell-сети, описанный процессор вовсе не обязательно. Концептуально от устройства требуется только одно: уметь интегрироваться в сеть (то есть содержать процессор, работающий под управлением соответствующих программ) и уметь выполнять над ячейками-данными ячейки-апулеты (например, содержать хотя бы один SPE). Вполне можно представить, что после «суперпроцессора» Cell появятся более простые варианты с меньшим (или наоборот, большим) числом SPE или даже совсем простые и дешевые мини-процессоры (использующие один SPE и более простой PPE, причем PPE может быть даже не PowerPC-процессором), которые можно будет за сущие гроши устанавливать в любую бытовую технику. С помощью Cell можно одинаково эффективно реализовывать и суперкомпьютеры[Уже представлены блейд-серверы из нескольких Cell-процессоров], и «цифровой дом».
Правда, настанет все это счастье, увы, нескоро - на создание принципиально новых операционных систем (основы Cell), стандартных Cell-библиотек, компиляторов и сред разработки, на перенос имеющегося программного обеспечения и, наконец, на самую обыкновенную перестройку мышления программистов уйдут в лучшем случае годы.
Доживем ли мы до «умных» сетей и распределенных «повсеместных» вычислений, столь же прозрачных, привычных и незаметных, как современные электросети? Годика через три увидим.
ТЕХНОЛОГИИ: Новая надежда
Выхода графического ускорителя нового поколения от ATI, известного под кодовым названием R520, ожидали долго. Даже, пожалуй, слишком долго: мы искали его на Computex, мы надеялись увидеть его в июле, когда nVidia начала продавать видеокарты GeForce 7800GTX, затем в сентябре, когда, казалось, ждать дальше уже было некуда.
Но прошли уже все мыслимые сроки, а R520 все не было.
Тестовая система:
Материнская плата: ASUS A8N SLI Deluxe. Оперативная память: Corsair DDR CMX512-3200XLPRO, 2x512 Мбайт, 2-2-2-10. Видеокарта: nVidia 7800GTX 256 Мбайт, ATI X1800XT 512 Мбайт. Операционная система: Microsoft Windows XP SP2. Драйверы: последние официальные на момент написания статьи. Все настройки системы оставлялись по умолчанию, процессоры функционировали на своих номинальных частотах: Athlon 64 FX-57 2,8 ГГц - множитель 14, шина 200 МГц, память в синхронном режиме с таймингами 2-2-2-10
Вот и получилось, что ситуация на рынке сегодня далеко не в пользу канадцев. Уверенно лидируя в «дешевых» и «интегрированных» нишах, солидных по оборотам, но, увы, не приносящих по-настоящему большой прибыли, самые «вкусные», высокопроизводительные сегменты еще недавно доминировавшая здесь ATI утратила. В результате - провальный квартал и 104 млн. долларов убытков.
Почему так вышло? Думаю, отчасти виноват новый, прогрессивный 90-нм low-k технологический процесс, освоение которого на заводах TSMC, производящей GPU по заказам aTI, вероятно, проходило далеко не так гладко, как рапортуют теперь маркетологи[Все мы помним, что первая итерация 90-нм процессоров Intel получилась «слишком горячей» (большие токи утечки вносили ощутимый вклад в тепловыделение ранних степпингов Prescott), а у aMD - «слишком медленной». Да и nVidia, тоже размещающая заказы на заводах TSMC, предпочла изготавливать свой новый GPU G70 по «старому, дорогому и медленному», зато проверенному 110-нм техпроцессу]. Отчасти - «погоня за двумя зайцами», то есть одновременная разработка и запуск в серию двух совершенно разных продуктов: основанного на унифицированной шейдерной архитектуре процессора R500[На нем построена приставка Xbox 360, выпуск которой намечен на ноябрь], который невозможно использовать в обычных видеокартах; и нашего сегодняшнего героя R520, построенного по «классической», но сильно переработанной архитектуре. Вдобавок чип получился по-настоящему новым и революционным (после едва ли не трех лет постепенной эволюции удачной линейки Radeon 9xxx), так что его проектирование и доводка наверняка отличались особенной сложностью, и сколько ушло итераций на то, чтобы отловить все ошибки, - знают только инженеры aTI.
Впрочем, довольно толочь воду в ступе. В конце концов, пусть и с полугодовым опозданием, но R520 - перед нами, и в ближайшее время видеокарты на его основе появятся в розничной продаже.
Технические характеристики новинки
Итак, что же удалось сделать ATI? Я бы сказал, невероятно многое. Словно все три года, пока регулярно выходили превосходные видеокарты, полученные экстенсивным расширением старой технологии, инженеры откладывали все по-настоящему интересные задумки в долгий ящик, чтобы потом реализовать их скопом.
Во-первых, радикально переработано сердце любого графического ускорителя - блок пиксельных процессоров, отвечающий за закраску сцены по заданным алгоритмам. Традиционно в этом блоке ставится энное количество одинаковых пиксельных конвейеров, каждый из которых «в параллель» с остальными вычисляет цвет отдельно взятого пиксела (или субпиксела) в нашей сцене[Строго говоря, одиночные конвейеры сейчас уже никто не использует, поскольку гораздо эффективнее собирать их в группы по четыре штуки (процессоры квадов), чтобы они обрабатывали не отдельные пикселы, а блоки 2x2 пиксела (квады). При этом часть логики удается объединить, проводя некоторые операции не над отдельными пикселами, а над квадами целом - это и быстрее и проще]. То есть, единожды попав на какой-нибудь конвейер, пиксел, обрабатываемый соответствующей ему программой - пиксельным шейдером, раз за разом проходит по этому конвейеру, как бы крутится внутри него до тех пор, пока не закончится вычисление его цвета. Соответственно все устройства, и, в частности, текстурные модули, выбирающие из видеопамяти необходимые для этих вычислений данные, напрямую подключены к исполнительным устройствам конвейера. Схема достаточно простая и эффективная: нужно увеличить вычислительную мощность графического процессора - ставим больше конвейеров, и количество обрабатываемых за такт пикселов, а вместе тем и скорость закраски изображения пропорционально возрастет.
Инженеры aTI пошли другим, «процессорным» путем,[Подробнее см. «КТ» #609 (рубрика 'Архитектура ХХ века")] не став дублировать конвейеры, а организовав из GPU своеобразный суперскалярный процессор с единым конвейером, на котором несколько пикселов могут обрабатываться одновременно. Вместо того чтобы «распихать» пикселы по разным конвейерам, R520 накапливает их (вместе с соответствующими шейдерными инструкциями) в специальном огромном планировщике, который aTI называет Ultra-Threading Dispatch Processor. Почему Ultra? Да потому, что этот планировщик управляет одновременным выполнением колоссального числа операций (512 квадов 2x2 пиксела в High-End, и более скромные 128 квадов - в менее дорогих Middle-End и Low-End графических чипах). Все квады хранятся в длиннющих очередях, и по мере того, как освобождаются вычислительные ресурсы, отправляются на соответствующее устройство, будь то вычислительный, текстурный блок или блок графического Back-end’а (запись результатов во фрейм-буфер, блендинг, z-тест, антиалиасинг и пр.). Это более сложный подход, чем несколько однотипных конвейров, но и более гибкий и эффективный. Например, мы можем сколь угодно гибко варьировать соотношение количества вычислительных и текстурных модулей, так как они больше не подключаются друг к другу, образуя единое целое, а разделены по операциям, которые они выполняют[Подобную оптимизацию можно будет увидеть в ядре R530 - сердце Middle-End ускорителя Radeon X1600. В нем будет три процессора квадов (3x4 = 12 пиксельных конвейера), но всего один процессор текстур (1x4 = 4 TMU). Для современных шейдеров, которые больше занимаются вычислениями, нежели выборкой данных из оперативной памяти, такой подход оправдан, поскольку позволяет рациональнее расходовать площадь кристалла, увеличив число пиксельных конвейеров за счет сокращения числа TMU]. Речь идет о текстурных операциях, которые ранее могли блокировать конвейер до тех пор, пока не будет завершена операция выборки очередного тексела[Традиционный конвейер GPU устроен гораздо проще конвейера CPU, так что переупорядочивания инструкций, которое позволило бы обогнать застрявшую в конвейере инструкцию другой, не зависящей от нее, - в графических процессорах нет].
Заодно решается и проблема динамических условных переходов в шейдерах. Что это такое? Сейчас объясню: ради все того же упрощения пиксельных конвейеров, которых нужно уместить побольше на ограниченный кусочек кремния, эти конвейеры устраивают таким образом, что они вначале как бы настраиваются на ту или иную конкретную операцию над пикселами (сложение, вычитание, умножение) и затем применяют ее много раз подряд к разным пикселам; после чего перестраиваются на следующую операцию и снова применяют ее много раз к тем же пикселам, и т. д. Поскольку один и тот же шейдер обычно требуется применить к умопомрачительному количеству пикселов, такая схема обычно работает замечательно. Однако если встречается шейдер, в котором есть динамические условные переходы (которые нельзя заранее предсказать), то может оказаться так, что для одной части пикселов, «бегающих по кругу» в конвейере, какую-то операцию применять нужно, а для другой - нет. И это столь серьезная проблема, что графические чипы ATI долгое время не поддерживали динамические переходы (а значит, и Shader Model 2.0a и 3.0).
Правда, решение nVidia очень уж красивым тоже не назовешь: в ее варианте «глупый» конвейер по кругу обрабатывает все пиксели, но в решающий момент над некоторыми из них производит операцию, а некоторые - игнорирует[Похожий способ исполнения условных переходов можно встретить в процессорах ARM]. ATI нашла гораздо лучший выход: поскольку вместо нескольких «глупых» и простых конвейеров у нее лишь один, но «умный» и сложный, то не требующие обработки пиксельные квады до исполнительных устройств просто-напросто не добираются, уступая место тем квадам, с которыми действительно нужно что-то делать. В результате конвейер хоть и исполняет по-прежнему одну и ту же операцию над разными пикселами, неторопливо перестраиваясь с одной на другую, но делает это не в пример интеллектуальнее и не разбазаривает попусту свои ресурсы. А заодно семейство Radeon X1000 получает практически «бесплатную» поддержку шейдеров третьей версии. Честно говоря, столь блестящему решению, убивающему разом целую стаю зайцев, можно только позавидовать! Это еще не унифицированная шейдерная архитектура, где единый конвейер (а вернее, набор из таковых) может обрабатывать любые шейдеры - как пиксельные, так и вершинные, но то, что полшага в ее сторону сделано, - несомненно.
Вторая группа изменений коснулась оптимизации графического процессора для работы на больших и очень больших тактовых частотах. Например, архитектура подсистемы памяти была полностью переделана для поддержки казавшейся невероятно быстрой видеопамяти - 1500 МГц GDDR3[И ведь это еще не предел - ходят вполне правдоподобные слухи, что R520 поддерживает не вышедшую пока в свет графическую оперативную память следующего поколения, GDDR4]. Вместо традиционной схемы с множеством текстурных модулей (TMU), централизованно подключавшихся к единому контроллеру оперативной памяти, который, в свою очередь, по широким шинам запрашивал данные из памяти и возвращал ответ по тем же каналам связи, по которым пришел запрос, ATI изобрела принципиально новую, кольцевую внутреннюю шину видеопамяти, «размазывающую» контроллер памяти едва ли не по всему графическому процессору. Идея в том, что вместо одного большого и сложного контроллера мы делаем до восьми маленьких контроллеров, каждый из которых контролирует только свой относительно небольшой кусочек видеопамяти. Причем он расположен в кристалле так, чтобы сравнительно узкую (32-разрядную) шину видеопамяти от него было удобнее разводить на печатной плате и тем самым сводить к минимуму помехи, обычно возникающие из-за несовершенства разводки. Вдобавок, небольшим контроллерам требуются небольшие же кэши данных, что позволяет отказаться от традиционных упрощенных и имеющих ряд недостатков кэшей прямого отображения и наборно-ассоциативных кэшей в пользу более сложных, но лишенных этого недостатка полностью ассоциативных кэшей.
Маленькие контроллеры (точнее, интерфейсы для подключения модулей памяти) объединяются очень быстрой внутренней двунаправленной кольцевой шиной (шириной 256 линий в каждом направлении для моделей с 256-разрядной основной шиной памяти и 128 линий - для более дешевых). На кольце имеется четыре «остановки» - точки подключения к внешних устройств. Например, для топовых R520 к каждой такой «остановке» подключено по два модуля памяти (шина памяти 2x32 разряда) и какая-то часть внутренних устройств процессора, расположенных поблизости. Каких? А неважно: какие было удобно подключить именно в этом месте, такие и подключили. Кроме того, по специальным простым управляющим шинам (по которым передаются только инструкции) каждая такая «остановка» подключена к «диспетчеру» - тому самому централизованному контроллеру памяти, который не занимается доставкой данных к исполнительным устройствам, а только «отдает распоряжения» и «присматривает» за тем, чтобы нужные данные прочитал нужный маленький контроллер и отправил их по кольцу до нужной «остановки», где их сможет снять само исполнительное устройство.