Про 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 означает, что разогнали на ~35% (верю с трудом) и использовали на 100% (вовсе не верю).

Начал разбираться. Нашел вот это:

Our sample HD7970 reaches over 1.3 TFLOPs in single precision and 200 GFLOPs in double precision.
Теперь другое странно: на двух HD6990 (т.е. 4 чипа предыдущего поколения) лично добивался 1.72 терафлопса на HPL (но там основное - тот же DGEMM), т.е. по 430 GFLOPs на чип, а потом ту же систему довели до 2.053 TFLOPs т.е. по 500 на чип. При теоретической (прямо по AMD-шному сайту) 2x1.37=2.74. То есть эффективность была 75% от теоретической, а ViennaCL гордится 200/947=21%.

Да, то что я мучал полтора года назад - это было написано бодрыми немцами на CAL/IL, ViennaCL - OpenCL, но не должно же быть ТАКОЙ разницы, больше чем в три раза по эффективности?

Если посмотреть на Anandtech-овские тесты Titan GTX, то там для DGEMM приведена цифирка: HD7970 - 689 GFLOP/s и референс на 'Matsumoto et al'. Я поискал и нашел вот эту вот статью (и только потом увидел ссылку на нее прямо у Ананда), из которой получается что 689 GFLOPs - это производительность APPML, а этот самый Мацумото получил over 800 (т.е. вполне разумные ~80% от теоретической, что для одночиповой системы похоже на правду для GEMM).

Анандтеху - незачет (потому что из всех возможных цифирок конкурента - взяли самую маленькую), но про ViennaCL остаюсь в еще более тягостном недоумении, если библиотека от вендора (APPML) дает результаты вдвое выше, чем у Vienna, то чем они там гордятся то?

Еще большая катастрофа происходит с OpenCL-бенчмарками на сильно разной архитектуре (AMD/NVidia).

Вот, к примеру, Luxmark Database.

Luxmark Benchmark, на первый взгляд, очень сильно зависит от производительности double precision. Во всяком случае, 600-я серия NVidia Geforce в этом тесте сильно проигрывает 500-й серии, несмотря на то, что формальные флопсы у GTX680 выше, чем у GTX580 раза в два.

Однако изучение исходников наличия double не показала. Да и сами разработчики говорят, что их там нет.

А если смотреть на результаты в Medium benchmark/Single GPU, то на верхушке будут разогнанные (примерно на 20%) Geforce GTX580, за ними идут HD7970, дальше GTX670, и только потом GTX680 (у которой и юнитов больше, чем у 670, и частота выше, сами юниты - вроде бы одинаковые, bandwidth памяти - тоже одинаковый). Удивительный какой-то парадокс, в случае пары 670/680 - у меня нет материалистических объяснений

Запомним этот результат, потому что это raytracing.

Посмотрим теперь на другие бенчмарки. Вот возьмем CLBenchmark и результаты для HD7970 и GTX680.

Мы видим, что практически по всем тестам, кроме Bitonic Merge Sort AMD рвет NVidia в клочья. И все было бы ничего, если бы не два теста: Global Atomic Add и Local Atomic Add. На AMD локальный (в быстрой памяти) - быстрее раз в 10 (что и ожидается), а на NVidia - наоборот, local add медленее глобального в ~4 раза. Этого не должно быть - а раз оно есть, то это означает какие-то проблемы с кодом (bank conflict, да мало ли). При этом, на GTX480 все выглядит прилично, у local atomics больше попугаев, чем у global.

Смотрим теперь на raytracing: Raytracing у CLBenchmark устроен так, что HD7970 дает вдвое больше попугаев, чем GTX680 и GTX580 - медленнее, чем GTX680.

