OpenCL

Про OpenCL-бенчмарки (опять, да!)

Злоба на эту тему у меня копится и периодически выплескивается.

История первая

В Mac OS X 10.8.3 поапгрейдили драйвера NVidia и у NVidia 6xx в LuxMark стало в полтора раза меньше попугаев.

Предполагая, что бенчмарка - нормальная (т.е. меряет время выполнения, никак его не нормализуя на конфигурацию железа), давайте попробуем разобраться что случилось:

  • Было (драйвер репортил): 28 юнитов
  • Стало: 7 юнитов (более широких, но не суть)
Само железо не изменилось. Мог, конечно, измениться (ухудшиться) OpenCL-компилятор, но у меня предположение другое: само приложение, увидев меньше юнитов, задает размеры грида (количество одновременно исполняемых Workgroups) поменьше. От этого происходит худшая утилизация железа (ну там латентность памяти не прячется) и уменьшаются попугаи. Проверить нетрудно, но лень читать исходники.

История вторая На Tomshardware большой тест скорости работы Titan GTX на вычислительных задачах.

Что мы видим:

  • На OpenCL-тестах: Titan в некоторых случаях хуже, чем 580GTX (и лишь незначительно лучше, чем 680GTX), а в некоторых - хуже 680GTX (у которой, заметим, поменьше юнитов и вообще всего поменьше при примерно той же архитектуре).
  • На CUDA-тестах: Titan всегда лучше всех, а вот второе место может быть как у 580GTX (двойная точность?), так и у 680GTX
CUDA - дает ожидаемые результаты (Titan ожидаемо быстрее всех), а с OpenCL - привычный бардак.

В очередной раз хочу сообщить, что тестировать один и тот же OpenCL-код на разном железе (без специфичных оптимизаций под конкретное железо) - бессмысленно.

Про Intel и OpenCL

И вторая за сегодня новость про OpenCL.

Вышел интеловский SDK (SDK for OpenCL Applications 2013 Release). А там, кроме всего прочего такое вот:

Support in dual adapter mode on Windows* 8: enables OpenCL workloads to be accelerated on Intel HD Graphics when the device is not directly connected to a display and fully enabled running Intel driver.
Я осуждаю то, что это только для Win8, а сам факт - одобряю. На Ivy Bridge/Haswell можно будет посчитать что-нибудь эдакое без чудовищного оверхеда по копированию по PCIe (а, всего-лишь, с небольшим оверхедом на double buffering :)

Про OpenCL-бенчмарки

Давно копил в себе злобу желание про это написать, а тут вот появился повод.

Вот есть такая ViennaCL, пакет линейной алгебры для "вычислительных ускорителей" (приходится писать так потому что Xeon Phi). На днях вышла версия 1.4.1 и про нее написано:

...and features a GEMM kernel reaching more than 1.3 TFLOPs on an AMD HD7970.
Я призадумался, как такое может быть, ведь HD7970 - это чуть меньше терафлопса на стандартных клоках, ну гигагерц-edition, но 1.3TFLOPs означает,...

Про HD7970

Договорился с жабой и купил новую грелку для ног.

