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.

    Apple также заявляет о поддержке OpenCL, которая, впрочем, обеспечивается за счет NVidia CUDA.
    Также в настоящее время сторонними разработчиками предлагается:
    • OpenTK — библиотека-обертка над OpenGL, OpenAL и OpenCL для .Net.
    • PyOpenCL – обертка над OpenCL для Pyton.
    • Java обертка для OpenCL.


    Заключение


    Технология OpenCL представляет интерес для различных компания IT сферы – от разработчиков игр до производителей чипов, а это означает что у нее большие шансы стать фактическим стандартом для разработки высокопроизводительных вычислений, отобрав этот титул у главенствующей в этом секторе CUDA.

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

    Интересные ссылки:


    www.khronos.org/opencl — страница об OpenCL на сайте Khronos Group
    www.nvidia.com/object/cuda_opencl.html — NVidia OpenCL (внизу страницы ссылки на различные документы: OpenCL Programming Guidу итп.)
    forums.amd.com/devforum/categories.cfm?catid=390&entercat=y – форум AMD по OpenCL
    habrahabr.ru/blogs/CUDA/55566 — небольшой обзор OpenCL на хабре
    developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx — страница AMD Stream SDK v2.0 beta
    ati.amd.com/technology/streamcomputing/gpgpu_history.html — история развития GPGPU по версии AMD

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 37
    • +1
      Спасибо, избавился от некоторых ложных представлений об OpenCL и CUDA.
      • 0
        >открытый Havoc
        Если не ошибаюсь, sorce-лицензия от 50к$ и бесплатным для инди разработчиков не так давно стал, намного позже PhysX. И причем тут AMD его Intel купил.
        • +1
          Если уточнить, у AMD с Havok всё как-то затихло, и сейчас они начинают продвигать Bullet Physics, третий по популярности физический движок
          • 0
            Вы правы, на хабре даже статья по это проскакивала небольшая.
            Видимо сотрудничество с Bullet и ознаменует конец дружбы с Havok (и, возможно, виной тому как раз покупка Havok конкурентом AMD — Intel)
            • 0
              Думаю, дело не в покупке, так как разговоры о сотрудничестве шли и после, а просто в бездействии Intel. Т.е. на словах всё хорошо, «давайте сделаем», но на деле — абсолютная тишина. Хотя Intel своими силами могли бы уже к этому моменту добавить поддержку OpenCL, ресурсы у них есть.
        • +3
          Моя софтина под OpenCL всего процентов на 5 медленнее оной же под CUDA.
          Так что все не так плохо :-)
          • 0
            Наверно, потому что у тебя OpenCL собрана поверх CUDA, возможно на других платформах твоя OpenCL софтина будет даже быстрее. (если конечно будет с чем сравнивать)
          • 0
            Хорошая статья. Буду давать знакомым — а то часто бывают совершенно ошибочные представления об OpenCL (например — это только для игр).
            • 0
              Спасибо, очень приятно, что первая статья вызывает одобрение читателей.
            • +2
              Поправьте опечатки, плз.

              > Пре_д_посылки появления OpenCL

              > в силу своей архитектуры имеет набор жестких....?
              • 0
                исправил, спасибо.
              • 0
                Отличная обзорная статья!
                • 0
                  Спасибо, отличная статья, все просто и понятно. Надеюсь на продолжение.
                  • 0
                    У меня к этому времени сложилось мнение что CUDA и OpenCL конкурирующие технологии нвидиа и ати соответственно, а оказывается OpenCL логичное продолжение идеи CUDA и схожесть синтаксиса тоже радует. Спасибо за информацию.
                    • 0
                      То что CUDA позволит писать переносимый код — хорошо, а может кто-то на пальцах объяснить, как происходит инициализация её? Т.е. надо ли мне знать, какие девайсы воткнуты в локальный комп и инициализировать их (например, выставлять количество SPU, выбор между AMD GPU или NVidia GPU)? Или всем этим занимается библиотека?
                      • 0
                        В скором времени я напишу подробную статью о том как строится OpenCL приложение.
                        В кратце так: из кода программы Вы можете получить число устройств с поддержкой OpenCL и их характеристики, потом выбрать и проинициализировать нужное устройство (или несколько устройств) и далее работать с ним.
                        • 0
                          Т.е. можно запустить одну и ту же задачу одновременно на нескольких девайсах? В смысле, нужное количество раз проинициализировать их и запустить на них задачи, склеивая потом результаты?
                          • 0
                            По крайней мере в CUDA — можно. Нужно только под каждый девайс завести свой CPU-поток.
                            • 0
                              Дело в том, что у меня нет в наличии нет двух устройств с поддержкой OpenCL чтобы протестировать это в текущей реализации NVidia
                              Но в общем да, использование нескольких ускорителей предполагается.
                              • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            > Летом 2009 года компания AMD сделала заявление о поддержке и соответствии стандарту OpenCL в новой версии Stream SDK. На деле же оказалось, что поддержка была реализована только для CPU. Да, именно так, это ничему не противоречит – OpenCL стандарт для гетерогенных систем и ничего не мешает Вам запустить kernel на CPU, более того – это очень удобно в случае если в системе нет другого OpenCL устройства.

                            Это реальная возможность нормально использовать многоядерные процессоры.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • +1
                                Летом 2009 года компания AMD сделала заявление о поддержке и соответствии стандарту OpenCL в новой версии Stream SDK. На деле же оказалось, что поддержка была реализована только для CPU.

                                Вчера ATI выпустила версию 2.0-beta4 поддерживающую ускорение вычислений на GPU.
                                First beta release of ATI Stream SDK with OpenCL™ GPU support.
                                • 0
                                  Здорово!
                                  А тут как раз и новая серия графических чипов — hd5000 — подоспела; все складывается как нельзя лучше.
                                • 0
                                  В летней школе мфти 2009 по высокопроизводительным вычислениям была секция по cuda.
                                  Преподаватель упомянул про opencl, что она есть и все. Когда же у него спросили про opencl он ответит примерно следующее- для пользовательских приложений это хороший выход, который сможет сэкономить время разработки программ. но для Серьезных вычислений научных, всегда будет нужна сверхвысокая производительность. по этому так как opencl должна поднять на более высокий уровень абстракции чем специфичные технологии заточенные под архитектуру, то opencl не станет равномощной узко заточенным системам таким как cuda.
                                  Хотя для не супер компьютеров это вполне подойдет
                                  • 0
                                    Ну уровень абстракции в OpenCL в общем-то не отличается от CUDA практически.
                                    Ведь OpenCL, как было упомянуто в статье, работает поверх CUDA Driver API (в случае NVidia) как и CUDA. А он, в свою очередь, работает с ускорителем, поэтому производительность OpenCL приложений может сравняться с CUDA.
                                    • +1
                                      имеется в виду что OpenCL всегда будет «наименьшим общим знаменателем» по функционалу с целью обеспечить легкость реализации на разных платформах. есть также механизм vendor-specific extensions, так что если понадобится поддерживать отдельно бранч под NVIDIA, то возвращаемся к тому, от чего бежали. Уунификация и максимальная производительность никогда не будут жить под одной крышей
                                      • 0
                                        C этим согласен, специфичные вещи легче внедрять в CUDA и тем самым обеспечивать интерес к платформе.

                                        Хотя вот есть же в Microsoft Visual C++ не описанные стандартом вещи, ну, скажем, __TRY / __CATCH / __FINALLY (кажется не напутал с количество подчеркиваний).

                                        В принципе тут ситуация могла бы развиваться по такому же пути… Не возьмусь судить, что лучше и, тем более, как оно будет в действительности, но возможность ведь есть?
                                      • 0
                                        cuda- частный пример. можно ли написать что бы на всех архитектурах работал opencl так же быстро как и на заточенной под архитектуру технология!?
                                        если честно мне кажется, что путь будет такой же как у языков высокого уровня в сравнении с ассемблером. скорость написания выше, но использовать на всю мощь архитектурные особенности тяжело.
                                        • 0
                                          Дело в том, что как язык — CUDA — это расширени С. Так же как OpenCL, в этом они схожи очень сильно, ведь Вы не пишите CUDA-приложения на ассемблерном коде GPU, за Вас это делает nvcc — специальный компилятор, а Вы решаете сколько хотите использовать ресурсов, как доступаться к памяти, в какой памяти размещать данные. Точно так же и с OpenCL, Вам прийдется делать все то же самое, в этом плане — это не язык высокого уровня.
                                          • 0
                                            Как выглядит cuda я знаю. Чуть чуть даже писал. Но то что язык СИ подобный еще ничего не говорит! Есть особенность архитектуры. К примеру есть разница в уровнях памяти систем на которых считаем. Есть разница в скорости доступа к этой памяти. На школе мфти летом нам показывали как сильно может меняться скорость работы программы от размещения данных в памяти.работали мы как раз с cuda.Когда у нас все было в общей памяти видеокарты(dram) это было одно время выполнения, когда было размещено в shared памяти это на порядок быстрее было. Есть еще много примеров архитектурных особенностей.
                                            И тот факт, что это все СИ подобно на архитектуру ну не как не влияет. А сможет ли opencl оптимизировать программу лучше программиста причем для всех возможных платформ...? Я конечно верю в, то что закодить можно все, но не до такой же степени.
                                            • 0
                                              Точно так же и с OpenCL, Вам прийдется делать все то же самое, в этом плане — это не язык высокого уровня

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

                                              OpenCL не предоставляет какой-то более высокий уровень абстракции, на котором все (или многое) будет делаться за программиста, нет, не будет. OpenCL ничего не оптимизирует (точнее компилятор оптимизирует кое-что, но не более чем nvcc в CUDA)

                                              Я сейчас пишу статью, в которой постараюсь все подробно объяснить, точнее похоже выйдет даже две — одна вгубь спецификаций OpenCL, другая больше практическая — что и как писать.

                                              • 0
                                                если Вы напишете эти 2 статьи я лично буду очень благодарен вам. так как про opencl действительно хочется знать побольше, а сейчас знание и понимание не полное.

                                                Что кто то оптимизировать будет кроме меня я и не надеюсь. Я хотел сказать что оптимизировать программу под каждую платформу придется отдельно. А это значит разную производительность.
                                                • 0
                                                  Постараюсь как можно быстрее закончить работу над статьями, я и не думал что этот вопрос вызовет такой интерес.

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

                                                  То есть чтобы использовать особенности архитектуры ускорителей AMD разработчик не должен учиться пользоваться Brook+, а должен изучить особенности архитектуры этих ускорителей (без этого-то совсем никуда) и написать OpenCL приложение так, чтобы оно использовало все доступные возможности.

                                                  Точно так же как MKL (математическая библиотека Intel) использует по максимуму возможности процессоров Intel, а ACML — аналог AMD — использует особенности процессоров AMD, хотя написаны обе они, вероятно, на С++
                                    • 0
                                      «Оптимизировать да, прийдется, если есть необходимость работы на конкретном железе, но в этом случае OpenCL может обеспечивать возможность этой оптимизации в рамках себя. „

                                      вот эту фразу всегда надо выделять тогда. если не делать акцент, то наверное не один я не до конца поймут смысл технологии.

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

                                      Желаю скорейшего написания статьи.
                                      • 0
                                        Большое спасибо за статью.
                                        • 0
                                          OpenCL полностью кроссплатформенная, а CUDA только на NVIDIA продуктах будет работать. Вот и вся разница. Иногда OpenCL может работать поверх CUDA, если хотим GPGPU, а графический процессор не поддерживает OpenCL, но поддерживает CUDA. Зато на OpenCL один раз написал хитрые алгоритмы и не паришься

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