Вышесказанное - не означает, что CLBenchmark или Luxmark - какие-то плохие. Они - хорошие, просто это - конкретные куски кода, которые "оптимизированы" (в кавычках т.к. собственно оптимизации могло не быть) под разные устройства. В результате, "один и тот же" raytracing в Luxmark получается оптимизированным под NVidia, а в CLBenchmark - под AMD. Думаю что не со зла, просто так получилось.

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

Пока же следует усвоить, что поведение в бенчмарках не означает вовсе ничего. Ну, кроме того случая, когда в production вы будете гонять ровно тот код, что и в тестах.

Comments

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

Не, ну все же эти бенчмарки - они ж хорошие. И Raytracing и Sobel filter и bitonic sort и parallel scan и что там еще есть у CLbenchmark.

Проблема там совершенно в другом. Когда в чип на "3-5-7 млрд транзисторов" напихивают 1500-2000-2700 "вычислительных ядер" - эти ядра получаются совсем уж простые. Сложного предсказания переходов, очень умных кэшей, многих портов исполнения и всего того, что как-то прячет глупость входного кода - там нет.
Наоборот, там очень много плохих особенностей чипа (те же bank conflicts, coalesced memory access - для NVidia) документированы явно и программист должен выпиливать код в обход этих проблем.

Ну и memory bandwidth - она на чип в 5-10 раз больше, чем на CPU, но в расчете на ядро - соответственно в десятки-сотни раз меньше, т.е. лишний поход в общую память стоит очень дорого, гораздо дороже чем на CPU.

А дальше начинается. Вот если на AMD доступно 32k local storage, а на NVidia - 48, то как мы должны делать код бенчмарки, под 32 (чтобы везде работало), под 48 (чтобы на NVidia было быстрее, а на AMD не работало) или вовсе конфигурироваться на ходу - но тогда бенчмарка будет сильно непрямолинейной. ?

А что, 2 млн транзисторов на приличное ядро - это уже совсем мало-мало? Например PPro - 5.5 млн, но там бог знает сколько на внешние интерфейсы, кэши и общесистемные невычислительные штуки (TLB, rings, поддержка 16-bit, что-то еще в количестве). В общем, по идее туда влезает не совсем уж простое вычислительное ядро.

Там кэши, быстрая память, отдельно реализованные fp32 и fp64, аппаратные синусы-косинусы. Прилично набирается того, чего у PPro не было.

Так я про это и говорю. Бенмарка долна решать задачу, при этом точить бенчмарку под железо должен производитель железа.

не думал, что для обработки фоток требуются такие высокие технологии)

GeForce GTX 580 [64 units @ 1800MHz] по ссылке в базе luxmark бенчмарков это что-то странное. Если искать 580 поиском отдельно, то находятся результаты примерно 800-1000 для medium сцены, у них у всех 16 юнитов. Википедия тоже говорит что у 580 -- 16 SMов. Так что luxmark скорее под AMD "заточен", а этот результат скорее outlier, наверно неправильно записанный multigpu.

Про 680 на бенчмарк-сайтах устоялось мнение, что у него урезан compute сознательно, и поэтому он значительно хуже пред. версии. Чтобы продавать титан и теслу.

На luxmark у AMD растет производительность от драйвера к драйверу. На моем 7950 при смене 12.10 драйвера на 13.1, результат на medium sala подскочил с 1700 до 1900 с чем-то. Возможно AMD начали вводить "специализации" под отдельные бенчмарки, как они это делают для игр. На линуксе та же сцена дает почему то только 1200, что неприятно. В целом впечатление от драйверов AMD после длительного использования NVIDIA крайне негативное. NVIDIA может и гады что не дают нам compute и DP, но по крайней мере у них драйвер работает. Из OpenCl related, например, АMDшный драйвер при попытке скомпилировать рендерер blender cycles, драйвер съедает больше 8 гигабайт памяти, и много минут компилирует (не помню успешно или нет). На http://devgurus.amd.com много жалоб на мискомпиляцию, а поддержка линукс драйвера (в целом) просто ужасна. Алсо вот http://techreport.com/review/24218/a-driver-update-to-reduce-radeon-fram... , про то как без специализаций драйвера под игру, у AMD была большая неоднородность в времени рендеринга кадров, из-за несовершенства менеджера памяти, который был недостаточно переделан с предыдущих более простых vliw архитектур, и пока эти журналисты не подняли шум, пользователи играли в запинающиеся игры.

