Skip to Content

GPGPU

HD7970 Overclock

СР, 02/01/2012 - 18:51 — lexa

Взял в одну руку LuxMark 2.0, в другую - Catalyst Control Center и посмотрел, как оно оверклочится:

  • Позволяемый драйвером максимум т.е. ~20% по частоте процессора (925-1125) и 9% по памяти (1375 - 1500) - совершенно влегкую. Кроме частот - больше ничего не трогал.
  • Попугаи LuxMark растут при этом на 17%
  • Температуру при этом дотянуть до 80-83С удается только минут за 10 (5 запусков бенчмарки подряд), греется мало
  • При такой температуре - вентилятор на половине (автоматическая регулировка).
Для сравнения, GTX480 (ну она горячая по жизни, конечно) нагревается до 90-с-хреном очень быстро и столь же быстро врубает вертушку на полную. Гораздо громче.

Сама по себе бенчмарка, хоть она и многим тестерам уже полюбилась, производит странное впечатление: i7-2600k@4.5 работает на уровне HD5870-HD6970 (~330-350 попугаев на Complex scene). Очень странные цифры, формально у 5870-6970 за два терафлопса в SP и полтерафлопса в DP, тогда как у интеловского горшка ~110 в SP (8x4.5x4) и половина этого в DP. Понятно, что "реальная задача" и вообще реальный мир, но удивительно.

Из LuxMark Database удалось выяснить, что существует какой-то более новый AMD APP runtime (886.1), который процентов на 20 быстрее доступного обычным смертным (851.6). Это хорошая новость, будем ждать.

Про HD7970

Втр, 01/31/2012 - 21:04 — lexa

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

Вкратце:

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

    На примере MatrixMultiplication из AMD APP - быстрее в 4 раза (single).

    С double не все так радужно - нужно явно как-то иначе оптимизировать, а может просто драйвера кривые. На всем что попробовал, 7970 получается непринципиально быстрее GTX480, а на каких-то задачах и помедленнее.

  • Сцуко, холодная. Idle temp 44C, прогреть больше чем до 80 счетным кодом не удалось. Наверное, если получше пооптимизироваться, то удастся подогреть больше. Ноги, короче, не греет.
  • Сцуко, тихая. Ну то есть если вручную вентиляторы поставить на 100%, то громкая, как и любая современная видеокарта со штатным охлаждением, но вышеуказанные 80 градусов были при скорости вентилятора чуть больше 2500RPM, это меньше половины (100% - 5400) и на этой скорости она тихая.
Заодно выяснил, что за тот год, что я туда не заглядывал - AMD'шный гайд по OpenCL стал из вообще никакого - довольно интересным чтением. Сижу, читаю. Про Tahiti там пока мало и невнятно, но какой-то раздел по оптимизации уже есть.

P.S. В игры - не играю, ничего не проверял. С картой был купон на DiRT3, но годный до 31 декабря. Смешно, в продаже они появились за неделю до этого....

P.P.S. Lux Render отчего-то вторую карту не видит, как и 5870 не видел. Все прочие разумные тулзы, вроде clinfo и CPU-Z - видят. Прямо хоть в сорцы лезь....

Грелки для ног и гигафлопсы

Пнд, 01/30/2012 - 09:11 — lexa

У желающих пощупать за вымя свежую архитектуру HD79xx есть два разумных выбора:

  • Купить 7970 сейчас (принципиально дешеветь дальше уже не будет, пока не отрастут конкуренты).
  • Подождать месяцок до реального появления в продаже 7950, которая будет примерно на сотку баксов дешевле.

Чтобы оправдать первый вариант (руки то чешутся), вот такой вот расчет:

HD7970

  • 2048 cores x 925 MHz /2 = 947 GFLOP/s (теоретическая, на double).
  • Рекомендованная цена $550 (и в newegg теоретически за столько можно купить) т.е. 1.72 GFLOPS/$
  • Реальная цена в московской рознице 19000, т.е. 0.0499 GFLOPS/руб.
