ВИДЕОКАРТЫ

Редакция THG,  23 марта 2009 Страница:   1 2 3 4

Быстрая связь: кольцевая шина

Чтобы обеспечивать когерентность кэшей, связь между разными процессорами и доступ к фиксированным блокам, таким как текстурные блоки, Intel реализовала довольно классическую кольцевую шину. Данный тип топологии недавно вновь стал активно использоваться, в качестве примеров можно привести процессор Cell и некоторые GPU AMD (X1800, X1900 и т.д.), поскольку он существенно упрощает проблему связи между компонентами, когда количество передаваемых данных увеличивается.

Intel снабдила Larrabee двумя 512-битными шинами, по одной на каждое направление, чтобы снизить задержки на связь. Однако подобное решение недостаточно, чтобы избежать задержек, которые могут достичь проблематичного уровня, когда число процессоров превысит определённое число. Поэтому в реализациях Larrabee, которые используют более 16 ядер, применяются несколько более коротких кольцевых шин (вероятно, обслуживающих только по восемь ядер).

Кстати, диаграмма Intel Larrabee не совсем точная. Чтобы избежать лишнего усложнения, Intel расположила контроллеры памяти по обе стороны чипа, а все текстурные блоки слева. На практике текстурные блоки и контроллеры памяти будут распределены вдоль периферии кольца, а не будут располагаться в одном месте. Это позволит избежать проблем с перегрузкой на конфигурациях, подобных показанной.

Текстурные блоки

Как мы уже говорили чуть выше, Larrabee не очень похож на традиционный GPU, но если Intel удалось устранить движок настройки (setup engine) и блоки растровых операций (ROP), интегрировав эти функции напрямую на уровне ядер Larrabee, то для текстурных блоков такое сделать уже не получилось. Эти блоки выполняют довольно специфическую работу, с которой справляются именно специализированные блоки. Сжатие текстур (DXTC), например, очень просто сделать аппаратно, что и обусловило успех этой технологии, но оно требует существенных ресурсов для программной реализации. Intel посчитала, что выполнение текстурных операций на процессорах будет в от 12 до 40 раз медленнее, чем на отдельных блоках, в зависимости от конфигурации (такой как качество фильтрации, сжатый или несжатый формат текстур).

Текстурные блоки довольно классические, и Intel не даёт о них много информации, за исключением того, что они будут поддерживать все стандартные операции Direct3D 10 и режимы сжатия. Фактически, это единственная особенность, которая может ограничить способности эволюции Larrabee. Как мы увидим позже, программное обеспечение полностью управляет конвейером рендеринга Larrabee, оно может добавлять грядущие функции программного интерфейса приложений (API) Microsoft через простое обновление 3D-движка, исполняемого ядрами Larrabee. С другой стороны, текстурные блоки будут ограничены определённым уровнем функциональности, который будет определять работу чипа в целом.

Одна любопытная особенность данных текстурных блоков в том, что они могут выполнять преобразование виртуальных адресов в физические. Если быть более конкретным, это означает, что вам больше не нужно загружать полную текстуру с её mipmap-стеком в локальную память. В памяти в виде страниц размером в несколько килобайт будут храниться только те части текстуры, которые необходимы для её отображения. Если страницы в памяти нет (page fault), текстурный блок оповещает процессор, который может вызвать требующиеся данные. Этот механизм упростит жизнь программистам, которые не ленятся выполнять сложные реализации, например, алгоритма, подобного id Software MegaTexturing.

Larrabee против Cell

Очень заманчиво сравнить Larrabee и Cell. Оба процессора используют множество одиночных ядер (с упорядоченным выполнением команд), делают акцент на векторные вычисления, имеют 256 кбайт выделенной кэш-памяти на ядро, кольцевую шину для связи и т.д. На первый взгляд сходств много. Но и различия тоже весьма существенны: Cell, в первую очередь, это центральный процессор. И хотя он ориентирован на потоковые приложения, он не подходит для расчёта и вывода рендеринга, то есть текстурных блоков у него нет.

Другим существенным отличием является способ работы с памятью. У Cell, за исключением PPE, который является единственной частью процессора с глобальным доступом к пространству памяти, доступ к памяти всех SPU ограничен 256 кбайт локальной памяти. Поэтому доступ к основной памяти должен выполняться исключительно через операции прямого доступа (DMA). Как мы уже видели выше, все ядра Larrabee имеют доступ ко всему пространству памяти через кэш-память, работа которой прозрачна программисту, даже есть некоторые возможности управления. Выбор Intel существенно упрощает программирование и позволяет избежать добавления более общих ядер, таких как PPE. Подобная гетерогенная система является одним из недостатков Cell, поскольку она усложняет жизнь программистов. Кроме тщательной проработки доступа к памяти, программист должен собирать два исполняемых файла с помощью двух наборов инструкций, что предусматривает работу с двумя разными компиляторами.

Поэтому ядра Larrabee намного более функциональные, чем SPU у Cell, так как они поддерживают все инструкции x86. Да и производительность расчёта векторов тоже выше. Это связано с тем, что ядра работают с 512-битными векторами, а не 128-битными, как в SPU. И если у Cell сохранится преимущество по частоте (Larrabee, как ожидается, будет работать на частотах от 2 до 2,5 ГГц, но это всё пока очень предположительно), подобная особенность компенсирует столь крупный недостаток. Означает ли, что Cell нечего противопоставить? Отнюдь. Cell, с 234 миллионами транзисторов (число, которое впечатляло три года назад, но сегодня удивить им сложно) намного дешевле производить, чем Larrabee, который будет крупнее и существенно дороже в производстве.