AMD и партнеры планируют развивать Heterogeneous System Achitecture с llvm-derived стандартом, для будущих APU в которых обещано сократить стоимость коммуникации акселератора с CPU. Но хочется чего-то вроде xeon phi,в качестве стандарта распараллеливаемых вычислений будущего, чтобы меньше зависеть от особенностей компилятора, проще предсказывать производительность (в теории).

Про units: у меня нет причин сомневаться в device count у бенчмарки. Чтобы "подать вычисление" на разные devices - нужно специально постараться т.е. сделать это в коде. Если там Nvidia-fans специально не жульничали, то device count - гарантированно правильный.
Кроме того, у меня на GTX480 в свое время получалось достаточно близко к данным из этой базы (поменьше, но не слишком), т.е. оснований не верить ей - нету.

Возможно, тут речь о количестве OpenCL workgroups, которые подаются на карту. Их, по хорошему, должно быть больше чем по одной на SM (зависит от register/shared memory pressure), так оно работает быстрее т.к. латентность глобальной памяти лучше прячется. И 4 workgroup на SM (128 threads) - хорошая величина, хотя я бы и больше пробовал.

Про 680 и compute - я не согласен. В отличие от прошлых случаев (C 260-й по GTX580), когда можно было что-то списывать на маркетинг и специальное урезание DP performance, в случае GK104/GK110 - все честно. Это два разных чипа и у теслы K10 на 104-м чипе - примерно тот же перформанс, что и у GTX680. Ну и как мы теперь знаем из описания титана, DP units - отдельные и отдельно же греются. Т.е. если мы все включим, то должны будем снизить частоту.
Что там было с DP units на предыдущих поколениях - так хорошо не известно. У меня была теория, что SP объединяются попарно, но может быть я не прав и юниты отдельные. И, соответственно, у теслы и geforce тоже были разные чипы.

А драйвера OpenCL - да, отдельный прикол. У всех, не только у AMD.

Если поискать GTX 580 в results search, то находится вот это(там только вариант с 16 units) и это тоже нужно как-то объяснить:

Score Submission Date Scene Name Mode Device Count Device Name(s) User
1049 2013-01-21 05:16:27 Sala GPU 1 GeForce GTX 580 [16 units @ 1880MHz] maximus2
1011 2012-02-16 11:40:27 Sala GPU 1 GeForce GTX 580 [16 units @ 1800MHz]
998 2013-01-14 18:27:52 Sala GPU 1 GeForce GTX 580 [16 units @ 1780MHz] npwski
902 2013-01-21 09:11:02 Sala GPU 1 GeForce GTX 580 [16 units @ 1645MHz] Sielan
899 2012-05-02 23:48:41 Sala GPU 1 GeForce GTX 580 [16 units @ 1564MHz] TekHousE
894 2012-04-10 10:41:45 Sala GPU 1 GeForce GTX 580 [16 units @ 1564MHz] bmt
893 2012-03-16 07:57:02 Sala GPU 1 GeForce GTX 580 [16 units @ 1566MHz] xavstar
892 2012-11-18 08:03:46 Sala GPU 1 GeForce GTX 580 [16 units @ 1564MHz]
885 2012-05-01 04:01:17 Sala GPU 1 GeForce GTX 580 [16 units @ 1566MHz] newnub1
868 2012-01-21 15:06:00 Sala GPU 1 GeForce GTX 580 [16 units @ 1830MHz] npwski