HD7950
  • 1792 cores * 800 MHz /2 = 716 GFLOP/s.
  • Рекомендованая цена $450 т.е. 1.59 GFLOPS/$
  • Какая будет цена в московской рознице - непонятно, но чтобы сравняться с 7970 по гигафлопсам на рупь, цена должна быть 14400, что крайне маловероятно. А 7970 может еще на тысчонку подешеветь спокойно.

Теоретически, конечно, 7950 хорошо гонится, может быть даже лучше чем 7970. Но практика для предыдуших двух серий Радеонов показывает, что многочасовой расчет на штатной частоте (без снижения) - это уже прекрасный результат и всерьез надеяться на оверклок не стоит. Игры в этом месте менее показательны, они пушат лимитсы меньше, чем любовно оптимизированный расчет.

Короче, моя жаба приведенным выше расчетом - удовлетворилась.

Об AMD 7970 и терафлопсах

СБ, 12/24/2011 - 22:53 — lexa

Я тут, со всей этой суетой предновогодней, пропустил анонс HD7970, сегодня только прочитал.

Очень хотелось, но кажется терафлопса (на DP) на одной карте таки не будет. Т.е. формально там что-то в районе 950 Gflop/s на штатной частоте, вроде можно разогнать где-то до 1100Mhz (а там на DP аккурат один килофлопс на такт: 2048 юнитов, 512 DP-операций, уможаем на 2 т.к. MAD), но маловероятно, что реальная эффективность на DGEMM будет выше 90%, а на HPL - выше 75-80. Потому что оверхед таки есть, на DMA, да много на что (на 6990, например, DGEMM получается эффективнее 90% только если найти те правильные ядра, которые с PCIe наиболее эффективно работают, по меньшей мере на оптеронах жизнь именно так устроена).

А жаль, счастье было так близко! Терафлопс на десктопе - это хороший такой рубеж.

Вместе с тем, интересно, насколько тамошние юниты - скалярны, из имеющихся в сети описаний я так и не понял. Могут ли они исполнять разные инструкции одновременно? Есть ли какие-то ограничения (загрузка из памяти по соседним адресам, например)?

Ибо если они совсем независимы (просто такой multi-core девайс, с регистрами, локальной памятью доступной группе ядер, ну и медленной глобальной памятью) - то это совсем другой разговор.

О вычислениях

ПТ, 12/23/2011 - 22:49 — lexa
Понастраивал тут кластер, добился для 12 нодов эффективности около 70%, на чем (заказчик) и успокоился.

Но все эти дни не отпускала такая вот простая мысль:

  • Вот значит кластер, в нем 7U Blade-серверов (набивка неполная, мест на шасси 10) плюс еще 1U "управляющего фронтенда", OpenMPI, подбор топологии и размеров задачи, чтобы коммуникации и вычислительная моща были сбалнсированы (а уже для 12 нод, без опыта - пришлось повозиться, хотя конечно можно было бы просто оставить подбираться на месяц и помешивать).

    Ну и стоит - не знаю сколько, но так подозреваю, что заметно за $100k.

  • Но те же 1.7 терафлопса получаются на половинке юнита (а добив памяти и увеличив задачу - на той машине уже за 2 Tflop/s получили). Ну ладно, на целом юните, если не увлекаться и просто пихнуть две HD6990 в подходящий корпус. И, по ощущениям, гемороя с отладкой какбэ не меньше. Стоить будет - ну скажем $10k за сервер и еще $2k за две видеокарты.

    Ну хорошо, пусть даже mainstream-решение: 4-GPU-Tesla (1U) и два 1U-сервера. И даже IB (на две ноды - можно без свитча - будет несколько сотен за 40Gbit порт). Но сбалансировать две ноды сильно проще чем 12, я проверял.

    Такой мейнстрим стоить будет тоже не $100k+, а 30-40. Электричества жрать не 6 киловатт, а два. А на 4xTesla те же 1.7 GF

