Чем Кеплер умнее Ферми, и как это поможет САПР

На конференции GTC 2012 NVIDIA анонсировала вступление в новую эпоху высокопроизводительных вычислений на видеокартах (GPU Computing)

Конечно, речь в статье пойдёт вовсе не о несуразном сравнении Энрико Ферми и Иоганна Кеплера, а об архитектурах видеокарт NVIDIA, названных в честь этих знаменитых ученых, и также о том, как GPU вычисления могут помочь развитию САПР.

К настоящему моменту NVIDIA уже добилась грандиозных успехов в области развития и продвижения своих технологий - это и платформа CUDA, со средствами отладки и профилировки под Windows, Linux и Mac, множество специализированных библиотек, таких как OptiX, PhysX, cuBLAS, cuFFT и др., средства разработки OpenACC, PGI Accelerator, OpenCL — подробную информацию можно найти в NVIDIA Developer Zone, а определенное впечатление о текущих достижениях составить из фоторепортажа с конференции GTC 2012.

Однако перед погружением в технические детали новейшей архитектуры NVIDIA Kepler и, учитывая недостаточную осведомленность многих профессиональных программистов и специалистов по вычислительной математике о возможностях современных GPU, полезно совершить небольшой экскурс в историю развития вычислений на видеокартах.

Предыстория

Developers, Developers, Developers, Developers,
Developers, Developers, Developers, Developers,
Developers, Developers, Developers, Developers!

Стив Баллмер напоминает, что надо
заботиться о прикладных разработчиках

Хотя рождение термина GPGPU (General Purpose GPU) компания NVIDIA датирует 2003 годом, в течение нескольких последующих лет программирование неграфических вычислений оставалось уделом энтузиастов — ведь оно подразумевало необходимость переформулировать свою задачу в терминах текстур и шейдеров, требовало отличного понимания архитектуры GPU и использования API графических библиотек (типа OpenGL). Поддержки вещественных чисел с двойной точностью не было, а выигрыш в производительности по сравнению с x86 процессорами было трудно назвать фантастическим.

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

Короче говоря, поскольку порог входа в область вычислений на видеокартах был чересур высок для большинства потенциальных пользователей, то NVIDIA, оценив перспективу рынка GPGPU, постаралась максимально сфокусироваться на потребностях разработчиков и упростить им жизнь. Вслед за выходом чипа G80 в 2006 году компания выпускает первую версию CUDA — технологию, позволяющую программировать с помощью специального расширения популярного языка C. Впрочем, работать можно было по-прежнему только с вещественными числами одинарной точности, и это резко снижало привлекательность для многих научных и индустриальных задач. На дальнейшие улучшения потребовались еще два года, и в середине 2008 вышла архитектура GT200, куда уже была добавлена поддержка вещественной арифметики с двойной точностью.

Иллюстрация «Закона» Мура: в 2006 году на кривой обозначена NVIDIA G80. Музей компьютерной истории. Сан-Хосе, Калифорния.

Однако настоящим прорывом стала Fermi (GF100), выпущенная в 2010 году. NVIDIA фактически перепроектировала чип, учтя приобретенный многолетний собственный опыт и опыт уже сформировавшегося сообщества пользователей.

Результат не заставил себя долго ждать: резко выросло число научных публикаций, посвященных разработке специальных алгоритмов для GPU, появилось множество коммерческих программных решений, превращающих настольный компьютер в высокопроизводительную систему, а в 2011 году гибридному суперкомпьютеру Tianhe (Китай), основанному на NVIDIA Tesla, удалось прорваться на первое место в рейтинге Top-500. Можно сказать, что в этот момент технология вычисления на видеокартах окончательно сформировалась как «мейнстрим».

Необходимо отметить, что на протяжении всего этого времени NVIDIA серьезно инвестировала не только в создание «железа», но и в развитие экосистемы вокруг своих решений. Создание специализированных библиотек, множество примеров решенных задач с исходным кодом, документация и тонны статей, грамотный маркетинг и PR — всё это способствовало удачному продвижению платформы CUDA и быстрому росту сообщества разработчиков. Кроме того, чтобы начать программировать, совсем необязательно покупать дорогую профессиональную Tesla - достаточно приобрести относительно дешевую GeForce (скажем, стодолларовую GTS 450) и проверить, насколько вся технология подходит для ваших задач. Впрочем, не стоит забывать, что GeForce от Tesla отличается не только ценой. Скажем, коэффициент отношения производительности вычислений с двойной точностью к одинарной для Tesla равен 1/2, а для GeForce - 1/8.

Дженсен Хуанг, CEO NVIDIA, представляет платформу CUDA «в числах»: за 4 года рост довольно впечатляющий.