Я изначально засомневался в приведенном по ссылке, потому что оно не соответствовал сформировавшемуся у меня стереотипу что luxmark на любых одночиповых нвидиях хуже чем на GCN радеонах. С чтения вот такого: http://www.tomshardware.com/reviews/geforce-gtx-680-review-benchmark,316... (другая сцена) http://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/17 (smallluxgpu, но это родственное)

Units это наверное CL_DEVICE_MAX_COMPUTE_UNITS , как оно используется в luxmark и влияет на производительность я не представляю. Может быть кто-то внес модификации в luxmark для увеличения утилизации на нвидии...

>т.е. оснований не верить ей - нету.

У меня в принципе тоже, для моей карты Tahiti [28 units @ 900MHz] результаты соответствуют.

>Это два разных чипа и у теслы K10 на 104-м чипе - примерно тот же перформанс, что и у GTX680

Я больше про то, что 680 проигрывает 580 на многих SP compute бенчмарках, согласно анадтекам итп. Сам не тестировал, но это какбе консенсус вроде. Биткоинщики жаловались на отсутсвие 32bit int rotate right инстуркций в нвидии.

>GK104/GK110 - все честно.

Ну у AMD то урезания DP на "дешевых" игровых картах меньше(1/4 theoretical согласно офиц. ист.). Я правда точно не знаю насколько хорошо теоретическое DP у AMD реализуется в практическое. Если, грубо говоря, так же хорошо как нарисовано на бенчмакрах на сайтах по сравнению с 680, то меня как человека интересующегося удешевлением вычислений не должны интересовать разграничения введенные нвидией на игровые и вычислительные карты, "честность", меня должны интересовать SP/DP гигафлопсы (или целочесленные IPSы, в зависимости от задачи) на доллар или ватт, и у AMD на многих реальных задачах(не бенчмарках) уделывает нвидию в плане долларов. Т.е. удешевление за счет геймеров, а не выделение карт в отдельную compute категорию, по крайней мере для single precision. Нвидия с 680 как бы расстраивает.

Интересно кстати, почему титан за $1k с 7 миллиардами транзисторов не так сильно обгоняет в SP и DP (3200 против 2300, и 1300 против 800 согласно мацумото) а иногда и вообще почти не обгоняет http://www.tomshardware.com/reviews/geforce-gtx-titan-performance-review... карту которую можно купить за 400 баксов. Неужели все эти бенчмарки НАСТОЛЬКО flawed. Я конечно понимаю что дополнительные 3 гб памяти не бесплатны, и незаменимы для многих задач, и что архитектура у NVIDIA по идее более гибкая...

Ещё из анекдотов вот например http://wili.cc/blog/gpgpu-faceoff.html Говорит что учитывая стоимость GK110 (от себя добавлю что и GK110 в titan варианте) 7970 выигрывает.

Да, я естественно видел эти варианты с 16 units.
Если недогружать карту (давать в SM меньше threads) - то производительность для большинства kernels будет хуже. Т.е. общее правило - прятать латентность в большом количестве threads.
Еще я увидел, что 64 units - это все на маке. Надо в хакинтош сунуть 480-ю (580-й у меня нет) и посмотреть.

Что же касается "вообще вычислений", то ситуация не столь проста, как кажется. Да, естественно, 6990 выигрывали у современной им Tesla M2070 в разы в гигафлопсах DP на доллар (практическими сравнениями 7970 с K20 я не занимался, а вот с предыдущим поколением - был грех). И на единицу карт тоже выигрывали: c одной 6990 в HPL можно было снять терафлопс в DP, а с M2070 - 500 или 600б не помню уже. Т.е. по цене терафлопса там разница была раз в 10 (или 6, не суть важно).