Ну то есть понятно, GPGPU еще не везде мейнстрим, особенно на AMD. Но посмотрев на все это вживую - никакой идеи считать что-то научное на "обычных компьютерах" - у меня больше не возникает.

P.S. С удовольствием приму участие в настройке какого-то кластера с теслами. Чисто за интерес.

О Терафлопсах - 2

ВС, 11/06/2011 - 12:34 — lexa

Алаверды к этому посту 

================================================================================
HPL-GPU 1.1.0  --  High-Performance Linpack benchmark  --   2010
Written by D. Rohr, M. Kretz and M. Bach,  Frankfurt Institute for Advanced Studies
...
================================================================================
...
================================================================================
T/V                N    NB     P     Q               Time    CPU          Gflops
--------------------------------------------------------------------------------
WC26L2C32      124928  2048     1     1             753.87 11956.78       1.724e+03
--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0001192 ...... PASSED
================================================================================

Finished      1 tests with the following results:
              1 tests completed and passed residual checks,
              0 tests completed and failed residual checks,
              0 tests skipped because of illegal input values.
--------------------------------------------------------------------------------

End of tests.
================================================================================

Оборудование то же: 2x AMD Opteron 6176, 128Gb RAM, 2x AMD/ATI HD6990, полтора киловатта питания, 1/2U.

А (почти) полтора раза (в сентябре было 1229 GFlop/s) получаются за счет, блин, "тонких" оптимизаций: точного раскидывания ядер по задачам (эти - только I/O с картой и т.п.), экономии этих самых ядер т.к. часть вычислений делается на CPU и так далее...

В сравнении с Fermi, получается сильно дешевле, сильно компактнее, но много более сексуально в программировании.

P.S. Больше подробностей - не раньше декабря.

Про AVX и OpenCL

Втр, 09/27/2011 - 15:04 — lexa

Вчера вышел 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, нашел даже один vandps ymm1,ymm1,[memory], но в подавляющем большинстве код - 128-битный.

Он и в прошлой версии был 128-битный, но какой-то более человеческий.

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

Ну то есть понятно, производительность не переносится, но 2-3 раза просадки - это беспредел.

Единственный пример, который стал быстрее, называется Histogram. Но его и старая версия отказывалась векторизовать (немудрено) и новая тоже не хочет.

О Терафлопсах

Пнд, 09/12/2011 - 21:55 — lexa

Для истинных ценителей: 

================================================================================
HPL-GPU 1.1.0  --  High-Performance Linpack benchmark  --   2010
Written by D. Rohr, M. Kretz and M. Bach,  Frankfurt Institute for Advanced Studies
Based on:
HPLinpack 2.0  --  High-Performance Linpack benchmark  --   September 10, 2008
Written by A. Petitet and R. Clint Whaley,  Innovative Computing Laboratory, UTK
Modified by Piotr Luszczek, Innovative Computing Laboratory, UTK
Modified by Julien Langou, University of Colorado Denver
================================================================================
...skip...
================================================================================
T/V                N    NB     P     Q               Time    CPU          Gflops
--------------------------------------------------------------------------------
WC06L2C64      122880  2048     1     1            1006.60 8742.71       1.229e+03
Avg. matri size per node: 112.50 GiB
--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0002429 ...... PASSED
Это один узел кластера, а не кластер; не Nvidia; прочие подробности я пока раскрывать не уполномочен. Через месяцок.

Но штука получается забавная. И хочется надеяться, что цифирка в правой колонке еще далека от окончательной.

P.S. Троллинг: в тред призывается поисковая команда Яндекса, получившая на 400 узлах в 600 раз меньше. Правда два года назад.

P.P.S. Это, естественно, двойная точность.

О нагреве видеокарт

Пнд, 09/12/2011 - 09:07 — lexa

Читаю доку (техрепорт) к CALDGEMM и внезапно вычитываю такое (по смыслу, не близко к тексту):

  • в readme: ключ -f заливает входные матрицы нулями, а не случайными данными, отчего инициализация проходит быстрее (ну да, попробуйте 60Gb random нагенерировать).
  • в техрепорте: если входные матрицы нулевые, то конструкция сильно меньше греется т.к. в результате вычислений не меняется ни одного бита памяти.