Здесь интересно упомянуть про конкурента NVIDIA — компанию AMD с их линейкой видеокарт Radeon и FireStream. Чуть отстав на старте гонки GPGPU, компания ATI Technologies, будучи уже купленной AMD, довольно быстро наверстала упущенное и время от времени вырывалась вперед, придавая заряд бодрости NVIDIA. Например, AMD первой в 2007 году поддержала на аппаратном уровне вещественную арифметику с двойной точностью в FireStream 9170, регулярно выпускала более мощные видеокарты и даже отметилась в списке Top-500 в 2009 году — суперкомпьютер Tianhe, основанный на Radeon HD 4870, занял 5-ую позицию (впоследствии, правда, Tianhe переориентировался на видеокарты NVIDIA).

Однако хорошее аппаратное или техническое решение — это половина дела. Необходимо, чтобы разработчики захотели для него создавать ПО. Трудно сказать, что явилось определяющим фактором — проблемы платформы StreamSDK (включавшей технологии ATI CAL и ATI Brook+), сложности с кодированием нетривиальных алгоритмов или просто отсутствие должного маркетинга, но приходится признать, что AMD серьезно проигрывает NVIDIA в войне за симпатии разработчиков GPGPU. В 2011 году AMD изменила свою стратегию и полностью перешла на стандарты OpenCL и DirectCompute.

Любопытно, что NVIDIA, являясь одним из поставщиков реализации OpenCL (и, кстати, первой компанией, поддержавшей этот стандарт в 2009), совсем не спешит рекомендовать его своим пользователям. В качестве причин приводятся сырость как самого стандарта, так и реализации и документации, отсутствие поддержки новейших возможностей видеокарт. Так что перед разработчиками сейчас возникает непростая альтернатива — или ориентироваться на CUDA и видеокарты NVIDIA, принося в жертву возможность запуска программ на AMD, или выбирать OpenCL, рискуя сильно потерять в эффективности на железе NVIDIA. И, по всей видимости, многое в этом выборе зависит от того, насколько успешной будет архитектура Kepler, возможности которой будут полностью раскрыты в Tesla на чипе GK110 и соответствующей  CUDA 5.0. Вряд ли стоит ожидать в обозримом будущем полной поддержки функционала Kepler для платформы OpenCL.

Короче говоря, к настоящему моменту технология вычислений на GPU уже набрала хорошие обороты. Больше не возникает сомнений, что для некоторых задач биоинформатики, вычислительной физики, визуализации и проч., коэффициент ускорения по сравнению с многоядерными процессорами может составить от 2 до нескольких десятков раз. Поэтому теперь перед NVIDIA стоит другая задача: закрепить успех своей платформы, не просто увеличивая производительность видеокарт, а предлагая такие улучшения, которые сделали бы адаптацию существующих алгоритмов под платформу CUDA не сложнее программирования для x86 процессоров. "Больше приложений - хороших и разных!", - таков девиз дальнейшей стратегии NVIDIA.

Архитектура Kepler нацелена на более широкий класс приложений — прежде всего на те, где требуется работа с нерегулярными данными. (Источник: NVIDIA.)

Технические особенности архитектуры Kepler

Специалисты NVIDIA выделяют 3 ключевых нововведения Kepler по сравнению с Fermi: SMX (есть и в GeForce, и в Tesla), Hyper-Q и Dynamic Parallelism (только в Tesla GK110).

SMX (Streaming multiprocessor) — это новый вычислительный модуль, пришедший на смену SM (Fermi). Поскольку энергопотребление уже давно является головной болью поставщиков процессоров и одним из главных ограничений для увеличения производительности, то при проектировании Kepler инженеры компании ориентировались на максимизацию соотношения «Производительность/Ватт» (в то время как несколько лет назад старались уменьшить себестоимость изделия: «Производительность/доллар»)

И, действительно, утверждается, что в метрике «Производительность/Ватт» Kepler выигрывает у Fermi в 3 раза. Количество ядер CUDA на SMX составляет 192 (было 32 на Fermi SM). Так что теперь топовые видеокарты Kepler оборудованы 8 SMX модулями с 1536 ядрами вместо 16 SM с 512 ядрами для Fermi, что дает рост абсолютной производительности также в 3 раза.

Под Hyper-Q понимается возможность одновременного выполнения нескольких (до 32) задач на GPU, запущенных, например, из разных CPU-процессов. Для Fermi пользователь тоже мог получить доступ к одной видеокарте из разных процессов и запустить несколько задач одновременно. Однако из-за того, что была только одна аппаратная очередь для задач, их исполнение происходило всегда последовательно. Скажем, если задача загружала ресурсы видеокарты на 20%, то остальные 80% не использовались, хотя «у дверей» в очереди ждали остальные задачи.

В Kepler с технологией Hyper-Q ситуация изменилась — теперь есть поддержка 32 аппаратных очередей задач, так что они могут быть запущены с настоящим параллелизмом. Если один из них использует ресурсы видеокарты не полностью, то драйвер запускает на исполнение задачу из другой аппаратной очереди, что полезно для большого количества небольших задач.