Но все эти рассуждения не учитывают существенных вещей:
а) технологичность. Теслы - с пассивным охлаждением, ставятся нормально в сервера по несколько штук, выпасание их освоено, включаешь и все работает. 6990 в реальной эксплуатации в многочасовых расчетах - перегреваются и или снижают частоту или просто виснут, много приколов.
б) драйвера (речь про Linux). Тесла просто работает. ATI нужно чтобы были запущены графические драйвера, чтобы на всех картах был бы какой-то виртуальный десктоп (а на винде - и подключенный монитор), это временами странно глючит.
в) Всякие странные хреновины, вроде GPU Direct (обмен данными карта-карта по сети Infiniband, вообще минуя CPU, все по PCIe). Понятно, нужно чтобы софт это умел, но если умеет, это многое облегчает.

г) Софт. Да, для OpenCL сейчас потихоньку начали писать, но вообще процентов 95 рассчетного - это CUDA.
И вот NVidia-библиотеки (и BLAS, и генератор случайных числел, и FFT, и, наверное, CuPP /не пробовал/ и Thrust) - можно брать и пользовать. У AMD с этим все гораздо печальнее: подвижки есть, но медленные. Это я про ситуацию лета-осени 2011, с тех пор с AMD плотно не работал.

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

На фоне перечисленного, разница в стоимости терафлопса, ну там 7970 стоит $400, а K20X - $5000 (а Титан - 1000) - вообще не играет роли. Если вы сами что-то разрабатываете. Потому что разница в цене одной карты, даже K20X против 7970, отбивается месяцем работы разработчика.

А если софт готовый и дописывать его не планируется - то надо его и бенчмаркать. Может оказаться, что там не 1.3-2 раза разница (как между Титаном и 7970 по анандтеху), а в 6 (потому что в пузе живет ViennaCL :)

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

И еще вдогонку:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6...
(не стал скачивать статью, абстракта достаточно)

На трех 7970 добились небольшого превосходства над одним условным титаном. Т.е. электричество втрое, слоты - втрое, а перформанс на 20% выше в DP (чем анандтех намерял) и в ~1.6 в SP.

Когда вы эту экономику попытаетесь поскейлить даже на небольшой датацентр и выясните что вам нужно ~2x по стойкам и по питанию, разница в цене карт перестанет волновать совсем.

> То есть эффективность была 75% от теоретической, а ViennaCL гордится 200/947=21%.
> Да, то что я мучал полтора года назад - это было написано бодрыми немцами на CAL/IL, ViennaCL - OpenCL, но не должно же быть ТАКОЙ разницы, больше чем в три раза по эффективности?

Я как раз ничего удивительного не вижу. Простенький код обычно такую эффективность и показывает (20%).

Не, ну а какой смысл в том что они делают, если вендоровый APPML сильно быстрее?

Никакого. Никто же, находясь в здравом уме, не измеряет общую производительность процессоров на примере собственноручно написанного алгоритма перемножения матриц. Обычно сравнивают, используя библиотеки, у Интела - MKL (для CPU и PHI), у NVIDIA - CUBLAS, у AMD что то еще (для CPU и GPU).

Вот когда мы полтора года назад выжимали терафлопсы из AMD - там речь шла именно о специально написанной (не нами) реализации DGEMM для AMD. Которая CALDGEMM

Это, понятно, бодрые немцы, которые собрали суперкомпьютер на картах AMD. Либо по пьяной лавочке, либо AMD их спонсировало железом. Кем надо быть, чтобы сделать такое за деньги - я не представляю.

Разве у AMD нет своей BLAS библиотеки для их GPU?

Нормальной - не было в тот момент (середина 2011 и чуть позже).

Насколько я помню (но мог и перепутать), была ACML-GPU (плохо совместимая с жизнью) а вот APPML появилась позже и первое время с жизнью тоже была совместима не очень (а потом меня HPC на AMD интересовать перестало :)

вроде эвристически "у амд ALU намного круче, но у нвидии контроллер памяти круче на десятки процентов" всегда работало :)

амд тесты с заточенной memory locality рвут нвидию в разы, а с ее отсутствием наоборот.