Вкратце:

  • OpenCL 1.1, поддерживается, работает. Посмотреть что там за код не получается, Kernel Analyzer не умеет это место.
  • Драйвера: под винды есть, бета, в основной Catalyst не включены (и, похоже, войдут не раньше чем в 12.3 т.е. через два месяца т.к. даже в 12.2-preview поддержки 79xx нет). Драйвера под линукс поискал для проформы (мне не надо) - и не нашел.
  • Сцуко, быстрая. Один и тот же OpenCL-код (написанный
  • ...

Про AVX и OpenCL

Вчера вышел Intel OpenCL SDK 1.5 с соответствующим анонсом: Increase OpenCL application performance with the new Intel OpenCL SDK 1.5

Пытаюсь enlarge increase эту самую performance, сую в бензопилу лом туда AMD-шные примеры, которые на предыдущей версии работали очень бодренько (и временами почти догоняли AMD-шную видеокарту) и вижу замедление в 2-3 раза для половины примеров.

Начинаю читать код и не вижу там 256-битности. Ну, почти не вижу. Кое-где есть 256-битные load/store, нашел даже один...

Об Intel ISPC

Интел выкатил в опенсорс такую вот игрушку: Intel SPMD Program Compiler.

Это очередная попытка придумать параллельный язык C: пишете некую функцию, к примеру, обрабатывающую элемент данных, варез сам строит SIMD-представление (SSE, AVX), которое обрабатывает 4(8) элементов за раз. Ну как-то так:

void vector_sum(uniform float in[], uniform int count, reference uniform float out[])
...

Об Intel OpenCL

Щупаю тут за вымя Intel OpenCL (для CPU) и эта игрушка мне все больше нравится.

Помимо оффлайн-компилятора (который выдает ассемблер или LLVM-код) эту хреновину можно профайлить при помощи VTune (нужно пару переменных окружения поставить, см. доку).

Беру я, значит, прямо тамошний пример MedianFilter и начинаю профайлить. Он содержит "CPU"-реализацию (в том смысле, что компилятор C++ ее превратит в обычный код) и OpenCL-вариант (который будет скомпилирован на лету). Обе реализации имеют настолько одинаковый C/C++ код внутри, насколько это...

Не все йогурты одинаково полезны

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

Более того, реализаций для CPU уже две на виндах: AMD-шная входит в состав ATI Catalyst (драйверов для видеокарты) и даже при отсутствии подходящей видеокарты эта часть драйверов поставится. Кроме того, Intel-овский OpenCL на днях перешел из стадии альфа в бету. На Linux, кстати, есть еще IBM-овский OpenCL для CPU, все руки не доходят его ощупать.

Берем AMD-шный пример BitonicSort...

AMD/ATI и GPGPU

Я как-то не уследил, потому что AMD/ATI-шными видеокартами начал интересоваться с выходом HD5xxx, а оказывается все очень весело. На gpgpu.ru это уже пообсуждали, ну я сюда наброшу, в более концентрированном виде.

Раньше высокоуровневым средством для разработки считалок на видеокартах у ATI был Brook+. Однако начиная с какой-то беты ATI Stream SDK 2.0 Brook из SDK исчез.

Читаем в ATI-шном форуме (это август-2009):

Yes, this SDK 2.0 beta is for CPU only. It focuses on OpenCL 1.0 for CPU. Brook+ is now available on SourceForge: http://sourceforge.net/projects/brookplus

Ну ладно, Stream SDK Beta-1 вообще не поддерживает никаких видеокарт, смешно.

Коня и трепетную лань

opencl.jpg Мучал ATI Radeon HD5870 и NVidia GTX280 в одной машине на предмет взаимной поддержки OpenCL. Поддерживают. С оговорками, но жить можно. Написал на эту тему небольшой текст:

OpenCL, NVidia, ATI и все все все....

В процессе читал AMD-шные форумы, вычитал страшного, много думал:

OpenCL performance issues
There are known performance issues for HD4XXX series of cards on OpenCL and there is currently no plan to focus exclusively on improving performance for that family. The HD4XXX series was not designed for OpenCL whereas the HD5XXX series was. There will be performance improvements on this series because of improvements in the HD5XXX series, so it will get better, but it is not our focus.

For example, if you are using local memory, they are all currently emulated in global memory. So it is possible you are going out to main memory twice as often as you do on NVidia. This can cause a fairly large performance hit if the application is memory bound. On the HD5XXX series, local memory is mapped to hardware local and thus is many times faster than the HD4XXX series.

Короче, слушайте вашу группу валенки. Формально OpenCL на HD4xxx поддержан, а фактически нужно совершенно другой kernel писать, который локальную память не использует.

А 48xx - важный кусок рынка, их много навыпускали и формально они совсем неплохие. Теперь и в этом сорте не скажу чего придется разбираться. Хорошо хоть про 2xxx/3xxx просто рекомендовано забыть.

P.S. Сравнивая два SDK, видно что ATI в области GPGPU очень заметно отстает (disclaimer: это лично мое мнение по результатам одного дня изучения :). Речь именно о качестве SDK: документации, примерах и тому подобных вещах.

CUDA vs OpenCL

Во-первых, сравнение производительности в предыдущем посте неверное. Действительно nBody/CUDA показывает 320+ GFLOP/s (на 280GTX), но это при количестве частиц в 32к. А при 8к - вдвое меньше, около 159 GFLOP/s.

Во-вторых, в свежих бетах (вчера вышла Beta 1.2) NVidia OpenCL производительность или самого примера или компилятора или обоих - тоже подтянули и сейчас на 8к частиц oclNBody показывает 129 GFLOP/s. Что уже вполне объясняется тем, что картинку для показа приходится гонять между OpenCL и OpenGL буферами.

Мораль: под OpenCL уже вполне можно девелопить, с тем чтобы когда все это счастье появится публично - уже быть готовым.

NVidia: CUDA и OpenCL

После появления первой доступной реализации OpenCL (доступна для зарегестрированных NVidia-девелоперов с девелоперского сайта) все кинулись смотреть (и я тоже).

Накопали всякого интересного:

  • Бинарное представление OpenCL-кода - это практически CUDA PTX (ссылки: PDF-текст про это, ветка форума к которой этот текст относится).
  • Возможно подсовывание PTX-кода от CUDA в OpenCL (ссылки те же), смысл может быть в использовании тех CUDA extenstions, которых нет в OpenCL. Правда, при этом можно использовать просто CUDA т.е. смысла не очень много.

Кроме того, многих фишек CUDA просто нет в текущей реализации OpenCL, что огорчительно:

  • Нет работы с mapped pinned memory (что появилось в CUDA 2.2). Т.е. требуются пересылки в память видеокарты даже там, где эта память - на самом деле системная память (ноутбучные видеокарты), да и вообще без пересылок удобнее.
  • В CUDA есть взаимодействие с OpenGL, в OpenCL - нету (в спецификации есть, но пока не поддержано). В результате, пример nbody в OpenCL-реализации работает вчетверо медленнее на GTX280 (80GFLOP/s вместо 320), ибо весь пар уходит в пересылку результата на хост, а с хоста - на отрисовку.

Вообще, со всеми этими extensions все выглядит пока весьма огорчительно. Даже если они появятся в условном OpenCL 1.1+, придется писать по варианту программы под каждую видео-архитектуру. И на текущем разнообразии железа не видно выхода, слишком оно разное, чтобы из одной программы компиляцией получались эффективные решения под ATI и NVidia одновременно.

Простые юнит-тесты еще не делал, руки не дошли, пока только смотрел код из SDK.

Update Похоже, про nbody товарищи не правы. Т.п. в oclNBody какая-то работа с OpenGL objects есть. Либо недоделано, либо просто NBody нужно под OpenCL делать как-то иначе.

Update2 Предыдущий апдейт неверен, ибо (согласно Release Notes): 2. OpenCL - OpenGL Interop is not supported.

Угадал, блин

Довелось оказаться пророком.

В комментариях к записи про анонс NVidia работающего OpenCL я предположил, что

Конечно, сейчас начнется, они вполне могут начать с драйверов для Линукса (или для 32-битной XP, что от меня столь же далеко)
И угадал, блин. Именно XP-32 и Linux-32. XP-шные бинарники на Висте не работают, несмотря на драйвер нужной версии, ругаются что не могут создать OpenCL context

А у меня Vista (32/64) и MacOS. Ну в Маке, ладно, обещали в заснеженном леопарде, а с вистой что? Руки же чешутся....

На закуску: согласно спекам OpenCL, его можно/нужно кормить исходником прямо на этом самом OpenCL (а это практически C). То бишь компилятор этого самого C сидит прямо в драйвере....

Интересно, насколько успешно это пойдет в индустрию, ведь получается что computing kernel засекретить не выйдет, можно же подсунуть приложению драйвер похожий на настоящий и почитать им исходника. Видятся мне OpenCL-обфускаторы.

Пеар и моркетинг

Пресс-релиз от NVidia, фанфары:

NVIDIA Corporation, the inventor of the GPU, today announced the release of its OpenCL driver and software development kit (SDK) to developers participating in its OpenCL Early Access Program.
....Developers can apply to become a GPU Computing Registered Developer at: www.nvidia.com/opencl

Ну ладно, иду и apply, мне несложно.

Заполнил форму и думаю, что надо заглянуть в уголок CUDA-девелопера (только для бе.. туда нужно тоже через Application, я больше двух лет назад вписался), вдруг там что новое.

Ага, есть новое:

Looking for OpenCL drivers?
You are in the right place. Registered developers with access to this web site will receive an email notification as soon as our Beta drivers are ready.

Маркетинг отстрелялся, а осадок у меня остался.....

А в OpenCL мне, помимо потенциальной многоплатформенности, люба трансляция из исходников на лету, у меня столько идей....

Subscribe to OpenCL