Главным изобретением в Kepler, наиболее интересным для программистов и разработчиков алгоритмов, является Dynamic Parallelism — возможность создавать вычислительные потоки (threads) внутри уже созданных потоков без передачи управления обратно в CPU. Важность этого нововведения станет понятной, если вспомнить про древовидную структуру огромного количества алгоритмов вычислительной и дискретной математики. Для Fermi было необходимо завершать потоки, возвращать управление на CPU, создавать новые и т.д., либо существенно видоизменять сам алгоритм. И то и другое не только добавляло накладные расходы и снижало итоговую эффективность кода, но и, что гораздо неприятней, увеличивало время разработки.

Дженсен Хуанг представляет результаты моделирования динамики сталкивающихся галактик на Kepler GPU. Используемый алгоритм (tree-code Барнса-Хата) призван продемонстрировать работоспособность ключевых особенностей архитектуры.

Так что, начиная с четвертого квартала 2012 года (а именно тогда выйдут видеокарты на основе чипа GK110, поддерживающие 3-х кратное увеличение производительности вычислений с двойной точностью, Hyper-Q и Dynamic Parallelism), жизнь большинства разработчиков будет существенно упрощена. Пока же доступны только видеокарты на основе чипа GK104, в 3 раза ускоряющего вычисления с одинарной точностью и нацеленного на задачи обработки изображений,  сигналов и сейсморазведки.

Более подробные характеристики архитектуры Kepler c описанием остальных особенностей (таких как, например, GPUDirect — технологии, которой обязательно заинтересуются пользователи гибридных суперкомпьютеров) можно найти в статье NVIDIA.

GPU вычисления на службе у САПР?

Приложения CAE для инженерного анализа, будучи наиболее требовательными к вычислительным ресурсам, уже давно используют для расчетов небольшие кластеры и суперкомпьютеры. Неудивительно, что разработчики этих приложений были одними из первых, кто осознал потенциал GPU вычислений — из хорошо известных примеров можно назвать программные продукты ANSYS или SIMULIA. Более того, у NVIDIA уже существует специализированное программно-аппаратное решение Maximus на базе видеокарт Quadro и Tesla, позволяющее одновременно выполнять и инженерный анализ и визуализацию.

Одновременный инженерный анализ и рендеринг для мотоцикла на рабочих станциях NVIDIA Maximus. (Источник: NVIDIA)

А как дела обстоят с САПР? Казалось бы, эти приложения со времени появления используют GPU по прямому назначению (рендеринг и визуализация), и их разработчики должны быть прекрасно осведомлены о возможностях неграфических вычислений на видеокартах.

Здесь стоит пояснить, что одной из наиболее вычислительно сложных задач в САПР является построение и обработка трехмерной модели, которая выполняется с помощью геометрического ядра. (Более подробно на тему ядер можно прочитать в серии статей Дмитрия Ушакова: «На ядре», «Геометрические ядра в мире и в России», «NURBS и САПР: 30 лет вместе».) Создание модели изделия — это интерактивный процесс, и инженер не может ждать десяток секунд для завершения определенной операции. Хотя производительность современных коммерческих ядер на большинстве моделей вполне удовлетворительна, известны случаи, когда скорость обработки необходимо увеличить в сотню раз. Технология GPU вычислений могла бы предоставить элегантное решение.

3D модель детали в САПР T-Flex. Используется 3D геометрическое ядро Parasolid (Siemens PLM Software).

К сожалению, на практике всё выглядит не так оптимистично. В статье Джорджа Аллена (Chief Technologist, Siemens PLM Software), представленной на конференции SIAM Geometric Design and Computing в 2007 году, были обозначены несколько характерных проблем, присущих существующим коммерческим геометрическим ядрам:

• Структуры данных и алгоритмы геометрического моделирования реализованы неэффективно для распараллеливания: подразумевают множество ветвей логики для обработки специальных случаев.
• ПО разрабатывалось с конца 80-х годов, и с точки зрения архитектуры никто не заботился о возможном распараллеливании. Разработка параллельных алгоритмов потребует переписывания миллионов строк legacy-кода и фактически разрушит способность к обмену данными с другими системами.
• Модифицировать алгоритмы в индустриально работающем ядре чрезвычайно трудно: пользователи хотят, чтобы результаты операций с моделью были полностью идентичны тем, которые получались 10 лет назад.

Учитывая все эти проблемы и тот факт, что за пять лет с момента выхода этой статьи не появлялось никакой информации об использовании GPU в ядрах ACIS, Parasolid, CGM, Granite One, можно сделать вывод, что соблазнительная перспектива ускорения САПР может произойти лишь в рамках написанного с нуля геометрического ядра.

Приятно отметить, что такие работы, включающие создание параллельных алгоритмов для вычислений с NURBS кривыми и поверхностями, определением расстояния между трехмерными телами и обнаружением столкновений, поиском пересечения поверхностей и кривых, уже плотно ведутся силами российских специалистов.