короче, железки разные и мерять их как процессоры не выходит, ага

более-менее честный тест на CPU, например HPL, делается примерно так: есть некая реальная задача (СЛУ), она использует некие критические по производительности примитивы (FFT, BLAS), тогда берём лучшую реализацию этих примитивов под данный CPU, запускаем и сравниваем. получается относительно честно. по отдельности FFT, BLAS можно считать синтетическими тестами, но в случае их "реального" использования это уже достаточно практический benchmark.

есть ещё подход SPEC INT/FP с исходными текстами, но он работает только потому, что CPU и их компиляторы всё равно внутренне более-менее похожи. скажем, можно скомпилировать SPEC INT и для CUDA, но результат будет не показательным.

на GPGPU сложнее, аппаратно архитектуры GPU все сильно разные, некоторые реализуют свою API (CUDA), много важных технических ограничений (размеры кешей, буферов, регистры, возможности синхронизации).

вообще, сравнивать FLOPS от GPU и Xeon Phi можно только весьма условно. ибо они сильно разные, как CPU и GPU и FPGA.

Не, ну конечно на GPU сложнее, о чем я и пишу.

Вместе с этим - есть проблема. Допустим, мы пишем программу для end-user и какое у него GPU - не знаем. Если мы при этом еще и под конкретные архитектуры (обе, хотя на самом деле, наверное, десяток) не оптимизируем, то разброс по относительной (относительно пиковой/теоретический) производительности будет чудовищным.

И это, собственно, и есть проблема. "Производительность не переносится"

ох уж эти benchmarks и их цифры, Wikipedia показывает
( теор. скорее всего ) :

Tahiti XT2

GFLOPS (Single-precision) : 4300
GFLOPS (Double-precision) : 1075

http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units...

Ну да, теоретические. 1050 мегагерц * 2048 юнитов * 2 (или 0.5) операции на такт.

Если кому интересно, авторы реализации быстрого кода для MM работают в университете Aizu, где я ещё буду месяц, и завтра кстати у Matsumoto защита докторской
MATSUMOTO, Kazuya
"Design and Performance Optimization of Matrix Multiplication and Shortest-Path
Algorithms on Hybrid CPU/GPU Systems"

Пара реплик по-поводу gtx titan\ tesla k20, тестировал доступные tesla k20m в основном на n-body кодах, пока результаты плачевные. В одинарной точности на уровне gtx670-680, в двойной на уровне старой теслы. Код как cuda так и opencl, и нвидиашный и самописный.
Остается уповать на сырость драйверов под linux.

Про K20: по идее, там все немножко иначе (относительно Fermi) - сами SMX больше (по числу одновременных потоков), регистровый файл тоже больше, shared memory - столько же.
Т.е. все оптимизации - другие.

Ну поиграться с параметрами ещё предстоит, но архитектура k20 близка к удвоенной gtx670 IMHO.
k20 это первая карта начиная с 8800, где плохо работает "правило", попугаи в выводе nbody из cuda sdk примерно равны произведению числа куда ядер на частоту :-)
Для к20 оно примерно вдвое меньше ожидаемого.

Ну так поди этот nbody никто не трогал на тему адаптации к Kepler?

Что у него с occupancy на этой архитектуре?

Думаю код не трогали пару лет.
Тем не менее, на gtx670 работает отлично, который тот же kepler.

Ну да. Но при этом на 670-й 7 SMX на 192Gb/sec memory bandwidth или по 27Gb/sec на SMX.
А на K20X - 14 штук SMX на 250 Gb/sec. Т.е. по 17Gb/sec на SMX. На просто K20 - 16Gb/sec на SMX

Может быть в этом дело (я код nbody не изучал и тем более не профайлил на предмет узких мест)

Не думаю, что в этом дело.
Там n-body довольно простой код с прямым суммированием, число вычислений растёт как n^2, а пересылаемые данные растут ~n, т.е. с определённого n скорость пропорциональна числу ядер, скорость обмена данными нивелируется.

