Запуск OpenCL на оборудовании разных поставщиков

Я играл с реализацией ATI OpenCL в их бета-версии Stream 2.0. OpenCL в текущей бета-версии пока использует только ЦП, предполагается, что следующая версия будет поддерживать ядра графического процессора. Я скачал Stream, потому что на моей рабочей машине стоит графический процессор ATI.

Я пишу программное обеспечение, которое получит огромную выгоду от использования графического процессора. Однако это программное обеспечение работает на клиентских компьютерах, и я не могу позволить себе роскошь (как многие среды научных вычислений) выбирать конкретное оборудование для разработки и оптимизации для него. Итак, мой вопрос: если я распространяю реализацию ATI OpenCL со своим приложением, будет ли это означать, что оно никогда не сможет использовать, например. Видеокарты NVidia? И если я использую SDK NVidia OpenCL, он никогда не будет оптимально работать на чипах AMD (учитывая связь ATI/AMD)?

Другими словами, кто, в конце концов, отвечает за реализацию OpenCL? Смогут ли пользователи, например. установить «драйвер» OpenCL для своей видеокарты NVidia вместе с «драйвером», который обеспечивает оптимальную производительность на их процессоре AMD?

Кроме того, есть ли хорошие / активные форумы поддержки OpenCL, кроме досок сообщений Khronos, или это то место, куда можно пойти? Я видел, что у ATI есть плата, и у NVidia, предположительно, есть своя, где тусуется сообщество пользователей/разработчиков OpenCL? Он уже объединился в одном месте?


person Roel    schedule 07.09.2009    source источник


Ответы (2)


В конечном итоге OpenCL будет работать так же, как OpenGL. То есть пользователи будут устанавливать текущие драйверы от своих поставщиков оборудования (ATI, NVIDIA, Intel). Вы, как разработчик, будете просто связываться с библиотекой OpenCL при создании своих приложений. Когда пользователи запускают ваше приложение, оно будет перенаправляться на соответствующие библиотеки конкретных поставщиков, предоставляемые драйверами.

Вот как это будет работать, но это пока не работает таким образом.

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

