Свежие комментарии

Я очень сомневаюсь, что для NV и для AMD подойдет один код и он даст "50%" от теоретической. Ну если только весь #ifdef-ами облепить.

Вот есть AMD-шный же OpenCL BLAS и FFT (без исходников), но я его не щупал за ненадобностью. А их же родной acml-gpu на их же родной 5870 50% от теоретического пика не набирает. Набирает 40.

Так дропнут саппорт в драйверах. Они ж свой новый язык готовят. А пока его нет, низкоуровнево писать не на чем.

Я тоже не видел шустрого DGEMM на OpenCL. Но я и не искал особо. Мне так кажется, написать что-то в районе 40%-50% от теоретической мощности даже я смогу. Один код для обоих производителей GPU. А 90% - это уже крайне маловероятно.

Так caldgemm не линкуется ни с одной библиотекой из SDK. Ему из SDK нужен только cal.h. А библиотеки - от драйвера. И хрен их подропаешь просто так, поломается совместимость тут же.

На OpenCL, насколько я знаю (мог что-то пропустить), разумного DGEMM пока нет.

Ну так да - там реально дохрена кода написано именно для поддержания одновременности работы всех деталей системы (CPU-GPU-DMA)

Но шейдеры там - compute. И сами шейдеры - относительно простые, от всего написанного кода DGEMM - процентов 10 кода (в байтах). А в остальных 90% творятся всякие ужасы. И драйвера патчить надо (хотя в моих тестах я пока разницы не увидел, но у меня узкое место в CPU)

Вот, нашел: http://developer.amd.com/afds/assets/presentations/2909_1_final.pdf

Там у них своя версия HPL, кстати. И умножают они просто огромные матрицы, которые в память GPU целиком не помещаются.

А с остальными Вашими замечаниями я согласен, да.

А разве в pixel-шейдерах есть double? Я просто не в курсе...

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

Я пытаюсь донести ту мысль, что отдельное "очень быстрое умножение матриц" (или "элементарная операция с изображением") - это хорошо, но мало. Ну вот стандартный HPL, даже с довольно быстрым DGEMM оказывается ограничен в другом месте. Если бы DGEMM был бы бесконечной скорости, то весь HPL получился бы ~140GFLOP/s. Ну и с картинками: делаем буквально пяток операций, должны упереться в bandwidth памяти видеокарты (100-150Gb/sec) или, в крайнем случае, в bandwidth PCI-e (4-6Gb/sec, пусть пополам), а реальная производительность В СТО РАЗ меньше.

А чтобы получить эффективную реализацию - надо или *все* перенести на GPU (что затратно, дохрена кода придется написать, втч и такого, который на GPU работает неэффективно, скажем с ветвлениями на каждом элементе вектора/матрицы), или написать реально сложное приложение. Вот CALDGEMM, который написан для HPL-GPU: там реально дохрена напрограммировали, вроде балансирования нагрузки (Multi-)GPU/CPU и так далее. ~200kb кода на умножение матриц (а казалось бы, три вложенных цикла, 6 строчек...).

Я читал недавно презентацию о, пожалуй, самой эффективной реализации DGEMM на AMD GPU. Помнится, там было порядка 90% от теоретической производительности. Использовался не Compute, а Pixel шейдер. А самое интересное то, что не использовалась локальная память. Много потоков практически полностью скрывали кешированный доступ к глобальной памяти. Мне кажется, это сейчас самый энергоэффективный способ умножать матрицы.

только это сложно, нужно перепрограммировать ==> только это тоже нужно программировать (редактирования каментов у меня нет, я жадный).

Ну и раз уж пишу доп-коммент.

Мой поинт в том, что для картинок какого-то разумного размера (с монитор, 1-4 мегапикселя) GPU нахрен не нужен. Но нужно, конечно, аккуратно повыпиливать хотспоты, а не просто все на прямолинейном C запрограммировать.

Ну так это a) alfa-preview версия технологии которая b) работает в самых невыгодных для нее условиях. И все равно оно уже быстрее.

Допишут, дотюнят, и будет раз в 5 разницы, как и положено.

PS: Мне вот вообще интересно, теоретически "Photoshop" все картинки может базово держать на видеокарте, если памяти хватает, и все алгоритмы отображения и обработки туда засунуть. Тогда memcopy только при Open/Save будут ну или на гигапиксельных картинках.

PPS: они 400msec копировали 1 мегапиксель туда-обратно? Там точно есть место для улучшения.

Совсем будет интересно, когда опенсорсный OpenCL допилят (который clover).
Его в рамках gsoc клепают, правда там пока только CPU имплементация (llvm/jit), а GPU обещают сделать "потом" (используя кодогенераторы из mesa)

+100500

Сегодня поперхнулся, получив такую SMS.

Ну вот они мне на днях звонили и предлагали перейти на VIP-обслуживание. В другом офисе, хотя тоже близко.
Сдается мне, что при этом все потроха клиента как-то перетаскиваются.

Особенно прикольно эту смс получать тем кто-таки ПОЛЬЗУЕТСЯ мобильным банком :)

Из карточек с процентами на остаток есть Связной с их 10%. Дать им денег в пределах лимита страхования вкладов - вполне можно, как мне кажется.

А в остальном - никак специально не управляю. Если "управлять", то будешь только этим и заниматься.