Наконец, хотя процессор Cell не получил такого успеха, какого от него ожидали, процессор используется в более, чем 20 миллионах экземпляров PlayStation 3, и при этом большое количество программистов провели дни многие и ночи, разрабатывая приложения для этой платформы, чтобы выжать из неё максимум. А платформе, между прочим, уже три года. На данный момент Larrabee существует только на бумаге, и даже когда новый графический процессор Intel будет воплощён в кремнии, вряд ли многие программисты решаться "копать целину". Большинство просто станет использовать API (OpenGL/Direct3D для 3D и OpenCL/Compute Shader для GPGPU).

Впрочем, с аппаратной точки зрения не вызывает сомнений, что Larrabee очень и очень интересный графический процессор. Cell послужил прообразом нескольких важных концепций, которые теперь проявили себя в Larrabee. Но если оглянуться в прошлое, процессор Cell был всё же слишком амбициозен для своего времени, и IBM пришлось пойти на серьёзные компромиссы, чтобы видение процессора было совместимо с технологиями, доступными тогда.

Larrabee против GPU

Как мы уже сказали раньше, Larrabee не похож на обычный GPU вообще за исключением текстурных блоков. Здесь нет ни малейшего следа других фиксированных блоков, которые обычно встречаются у GPU: движка настройки (setup engine), преобразовывающего треугольники в пиксели и интерполирующего различные атрибуты вершин, растрового конвейера (ROP), который записывает пиксели в кадровый буфер, выполняет сглаживание и все необходимые операции смешения. В случае Larrabee все эти операции выполняются напрямую ядрами. Преимущество такого подхода заключается в увеличении гибкости. В случае смешения, например, можно управлять прозрачностью независимо от порядка, в котором отсылаются примитивы, что довольно сложно достижимо у современных GPU. Недостатком можно назвать то, что Intel придётся обеспечивать GPU большей вычислительной мощностью, чем у конкурентов, которые используют выделенные блоки для задач подобного рода, а программируемые блоки концентрируются на шейдерах.

Хотя GPU стали очень гибкими после появления Direct3D, они по-прежнему далеки до гибкости, которую способен обеспечить Larrabee. Одно из основных ограничений GPU, даже при использовании API подобно CUDA, заключается в доступе к памяти. Как и в случае Cell, работа с памятью сильно усложнена, и чтобы получить оптимальную производительность, нужно минимизировать число используемых регистров, а также приходится использовать небольшие участки памяти в несколько килобайт.

Более того, несмотря на гибкость, которую получили современные GPU, их функции остаются, в значительной мере, ориентированными на чистые расчёты. Например, никто даже не думает выполнять операции ввода/вывода на GPU. Напротив, Larrabee способен с этим справиться, то есть Larrabee может напрямую выполнять операции printf или работать с файлами. Кроме того, можно использовать рекурсивные и виртуальные функции, что в случае GPU невозможно.

Конечно, все эти функции даются не бесплатно, и все они неотвратимо влияют на эффективность выполнения программ, так как мы отходим от парадигмы параллельного программирования. Но всё это приемлемо для кода, который не будет использоваться в области, чувствительной к производительности. Возможность выполнения подобного кода без использования CPU открывает ряд интересных возможностей. Например, современные GPU используют компилятор "just-in-time" (JIT) в драйверах, который адаптирует шейдеры к специфическим деталям архитектуры "на лету" во время выполнения задачи. Larrabee не стал исключением из правила, но вместо интеграции данного компилятора с центральным процессором, он работает напрямую на Larrabee.

Ещё одна интересная возможность – код можно отлаживать напрямую на Larrabee, вместе с тем отладка кода CUDA, как правило, невозможна без использования эмуляции на CPU. В подобных случаях CPU эмулирует GPU, но не в точности повторяет его поведение, поэтому могут возникнуть различные ошибки, "выловить" которые не всегда просто.

Larrabee против себя?

На первый взгляд, Larrabee кажется победившим при сравнении с прямыми конкурентами. Процессор более параллельный, чем Cell, более гибкий, чем GPU, то есть, вроде бы, лучшего желать не приходится. Но в реальности не всё так гладко. Продукт, существующий только на бумаге, всегда обладает всеми нужными качествами без недостатков. Долгое время Itanium казался будущим процессоров, прежде чем его тяжкий промах не стал очевидным: если не очень легко динамически реорганизовать инструкции программы на процессоре, то столь же тяжело сделать это статически в компиляторе.

Поэтому не стоит слепо встречать объявление каждой новой технологии. В некоторых форумах на каждый вопрос, касающийся рендеринга или каких-либо алгоритмов, кто-то всё равно упомянет Larrabee в качестве идеального решения, что на данный момент преждевременно. Larrabee не решит всех проблем рендеринга 3D в реальном времени, хотя и может привести к заметному прогрессу.

Larrabee, вне сомнения, встречают очень положительно, поэтому Intel необходимо быть очень осторожной, что не получить обратный эффект, если первое поколение продуктов не будет соответствовать ожиданиям (синдром Merced).

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

feed_id: 6177 pattern_id: 2818

Отзывы о Intel Larrabee в Клубе экспертов THG

Другие статьи

СОДЕРЖАНИЕ |Одной страницей|Версия для печати

Введение Ожидаемое возвращение? Общий обзор Ядра в деталях: что-то новое, что-то (очень) старое x86: правильный выбор? В деталях: скалярный блок и SMT Векторный блок и новый набор инструкций Векторный блок и регистр маски Быстрая связь: кольцевая шина Текстурные блоки Larrabee против Cell Larrabee против GPU Larrabee против себя?  Отзывы о Intel Larrabee в Клубе экспертов THG [ 254 отзывов]