AMD о будущем взаимодействия CPU и GPU

Инициатива AMD, именуемая HSA или heterogeneous system architecture (гетерогенная системная архитектура), – это объект постоянного интереса еще с 2007, когда компания впервые заговорила о процессорах Fusion. А 26 августа сего года на международной технологической конференции Hot Chips компания выступила с докладом, в котором раскрыла детали о том, над чем работает HSA Foundation, а также о языке, который претворяет эту технологию в жизнь, т.е. о HSAIL (HSA Intermediate Language или «вспомогательном языке HSA»).

Начать лучше с общего взгляда на проблему. Несмотря на популярность OpenCL и прямые инвестиции Nvidia (исчисляющиеся сотнями миллионов долларов) в Tesla и CUDA, текущая проблема перемещения задач от CPU к GPU, их обработка и возврат обратно к CPU – это по-прежнему гигантская головная боль. И если вкратце, суть этой проблемы состоит в том, что довольно долгое время главенствующим трендом в вычислениях был перенос задач на CPU, где они и обрабатывались. В сущности, гейминг – это единственная область, которая сопротивлялась данному тренду (перемещение GPU на кристалл – это не то же самое, что программировать игру, которая будет работать на CPU).

Тенденция «Вперед, к CPU!» царила несколько десятилетий, поэтому создание такой системы, которая повернула бы этот вектор в сторону GPU, заодно сделав его равным партнером своему кристаллическому собрату, приобрело статус очень непростого дельца. Для того, чтобы справляться с гетерогенными вычислениями, система CPU-GPU должна обладать некой мощностью, а хардверная составляющая HSA-совместимости как раз и занимается определением этой мощности. Во-первых, CPU и GPU должны делиться общим набором записей таблицы страниц. Во-вторых, эти записи должны позволить и CPU, и GPU объявлять об ошибках страниц (а также пользоваться тем же адресным пространством). В-третьих, система должна уметь выстраивать в очередь команды для их выполнения при помощи GPU без необходимости всякий раз беспокоить ядро ОС. В-четвертых, GPU должен уметь переключать задачи независимо. И в-пятых, оба устройства должны уметь работать с одним и тем же когерентным блоком памяти.

А что касается HSAIL, то этот язык отвечает за программную составляющую технологии.

HSAIL – это не API

Чтобы не было путаницы, я напишу об этом сразу. HSAIL – это вспомогательный язык-посредник, созданный во время работы над проектом и совместимый с ISA поставщика. Именно благодаря этому секретному ингредиенту разные компании-поставщики – вроде Imagination, ARM, AMD и Qualcomm – и смогут заработать на этой технологии, причем даже несмотря на то, что продают совершенно разные GPU-устройства. Идея заключается в том, что вы можете писать код на любом языке (в списке C++, AMP, OpenCL, Java и Python), компилировать его с помощью HSAIL и запускать на любом GPU, встроенном в систему.

По словам AMD, преимущество HSAIL заключается в том, что программистам не понадобится учить новый язык. Если вы знакомы с OpenCL, используйте OpenCL. На данный момент возможности HSAIL все еще могут идти внахлест OpenCL 2.0, однако HSAIL явно создан для того, чтобы упростить самые сложные моменты программирования на GPU. Кроме того, это открывает возможность для ускорения языков вроде Java (на GPU), но опять же, это не требует того, чтобы Java соответствовал графической карте. У этой гидры миллион голов.

Как показано выше, центральная идея заключается в том, что HSAIL-железу не нужна ни совместимость с x86, ни база GCN, ни какая-либо другая архитектурная привязка. Это значит, что Imagination может запустить свой код с таким же успехом, что и Qualcomm. Ну, или по крайней мере, каждая компания может писать свои собственные драйверы. Но опять же, отныне это бремя несет не только программист, а это и есть главное преимущество.

А как насчет гейминга?

Это более сложный вопрос. То, что мы называем «геймингом», – это невероятно сложный поток данных между CPU, GPU, оперативной памятью и памятью на винчестере. Между CPU и GPU связь была всегда, но, как правило, эта связь была асинхронна. Она была быстра лишь в одном направлении (см. график ниже).

На этом графике отображена пропускная способность CPU и GPU во время доступа к разным типам памяти. Она ассиметрична, поскольку отражает дисбаланс между стандартной пропускной способностью CPU и GPU к разным участкам оперативной памяти. Асимметричные связи могут быть ускорены, а задержка – снижена, но смысл в том, что эта картинка наглядно иллюстрирует статус-кво, которого разработчики придерживались десятилетиями. Игры всегда создавались такими, чтобы работать на конкретном типе конфигурации. У HSA есть шанс изменить эту традицию, но разработка ПО всегда плетется позади нового железа.

Это не значит, что HSA не будет иметь никакого значения для производительности в играх, и уж тем более – что не сможет улучшить ее. Помимо прочего, AMD обратила внимание на тот факт, что GPU пускай и использовался для ускорения и улучшения игровой физики, но большая часть этих нововведений были чисто косметическими. PhysX от Nvidia позволял добавить картинке дополнительного лоска, но этот лоск не влиял на саму игру. Внутриигровая физика – это проблема вычислений, и HSA, по всей видимости, может быть использован для создания более сильных игровых впечатлений.

HSA может здорово проявить себя в гейминге, но тому есть несколько препятствий. Во-первых, должны быть созданы физические движки, способные перемещать данные взад-вперед (т.е. от CPU к GPU и обратно), во-вторых, HSAIL еще не выпущен, а в-третьих, переход на новую модель программирования может занять некоторое время. В данный момент они фокусируются на том, чтобы использовать HSAIL для вычислений, и поэтому большинство компаний, анонсировавших поддержку HSA, сосредоточены именно на высокоэффективных вычислениях.

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