Ну, собственно, так и есть, проверено на себе: с минус -f все работает как из пушки, а без оного - уносит нафиг, если вентилятор заранее не раскрутить (время реакции системы термосенсор - думатель - вентилятор недостаточно, нагрев практически мгновенно происходит).

Остается понять - это нулевые биты меньше греются или достаточно того, что содержимое не меняется?

I like to move it, move it

СР, 08/17/2011 - 19:18 — lexa

Мониторю всяческие новости про OpenCL, CUDA и прочие GPGPU и в последние дни просто засыпан новостью про то, что GEGL is getting GPU-based image rendering and processing.

Довеском к этой новости идет ссылка на OpenCL on GEGL: Results up to now, где сравнивается реализация brightness-contrast фильтра на CPU и на GPU (и не каком-то, а Tesla 2050 ценой 2 килобакса) и получается для 1-мегапиксельного изображения:

  • 526 msec на CPU
  • 483 msec на GPU
Просто гигантский выигрыш, почти 10% !!! Притом, как я понял (может быть и неправильно), во время исполнения на GPU не посчитана пересылка "обратно", с карты в RAM.

При этом, заметим, на CPU оно работает на одном ядре (хоть и на SSE2), а значит на 4 ядрах оно банально будет быстрее разика в три.

Причина тривиальна и прямо в том блог-посте описана, весь пар ушел в свисток, а все время исполнения - на пересылку данных. Собственно исполнение обработки на GPU занимает около 1/10 всего времени.

При этом, само время исполнения - чудовищно. Полсекунды на 1 мегапиксель, даже если пиксели 16-байтные (4 float) - это 32 мегабайта в секунду. Э.... По PCIe обычно ходит 4-5 гигабайт/сек..... Проблема, судя по всему, кроется в тайлововой организации картинки в GEGL, тайл при этом мелкий (128x64) и даже на CPU обрабатывать их эффективно не получается, что уж говорить про GPU, где под каждый тайл аллоцируется текстура.

На эту тему имею рассказать следующую историю:

Об Intel ISPC

Пнд, 06/27/2011 - 19:15 — lexa

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

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

  1. void vector_sum(uniform float in[], uniform int count, reference uniform float out[]) {
  2.     float sum = 0.0;
  3.     for (uniform int i = 0; i < count; i += programCount) {
  4.         int index = i + programIndex;
  5.         sum+= in[index];
  6.     }
  7.     out[programIndex] = sum;
  8. }
И оно у вас пойдет фигачить шириной programCount, ну там дальше надо будет элементы out просуммировать уже снаружи.

Об Intel OpenCL

ЧТ, 06/23/2011 - 22:48 — lexa

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

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

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

И вот что я вижу:

  • CPU-вариант при компиляции Visual C++ 2008: 389 msec на исполнение. Это без processor-specific оптимизаций и без распараллеливания.
  • OpenCL-вариант: 15 msec.
В 26 раз быстрее, однако.

Ну ладно, VC++2008 - не самый новый, да и процессора моего не знает. Переключаю компилятор на Intel C++ 12-й версии (который Composer XE), включаю оптимизацию для AVX, уже лучше: 151 msec. Но тоже в 10 раз.

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

СБ, 05/07/2011 - 21:23 — lexa

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

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

Берем AMD-шный пример BitonicSort из APP SDK 2.4 (это AMD-шный SDK для GPGPU) и запускаем, без перекомпиляции, прямо на всех имеющихся в машине девайсах и реализациях. Сортируем 16 млн. элементов. В порядке падения быстродействия:

  1. Intel OpenCL (процессор i7-2600k @4.5Ghz): 10.6 сек.
  2. NVidia OpenCL (GTX480, драйвер 270.61): 16.4 сек.
  3. AMD OpenCL (Radeon 5870, драйвер 11.4): 29.3 cек.
  4. AMD OpenCL на CPU (тот же самый): 415 сек.