person Eric    schedule 07.09.2009
comment
Разница с OpenGL заключается в том, что для OpenGL поставщик графического процессора пишет драйверы - и точка. OpenGL работает только на видеокарте. Но для OpenCL в идеале поставщик ЦП пишет драйвер для ядер ЦП, а поставщик ГП пишет драйверы для ядер ГП, поскольку ядра OpenCL могут работать в потоках ЦП или потоках ГП. Так ли это должно работать в будущем? - person Roel; 07.09.2009
comment
OpenGL всегда поддерживает программный путь, когда аппаратное обеспечение не поддерживает определенные операции. Таким образом, поставщики ОС должны предоставлять программную реализацию OpenGL (OpenGL для MS Windows застрял на OpenGL 1.1). Нечто подобное, вероятно, произойдет и с OpenCL. В любом случае AMD/ATI, скорее всего, выпустит версию OpenCL, которая будет поддерживать как их процессоры, так и их графические процессоры. Точно так же Intel, скорее всего, выпустит OpenCL, поддерживающий обычные процессоры и графические процессоры Larrabee. Я недостаточно знаю о реализации Apple OpenCL, чтобы знать, что она поддерживает. - person Eric; 07.09.2009
comment
Итак, могу ли я сделать вывод, что если у клиента есть видеокарта ATI и процессор Intel, у них не будет оптимальной производительности? Что, в зависимости от того, какой драйвер/реализация OpenCL они установили, они будут запускать ядра либо на процессоре, либо на графическом процессоре? Я имею в виду, что я знаю, что он, вероятно, запустится на машине, это не моя забота; меня беспокоит, будет ли он работать быстро (поэтому с использованием всего оборудования на машине, всех ядер ЦП и всех «ядер» графического процессора). - person Roel; 07.09.2009
comment
Короткий ответ: пока рано говорить, особенно в сценариях с разными поставщиками. Кроме того, между использованием всего оборудования и оптимальным использованием всего оборудования может быть разница в несколько порядков. Удовлетворение архитектуры памяти и оптимального размера рабочей группы на разных платформах будет иметь решающее значение для получения максимальной производительности вашего приложения. Даже если вы ориентируетесь только на процессоры и графические процессоры AMD, вам, вероятно, потребуется настроить параметры ядра для каждого из них, чтобы получить максимальную производительность. - person Eric; 07.09.2009
comment
Кроме того, я думаю, что вы преждевременно оптимизируете сейчас. OpenCL — это путь в будущее, если вам нужны кроссплатформенные высокопроизводительные вычисления. Сосредоточьтесь на изучении деталей сейчас и оптимизации для вашей текущей платформы. Позже вы можете беспокоиться о нескольких поставщиках/платформах. - person Eric; 07.09.2009
comment
Ну тут я с тобой не согласен. Если мне нужно подождать еще год или два, прежде чем драйверы появятся в Windows (единственная платформа, которая меня волнует), и в то же время я не могу рассчитывать на производительность на всех (или большинстве) процессорах и графических процессорах, мне лучше разрабатывать напрямую для CUDA и говорю своим клиентам, что «это будет работать быстро только с картой nVidia». CUDA более зрелая, чем OpenCL, лучшие инструменты, оптимизированные для одной аппаратной платформы. Единственная причина выбрать OpenCL сейчас — это поддержка аппаратного обеспечения разных производителей. Если это ненадежно, большая часть преимуществ OpenCL (для меня) исчезла. В любом случае, спасибо за ваши идеи. - person Roel; 07.09.2009
comment
Я думаю, вы упускаете из виду то, что я пытаюсь донести. Даже когда OpenCL является кросс-платформенным, вам все равно придется выполнять множество пользовательских разработок. Лучше всего начать эту разработку сейчас на какой-нибудь платформе, на которой она может оптимально работать в то же время. Если вы выберете CUDA, которая является хорошей платформой, и планируете позже перейти на поддержку карт ATI, то я рекомендую использовать низкоуровневый Driver API, так как он ближе к OpenCL API. - person Eric; 08.09.2009
comment
Я думаю, что мы спорим о разных случаях здесь. Я понимаю, что для получения /оптимальной/ производительности от OpenCL мне нужно было бы настроить для разных ядер - GPU, ЦП, конкретных поставщиков, ... Причина, по которой я сначала рассматриваю OpenCL (по сравнению с CUDA или Stream или другими специфичными для поставщика API) потому, что это позволило бы мне писать распараллеленный код, который будет работать на всех графических процессорах и всех ядрах ЦП, т. е. с максимальным параллелизмом. (Я согласен с тем, что мой более ранний комментарий об «оптимальной производительности» был преувеличением, я имел в виду «базовый параллелизм, поскольку это даст моему конкретному варианту использования значительный прирост скорости»). - person Roel; 08.09.2009
comment
(дурацкий предел в 600 символов) Но, если OpenCL не даст мне даже базового параллелизма в тех случаях, когда у клиентов есть комбинации GPU/CPU от разных поставщиков, то мне, возможно, лучше отказаться от универсального подхода и выбрать «одного поставщика». (например, нвидиа). Если я это сделаю, я смогу по крайней мере действительно оптимизировать для этой платформы (если я выберу OpenCL, я не буду писать собственные ядра для каждого поколения графических процессоров — мне придется довольствоваться одним «достаточно хорошим» подходом из-за времени). ограничения бюджета). - person Roel; 08.09.2009
comment
В конце концов, это проблема оптимизации, и большинство переменных я даже не могу измерить (сколько моих клиентов будут использовать комбинации ЦП и ГП разных поставщиков? Как изменится качество реализации OpenCL? Сколько времени я потрачу на это). об оптимизации моего кода для чипсетов CUDA и т. д.). Я просто говорю, что вопрос «OpenCL/CUDA/Stream» не является четким выбором, как если бы OpenCL в будущем мог оптимально использовать все оборудование, независимо от поставщика. - person Roel; 08.09.2009
comment
Лучше бы ты написал ответ, чем комментарий. - person whatnick; 26.09.2009

Я знаю, что это старый вопрос со старыми ответами выше. Думал, что обновлю его с актуальным ответом.

Да, одна реализация ядер и кода OpenCL будет работать на самых разных устройствах сегодня с правильно написанным кодом перечисления платформ и устройств. Написать правильный код перечисления платформ и устройств довольно легко, сложная часть заключается в выборе платформы или устройства. Вероятно, вам следует предоставить параметр конфигурации в своем приложении, где пользователь может выбрать один из них, или запустить микротест для каждого из них, динамически выбрать один и кэшировать результат тестирования.

Люди могут и будут иметь более одной платформы. Например, в моей системе есть GTX 580 SLI, поэтому в ней два устройства на платформе NVidia. Он также имеет Intel OpenCL SDK, поэтому мой процессор CoreI7 990x Extreme также подходит как устройство на платформе Intel.

Да, двоичный файл, разработанный и собранный с использованием, например, NVidia OpenCL SDK, будет работать на ATI или Intel OpenCL и наоборот. Больше не нужно беспокоиться об этом.

Очевидно, что у конечного пользователя может вообще не быть OpenCL, поэтому вам может потребоваться отложенная загрузка или загрузка библиотеки opencl.dll и динамическая ссылка.

Я настоятельно рекомендую протестировать ваш код на Intel OpenCL SDK, на графических процессорах NVidia и на графических процессорах AMD. Вы, вероятно, найдете ошибки, которые вызывают проблемы на одной платформе, но отлично работают на других. Вы также, вероятно, обнаружите, что совершенно прекрасный код таинственным образом не дает правильных результатов на одной из этих платформ из-за ошибок драйвера.

person doug65536    schedule 10.03.2012
comment
Спасибо за это, я писал новый вопрос, чтобы узнать, изменилось ли что-то с момента первого ответа... - person Mikarnage; 10.01.2013