Ну вот bandwidth на ядро в Kepler явно же меньше, чем в прошлых поколениях. И shared mem на ядро - тоже меньше.

Может быть тут и наступает лимит для данной задачи?

Ну придётся играться с параметрами и оптимизацией.
В течении марта-апреля мне будет доступен зоопарк из gtx titan, tesla k20, xeon phi, интересно будет сравнить на одинаковом коде.
Кстати, вопрос не по теме немного.
А имеет ли смысл возиться с opencl например в dcraw?
Я попробовал последний imagemagick + opencl. Мне так и не удалось получить какого-либо выигрыша при конволюции больших изображений на мощных картах. Подозреваю, что декодирование + открытие изображения нивелируют скорость фильтра на GPU.
Аналогично с проприетарным aftershotpro. Есть поддержка opencl, но никакого выигрыша в скорости у меня не даёт, а часто даже тормозит.

Сдается мне, что "одинаковый код" - дело такое, довольно бессмысленное.
Увы, но под каждое железо имеет смысл оптимизировать под его особенности (coalesced access нужной ширины, конфликты банков, относительные тайминги атомиков).

Касаемо OpenCL/CUDA и обработки RAW: проблема в том, что почти нет смысла переносить на акселератор кусочки, даже самые жручие. Ну, может быть, кроме какой-то прожорливой демозаики (AHD и прочая). Потому что в этом случае вы лимитированы скоростью transfer, а она в большинстве случаев относительно небольшая (если мы говорим про average user, то скорее ближе к 2.5-3.5 Gb/sec в каждую из сторон, может быть на PCIe3 стало получше, а на PCIe2 оно так).
И даже в случае dcraw (а особенно - с LibRaw+OpenMP), каждый отдельный кусочек исполняется быстрее, чем эти 2.5-3.5/пополам.

А вот перенести всю обработку, особенно если у вас еще и отрисовка той же видеокартой и вы на последней стадии рендерите в текстуру, которую тут же и покажете - на мой взгляд должно иметь огромный смысл. Но я не пробовал.

Года 2 обратно заглядывал в код ImageMagick accelerate.c функция AccelerateConvolveImage (единственное переложенное на opencl на тот момент). Так вот создалось впечатление, что GPU opencl convolution там в time-domain, а вот как на CPU - не смотрел, но fftw на процессоре он умеет. Может и в этом причина, помимо копирования? Но шибко глубоко не смотрел. Мне хотелось найти opencl реализацию fft и обратно. Там не нашел.
Ну и гляньте darktable. Там много обработки на видеокарту вытащено. Не отдельными функциями, а большими кусками.

Если я правильно помню, OpenCL-реализация FFT есть у AMD.

При этом, драйверу можно (было?) сказать, чтобы он заливаемый на него OpenCL-код дампал в /tmp (или в $HOME, забыл уже). Я так их автотюнящийся BLAS изучал, быстро оттаскивая эти дампы в сторонку.
Но было это все давно.

Ну и у AMD в форумах если покопаться, находится вот такой вот thread: http://devgurus.amd.com/thread/159149

Спасибо
>И еще вот: http://code.google.com/p/tope-fft/
этот хотел попробовать. но git clone у меня сломался на нем. Поэтому прошел мимо.

На AMD смотрел какое то время на форумы. На тот момент были замороки тоже. Не помню уже. Что то типа: оно результат хотело в host memory вернуть, и несколько кернелов создавало (3), в зависимости от размера, и были замороки с работой этих ядер на nvidia. Не помню уже. А сейчас пока хотелка пропала (иметь 3 версии cpu, amd, nvidia). Может когда снова вернется, если cpu вариант задачки заработает как хочется.

Пробовал разные тесты От Viena дествительно есть прок, а от бенчмарков данные полна чушь