Я подозреваю, что AMD-шный OpenCL в случае CPU просто процессор не опознал и сгенерировал код для 8086 или что-то вроде этого. Для CPU AMD Kernel Analyzer показывает нам невекторизованый код, т.е. процессор не опознался и что под него генерировать AMD не знает. На предыдущем процессоре (i7-920) такой разницы с интеловским OpenCL (тогда он был в первой альфе) не было. При этом, при исполнении на AMD-OpenCL процессор загружен где-то на четверть, а "под интелом" - на 100%

Прикол тут в другом: по формальному быстродействию горшки ранжируются в обратном порядке: у AMD бешеные 2 терафлопса на float (по пресс-релизу AMD: 2.7 TFLOP/s), у NVidia - раза в два поменьше (в районе 1.35 TFLOP/s если формально считать), у CPU же, даже если AVX посчитать как 16 операций на такт (две AVX-операции на такт) получается 16 x 4 ядра x 4.5 гигагерца = 288 GFLOP/s.

Понятно, что сортировка - дело такое, для потоков плохо предназначенное.

Чтобы два раза не вставать: большинство AMD-шных примеров на GTX480 работает быстрее (и лишь некоторые - незначительно медленнее), чем на HD5870. Несмотря на формальные попугаи, говорящие об обратном. Обратного, чтобы OpenCL-примеры NVidia работали бы быстрее на AMD, - не наблюдается.

Update: Помучал тот же пример на машине с i7-920 и GTX280. AMD OpenCL/CPU никуда не годится и там, увы. Может быть надо kernel как-то иначе писать. Что же касается реализаций Intel (CPU) и NVidia (GPU), то на этой паре железок и BitonicSort они работают практически одинаково по скорости.

О термоинтерфейсах

СР, 04/20/2011 - 16:01 — lexa

Экспериментально выяснил, что термопаста на NVidia GTX280 за 2.5 года высыхает. Из этих 2.5 лет оно где-то с год лежало на полке, остальное время работало. Сейчас вот снова достал и на тебе.

Измазал туда тюбик термопасты (там один радиатор на полтора десятка чипов), вроде попустило.

640 килобайт таки мало

СБ, 03/27/2010 - 13:04 — lexa
Капитан Очевидность Я в свое время почти угадал.

В том смысле, что я предсказывал 64-битную адресацию, она физически стала 40-битной. Хотя размер индекса в одном массиве остается 32-битным (собственно длинных int нету).

А так - забавно наблюдать, как оно эволюционирует. Нет, вполне разумно, но видно что первоначальная идея много очень простого железа оказалась слишком идеалистичной. Вот кэши на глобальную память добавили, притом сразу два уровня (был текстурный кэш L2, впрочем).

Сама же G200 GF100 (представленная вчера в виде GTX470/480) выглядит черезвычайно вкусно. Всяких текстов в сети навалом, сам я отпишусь когда куплю, жевать чужие тексты довольно бессмысленно.

NVidia Nexus и VMWare

ЧТ, 02/04/2010 - 19:36 — lexa

Зря я мудохался связывался с мультизагрузкой Mac OS и Windows, работать все едино было неудобно (мониторов на все не хватает), поэтому потратил еще час-другой и асилил:

NVdia Nexus: работа из виртуальной машины

Если в двух словах, то требование "или два компютера, или один но с двумя видеокартами G92/G200" - слишком жесткое, достаточно одной G92/G200 и второй - любой.

Курс по NVidia CUDA для всех желающих (Москва)

ПТ, 01/22/2010 - 19:11 — lexa

В прошлом году я прощелкал, а в этом - нет, успеваю анонсировать.

С 24 февраля по 12 мая, еженедельно, по вторникам, на ВМиК МГУ (Москва, Воробьевы горы, м. Университет) будет читаться курс программирования NVidia CUDA для всех желающих.

Процитирую из анонса:

Московский Государственный Университет им. М.В. Ломоносова совместно с компанией NVIDIA приглашает заинтересованных студентов пройти специализированный курс "Архитектура и программирование массивно-параллельных вычислительных систем" на основе технологии CUDA. В рамках курса вы узнаете о современных многоядерных архитектурах, моделях программирования и основополагающих принципах, лежащих в основе построения эффективных параллельных алгоритмов. Вы также познакомитесь с реализациями типичных алгоритмов и задач, возникающих в цифровой обработке сигналов, математическом моделировании и гидродинамике. По окончании курса вы сможете применить свои знания на практике уже сегодня при решении вычислительноемких задач в ваших курсовых и дипломных работах. Приобретенные знания необходимы для всех, кто планирует связать свое будущее с высокими технологиями и высокопроизводительными вычислениями. Всем студентам, успешно завершившим курс "Архитектура и программирование массивно-параллельных вычислительных систем" будут выданы дипломы.

AMD/ATI и GPGPU

Втр, 01/12/2010 - 22:50 — lexa

Я как-то не уследил, потому что 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 вообще не поддерживает никаких видеокарт, смешно.

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

ВС, 12/20/2009 - 20:40 — lexa

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

ЧТ, 06/04/2009 - 11:39 — lexa

Во-первых, сравнение производительности в предыдущем посте неверное. Действительно 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

ВС, 05/24/2009 - 11:02 — lexa

После появления первой доступной реализации 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.

Угадал, блин

СР, 05/13/2009 - 11:59 — lexa

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

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

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

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

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

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

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

Втр, 04/21/2009 - 09:20 — lexa

Пресс-релиз от 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 мне, помимо потенциальной многоплатформенности, люба трансляция из исходников на лету, у меня столько идей....

NVidia GTX280: бенчмарки с плавающей точкой

ПТ, 12/26/2008 - 11:05 — lexa

gtx280.jpg Каждые полгода мы с друзьями я бенчмаркаю вычисления на видеокартах. В этот раз изучалась NVidia GTX280.

SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.

Понятно, что Core i7 разницу несколько сократит, но по тем бенчмаркам с плавающей точкой, что я видел (а видел я пока только Linpack, причем не факт что в оптимальном для i7 виде), рост в производительности i7 - процентов 20.

Всякие соображения про масштабируемость решения - в самой статье.

gtx280.jpg Каждые полгода мы с друзьями я бенчмаркаю вычисления на видеокартах. В этот раз изучалась NVidia GTX280.

SGEMM/DGEMM на видеокарте и CPU, серия 7: NVidia GTX280
В чипе NVidia G200 появились операции с двойной точностью. Их производительность не феноменальна, но даже с учетом ввода-вывода данных в карту GTX280 обгоняет 4-ядерный 3-гигагерцовый Penryn. Если же рассматривать только скорость вычислений (что актуально, если задача позволяет спрятать затраты на ввод-вывод), то на двойной точности видеокарта быстрее CPU в 1.8 раза.
На одинарной точности разрыв видеокарты и CPU вырос: GTX280 обгоняет Core2Quad впятеро.

Понятно, что Core i7 разницу несколько сократит, но по тем бенчмаркам с плавающей точкой, что я видел (а видел я пока только Linpack, причем не факт что в оптимальном для i7 виде), рост в производительности i7 - процентов 20.

Всякие соображения про масштабируемость решения - в самой статье.

AdobeLabs PixelBender: отличная штука, но....

ПТ, 12/12/2008 - 15:29 — lexa

Что-то я анонс пропустил, а сегодня случайно наткнулся на Pixel Bender от Adobe Labs.

Казалось бы, отличная идея: пишешь шейдеры kernels на скриптовом языке, они исполняются на видеокарте или на CPU. Анонс тоже завлекал: дескать поддержвается любая разрядность цвета, все такое мультиплатформенное и хорошее. Есть плагин для Photoshop т.е. все изыски можно прямо в бою и использовать.

В-общем, я раскатал губу, скачал, поставил, закатал рукава и приготовился творить.

Syndicate content


.