CUDA vs OpenCL
Решил попробовать CUDA.
Были большие ожидания, мол должен быть клевый язык с фишками, плюшками, интеграцией в VisualStudio.
Но с 2015 где update > 2 не работает, хм, ладно поставил 2013.
Отладка не заработала из коробки ( может ее и нет вообще
И еще был дико возмущен необходимостью писать вот такой код:
__global__ void addKernel(double3 *c, const double3 *a, const double3 *b)
О новое тысячелетие! О космические корабли!((
После этого мираж о суперудобной куде растворился совсем(
Теперь смотрю в сторону брутального OpenCL, уж если брутализировать то шоб прям соусем !
Какие у CUDA нынче плюшки по сравнению с OpenCL?
Пока только одну нашел — студия подсвечивает ошибки в коде
Что еще?
#1
5:59, 12 авг 2016
Куда — это более зрелая технология с достаточно развитым toolchain разработки. Большие научные сообщества как правило предпочитают использовать Куда (не в последнюю очередь ввиду того, что NVIDIA инвестирует в данную технологию и под неё есть вагон библиотек). В OpenCL есть совместимость с устройствами помимо видеокарт NVIDIA и пользоваться ей чуть менее удобно. В целом же, обе технологии очень близки друг к другу. Писать эффективный код и под так, и под другую сложно.
#2
10:15, 12 авг 2016
Arxon
> Какие у CUDA нынче плюшки по сравнению с OpenCL?
Практически никаких 🙂 Возможно может наличие более удобных тулзов. Но Это все спорный момент, для AMD есть CodeXL. С учетом того что возможно новые разработки будут писаться на OpenCL и он на некоторых задачах OpenCL на AMD рвет CUDA на nVidia. Для будущего я бы выбрал OpenCL поддержка всех видеокарт в отличие от nVidia это больший плюс.
#3
12:03, 12 авг 2016
Andrey
> Практически никаких 🙂
Ну да, никаких Tesla в природе не существует. У CUDA R&D поддержка в разы больше, чем у AMD.
> Для будущего я бы выбрал OpenCL поддержка всех видеокарт в отличие от nVidia
> это больший плюс.
CL не только для GPU может быть
#4
12:06, 12 авг 2016
Andrey
> рвет
#5
14:06, 12 авг 2016
CUDA не может компилировать исходники в рантайме, может что-то и добавили, но весьма геморно.
OpenCL не поддерживает перегрузку функций и этот жуткий синтаксис кастов: convert_float, convert_int2 и тд.
Это мои основные претензии, у CUDA вроде с отладкой получше, с интеграцией с GL, с поддержкой фич в отличие от OpenCL на nVidia, но я выбрал OpenCL.
Кстати, OpenCL программы компилируются заметно дольше чем GLSL, возможно они лучше оптимизируются, либо так медленно перегоняются в CUDA ))
#6
21:18, 12 авг 2016
innuendo
> У CUDA R&D поддержка в разы больше, чем у AMD.
неа. У АМД Никак не меньше, и дальше еще будет лучше.
/A\
> OpenCL программы компилируются заметно дольше чем GLSL, возможно они лучше оптимизируются
про оптмизацию врядли, А насчет времени компиляции, то тут предположительно сложность шейдеров иная.
#7
22:11, 12 авг 2016
Andrey
> неа. У АМД Никак не меньше, и дальше еще будет лучше.
У них есть аналог Tesla ?
Напомни, что лично ты делал на compute shaders ?
#8
22:34, 12 авг 2016
Кимпиляция в рантайме это минус для удобства разработки.
В датацентрах сплошная нвидиа.
Вижу что CUDA как технология лучше, думаю спорить никто не будет.
Интересны ее килер фичи.
#9
22:50, 12 авг 2016
Ты что делать хочешь ? Лучше знать оба
#10
23:22, 12 авг 2016
Я вроде слышал, что CUDA быстрее, чем OpenGL и всякие вычислительные кластеры с GPGPU делают с NVidia’вскими карточками.
Но меня возмущает то, что она совместима только с одной IDE, причём её старой версии. Из-за этого я принципиально не буду использовать CUDA без крайней необходимости. Можно конечно наверное и из консоли, но не хочу так красноглазить. На винде это слишком неудобно.
#11
1:49, 13 авг 2016
innuendo
>>Ты что делать хочешь ?
Image processing на сервере
>>Лучше знать оба
Нет смысла знать даже один, главное знать как железка устроена и писать удобно код.
#12
18:38, 13 авг 2016
Arxon
> > > что делать хочешь ?
> Image processing на сервере
Любое железо или только Nvidia ?
Andrey
> про оптмизацию врядли, А насчет времени компиляции, то тут предположительно
> сложность шейдеров иная.
Напомни, что лично ты делал на compute shaders ?
#13
21:34, 13 авг 2016
innuendo
>>Любое железо или только Nvidia ?
Скорее всего нвидиа будет, на амазоне другого нету
Но не в сервере дело, дело в моем личном удобстве при разработке, так как пока нефига не работает расчет и чтоб проверять различные гипотезы не хочется ждать многие минуты. Сейчас не до оптимизаций, брутфорс бы немного скрасил процесс.
Забегая вперед. Есть ли у CUDA движения в сторону Inter Process Communication, всякие темы с шарингом памяти, семфорами?
Копирование туда сюда не впечатляет. Для текущей задачи это совсем не нужно, просто интересно как быстро к гомогенной архитектуре движутся.
#14
10:50, 16 авг 2016
Arxon
> Забегая вперед. Есть ли у CUDA движения в сторону Inter Process Communication,
> всякие темы с шарингом памяти, семфорами?
Ты рамсы попутал? Какие к черту семафоры? На ГПУ используюися барьеры памяти.
Лично я пишу на OpenCl + CodeXL, т.к. на студии уже давно не программирую. В CUDA есть только один плюс — интеграция в студию, где есть встроенный отладчик gpu
OpenCL. Что это такое и зачем он нужен? (если есть CUDA)
Многие, наверное, слышали или читали на хабре об OpenCL – новом стандарте для разработки приложений для гетерогенных систем. Именно так, это не стандарт для разработки приложений для GPU, как многие считают, OpenCL изначально задумывался как нечто большее: единый стандарт для написания приложений, которые должны исполняться в системе, где установлены различные по архитектуре процессоры, ускорители и платы расширения.
Предпосылки появления OpenCL
Основным местом, где можно встретить гетерогенные системы, являются высокопроизводительные вычисления: от моделирования физических процессов в пограничном слое до кодирования видео и рендеринга трехмерных сцен. Раньше подобные задачи решали применяя суперкомпьютеры либо очень мощные настольные системы. С появлением технологий NVidia CUDA/AMD Stream стало возможным относительно просто писать программы, использующие вычислительные возможности GPU.
Стоит отметить, что подобные программы создавались и раньше, но именно NVidiaа CUDA обеспечила рост популярности GPGPU за счет облегчения процесса создания GPGPU приложений. Первые GPGPU приложения в качестве ядер (kernel в CUDA и OpenCL) использовали шейдеры, а данные запаковывались в текстуры. Таким образом необходимо было быть хорошо знакомым OpenGL или DirectX. Чуть позже появился язык Brook, который немного упрощал жизнь программиста (на основе этого языка создавалась AMD Stream (в ней используется Brook+) ).
CUDA стала набирать обороты, а между тем (а точнее несколько ранее) в кузнице, расположенной глубоко под землей, у подножия горы Фуджи (Fuji), японскими инженерами был выкован процессор всевластия Cell (родился он в сотрудничестве IBM, Sony и Toshiba). В настоящее время Cell используется во всех суперкомпьютерах, поставляемых IBM, на его основе постоены самые производительные в мире суперкомпьютеры (по данным top500). Чуть менее года назад компания Toshiba объявила о выпуске платы расширения SpursEngine для PC для ускорения декодирования видео и прочих ресурсоемких операций, используя вычислительные блоки (SPE), разработанные для Cell. В википедии есть статья, в кратце описывающая SpursEngine и его отличия от Cell.
Примерно в то же время (около года назад) оживилась и S3 Graphics (на самом деле VIA), представив на суд общественности свой новый графический адаптер S3 Graphics Chrome 500. По заявлениям самой компании этот адаптер так же умеет ускорять всяческие вычисления. В комплекте с ним поставляется программный продукт (графический редактор), который использует все прелести такого ускорения. Описание технологии на сайте производителя.
Итак, что мы имеем: машина, на которой проводятся вычисления может содержать процессоры x86, x86-64, Itanium, SpursEngine (Cell), NVidia GPU, AMD GPU, VIA (S3 Graphics) GPU. Для каждого из этих типов процессов существует свой SDK (ну кроме разве что VIA), свой язык программирования и программная модель. То есть если Вы захотите чтобы ваш движок рендеринга или программа расчета нагрузок на крыло боинга 787 работала на простой рабочей станции, суперкомпьютере BlueGene, или компьютере оборудованном двумя ускорителями NVidia Tesla – Вам будет необходимо переписывать достаточно большую часть программы, так как каждая из платформ в силу своей архитектуры имеет набор жестких ограничений.
Так как программисты – народ ленивый, и не хотят писать одно и то же для 5 различных платформ с учетом всех особенностей и учиться использовать разные программные средства и модели, а заказчики – народ жадный и не хотят платить за программу для каждой платформы как за отдельный продукт и оплачивать курсы обучения для программистов, было решено создать некий единый стандарт для программ, исполняющихся в гетерогенной среде. Это означает, что программа, вообще говоря, должна быть способна исполняться на компьютере, в котором установлены одновременно GPU NVidia и AMD, Toshiba SpursEngine итд.
Решение проблемы
Для разработки открытого стандарта решили привлечь людей, у которых уже есть опыт (весьма успешный) в разработке подобного стандарта: Khronos Group, на чьей совести уже OpenGL и OpenML и еще много всего. OpenCL является торговой маркой Apple Inc., как сказано на сайте Khronos Group: «OpenCL is a trademark of Apple Inc., and is used under license by Khronos. The OpenCL logo and guidelines for its usage in association with Conformant products can be found here:
http://developer.apple.com/softwarelicensing/agreements/opencl.html». В разработке (и финансировании, конечно же), кроме Apple, участвовали такие воротилы IT как AMD, IBM, Activision Blizzard, Intel, NVidia итд. (полный список тут).
Компания NVidia особо не афишировала свое участие в проекте, и быстрыми темпами наращивала функциональность и производительность CUDA. Тем временем несколько ведущих инженеров NVidia участвовали в создании OpenCL. Вероятно, именно участие NVidia в большой мере определило синтаксическую и идеологическую схожесть OpenCL и CUDA. Впрочем программисты от этого только выиграли – проще будет перейти от CUDA к OpenCL при необходимости.
Первая версия стандарта была опубликована в конце 2008 года и с тех пор уже успела претерпеть несколько ревизий.
Почти сразу после того как стандарт был опубликован, компания NVidia заявила что поддержка OpenCL не составит никакой сложности для нее и в скором времени будет реализована в рамках GPU Computing SDK поверх CUDA Driver API. Ничего подобного от главного конкурента NVidia – AMD слышно не было.
Драйвер для OpenCL был выпущен NVidia и прошел проверку на совместимость со стандартом, но все еще доступен только для ограниченного круга людей – зарегистрированных разработчиков (заявку на регистрацию подать может любой желающий, в моем случае рассмотрение заняло 2 недели, после чего по почте пришло приглашение). Ограничения доступа к SDK и драйверам заставляют задуматься о том, что на данный момент существуют какие-то проблемы или ошибки, которые пока не удается исправить, то есть продукт все еще находится в стадии бета-тестирования.
Реализация OpenCL для NVidia была достаточно легкой задачей, так как основные идеи сходны: и CUDA и OpenCL – некоторые расширения языка С, со сходным синтаксисом, использующие одинаковую программную модель в качестве основной: Data Parallel (SIMD), так же OpenCL поддерживает Task Parallel programming model – модель, когда одновременно могут выполняться различные kernel (work-group содержит один элемент). О схожести двух технологий говорит даже то что NVidia выпустила специальный документ о том как писать для CUDA так, чтобы потом легко перейти на OpenCL.
Как обстоят дела на настоящий момент
Основной проблемой реализации OpenCL от NVidia является низкая производительность по сравнению с CUDA, но с каждым новым релизом драйверов производительность OpenCL под управлением CUDA все ближе подбирается к производительности CUDA приложений. По заявлениям разработчиков такой же путь проделала и производительность самих CUDA приложений – от сравнительно невысокой на ранний версиях драйверов до впечатляющей в настоящее время.
А что же делала в этот момент AMD? Ведь именно AMD (как сторонник открытых стандартов – закрытый PhysX vs. открытый Havoc; дорогой Intel Thread Profiler vs. бесплатный AMD CodeAnalyst) делала большие ставки на новую технологию, учитывая что AMD Stream не удавалось хоть сколь-нибудь соревноваться в популярности с NVidia CUDA – виною тому отставание Stream от CUDA в техническом плане.
Летом 2009 года компания AMD сделала заявление о поддержке и соответствии стандарту OpenCL в новой версии Stream SDK. На деле же оказалось, что поддержка была реализована только для CPU. Да, именно так, это ничему не противоречит – OpenCL стандарт для гетерогенных систем и ничего не мешает Вам запустить kernel на CPU, более того – это очень удобно в случае если в системе нет другого OpenCL устройства. В таком случае программа будет продолжать работать, только медленнее. Или же вы можете задействовать все вычислительные мощности, которые есть в компьютере – как GPU так и CPU, хотя на практике это не имеет особого смысла, так как время исполнения kernel’ов которые исполняются на CPU будет намного больше тех что исполняются на GPU – скорость процессора станет узким местом. Зато для отладки приложений это более чем удобно.
Поддержка OpenCL для графических адаптеров AMD так же не заставила себя долго ждать – по последним сообщениям компании версия для графических чипов сейчас находится на стадии подтверждения соответствия спецификациям стандарта. После чего она станет доступна всем желающим.
Так как OpenCL должен работать поверх некоторой специфической для железа оболочки, а значит для того чтобы можно этот стандарт действительно стал единым для различных гетерогенных систем – надо чтобы соответствующие оболочки (драйверы) были выпущены и для IBM Cell и для Intel Larrabie. Пока от этих гигантов IT ничего не слышно, таким образом OpenCL остается еще одним средством разработки для GPU на ряду с CUDA, Stream и DirectX Compute.
- OpenTK — библиотека-обертка над OpenGL, OpenAL и OpenCL для .Net.
- PyOpenCL – обертка над OpenCL для Pyton.
- Java обертка для OpenCL.
Заключение
Технология OpenCL представляет интерес для различных компания IT сферы – от разработчиков игр до производителей чипов, а это означает что у нее большие шансы стать фактическим стандартом для разработки высокопроизводительных вычислений, отобрав этот титул у главенствующей в этом секторе CUDA.
В будущем я планирую более подробную статью о самом OpenCL, описывающую что из себя представляет эта технология, ее особенности, достоинства и недостатки.
Спасибо за внимание.
Что лучше OpenCl (AMD) или CUDA (Nvidia) для рендеринга и обработки видео?
Собрал себе домой новый комп (i7-4770, 32gb ram), но вот видюху пока не купил, не подобрал. Комп планируется использовать для:
— Photoshop (ускоряется через OpenCL, но тут и CPU скорее всего хватит)
— After Effects (ускоряется CUDA для raytracing рендера, не понял, ускоряются ли эффекты/фильтры)
— Cinema 4d (встроенный рендер только CPU, сторонние, которые прикручиваются к C4D есть как OpenCl, так и CUDA, с конкретным рендером не определился еще)
— e-on Vue (только CPU, но вдруг кто знает чего-то про GPU рендер для него)
На видюху у меня осталось около 13т.р. (можно чуть больше). Хочется найти наиболее универсальное решение не только для вышеописанных приложений, но и родственных, н-р, Premiere Pro (вроде бы OpenCl его ускоряет лучше), для других 3d. Мало ли что поменяется.
Nvidia вроде как универсальнее, есть и CUDA и OpenCL. Но, насколько я нагуглил, OpenCl на Nvidia сильно сливает AMD.
Хотя, где-то мне попадалось что это из-за недостаточно оптимизированного драйвера/компилятора. Можно ли надеяться что в будущем OpenCL на Nvidia будет лучше? Еще вычитал что для рендера на видюхе необходимо чтобы вся сцена влезла в ее память, поэтому надо чтобы памяти было не меньше 4 ГБ. Карточки от AMD при таком условии получаются подешевле.
Что посоветуете?
Спасибо!
- Вопрос задан более трёх лет назад
- 24290 просмотров
OpenCL vs CUDA
каково нынешнее состояние OpenCL? нередко встречаю мнение что OpenCL не готов для широкого применения, т.к. все реализации пока что глючные на большей части железа поддерживающего OpenCL.
легко ли портировать код CUDA на OpenCL?
vasaka ★★★
30.03.11 23:03:15 MSK
PayableOnDeath ★
( 30.03.11 23:16:45 MSK )
Если cuda используется по максимумому — плюсы, шаблоны и прочие удобства, то портировать будет достаточно гиморно, ибо на opencl как минимум в два раза больше кода потребуется.
А зачем тебе opencl ? Пиши на cuda. В ней и отлаживаться проще и она существенно вылизанней.
Reset ★★★★★
( 31.03.11 10:21:55 MSK )
Ответ на: комментарий от Reset 31.03.11 10:21:55 MSK
на opencl как минимум в два раза больше кода потребуется.
Судя по простеньким примерам, не в два, а чуть ли не на порядок. Если простейшие функции, в CUDA занимающие 2-3 строки, в openCL’е раздуваются чуть ли не до страницы кода.
Eddy_Em ☆☆☆☆☆
( 31.03.11 10:23:47 MSK )
Ответ на: комментарий от Reset 31.03.11 10:21:55 MSK
>А зачем тебе opencl ?
я собственно и пытаюсь выяснить нужен ли мне OpenCL
vasaka ★★★
( 31.03.11 11:12:23 MSK ) автор топика
Ответ на: комментарий от Reset 31.03.11 10:21:55 MSK
А зачем vendor-lock?
Chaser_Andrey ★★★★★
( 31.03.11 11:15:31 MSK )
Ответ на: комментарий от Chaser_Andrey 31.03.11 11:15:31 MSK
Тебе шашечки или ехать?
Reset ★★★★★
( 31.03.11 11:16:18 MSK )
Ответ на: комментарий от Reset 31.03.11 11:16:18 MSK
Ехать. И не только на видеокартах NVidia.
Chaser_Andrey ★★★★★
( 31.03.11 11:18:54 MSK )
Ответ на: комментарий от Chaser_Andrey 31.03.11 11:18:54 MSK
На видеокартах отличных от nvidia ехать пока нельзя
Reset ★★★★★
( 31.03.11 11:21:01 MSK )
Ответ на: комментарий от Reset 31.03.11 11:21:01 MSK
ЩИТО? OpenCL уже давно поддерживается ATI.
Chaser_Andrey ★★★★★
( 31.03.11 11:25:34 MSK )
Ответ на: комментарий от Chaser_Andrey 31.03.11 11:25:34 MSK
Ну и? Работает оно медленно.
Reset ★★★★★
( 31.03.11 11:26:18 MSK )
Ответ на: комментарий от Reset 31.03.11 11:26:18 MSK
Под родной мак вроде нормально. Есть надежда
namezys ★★★★
( 31.03.11 11:27:05 MSK )
Ответ на: комментарий от Reset 31.03.11 11:26:18 MSK
Медленно работает на ATI или медленно работает OpenCL в целом?
Chaser_Andrey ★★★★★
( 31.03.11 11:27:56 MSK )
Ответ на: комментарий от Reset 31.03.11 10:21:55 MSK
> А зачем тебе opencl ?
Кросплатформенность. libopencl есть и на nvidia, и на ati.
ZenitharChampion ★★★★★
( 31.03.11 11:29:48 MSK )
Ответ на: комментарий от Chaser_Andrey 31.03.11 11:27:56 MSK
Reset ★★★★★
( 31.03.11 11:36:25 MSK )
Ответ на: комментарий от ZenitharChampion 31.03.11 11:29:48 MSK
а через ocelop, говорят, CUDA код можно запустить на ATI.
vasaka ★★★
( 31.03.11 11:41:13 MSK ) автор топика
Ответ на: комментарий от vasaka 31.03.11 11:41:13 MSK
vasaka ★★★
( 31.03.11 11:42:31 MSK ) автор топика
Ответ на: комментарий от vasaka 31.03.11 11:41:13 MSK
Стопудово делали русские, которые смотрели Кид-дза-дза (эцелопы). Спасибо за информацию.
ZenitharChampion ★★★★★
( 31.03.11 11:44:40 MSK )
Ответ на: комментарий от ZenitharChampion 31.03.11 11:44:40 MSK
да я перепутал, это кошка такая, ocelot, коментом выше ссылка.
vasaka ★★★
( 31.03.11 11:49:41 MSK ) автор топика
Ответ на: комментарий от Reset 31.03.11 11:36:25 MSK
По крайней мере, оно хоть как-то работает на ATI, в отличии от CUDA.
Chaser_Andrey ★★★★★
( 31.03.11 11:59:37 MSK )
Ответ на: комментарий от Reset 31.03.11 11:36:25 MSK
Ну так они когда-нибудь поправят, зато проект заранее будет кроссплатформенным (в смысле карт) и в будущем не надо будет его переписывать.
Впрочем, это зависит от целей автора. Если ему надо прямо сейчас и очень быстро, то CUDA.
anonymous
( 31.03.11 12:31:47 MSK )
Ответ на: комментарий от vasaka 31.03.11 11:49:41 MSK
Ага, не перепутал ты, у меня ассоциация просто. Внизу есть список лучших пожертвовавших и все нерусские, так что моё предположение не верно.
ZenitharChampion ★★★★★
( 31.03.11 12:33:20 MSK )
Как раз еду с конференции, где этот вопрос освещался. Большинство использует все-таки CUDA, но был один докладчик, который сравнивал производительность cuda и opencl на карточках nvidia, получил сравнимые результаты и остановился на opencl, так как ему нужна была переносимость.
Да, и кстати, я спрашивал сотрудников AMD, они говорят что CUDA жить осталось не долго, а вот за opencl наоборот светлое будущее 😉
lukash ★
( 31.03.11 22:31:29 MSK )
Ответ на: комментарий от lukash 31.03.11 22:31:29 MSK
Да, и кстати, я спрашивал сотрудников AMD, они говорят что CUDA жить осталось не долго, а вот за opencl наоборот светлое будущее 😉
Я сильно удивился, если бы сотрудники AMD сказали что-то другое 🙂
Reset ★★★★★
( 01.04.11 19:07:52 MSK )
OpenCL на ATI не безглючен, но писать уже вполне можно. При этом хорошо бы сначала определиться с устройством, для которого пишется код, и от этого идти. Потому что для разных устройств разные одни и те же «оптимизации» могут дать противоположный результат.
tim239 ★★
( 02.04.11 00:42:43 MSK )
Ответ на: комментарий от lukash 31.03.11 22:31:29 MSK
осталось дождаться, когда они запилят рабочие дрова для видюшек
TERRANZ ★★★★
( 02.04.11 00:50:28 MSK )
Ответ на: комментарий от tim239 02.04.11 00:42:43 MSK
вот определиться с железом — это не выйдет, код пишется на широкую аудиторию, и предсказать какое у них будет железо нереально.
vasaka ★★★
( 02.04.11 01:17:27 MSK ) автор топика
Ответ на: комментарий от vasaka 02.04.11 01:17:27 MSK
но бонусом является то что топовая производительность не нужна, просто вывести некоторые длинные операции на real-time.
vasaka ★★★
( 02.04.11 01:31:55 MSK ) автор топика
Ответ на: комментарий от vasaka 02.04.11 01:17:27 MSK
Тогда OpenCL — в крайнем случае на процессоре запустится.
tim239 ★★
( 02.04.11 01:38:11 MSK )
Предыдущая работа была связана с вычислениями на видеокарте. Использовали OpenCL. Впечатление хорошее, нужно быть чуть более Ъ чем на CUDA, но в целом и CUDA тоже не настолько торт чтобы ее превозносить. Особенно «радует» на CUDA дебаг на видеокарте, о котором так громко орут. Для него нужно два компа с двума видяхами и студия с не менее анальным плагином. Это надо соеденить и потом дебагать. Короче цирк.
В CUDA пошире синтаксис будет, зато нужно компилять файлы. В OpenCL это делается в рантайме путем передавания строк в функцию (OpenGL way). Работают приблизительно на одинаковой скорости. Зато OpenCL работает на ATI, которая проигрывает NVidia в работе с памятью и на такого рода тестах сливает реально жирно. Зато ATI хорошо оптимизирует длинные математические формулы. У них в доках есть набор выражений, которые будут преобразованы в одну инструкцию. Если их юзаешь, то помогаешь видеодрайверу. Но все же на реальных задачах ATI конечно в жопе. Мы даже меряли карточки подороже чем аналоги на Nvidia. Все равно сливают. Но вообще код таки очень интенсивно работал с памятью.
Эмулировать на проце OpenCL умеет только ATI или Apple с любой видяхой. Строка платформы например на винде пишет конкретную вендоровскую платформу, например CUDA, а на Apple пишет Apple. Тоесть там общая прослойка и переключается на проц. Но не льстите себе что все так прекрасно на проц ляжет. Если у вас код хоть как-то специфичен к всяким железным вещам типо общей памяти или количества аппаратных потоков, то не удивляйтесь если вы не догадаетесь протестировать его при отсутсвии у устройства общей памяти или присутсвии всего одной нити. А это проц.
Не смотря на то что синтаксис кроссплатформенный, но не все девелоперы читали спеки и вы можете написать код, который работает у вас. Но тестировать нужно на очень разном железе, косяки всплывут точно. Я вон код с Apple к себе на Gentoo получил разок, так час потратил на то, что там платформу нельзя указывать null. А на Apple если null, то берет дефолтную. На Линуксе же на CUDA отправляет лесом.
Еще прикол. Видесистема вырубает по дефолту ядро, которое работает слишком долго. Борьба с зависаниями. Но слишком долго — это около 10 сек. И теперь внимание, барабанная дробь, как это лечится. В винде — ключик реестра, который нужно очень долго гуглить. В линуксе — работой без иксов и все, уже лучше. Пальма первенства передается Apple — не лечится! )